[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-mobileip-hmipv6

Mobile IP Working Group                               Claude Castelluccia
                                                      Ludovic Bellier
Internet Draft                                        INRIA, France
                                                      July 2000




                        Hierarchical Mobile IPv6
                draft-castelluccia-mobileip-hmipv6-00.txt



Status of this Memo

   This document is an Internet-Draft and is in full conformance with all
   provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering Task
   Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at:
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at:
   http://www.ietf.org/shadow.html.

   This document is an individual submission for the mobile-ip Working
   Group of the Internet Engineering Task Force (IETF).  Comments should
   be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing
   list.

   Distribution of this memo is unlimited.



Abstract

   In Mobile IPv6 a mobile node registers with its home agent and its
   correspondent hosts each time it changes care-of address.

   This draft presents a Hierarchical  Mobile IPv6 proposal that reduces



C. Castelluccia, L. Bellier      Expired January 2001            [Page 1]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


   the number of signaling messages sent by a mobile host to its home
   agent and correspondent hosts and that reduces the signaling delay.

   Our proposal relies on the deployment of Mobility Networks that
   provide flexibility and scalability.



1. Introduction

   This Internet Draft presents a Hierarchical Mobile IPv6 proposal. Our
   proposal makes full use of new IPv6 functionalities such as a large
   address space and the neighbor discovery mechanisms to propose a
   mobility management solution that is flexible, scalable and robust. As
   most of the existing hierarchical Mobile IP schemes we use anchor
   points, that we call mobility servers (MS), to deploy two levels of
   hierarchies ([2] describes how to deploy more than two levels of
   hierarchy). Each domain contains one or several mobility servers.  If
   a mobile host moves into a new domain it gets two CoA, a global one
   (GCoA) and a local one (LCoA).  If it moves within a domain, it only
   needs to change its LCoA, the GCoA remains the same. The mobile host
   registers its GCoA with its home agent and correspondent hosts and the
   binding (LCoA, GCoA) with the domain mobility server. Packets
   addressed to the mobile host's GCoA are routed to the domain,
   intercepted by the MS and encapsulated to the MH's current LCoA.  In
   contrast to existing schemes ([3], [4]), the GCoA is not the address
   of the MS but an address belonging to the MS's subnet (that we call
   Mobility network). As a result, the MS can be changed (for load
   balancing or robustness purposes) dynamically without having to change
   the GCoAs (i.e. without breaking ongoing communications) of the mobile
   hosts currently roaming  in the domain.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 3119.

   Binding Update : BU
   Border Router : BR
   Correspondent Host : CH
   Global Care-of Address : GCoA
   Home Address : H@
   Home Agent : HA
   Local Care-of Address : LCoA
   Mobile Host : MH
   Mobility Server : MS
   Mobility Network : MN



C. Castelluccia, L. Bellier      Expired January 2001            [Page 2]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


3. Protocol Overview

   Our proposal differentiates the intra-domain mobility from the inter-
   domain mobility. As a result, a host communicating with a mobile host
   is only aware of the MH's inter-domain mobility. The mobile host's
   intra-domain mobility is completely hidden. In this draft, we define a
   domain as the highest level of our hierarchical architecture. A domain
   is actually an arbitrary structure. It can be an ISP network, a campus
   network, a company network, a set of LANs or even a single LAN. A
   domain is connected to the rest of the Internet via one or several
   interconnection routers that we call Border Routers (BR).

   Our proposal is based on the deployment of Mobility Networks. A
   Mobility Network of a domain is a LAN that defines an address space
   for the mobile hosts roaming within this domain. A Mobility Network
   contains one or several Mobility Servers. A Mobility Server (MS) is a
   router of the Mobility Network that maintains a binding per mobile
   hosts currently visiting the domain. Note that there is no constraint
   on the physical location of the Mobility Network. However for
   efficiency reasons, it is  preferable to connect it to the border
   router of the network that it is serving. The mobility Network can
   actually be any sub-network of the domain. It does not have to be
   dedicated to mobile hosts but instead can support ordinary (fixed)
   hosts.

   Deploying a Mobility Server in a separate Mobility Network instead of
   implementing it on the BR, as proposed in [4], has two main
   advantages. First, it does not require any modification to the routers
   and is therefore easier to deploy. Second, it is more scalable since
   (1) it does not add additional processing constraints on the BR, (2)
   several MSs could be deployed for scalability and/or robustness
   motivations. However the MS can be implemented within the BR if this
   is desirable. This would then be very similar to the scheme proposed
   in [4].

   Note that a domain may contain more than one Mobility Networks if
   necessary. If a domain has several BRs, we suggest to deploy one
   Mobility Network per BR. Each MN is then in charge of a particular
   area of the domain.

 3.1. Inter-domain mobility

   When a mobile host enters into a new domain, it gets two CoAs: a Local
   Care-of Address (LCoA), which is a CoA on the link it is attached to,
   and a Global Care-of Address (GCoA), which is a CoA in the Mobility
   Network of the domain (note that in Mobile IPv6 only the LCoA is
   required.).




