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]