Internet Engineering Task Force Vrizlynn L. L. Thing INTERNET-DRAFT Henry C. J. Lee Yi Xu Laboratories for Information Technology 21 June 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 21 December 2002 [Page i] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 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 - LMA Probe . . . . . . . . . 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 Configuration . . . . . . . . . . . . . . . . 5 3.3.3. LMA Configuration Acknowledgement . . . . . . . . 6 3.3.4. LMA Alive Notification . . . . . . . . . . . . . 7 3.4. Modification to Mobile IPv6 Binding Update . . . . . . . 8 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 13 8. IANA Considerations 14 9. Security Considerations 14 9.1. Binding Updates to Home Agent . . . . . . . . . . . . . . 14 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. Acknowledgement 15 11. References 15 12. Authors' addresses 16 Thing, Lee, Xu Expires 21 December 2002 [Page ii] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 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 other external domains Intermediate Local Mobility Agent Any router, excluding the Gateway Local Mobility Agents, in a domain, acting as Local Mobility Agent Thing, Lee, Xu Expires 21 December 2002 [Page 1] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 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 Node. This Care-of Address is used for registering with Mobile Node's 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, 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. Routers distributed 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. 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 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. Thing, Lee, Xu Expires 21 December 2002 [Page 2] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 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 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. Thing, Lee, Xu Expires 21 December 2002 [Page 3] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 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 local mobility domain. 3.3. New ICMPv6 Messages Hop-by-Hop LMAs Probing LMM defines four new ICMPv6 [5] Messages, namely, LMA Probe Reply, LMA Configuration, LMA Configuration Acknowledgement and LMA Alive Notification. The first one to cater for the LMAs Discovery, the other three 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: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LMA Probe ID | Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + LMA IP Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 143 = 0x8F Code 0 Thing, Lee, Xu Expires 21 December 2002 [Page 4] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 143 = 0x8F Code 1 Checksum The ICMP Checksum [5]. Thing, Lee, Xu Expires 21 December 2002 [Page 5] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 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.3. 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 2 Checksum 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: Thing, Lee, Xu Expires 21 December 2002 [Page 6] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 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.4. 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: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LMA Probe ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + LMA IP Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 143 = 0x8F Code 3 Checksum The ICMP Checksum [5]. Thing, Lee, Xu Expires 21 December 2002 [Page 7] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 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. 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 'L' flag is used to indicate LMA registration. When MN registers with an LMA, the 'L' flag MUST be set. The modified Mobile IPv6 Binding Update has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|S|D|L| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thing, Lee, Xu Expires 21 December 2002 [Page 8] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 4. Local Mobility Agents Discovery When 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 MN. As this message is transmitted along the route from MN to HA, each LMA, which received 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, configuration 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, no LMAs SHOULD 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. 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 Thing, Lee, Xu Expires 21 December 2002 [Page 9] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 +------+ | 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. Scenario 2: LMM Scheme implemented in the visited and external domains (e.g. Home Domain) Thing, Lee, Xu Expires 21 December 2002 [Page 10] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 +------+ | 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. 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. Scenario 3: LMM Scheme not implemented in the visited domain but in the external domains (e.g. Home Domain) Thing, Lee, Xu Expires 21 December 2002 [Page 11] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 +------+ | 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. Therefore, 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. 5. Local Mobility Agents Selection and Registration When HA receives the ICMPv6 Echo Request message, it will reply with an ICMPv6 Echo Reply message. When MN receives the ICMPv6 Echo Reply message, which correspond to the ICMPv6 Echo Request message (with the LMA Probe option), from the HA, it would check for any LMA Probe Reply messages. If no LMA Probe Reply messages are 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 Gateway LMA (GLMA), to be selected for registration. The information of the other LMAs Thing, Lee, Xu Expires 21 December 2002 [Page 12] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 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 6: Failure Detection). To register with the GLMA, MN will send a BU message to this GLMA with the LCoA in the Source Address field, the 'L' flag set, the GCoA lifetime in the Lifetime field, and the home address of MN in the Home Address field. A tunnel [6] will then be set up between the GLMA and MN, whereby GLMA will tunnel all packets destined to MN's home address to its new LCoA. After receiving a Binding Acknowledgement message from the GLMA, 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. For the outer packet, it will have the LCoA in the Source Address field, and the GCoA in the Destination Address field. At the GLMA, 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 GLMA. If MN has existing bindings with CNs (recorded in the Mobile IPv6 Binding Update List), BU messages to update the bindings will be sent through this tunnel. In this case, the Destination Address field of the inner packet will hold the CN's address. 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 GLMA. 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. If the currently registered LMA is the same as the one selected for registration, 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 still remains the same. If a different LMA is selected, the BU messages will be sent to this LMA, HA, and CNs (if bindings exists in MN's Mobile IPv6 Binding Update List) to update the new LCoA and GCoA. The registration process is described in Section 5. 7. Failure Detection After sending the Binding Acknowledgement message to MN, the GLMA will send a LMA Configuration message to MN. This message includes the LMA Alive Notification Interval, which specifies the intervals Thing, Lee, Xu Expires 21 December 2002 [Page 13] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 that it will send LMA Alive Notification messages to MN. MN will keep track of these messages. If one has not been received exceeding the Maximum Notification Delay (typically three times the Alive Notification Interval, in seconds), MN will deem that a node or link failure of the GLMA 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, the LMA Discovery process will then be triggered. 8. IANA Considerations This document defines a new Hop-by-Hop option and four 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 Configuration Message ICMPv6 Code = 2 for LMA Configuration Acknowledgement Message ICMPv6 Code = 3 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. Thing, Lee, Xu Expires 21 December 2002 [Page 14] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 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. 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 additional security issues existing 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-17.txt (Work in Progress), Internet Engineering Task Force, May 2002. [2] Carl Williams. Localized Mobility Management Requirements for IPv6. Internet Draft draft-ietf-mobileip-lmm-requirements-01.txt (Work in Progress), Internet Engineering Task Force, March 2002. Thing, Lee, Xu Expires 21 December 2002 [Page 15] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing 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. [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 Thing, Lee, Xu Expires 21 December 2002 [Page 16] INTERNET-DRAFT Hop-by-Hop Local Mobility Agents Probing June 2002 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 Thing, Lee, Xu Expires 21 December 2002 [Page 17]