C. Castelluccia, L. Bellier      Expired January 2001            [Page 3]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


   The mobile host then sends few BUs. It sends:
      - a BU that specifies the binding between its GCoA and its LCoA to
      the domain MS.
      - a BU that specifies the binding between its home address (H@) and
      its GCoA to its HA and to its external CHs (i.e. CHs that are
      outside the domain).
      - a BU that specifies the binding between its home address (H@) and
      its LCoA to its local CHs (i.e. CHs that are within the domain).

   As a result,
      - An external host that sends packets to the mobile host uses its
      GCoA. Packets are then routed to the Mobility Network of the
      visited domain, intercepted by the Mobility Server and forwarded
      (tunneled) to the current LCoA of the MH.
      - A local host that sends packets to the mobile host uses its LCoA.
      Packets are then directly delivered to the mobile host.

 3.2. Intra-domain mobility

   When a mobile host moves within the domain, it gets a new LCoA on its
   new point-of attachment. The GCoA does not change. The mobile host
   then sends the following BUs:

      - a BU that specifies the binding between its home address and its
      new LCoA to its local CHs (i.e. CHs that are within the domain).
      - a BU that specifies the binding between its GCoA and its new LCoA
      to the domain Mobility Server.

   Note that during intra-domain mobility, no BU is sent on the Internet.
   Figures 1 and 2 illustrate the Inter-domain and Intra-domain mobility
   operations.
    Figure 3 illustrates packet delivery.

     -----    (H@,GCoA)    ----
    | CH1 |<+++++++++++++>| HA |
     -----         +       ----
        |          +      /
       ------------+------
      |            +      |
      |  Internet  +      |
      |            +      |
       ------------+------
        /          +   |
       /           +   |
     -------      -+--------------------------------
    |       |    | +   |                   domain 2
    | domain 1|    | +  ----    |
    |       |    | + | BR |---|    ----



C. Castelluccia, L. Bellier      Expired January 2001            [Page 4]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


    |       |    | +  ----    |---| MS |
    |       |    | +          |    ----<++++++++++ (LCoA1,GCoA)
    |       |    | +                             +
    |       |    | +++++++++++++++++++++++++++++++
    |       |    |        +                      +
    |       |    |  ----- + (H@,LCoA1)      ---- +
    |       |    |     |  +                   |  +
    |       |    |   -----v                  ----+
    |       |    |  | CH2 |                 | MH |
    |   *   |    |   -----                   ^---
     ----*--       --------------------------*--------
          *                                 *
          **********************************

      ******>  MH movement
      ++++++>  BU

         Figure 1 : Intra Domain Mobility





    -----                 ----
   | CH1 |               | HA |
    -----                 ----
       |                 /
    -------------------
   |                   |
   |      Internet     |
   |                   |
   -------------------
            |
            |
   -----------------------------------------
  |                    |
  |                   ----    |
  |                  | BR |---|    ----
  |                   ----    |---| MS |
  |                           |    ----
                                    ^
  |                                 +
                                    +
  |                (H@,LCoA)   ++++++
                               +
  |                       ++++++++
  |    ------       ----- +      + -----
  |      |             |  +      +  |



C. Castelluccia, L. Bellier      Expired January 2001            [Page 5]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


  |     ----         -----v      +---
  |    | MH |       | CH2 |     | MH |
  |     ----         -----       ^---
   ------*----------------------*--------
         *                     *
         **********************


      ******>  MH movement
      ++++++>  BU

         Figure 2 : Inter Domain Mobility







    -----                 ----
   | CH1 |oooooooooo     | HA |
    -----          o      ----
         |          o      /
       ------------o------
      |            o      |
      |  Internet  o      |
      |             o     |
       --------------o----
   ---------------------o-------------------
  |                    |oooooooo
  |                   ----    |o
  |                  | BR |---|ooo>----
  |                   ----    |---| MS |
  |                           |OOO ----
  |                            O
  |                            O
  |                ooooooooo   O
  |           -----o       o --O--
  |              | o       o  |O
  |            -----       v---v
  |           | CH2 |     | MH |
  |            -----       ----
   ----------------------------------------
      oooo> packets
      OOOO> encapsulated packets

         Figure 3 : Packets delivery




