Mobile IP Working Group Rajeev Koodli INTERNET DRAFT Charles E. Perkins 28 October 2000 Communication Systems Laboratory Nokia Research Center Fast Handovers in Mobile IPv6 draft-koodli-mobileip-fastv6-01.txt Status of This Memo This document is a submission by 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. 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. Abstract When a mobile node moves to a new point of attachment in the Internet, relying on router advertisements may be insufficient to insure adequate performance of time-critical applications running on the mobile node. In many cases, other indications are available to trigger handover of the mobile node to a new point of attachment, at a new access router. The mobile node and the access router may then be able to take steps, in addition to those specified for Mobile IPv6, to reduce the time during which the mobile node is effectively disconnected from the Internet. This specification defines the fast handover problem and outlines a proposed solution to the problem. Koodli, Perkins Expires 28 April 2001 [Page i] Internet Draft Fast Handovers in Mobile IPv6 28 October 2000 Contents Status of This Memo i Abstract i 1. Fast Handover Definition 2 2. Proposal 3 3. New Access Router Processing 6 4. ICMP Handover Redirect Message Format 6 5. ICMP Handover Message Format 8 6. ICMP Handover Authentication Suboption Format 9 7. ICMP Handover Error Format 9 8. Security Considerations 9 A. Link Failure 10 B. Alternative to ICMP Handover Message 11 Addresses 11 Koodli, Perkins Expires 28 April 2001 [Page 1] Internet Draft Fast Handovers in Mobile IPv6 28 October 2000 1. Fast Handover Definition When a Mobile Node (MN) undergoes handover from one link to another, it needs to obtain a new care-of address at the New Router as soon as possible in order to be able to send and receive IP packets. See Figure 1 for a reference diagram of handover assumed in the rest of this document. The latency involved in forming a new CoA in IPv6 comes mainly from Neighbor Discovery, which includes Router Advertisement and possibly Router Solicitation, and Duplicate Address Detection (DAD) when stateless auto-configuration is used. After the mobile node forms a new CoA, it may be able send packets using the new CoA, but it cannot receive packets at that address until its mobility agent(s) and correspondent nodes are notified with Binding Updates. The timeline for these operations is illustrated in Figure 2. Thus, the delay involved in forming a new CoA must be reduced so that the mobile node can resume IP packet transmission quickly, and, the latency involved in forwarding packets to the mobile node until it successfully informs its mobility agent(s) and correspondent Node(s) must be reduced as well. We outline a proposal to reduce these two latencies when handovers are network-controlled, i.e., some network entity instructs the mobile node to undergo handover from one access router to another. This network entity is assumed to know the IP addresses and network prefixes of those routers. v +------------+ +-+ | Previous | < | | ---------- | Router | ------ > ----\ +-+ | (Prtr) | < \ MN | | \ | +------------+ +---------------+ | ^ IP | Correspondent | | | Network | Node | V | +---------------+ v / v +------------+ / +-+ | New | < / | | ---------- | Router | ------ > ----/ +-+ | (Nrtr) | < MN | | +------------+ Figure 1: Reference Scenario for Handover Koodli, Perkins Expires 28 April 2001 [Page 2] Internet Draft Fast Handovers in Mobile IPv6 28 October 2000 X-------X-----X--------------X--------> Time ^ ^ ^ ^ | | | | | | | | Handover | | | epoch start | | | | | | New | | link | | formation | | | | | | ND(+DAD) | MN forms new | CoA and sends | Binding Update | | | Binding Update received. MN can receive packets at new CoA Figure 2: Handover Milestones and Latencies 2. Proposal Our proposal has the following key components. First, the Previous Router informs the mobile node to undergo handover, using a new form of the Neighbor Discovery Redirect message. In this message, the Previous Router supplies the required information for the mobile node to form a new CoA as well as obtain the New Router's link-local and link-layer addresses. Second, subsequent to delivering the Redirect message, the Previous Router sends a message to the New Router supplying the mobile node's new CoA and requesting it to act as a ND Proxy for that address. This message could also include the mobile node's previous CoA as well as security keys that the New Router can use to validate the ND cache entry when the mobile node establishes connectivity. This message sets up a forwarding path from the Previous Router to the mobile node's new CoA. Finally, after establishing the link connectivity, the mobile node sends a message to the New Router which has the effect of resolving any potential address conflicts and validating the mobile node's entry in the Koodli, Perkins Expires 28 April 2001 [Page 3] Internet Draft Fast Handovers in Mobile IPv6 28 October 2000 New Router's ND cache. This message includes Binding Update as an encapsulation, so that if the ND cache entry can be validated, the Binding Update can be sent right away. In addition to reducing the latencies mentioned earlier (using basic IPv6 and Mobile IPv6 extensions), the above operations involve sending minimal number of messages over an air interface, which could be an important consideration in bandwidth-constrained links. When the handovers are triggered by the network, with possible assistance from the mobile node regarding the decision to undergo handover, the Previous Router determines the network prefix of the New Router to which the mobile node will get attached to next. The Previous Router has to obtain one or more network prefix(es), e.g_from a network entity that controls the handover. Subsequently, the Previous Router sends a Handover Redirect message (which is a modified ICMP Redirect) to the mobile node, containing the new access router's IPv6 address as well as its link-layer IP address and (implicitly) its link-local address. This typically allows the mobile node to determine its new CoA while still being attached to the Previous Router. Optionally, the previous access router MAY supply a specific care-of address for the mobile node to use when it establishes its new link to the new access router. The mobile node should use this new CoA after establishing link connectivity at the New Router. The Handover Redirect message is specified in section 4. X-------X-----X--X------------------> Time ^ ^ ^ ^ | | | | | | | MN ready to Handover | | send and receive start epoch | | packets | | New | link | formation | | | ND(+DAD) Figure 3: Optimized Handover Delays Koodli, Perkins Expires 28 April 2001 [Page 4] Internet Draft Fast Handovers in Mobile IPv6 28 October 2000 After transmitting the Handover Redirect message to the mobile node, the Previous Router sends a ICMP Handover message (see section 5 to the New Router, containing the mobile node's new CoA. The New Router verifies if the new CoA is already in use by simply verifying if an entry exists in its ND cache entry. If an entry exists, it does nothing (See below). If an entry does not exist, the New Router begins to act as a Proxy so that it can respond to any potential DAD conflicts on its link for the new CoA. This provides means for avoiding potential DAD conflicts due to selecting an address while not on-link. The behavior of the New Router as a Proxy is according to the specifications in [3]. As mentioned earlier, the above message from the Previous Router to the New Router SHOULD include security keys (see section 6) that the latter could use when the mobile node establishes connectivity with it. This message may also include additional control information, such as an indication to buffer packets sent to the new CoA, as well as any other useful context information. After receiving the Handover Redirect message and forming a new CoA, the mobile node undergoes Layer 2 handover to establish a new link to the New Router. Note that the mobile node already has the New Router's link-local and link-layer addresses. It can thus send IP packets (including a Binding Update) directly to the New Router (to forward). However, since the ND cache entry at the New Router must be verified to ensure a unique address and possibly validated through authentication, the mobile node first sends a message to the New Router containing its link-layer address and an authentication header. This message also includes the Binding Update as an encapsulated packet. If the New Router can successfully validate the ND cache entry, then the Binding Update is delivered right away. If not, an appropriate error message is sent back to the mobile node, which then has to resort to forming a new CoA if the address is already in use. The above message has the effect of propagating the mobile node's link-layer address (and the security credentials) to the New Router with the assumption that the IP address is valid. Thus, it effectively reduces handover latency by the amount of time necessary for two messaging round-trips -- once, for DAD, and and again for Neighbor Solicitation and Neighbor Advertisement to determine New Router's link-layer address. Besides saving handover time, the handover message also serves to eliminate the bandwidth overhead which would otherwise be consumed as the mobile node and new access router perform DAD and Neighbor Discovery messages. Note that since the Previous Router already has an association from the previous CoA to the new CoA, the packets could be arriving at the New Router almost as soon as a new link is established for the mobile Koodli, Perkins Expires 28 April 2001 [Page 5] Internet Draft Fast Handovers in Mobile IPv6 28 October 2000 node. Some of these packets that arrive earlier than the mobile node's establishment of IP connectivity at the New Router could be lost without appropriate support for buffering. 3. New Access Router Processing When the new access router receives the ICMP Handover message, it SHOULD first check for the existence and validity of an AH header, with authentication data computed according to the security association between the previous access router and the new access router. If the handover message does not have the `M' bit set, the new access router SHOULD compute the layer-2 address of the mobile node by masking off the bits corresponding to the given Mobile Node Care-of Address field. This will allow the new access router to send messages to the mobile node at its new care-of address without having to perform Neighbor Solicitation. If the new access router receives a handover message containing a new Care-of Address that is already in use by another node in its Neighbor Cache, the new access router SHOULD return a ICMP Handover Error message (see section 7) to the previous access router. 4. ICMP Handover Redirect Message Format Routers send Handover Redirect packets to inform a mobile node of a better access router. The redirect message SHOULD also contain information enabling the mobile node to determine the layer-2 address for the new access router, as well as its new care-of address for attachment to the Internet at the new access router. Koodli, Perkins Expires 28 April 2001 [Page 6] Internet Draft Fast Handovers in Mobile IPv6 28 October 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Size |M|C| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Router IPv6 Address (128 bits) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Access Router MAC Address (64 bits) (if present) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ New Care-of Address (128 bits) (if present) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Code 0 M If the `M' bit is set, the 64-bit Access Router MAC Address field is present. C If the `C' bit is set, the 128-bit New Care-of Address field is present. If the `M' bit is not set, then the Access Router's MAC address may be determined by applying the value in the Prefix Size to mask off the routing prefix bits of the value in the Access Router IPv6 Address field. If the `C' bit is not set, then the mobile node may determine its new care-of address by applying the value in the Prefix Size to select the routing prefix from the the address in the Access Router IPv6 Address field. This routing prefix may then be prepended to the lower-order bits of the mobile node's current care-of address. The mobile node determines the new router's link-local address by replacing Prefix-Size bits by the well-known link-local address prefix FE80:. Whether or not the `C' bit is set, the mobile node MAY attempt to acquire a new care-of address once connectivity is established at the new access router, or else it MAY continue to use the care-of address Koodli, Perkins Expires 28 April 2001 [Page 7] Internet Draft Fast Handovers in Mobile IPv6 28 October 2000 implicitly or explicitly formed as above. Such care-of address acquisition follows the Mobile IPv6 specification [1]. 5. ICMP Handover Message Format An access router sends an ICMP Handover message to inform a new access router that it will soon be the default (edge) router for a mobile node. The handover message contains enough information so that the new access router can create the appropriate entry in its Neighbor Cache for the prospective mobile node. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Size |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Mobile Node's New Care-of Address (128 bits) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Mobile Node MAC Address (64 bits) (if present) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Type TBD Code 0 M If the `M' bit is set, the 64-bit Mobile Node MAC Address field is present. If the `M' bit is not set, then the mobile node's MAC address may be determined by using the routing prefix to mask off the leading bits of the mobile node's care-of address. Available suboptions include a Mobile Node Authentication suboption. Other suboptions may be defined to handle necessary context transfers. The previous router needs to determine the correct address for inclusion as the Mobile Node's New Care-of Address field. This can be done by consulting its local tables to determine the correct routing prefix for the new access router's service area. Determining Koodli, Perkins Expires 28 April 2001 [Page 8] Internet Draft Fast Handovers in Mobile IPv6 28 October 2000 the assocation between neighboring access routers, and their prefixes which are to be used for creating new care-of addresses, is carried out by techniques beyond the scope of this specification. It should be noted, however, that manual configuration is a realistic possibility at the time the access routers are installed. When the new access router receives a ICMP Handover message that does not contain the Mobile Node MAC Address field, the new access router determines the mobile node's layer-2 address by masking off the leading bits according to the appropriate prefix size for that subnet. The routing prefix is naturally known to the new access router, since it is the default router for that subnet. 6. ICMP Handover Authentication Suboption Format TBD 7. ICMP Handover Error Format A prospective new access router sends the ICMP Handover Error message to inform the previous access router that the handover is likely to fail, and that the mobile node should not expect to consider the sending access router as its new default router. The Handover Error message contains enough information so that the previous access router can determine which Handover Message caused the error. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Mobile Node's New Care-of Address (128 bits) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The previous access router uses its cached handover information to determine which of its visiting mobile nodes is indicated by the value given in the Mobile Node's New Care-of Address field. 8. Security Considerations Any handover message has to be made secure against malicious nodes wishing to fraudulently redirect traffic away from the mobile node. Koodli, Perkins Expires 28 April 2001 [Page 9] Internet Draft Fast Handovers in Mobile IPv6 28 October 2000 Messages from the mobile node have to be authenticated so that an access router does not erroneously redirect traffic to a malicious interloper. Messages, if any, to the previous access router have to be authenticated so that the previous access router does not erroneously redirect traffic away from the mobile node. Messages to the new access router SHOULD be authenticated to enable detection of malicious attempts to cause the new access router to wastefully reserve resources for a mobile node that is unlikely to arrive. References [1] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in progress). draft-ietf-mobileip-ipv6-12.txt, April 2000. [2] R. Koodli and C. Perkins. A Framework for Smooth Hand-overs in IP Mobile Networks (work in progress). draft-ietf-koodli-smoothv6-00.txt, July 2000. [3] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. A. Link Failure In some radio networks, it is possible that the mobile node is not able to establish the link with the New Router after deciding to undergo new link establishment. In such a case, the mobile node may revert back to the Previous Router resulting in a ``link reversal''. When this happens, the mobile node has to send a message requesting to disable forwarding to the new CoA that is no longer valid. When this happens, the Previous Router may determine, through the Handover Error message, that it has to stop forwarding packets to the MN's new CoA. It may then determine if the mobile node is present on its link and resume forwarding packets as appropriate. Alternatively, the mobile node itself may send a message requesting to disable forwarding to the new CoA that is no longer valid. Note that since a Binding Update has not been delivered yet, packets will still be arriving at the Previous Router, and by disabling forwarding to the new CoA, those packets can be delivered again at the mobile node's current location. Koodli, Perkins Expires 28 April 2001 [Page 10] Internet Draft Fast Handovers in Mobile IPv6 28 October 2000 B. Alternative to ICMP Handover Message The Previous Router MAY use an unsolicited SHREP message defined in [2] to supply the mobile node's new CoA and security information to the New Router. The mobile node MAY use a SHIN message defined in the same document when it sends a message to propagate its link-layer address to the New Router. The Previous Router MAY use the unsolicited SHREP message to also supply any control information (such as an indication to buffer packets) as well as any useful context information (such as header compression state variables). Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola 6000 Connection Drive 1501 West Shure Drive M/S M8-540 Irving, Texas 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com Questions about this memo can also be directed to the authors: Rajeev Koodli Charles E. Perkins Communications Systems Lab Communications Systems Lab Nokia Research Center Nokia Research Center 313 Fairchild Drive 313 Fairchild Drive Mountain View, California 94043 Mountain View, California 94043 USA USA Phone: +1-650 625-2359 Phone: +1-650 625-2986 EMail: rajeev.koodli@nokia.com EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Fax: +1 650 625-2502 Koodli, Perkins Expires 28 April 2001 [Page 11]