Internet Engineering Task Force Vrizlynn L. L. Thing INTERNET-DRAFT Henry C. J. Lee Yi Xu Laboratories for Information Technology 08 October 2002 Hop-by-Hop Local Mobility Agents Probing for Mobile IPv6 Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Abstract This document introduces an extension to Mobile IPv6 to provide support for Localized Mobility Management. This proposed Hop-by-Hop Local Mobility Agents Probing scheme specifies the Local Mobility Agents Discovery, Selection and Failure Detection architecture and procedures for deploying the localized mobility management, whereby the Local Mobility Agents are distributed. It reduces the amount of signalling to the home agent and correspondent nodes when mobile node moves among the subnets of the visited domain. Thing, Lee, Xu Expires 08 April 2003 [Page i] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 Contents Status of This Memo i Abstract i 1 Introduction........................................................1 2 Terminology.........................................................1 3 Overview of Hop-by-Hop Local Mobility Agents Probing................2 3.1 Basic Operation.................................................2 3.2 New IPv6 Hop-by-Hop Option......................................3 3.2.1 LMA Probe Option.............................................3 3.3 New ICMPv6 Messages.............................................4 3.3.1 LMA Probe Reply..............................................4 3.3.2 LMA Discovery Completed......................................5 3.3.3 LMA Configuration............................................6 3.3.4 LMA Configuration Acknowledgement............................7 3.3.5 LMA Alive Notification.......................................8 3.4 Modification to Mobile IPv6 Binding Update......................9 4 Local Mobility Agents Discovery.....................................9 5 Local Mobility Agents Selection and Registration...................12 6 MN's movement within Visited Domain................................13 7 Failure Detection..................................................14 8 IANA Considerations................................................14 9 Security Considerations............................................15 9.1 Binding Updates to Home Agent..................................15 9.2 Binding Updates to Correspondent Nodes.........................15 9.3 Placement of Global CoA in inner IPv6 packet by MN.............15 9.4 Proxy support for MN by LMA....................................15 10 Acknowledgements..................................................16 11 References........................................................16 12 Authors' Addresses................................................16 13 Changes from Previous Version of the Draft........................17 Thing, Lee, Xu Expires 08 April 2003 [Page ii] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 1 Introduction In real-time applications, stringent requirements such as delay and packet loss are imposed. In order to meet these requirements, Mobile IPv6 [1] is facing technical challenges in terms of performance and scalability. In Mobile IPv6, every inter-domain binding update sent by the mobile node (MN) to its home agent (HA) and correspondent nodes (CNs) to inform of its movement to a new Access Router, introduces delay and potential packet loss due to the large round-trip time (in the order of 300 to 500 ms). In the case of high handoff rate, binding updates (BUs) are soon rendered invalid and new ones have to be generated and sent to the MN's HA and CNs, which results in a higher signalling overhead. This document specifies the concept of a Localized Mobility Management (LMM) [2] scheme using Hop-by-Hop Local Mobility Agents (LMAs) Probing. It is an extension to Mobile IPv6 to provide support for regional registration with the LMA Discovery, Selection and Failure Detection mechanisms. The main objective is to limit the processing of registration for the MN's movement within the visited domain locally so as to reduce the network traffic and delay caused by the re- registrations with the HA and CNs. When the MN moves into the visited domain, a LMA registers with HA on behalf of the MN. As MN roams among networks of this domain, only LMA is updated of its location, thus avoiding all the signalling traffic towards HA and CNs. By its very nature, it also serves as a mechanism to hide MN's location from observers outside this domain. 2 Terminology The keywords "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 2119 [3]. This document also uses the terminology described in [1] and [2]. Gateway Local Mobility Agent (GLMA) Domain gateway acting as a Local Mobility Agent Domain Gateway External Interface (DGEI) Any interface on Gateway Local Mobility Agents linked to an external domain Furthest Local Mobility Agent (FLMA) Thing, Lee, Xu Expires 08 April 2003 [Page 1] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 Local Mobility Agent, having the longest hop distance away from MN, discovered during the Local Mobility Agents Discovery process Intermediate Local Mobility Agent Any router, excluding the Gateway Local Mobility Agents, in a, acting as Local Mobility Agent Home Domain Mobile Node's home network domain Visited Domain An administrative domain, other than the Home Domain, where Mobile node has moved to Global Care-of Address (GCoA) Global IP address of the Local Mobility Agent selected by Mobile. This Care-of Address is used for registering with Mobile Home Agent. Local Care-of Address (LCoA) A new IP address acquired by Mobile Node when it connects to a router in the Visited Domain. This Care-of Address is used for registering with the selected Local Mobility Agent. 3 Overview of Hop-by-Hop Local Mobility Agents Probing 3.1 Basic Operation The Hop-by-Hop LMAs Probing LMM scheme introduces an extension to Mobile IPv6 to reduce the latency due to frequent handoffs between access routers in the visited domain as lesser time will be used to update a binding locally, than with a distant HA. In addition, BUs to all CNs with an existing binding entry for MN would not have to be re- generated, which would otherwise result in a relatively high signalling overhead. For domains which implement this LMM scheme, all domain gateways MUST be configured to act as LMAs. This is to identify that the boundary of the domain has been reached so that LMAs in other external domains will not be mistaken as those in the visited domain. It will also ensure that at least one LMA is discovered when MN performs probing along the transmission path to its HA. Other routers within the local mobility domain MAY be configured too for redundancy, which could take the place of the Gateway LMAs in the case of node or link failure. Load balancing MAY also be supported, whereby LMAs MAY implement Thing, Lee, Xu Expires 08 April 2003 [Page 2] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 constraints to resources allocation. A LMA MAY then choose not to reply during the LMAs Discovery process when its resources allocation limit (e.g. the number of MNs it is able to support) has been reached. When MN moves into the visited domain initially, it will acquire a new Care-of Address (CoA) known here as the Local Care-of Address (LCoA). It will then perform probing to search for all the LMAs along the transmission path to its HA. The furthest LMA discovered in this visited domain will be selected as the LMA to be registered with. The decision to select the furthest LMA is to prevent re-registrations with HA and CNs when MN performs frequent handoffs within the visited domain, resulting in a new LMA being selected. After a LMA is selected, MN will register with it to bind its Home Address with its Local Care-of Address (LCoA). Therefore, the LMA is acting as the HA for MN in this visited domain and MUST have the HA functionalities incorporated. After which, MN will use the global IP address of this LMA as its Global Care-of Address (GCoA) to register with its HA and CNs. From then on, packets intended for MN will be sent to the registered LMA, which will tunnel them to MN's LCoA. In this way, when MN moves to connect to another Access Router and acquire a new LCoA (within the visited domain), only the registered LMA needs to be informed. The details of the extensions to Mobile IPv6 will be presented later in this document. It SHOULD be noted that this LMM scheme by Hop-by-Hop LMAs Probing is simply an extension to the Mobile IPv6 protocol. When it is implemented, MN will proceed with registration to the selected LMA, and then to its HA and CNs if necessary (i.e. on initial movement to visited domain or when re-registration is REQUIRED when LMA changes). In the situation whereby this LMM scheme is not implemented, the standard Mobile IPv6 procedures are carried out. 3.2 New IPv6 Hop-by-Hop Option Hop-by-Hop LMAs Probing LMM defines a new IPv6 Hop-by-Hop option [4], the LMA Probe option. This option is used to initiate the LMAs Discovery process. 3.2.1 LMA Probe Option Thing, Lee, Xu Expires 08 April 2003 [Page 3] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 This Hop-by-Hop LMA Probe option is used in an ICMPv6 [5] Echo Request packet sent by MN to its HA, to probe for all LMAs along the transmission path. This LMA Probe option has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LMA Probe ID | Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 32 = 0x20 Option Length 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 4. LMA Probe ID An identifier to aid in matching LMA Probe Replies to this LMA Probe message. Counter Initialized to zero by sending node. Incremented by each LMA in the visited domain along transmission path till set to 0xFFFF (Boundary Encountered Value) by the Domain Gateway External Interfaces (DGEIs). It is used to locate Intermediate and Gateway LMAs within the local mobility domain. 3.3 New ICMPv6 Messages Hop-by-Hop LMAs Probing LMM defines five new ICMPv6 [5] Messages, namely, LMA Probe Reply, LMA Discovery Completed, LMA Configuration, LMA Configuration Acknowledgement and LMA Alive Notification. The first two are used for the LMAs Discovery, and the other three are used to handle failure detection. 3.3.1 LMA Probe Reply This ICMPv6 message is sent by LMAs, which are along the transmission path from MN to its HA. Through this reply, all the en-route LMAs, within the visited domain, are discovered. This LMA Probe Reply message has the following format: Thing, Lee, Xu Expires 08 April 2003 [Page 4] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LMA Probe ID | Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + LMA IP Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 143 = 0x8F Code 0 Checksum The ICMP Checksum [5]. LMA Probe ID The identifier from the invoking LMA Probe message. Counter The Counter value from the invoking LMA Probe message. Valid Lifetime The minimum value (in seconds) of the preferred and valid lifetimes of the prefix assigned to the LMA's subnet. This value indicates the validity of the LMA's address and consequently the time for which the GCoA is valid. LMA IP Address The LMA's Global Routable Address. 3.3.2 LMA Discovery Completed Thing, Lee, Xu Expires 08 April 2003 [Page 5] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 This ICMPv6 message is sent by the Gateway LMA to MN, when the counter value is changed from a non Boundary Encountered Value to the Boundary Encountered Value at the DGEI. It is to mark the completion of the LMAs Discovery process as early as possible, instead of waiting for the ICMPv6 Echo Reply from HA, which would cause a higher delay due to the larger round trip time. This LMA Discovery Completed message has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LMA Probe ID | Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 143 = 0x8F Code 1 Checksum The ICMP Checksum [5]. LMA Probe ID The identifier from the LMA Probe message. Counter The Counter value before being changed to the Boundary Encountered Value. This will allow MN to know how many LMAs it has discovered. 3.3.3 LMA Configuration This ICMPv6 message is sent by the LMA to MN after registration, to notify the MN, of the registered LMA's configuration information related to this LMM scheme. This LMA Configuration message has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LMA Probe ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LMA Alive Notification Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thing, Lee, Xu Expires 08 April 2003 [Page 6] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 Type 143 = 0x8F Code 2 Checksum The ICMP Checksum [5]. LMA Probe ID The identifier from the LMA Probe message. Reserved 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. LMA Alive Notification Interval The interval, in seconds, which the registered LMA has to send LMA Alive Notification messages to the MN to notify that it is still "alive" and serving as a proxy for the MN. 3.3.4 LMA Configuration Acknowledgement This ICMPv6 message is sent by MN to the LMA, to notify the LMA of the receipt of the LMA Configuration message by MN. This LMA Configuration Acknowledgement message has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LMA Probe ID | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 143 = 0x8F Code 3 Checksum Thing, Lee, Xu Expires 08 April 2003 [Page 7] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 The ICMP Checksum [5]. LMA Probe ID The identifier from the LMA Configuration message. Status 8-bit unsigned integer indicating the disposition of the LMA Configuration. The following Status values are currently defined: 0 LMA Configuration message accepted and information in it stored in receiving node 128 Incorrect LMA Probe ID Reserved 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. 3.3.5 LMA Alive Notification This ICMPv6 message is sent by the registered LMA to the MN for whom it is serving as a proxy, at intervals of the LMA Alive Notification Interval value (configured by the LMA Alive Notification Configuration message). This message is used to inform MN that the registered LMA is still "alive" and serving as a proxy for the MN. The LMA Alive Notification message has the following format: Thing, Lee, Xu Expires 08 April 2003 [Page 8] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LMA Probe ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + LMA IP Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 143 = 0x8F Code 4 Checksum The ICMP Checksum [5]. LMA Probe ID The identifier from the LMA Probe message. Reserved 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Valid Lifetime The minimum value (in seconds) of the preferred and valid lifetimes of the prefix assigned to the LMA's subnet. This value indicates the validity of the LMA's address and consequently the time for which the GCoA is valid. The local binding will be updated if there's a change from the registered value. LMA IP Address The registered LMA's Global Routable Address. Thing, Lee, Xu Expires 08 April 2003 [Page 9] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 3.4 Modification to Mobile IPv6 Binding Update Registration with HA or CN is indicated by the 'H' flag. To differentiate registration with LMA, a new flag is added to the Binding Update (BU) message in Mobile IPv6. This 'V' flag is used to indicate LMA registration (at Visited Domain). When MN registers with an LMA, the 'V' flag MUST be set. The modified Mobile IPv6 Binding Update has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|S|D|L| Reserved |V| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 Local Mobility Agents Discovery When the MN moves into the visited domain, it will acquire a new Local Care-of Address (LCoA). It will then proceed to send an ICMPv6 Echo Request message to its HA. This message will include the LMA Probe option. The LMA Probe ID is randomly generated and the Counter will be set to zero by the MN. As this message is transmitted along the route from MN to HA, each LMA, which receives this message, will process the LMA Probe option. The Counter value is incremented by the LMA and a LMA Probe Reply message is generated and sent to the soliciting MN. Intermediate nodes, which do not recognize this LMA Probe option will skip over it and proceed to process other options. Therefore, modification is only REQUIRED on LMAs and MNs. Modification to HAs, CNs and other nodes not supporting this LMM scheme is not REQUIRED. When the LMA Probe Option arrives at a Domain Gateway External Interface (DGEI), the Counter value in the LMA Probe Option will be set to the Boundary Encountered Value of 0xFFFF by the LMA. This is to indicate that a boundary is reached. After which, any LMA processing this message MUST NOT reply to this probing if the Counter in the LMA Probe is found to contain this Boundary Encountered Value. This is to ensure that LMAs in other domains will not be discovered and mistaken as those in the visited domain. At the DGEI, when the counter value is being changed from a non Boundary Encountered Value to the Boundary Encountered Value, the LMA will send the LMA Discovery Completed message to MN to mark the completion of the LMAs Discovery process. Thing, Lee, Xu Expires 08 April 2003 [Page 10] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 The following describes four scenarios of LMAs Discovery. In Figure 1, 2 and 3, DGEIs are indicated by the 'X' signs. Scenario 1: LMM scheme implemented in the visited domain only +------+ | HA | +------+ | +----------------+ | Internet | +----------------+ | +---+ | +---X--+ | LMA1 | +------+ | +------+ | R1 | +------+ | +------+ | LMA2 | +------+ | +------+ | MN | +------+ Figure 1: Hop-by-Hop LMA Probing LMM Scheme in the Visited Domain In Figure 1, as the LMA Probe Option is transmitted along the route from MN to HA, intermediate nodes configured to serve as LMAs will trigger the sending of a LMA Probe Reply message to MN. LMA2 will send a LMA Probe Reply message to MN with a Counter value of 1, and LMA1 will send a LMA Probe Reply message with a Counter value of 2. At LMA1's DGEI, the Counter value is set to the Boundary Encountered Value of 0xFFFF and no other LMA Probe Reply messages will be sent to MN from that point onwards. LMA1 will also send a LMA Discovery Completed message to MN to mark the completion of the LMAs Discovery process. Thing, Lee, Xu Expires 08 April 2003 [Page 11] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 Scenario 2: LMM Scheme implemented in the visited and external domains (e.g. Home Domain) +------+ | HA | +------+ | +--------+ | LMA(H) | +---X----+ | +------------+ | Internet | +------------+ | +--+ | +---X--+ | LMA1 | +------+ | +------+ | LMA2 | +------+ | +------+ | MN | +------+ Figure 2: Hop-by-Hop LMA Probing LMM Scheme in the Visited and External Domains In Figure 2, LMA2 will send a LMA Probe Reply message to MN with a Counter value of 1, and LMA1 will send a LMA Probe Reply message with a Counter value of 2. At LMA1's DGEI, the Counter value is set to the Boundary Encountered Value of 0xFFFF. LMA1 will then send a LMA Discovery Completed message to MN to mark the completion of the LMAs Discovery process. When LMA(H) receives the LMA Probe Option at its DGEI and sees that the Counter value has already been set to the Boundary Encountered Value, it will just skip over this option. Therefore, LMA(H) (including LMAs beyond it) will not send any LMA Probe Reply message to MN. Thing, Lee, Xu Expires 08 April 2003 [Page 12] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 Scenario 3: LMM Scheme not implemented in the visited domain but in the external domains (e.g. Home Domain) +------+ | HA | +------+ | +--------+ | LMA(H) | +---X----+ | +------------+ | Internet | +------------+ | +--+ | +------+ | R1 | +------+ | +------+ | MN | +------+ Figure 3: Hop-by-Hop LMA Probing LMM Scheme in the External Domain but not the Visited Domain In Figure 3, the LMA Probe Option will be skipped by intermediate nodes, not acting as LMAs, and forwarded on to the next node on the transmission route. It will then arrive at the DGEI of the LMA(H), which will set the Counter value in the LMA Probe Option to the Boundary Encountered Value. LMA(H) will then send a LMA Discovery Completed message to MN to mark the completion of the LMAs Discovery process. LMA(H) (including LMAs beyond it) will not send any LMA Probe Reply message to MN. Scenario 4: LMM Scheme not implemented in the visited and external domains In the case that this LMM scheme is not implemented in any of the domains that the ICMPv6 Echo Request message is sent to, no LMA Probe Reply will be received by the MN. No LMA Discovery Completed message will be sent to MN in this case. 5 Local Mobility Agents Selection and Registration If MN receives the LMA Discovery Completed message, which marks the completion of the LMAs Discovery process, it will start the selection Thing, Lee, Xu Expires 08 April 2003 [Page 13] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 process immediately. However, if the LMM scheme is not implemented and no LMA Discovery Completed message is received, the ICMPv6 Echo Reply message sent by HA, which corresponds to the ICMPv6 Echo Request message (with the LMA Probe option), will be used to mark the completion of the LMA Discovery process. After the LMAs Discovery is completed, MN would check for any LMA Probe Reply messages received. If no LMA Probe Reply message is received, the LMM scheme is not implemented in the visited domain and MN will proceed to perform the standard Mobile IPv6 registrations. If there are LMA Probe Reply messages, MN will check their Counter value to locate the one with the highest value. This will be the Furthest LMA (FLMA), to be selected for registration. The information of the other LMAs received in the LMA Probe Reply messages, corresponding to the latest LMA Probing, is stored in MN for redundancy purpose (will be discussed further in Section 7: Failure Detection). To register with the FLMA, MN will send a BU message to this FLMA with the LCoA in the Source Address field, the 'V' flag set, the GCoA lifetime in the Lifetime field, and the home address of MN in the Home Address field of the Home Address Destination Option. A tunnel [6] will then be set up between the FLMA and MN, whereby FLMA will tunnel all packets destined to MN's home address to its new LCoA. After receiving a Binding Acknowledgement message from the FLMA, MN will send a BU message to its HA. For the inner packet, it will have the GCoA in the Source Address field, the HA's address in the Destination Address field, and the home address of MN in the Home Address field of the Home Address Destination Option. For the outer packet, it will have the LCoA in the Source Address field, and the GCoA in the Destination Address field. At the FLMA, it will remove the outer packet and forward the inner packet to the HA. Packets destined to MN's home address will be intercepted by HA and tunnelled to the FLMA. Alternatively, MN MAY register with its HA using the Alternate Care- of-Address Mobility Option. The Source Address field will contain MN's LCoA, and the Destination Address field will contain HA's address. The Alternate CoA field in the BU's mobility option will be set to the GCoA, and the Home Address field of the Destination Option will be set to MN's home address. If MN has existing bindings with CNs (recorded in the Mobile IPv6 Binding Update List), BU messages to update the bindings will be sent to the CNs in the same way as to HA. In this case, the Destination Address field of the inner packet will hold the CN's address and the ‘H’ bit will not be set. It SHOULD be noted that the lifetime of the binding with HA and CNs MUST NOT be larger than the MN's binding lifetime with the FLMA. Thing, Lee, Xu Expires 08 April 2003 [Page 14] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 6 MN's movement within Visited Domain When MN moves to connect to a new Access Router within the Visited Domain, it will obtain a new LCoA. The LMAs Discovery process is therefore triggered. Source Routing will be used to check if MN is still within the visited domain. The LMA Probe message will include a Type 0 Routing Header, which will contain the registered LMA's address. If MN is able to receive a LMA Probe Reply message from the registered LMA (i.e. MN is still within the visited domain), only the binding with the currently registered LMA needs to be updated. A new BU will be sent to this LMA to update the registration to bind the GCoA to this new LCoA. The HA and other CNs will not be informed as the GCoA remains the same. In this case, the MN’s movement is transparent to the HA and the CNs. If MN does not receive a LMA Probe Reply message from the registered LMA (i.e. MN has moved out of the visited domain), a LMA in the new visited domain needs to be selected. The BU messages will be sent to the newly selected LMA, HA, and CNs (if bindings exists in MN's Mobile IPv6 Binding Update List) to update the new LCoA and GCoA. A BU message (with lifetime of 0) will be sent to the old LMA to delete the binding. The selection and registration process is described in Section 5. 7 Failure Detection After sending the Binding Acknowledgement message to MN, the registered LMA will send a LMA Configuration message to MN. This message includes the LMA Alive Notification Interval, which specifies the intervals that it will send LMA Alive Notification messages to MN. MN will reply with a LMA Configuration Acknowledgement message. MN will then keep track of the LMA Alive Notification messages received from the registered LMA. If one has not been received exceeding the Maximum Notification Delay (typically three times the Alive Notification Interval), MN will deem that a node or link failure of the registered LMA has occurred. When a failure is detected, the information of the other LMAs received in the LMA Probe Reply messages, corresponding to the latest LMA Probing, which is stored in MN for redundancy purpose will be scanned. This scanning locates the LMA with the next highest Counter value (after the previously registered LMA). The LMA registration process is triggered to register with this LMA. In the case whereby registration with this LMA could not be completed successfully (e.g. link failure of the previously registered LMA involves this LMA), the scanning process is repeated. If the scanning could not result in locating a potential LMA (e.g. in the event of network partitioning, which is the worst case scenario), the LMA Discovery process will then be triggered. Thing, Lee, Xu Expires 08 April 2003 [Page 15] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 8 IANA Considerations This document defines a new Hop-by-Hop option and five new IPv6 ICMP messages. They MUST be assigned a protocol number. These new protocols are described in Section 3.2 and 3.3, and include the following: Hop-by-Hop Option Type = 32 for LMA Probe Option ICMPv6 Type 143 and ICMPv6 Code = 0 for LMA Probe Reply ICMPv6 Code = 1 for LMA Discovery Completed Message ICMPv6 Code = 2 for LMA Configuration Message ICMPv6 Code = 3 for LMA Configuration Acknowledgement Message ICMPv6 Code = 4 for LMA Alive Notification Message These future values can be allocated using standards action [7]. 9 Security Considerations 9.1 Binding Updates to Home Agent BU messages from MN to HA will be protected by authentication. The inner packet with GCoA in the Source Address field and HA's address in the Destination Address field will be protected by including the Authentication Header in IPSec. This authentication is based on the Security Association between the MN and its HA. 9.2 Binding Updates to Correspondent Nodes BU messages from MN to CNs are not protected by the IPSec Authentication Header. However, the related security issues in this case, is taken care of by the standard Mobile IPv6's Home Test and Care-of Test. 9.3 Placement of Global CoA in inner IPv6 packet by MN In the BU messages for HA and CNs, MN is required to place the GCoA as the Source Address in the inner packet on behalf of the registered LMA (as the source node to forward this packet). A malicious MN might send BUs in which the Source Address in the inner packet is set to the address of a victim node. If such BUs are accepted, packets are forced to be sent to the victim nodes causing a denial of service attack. Thing, Lee, Xu Expires 08 April 2003 [Page 16] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 This could be prevented by implementing a GCoA <-> Home Address binding cache on the registered LMA. When the registered LMA receives a BU message for HA or CNs, it will check it's Mobile IPv6 Binding Cache and GCoA <-> Home Address Binding Cache, that it does have a binding between the GCoA, LCoA, and Home Address in the packet. It will then remove the outer packet and forwards the packet on behalf of the MN. If the checking shows that it does not have the GCoA, LCoA, and Home Address binding, it will reject (the request to forward) this packet. 9.4 Proxy support for MN by LMA The LMA does not have a security association with MN in this case. However, this design does not introduce any additional security issues in IPv6 standard routers. 10 Acknowledgements The authors would like to thank Dr. Robert H. Deng (Laboratories for Information Technology) for his valuable analysis and advice on the security aspects in this document. 11 References [1] David B. Johnson, Charles Perkins, and Jari Arkko. Mobility Support in IPv6. Internet Draft draft-ietf-mobileip-ipv6-18.txt (Work in Progress), Internet Engineering Task Force, June 2002. [2] Carl Williams. Localized Mobility Management Requirements for IPv6. Internet Draft draft-ietf-mobileip-lmm-requirements-02.txt (Work in Progress), Internet Engineering Task Force, June 2002. [3] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [4] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. Request for Comments (Draft Standard) 2460, Internet Engineering Task Force, December 1998. [5] A. Conta and S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. Request for Coments (Draft Standard) 2463, Internet Engineering Task Force, December 1998. Thing, Lee, Xu Expires 08 April 2003 [Page 17] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 [6] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 Specification. Request for Comments (Proposed Standard) 2473, Internet Engineering Task Force, December 1998. [7] T. Narten and H. Alvestrand. Guidelines for Writing an IANA Considerations Section in RFCs. Request for Comments (Best Current Practice) 2434, Internet Engineering Task Force, October 1998. 12 Authors' Addresses Questions about this document can also be directed to the authors: Vrizlynn L. L. Thing Laboratories for Information Technology 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65 6874 6728 Fax: +65 6776 8109 Email: vriz@lit.a-star.edu.sg Henry C. J. Lee Laboratories for Information Technology 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65 6874 6668 Fax: +65 6776 8109 Email: hlee@lit.a-star.edu.sg Yi Xu Laboratories for Information Technology 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65 6874 8457 Fax: +65 6776 8109 Email: yxu@lit.a-star.edu.sg 13 Changes from Previous Version of the Draft This appendix briefly lists some of the major changes in this draft relative to the previous version of this same draft, draft-vriz- mobileip-hbhlmap-00.txt: Thing, Lee, Xu Expires 08 April 2003 [Page 18] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing October 2002 . Instead of choosing the GLMA for registration, the FLMA will be chosen. LMAs discovered MAY exclude certain higher layer LMAs if they choose not to reply to LMA Probe (e.g. based on counter value indication, constraints on resource allocation). Therefore, load balancing MAY be supported. . A new ICMPv6 message, LMA Discovery Completed, has been introduced to improve the performance of LMAs Discovery by reducing the time taken for the discovery process (if LMM is implemented), instead of waiting for the ICMPv6 Echo Reply message from HA. . Modifications to the Mobile IPv6 Binding Update format to use the 'V' flag to indicate LMA registration and to conform to Mobile IPv6 Internet draft version 18. . Usage of the Alternate Care-of-Address Mobility Option for sending Binding Updates to the HA and CNs has been included as an alternate method. . Usage of Source Routing to detect if MN's movement is within or out of visited domain to prevent triggering of LMAs Discovery unnecessarily, thus preventing discovery of new FLMA while still within visited domain resulting in new registration with HA and CNs. Thing, Lee, Xu Expires 08 April 2003 [Page 19]