C. Castelluccia, L. Bellier      Expired January 2001            [Page 6]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


4. Protocol Details

 4.1 New Router Advertisement Options

      In order to register, a mobile host needs the following
      information:

         - the Mobility Server address,
         - the Mobility Network prefix length.

      This information is advertised by a new option used in the Router
      Advertisement messages of the IPv6 Neighbor Discovery. The format
      of this option, called the Mobility Information Option, is defined
      as follows:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     type      | length        |      na       |     plen      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                            MS address                         |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      - type = the type of the option (TBD).
      - length = the length of the option = 20 bytes.
      - na = not used, set to 0.
      - plen = prefix length of the Mobility Network.
      - MS address = the address of the mobility server in charged of
      this link.

         Figure 4 : Router Advertisement Mobility Information Option
         Format


      A router must be able to store the MS address and its prefix length
      to fill in an Mobility Information Option in its router
      advertisements. This information can be configured manually in each
      router or dynamically via a specific protocol.  For more
      flexibility, we have designed a new protocol between the MS and the
      routers.  The MS periodically sends information packets to the
      routers. These packets are IPv6 packets with a destination option
      header. We created a new option in this header, the Mobility
      Information Option.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     htype     |   hlength     |     otype     |     olen      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       na                      |     plen      |



C. Castelluccia, L. Bellier      Expired January 2001            [Page 7]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                              MS address                       |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      - htype = header type = destination options header.
      - hlength = length of the header, 5.
      - otype = option type (TBD)
      - olen = option length, 20 bytes.
      - plen = prefix length of the Mobility Network.
      - MS address = the address of the local mobility agent.

         Figure 5 : Destination Option Header Mobility Information Option
         Format

      A router must be able to receive and to handle the Mobility
      Information Option.  If the MS address is the unspecified address
      or if the prefix length is 0, the router must stop advertising the
      MS.


 4.2 Mobile Host Operation

  4.2.1 Registration Request and Update

      In our proposal, the registration phase differs during local
      (intra-domain) and global (inter-domain) mobility.

      Inter-domain Mobility :

      When the mobile host moves into a new domain, the Mobile host
      performs the following operations:

         - it gets a new GCoA (it gets the Mobility Network prefix
         address from the Mobility Information Option of the router
         advertisement and concatenates it with its interface ID)  in the
         Mobility Network,
         - it gets a new LCoA on the local link and performs a DaD
         (Duplicate Address Duplication),
         - it registers the (GCoA,LCoA) binding with the MS (the MS then
         performs a DaD and rejects the registration if it fails) using
          a Registration Request packet as defined in Figure 6,
         - it registers the (H@,LCoA) binding with its local CHs using
         MIP Binding Updates. Note that each time the MH moves between
         two domains, it should read its correspondent nodes list, and
         compare its current LCoA prefix with the CH address prefix. If



C. Castelluccia, L. Bellier      Expired January 2001            [Page 8]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


         they match, the correspondent node and the mobile host are in
         the same domain. The MH should tag the correspondent node entry
         with a local flag. This flag should be used by the binding
         update function to build packet with the LCoA or with the GCoA.
         - it registers the (H@,GCoA) binding with its HA using a MIP
         Binding Update
         - it registers the (H@,GCoA) binding with its external CHs using
         MIP Binding Updates.

         Intra-domain Mobility :

         When the mobile host moves locally (i.e. within the domain)

         - it gets a new LCoA on the link, using the Prefix Information
         Option of the router advertisement, and performs a DaD
         (duplicate address detection),
         - if the DaD is successful, it registers the (GCoA,LCoA) binding
         with the MS using a Registration Update packet as defined in
         Figure 7.
         - it registers the (H@,LCoA) binding with its local CHs.

      The Mobility Servers must, as the Home Agent does in Mobile IPv6,
      acknowledge the reception of the Bindings coming from the MH.
      Consequently, the registration messages sent by the MHs to the MSs
      must have the 'acknowledge' flag set to 1.

      Note that if the registration with the MS fails (i.e. the MH does
      not receive any acknowledgment or an acknowledgment with an error
      status), the MH MUST immedially switch to regular Mobile IP6. It
      must then registers its LCoA directly with its HA and CHs and
      bypass the MS registration phase.


                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |      otype     |      olen    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    flag       |    malen      |          seq number           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           lifetime                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     ptype     |     plen      |        pad     |         pad  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                               previous                        |
      |                           mobility server                     |
      |                               address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     pad       |     pad       |      atype      |    alen     |



C. Castelluccia, L. Bellier      Expired January 2001            [Page 9]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      |                           home address                        |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      - otype = option type (TBD)
      - olen = the option length, 32 bytes
      - flag = A flag, same as Mobile IPv6.
      - malen = prefix length of the Mobility Network.
      - seq number = we use the same mechanism that Mobile IPv6. The MS
      stores the sequence number read in the Registration packet. If the
      next Registration packet contains a lower or equal sequence number,
      the Registration packet is discarded and an acknowledgment is sent
      to the MH with the status OPT6_BNDA_BADSEQ. The very first
      Registration packet (after the first movement) must contain a
      sequence number field set to 1. Each time the MH sends a
      Registration Request, Update or Refresh packet, it has to increment
      the sequence number. When the mobile host roams between two
      domains, it must not reset its sequence number to 0. It has to
      continue to increment the number because this number will be used
      in the handoff request packet and will be checked by the previous
      MS.
      - lifetime = the requested lifetime for the binding. The MS has to
      start a timer for this mobile host. If the timer expires, the MS
      must remove the mobile host entry from its cache. The MH should
      send refresh packet to refresh the timer.  We use a sub-option to
      add the address of the previous MS in the registration packet.
      - ptype = the sub-option type, we use 102.
      - plen = the length of the sub-option, 18.  A MH is always
      identified by its home address. We add a Home Address option in our
      destination option to carry the home address.
      - atype = home address option type.
      - alen = 16.

         Figure 6 : Registration Request Packet Format



                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |      otype     |      olen    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    flag       |    malen      |          seq number           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           lifetime                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     pad       |     pad       |      atype      |    alen     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



C. Castelluccia, L. Bellier      Expired January 2001           [Page 10]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


      |                                                               |
      |                                                               |
      |                           home address                        |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      - otype = option type (TBD)
      - olen = the option length, 8 bytes
      - flag = A flag, same as Mobile IPv6.
      - malen = prefix length of the Mobility Network.
      - seq number = we use the same mechanism of Mobile IPv6. The MS
      stores the sequence number read in the update packet. If the next
      update packet contains a lower or equal sequence number, the update
      is discarded and an acknowledgment should be sent to the MH with
      the status OPT6_BNDA_BADSEQ.
      - lifetime = the requested lifetime for the binding. The MS has to
      restart the timer for this mobile host. Note that this timer was
      previously started by a mobile host registration packet.  If the
      timer expires, the MS must remove the mobile host entry from its
      cache.  The MH should send a Registration Update packet to refresh
      the timer.  A MH is alway identified by its home address. We add a
      Home Address option in our destination option to carry the home
      address.
      - atype = home address option type.
      - alen = 16.

         Figure 7 : Registration Update Packet Format


  4.2.2 Registration Refresh

      A Mobile Host must periodically send to its MS a Registration
      Refresh packet to refresh its binding. The format of the
      Registration Refresh packet is identical to one presented in Figure
      7,  with a different option type value (TBD).


 4.3 Mobility Server Operation

  4.3.1. Mobility Server Discovery

      The MS periodically sends Mobility Server Information Packet to all
      routers of its area.

  4.3.2. Registration Request




C. Castelluccia, L. Bellier      Expired January 2001           [Page 11]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


      The MS must register mobile hosts. When a MS receives a
      Registration Request packet, it has to check this registration
      (authentication and sequence number). If the registration is
      successful, the MS must add a binding for this MH in its cache and
      act as a proxy between the GCoA and the LCoA (like a home agent).
      Note that the GCoA is not contained in the registration packet. The
      MS has to reconstruct it from the Mobility Network Prefix address
      and the MH's Interface ID (derived from the Home Address). It then
      performs a DaD with the constructed GCoA on the Mobility Network.
      The lifetime field contained in the Registration Request packet is
      used to start a timer. If this timer expires, the MH entry is
      removed from the cache, and the proxy is stopped.
      If the registration is accepted, the MS must return an
      acknowledgment (that has the same format than MIP acknowledgment
      packets) to the MH with the status OK.
      If the registration aborts or is refused (because the DaD failed
      for example), the MS has to return an acknowledgment to the sender
      with the corresponding error status.

      Note that we use the same error status of Mobile IPv6 registration
      process.

  4.3.3. Registration Update

      When a MH receives a Registration Update packet from a MH, it has
      to check if the sender is already registered and if the sequence
      number of the incoming packet is greater than the previous sequence
      number.  If the Registration Update packet is valid, the MS must
      update the MH's LCoA entry with the update packet source IP
      address, restart the MH lifetime timer
       with the value contained in the lifetime field of the registration
      update packet and send a acknowledgment back to the MH (same format
      than MIP's Binding Acknowledgment packet).  If the Registration
      Update packet is discarded, the MS has to send an acknowledgment
      with the corresponding error status to the sender.

  4.3.4. Registration Refresh

      When a MS receives a Registration Refresh packet, it has to check
      if the sender is already registered and if the sequence number of
      the incoming packet is greater than the previous sequence number.
      If the Refresh packet is valid, the MS must restart the MH lifetime
      timer with the value contained in the lifetime field of the
      registration refresh
       packet.

      If the registration update packet is discarded, the MS has to send
      an acknowledgment with the corresponding error status to the



C. Castelluccia, L. Bellier      Expired January 2001           [Page 12]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


      sender.

  4.3.5 Packet Delivery

      As shown in figure 3, the MS acts as a proxy between the GCoA and
      the LCoA. We use the same mechanism of a home agent to manage this
      proxy.
      External correspondent nodes use the GCoA to send packets to the
      MH. Those packets are intercepted by the MS, encapsulated and
      routed to the MH position (LCoA) (Note that instead of
      encapsulating and decapsulating packets, the mobility server can
      merely change the source and destination IP addresses of the
      encapsulating IP header).
      Internal correspondent nodes use the LCoA. The packets are directly
      routed to the MH position.

  4.3.6. Smooth Handoff

      A MS must be able to handle handoff.

      When a mobile host moves into a new domain, the new MS should send
      a Handoff Request Packet to the previous MS requesting to forward
      packets addressed to the MH. The Handoff Request packet format is
      displayed in Figure 8.
      No retransmission mechanism is needed. If the Handoff Request
      packet is lost, the MH might lose few packets during the handoff.
      We assume that those packets can easily be retransmitted by the
      transport protocol or by the application.

      When a MS receives a Handoff Request, it has to check that the MH
      is registered, that the handoff request packet is authenticated
      correctly and that the sequence number is greater than the previous
      number (note that the sequence number in the handoff request packet
      is the same than the sequence number used by the MH in its last
      Registration Request packet). If the handoff request is accepted,
      the MS has to update its cache by updating the LCoA associate to
      the MH with the MH's new GCoA (as a result the packets in transit
      will be redirected from the previous MS to the new one and then
      encapsulated to the MH's current LCoA). The lifetime timer of the
      MH is restarted by using the lifetime value found in the handoff
      request packet.

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |      otype     |      olen    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    flag       |    malen      |          seq number           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           lifetime                            |



C. Castelluccia, L. Bellier      Expired January 2001           [Page 13]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     ptype     |     plen      |        pad     |         pad  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                               Global                          |
      |                                CoA                            |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     pad       |     pad       |      atype      |    alen     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      |                           home address                        |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      - otype = option type (TBD)
      - olen = the option length, 32 bytes
      - flag = A flag, same as Mobile IPv6.
      - malen = prefix length of the Mobility Network.
      - seq number = we use the same mechanism that Mobile IPv6. The MS
      stores the sequence number read in the Registration Request packet.
      If the next registration packet contains a lower or equal sequence
      number, the registration is discarded and an acknowledgment is sent
      to the MH with the status OPT6_BNDA_BADSEQ.
      - lifetime = the requested lifetime for the binding. The MS has to
      start a timer for this mobile host. If the timer expires, the MS
      must remove the mobile host entry from its cache. The MH should
      send refresh packet to refresh the timer.  We use a sub-option to
      add the address of the previous MS in the registration packet.
      - ptype = the sub-option type, we use 103.
      - plen = the length of the sub-option, 18.  - GCoA = the new GCoA
      of the MH A MH is always identified by its home address. We add a
      Home Address option in our destination option to carry the home
      address.
      - atype = home address option type.
      - alen = 16.

         Figure 8 : Handoff Request Packet Format


 4.4 Home Agent Operation

      - see Mobile IPv6 [1]-

 4.5 Correspondent Host Operation

      -see Mobile IPv6 [1]-




C. Castelluccia, L. Bellier      Expired January 2001           [Page 14]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


5. Security Consideration

 5.1. Correspondent Node Consideration

   Our solution does not introduce more security problems than Mobile
   IPv6. The IPSec SA are created by using the home address of the mobile
   hos.

 5.2. Mobility Server Consideration

  5.2.1. MS <-> MH

      A mobile host has to register with its home agent and with the
      local mobility server. All registration messages between the MH and
      the MS have to be authenticated. This means that the mobile host
      has to share an authentication key (private or public) with all
      domains (i.e. the MS) it may visit. These keys can be pre-installed
      manually or obtained via AAA servers.

  5.2.2. MS <-> MS

      After an inter-domain movement, the new MS may ask the previous MS
      to redirect the packets addressed to the MH to it. This is
      performed by the emission of a Handoff Request packet from the
      current MS to the previous one (see Section 4.3.5). This operation
      requires that the 2 MSs share an authentication key. This key can
      be pre-intalled or obtained dynamically via some kind of AAA
      servers for example.

6. Conclusion

   This paper presents a solution that makes use of IPv6 new
   functionalities, such as a large address space and the Neighbor
   Discovery mechanism, to propose a mobility management scheme that is
   hierarchical, flexible and scalable. We propose a hierarchical
   architecture that separates local mobility (within a domain) from
   global mobility (across domains). Local handoffs are managed locally
   and transparently to a mobile node's correspondent hosts.

   As most of proposed schemes ([3], [4]) we use anchor points to deploy
   two levels of hierarchy ([2] describes how to deploy more than two
   levels of hierarchy) in the networks and we assign to each mobile host
   a Global Care-of Address that only needs to be changed when the mobile
   host moves into a new domain. However in contrast to other schemes,
   the GCoA that we assign to a MH is not the address of the anchor
   point. As a result, the anchor point can be replaced (for load
   balancing, scalability, robustness purposes) dynamically and
   transparently to ongoing communications.



C. Castelluccia, L. Bellier      Expired January 2001           [Page 15]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


   Our proposal is built on top of and is fully compatible with the IETF
   Mobile IPv6 protocol. It does not require installation everywhere to
   be useful but instead can be deployed gradually.

7. Implementation Status

      The implementation of Hierarchical Mobile IPv6 is done under
      FreeBSD 3.3 and can be down-loaded from :
      http://www.inrialpes.fr/planete/people/bellier/hmip.html
      This implementation is in full conformance with the Mobile IPv6
      Internet Draft 7. We have to adapt the implementation to be in full
      conformance with the Mobile IPv6 Internet Draft 12.


References

      [1] D. Johnson and C. Perkins. "Mobility support in IPv6",
          draft-ietf-mobileip-ipv6-10.txt, February 2000.

      [2] Castelluccia C., "An Hierarchical Mobile IPv6 Proposal", INRIA
      TR-0226, November 1998. Available
       at http://www.inrialpes.fr/Planete/people/ccastel/index.html

      [3] E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IP Regional
      Tunnel Management",
        draft-ietf-mobileip-reg-tunnel-02.txt (work in progress), March
      2000.

      [4] K. El Malki and H. Soliman, "Hierarchical Mobile IPv4/v6 and
      Fast Handoffs",
         draft-elmalki-soliman-hmipv4v6-00.txt, March 2000.

Authors' Addresses

      Claude Castelluccia
      INRIA Rhone-Alpes
      655 avenue de l'Europe
      38330 Montbonnot Saint-Martin
      France
      email: claude.castelluccia@inria.fr
      phone: +33 4 76 61 52 15
      fax:   +33 4 76 61 52 52

      Ludovic Bellier
      INRIA Rhone-Alpes
      655 avenue de l'Europe
      38330 Montbonnot Saint-Martin
      France



C. Castelluccia, L. Bellier      Expired January 2001           [Page 16]


Internet Draft       INRIA Hierarchical Mobile IPv6  July, 6 th 2000


      email: ludovic.bellier@inria.fr
      phone: +33 4 76 61 52 15
      fax:   +33 4 76 61 52 52
















































C. Castelluccia, L. Bellier      Expired January 2001           [Page 17]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/