Mobile IP Working Group Rajeev Koodli INTERNET DRAFT Charles E. Perkins 2 March 2001 Communication Systems Laboratory Nokia Research Center Jonathan Trostle Cisco Systems Fast Handovers in Mobile IPv6 draft-koodli-mobileip-fastv6-02.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 provides security extensions to the solution proposed in the earlier version of this Koodli, Perkins, Trostle Expires 2 September 2001 [Page i] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 document for fast handovers. These security extensions are based on a light-weight version of the Kerberos Authentication Service. Koodli, Perkins, Trostle Expires 2 September 2001 [Page ii] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 Contents Status of This Memo i Abstract i 1. Fast Handover Definition 2 2. Proposal 3 3. Security Extensions 6 4. New Access Router Processing 8 5. ICMP Handover Redirect Message Format 8 5.1. Light-weight Kerberos Authentication sub option . . . . . 10 6. ICMP Handover Message Format 10 6.1. ICMP Handover Authentication Suboption Format . . . . . . 12 6.1.1. Router Solicitation and Advertisement Options . . 13 7. ICMP Handover Error Format 14 8. Security Considerations 14 A. Link Failure 15 B. Alternative to ICMP Handover Message 15 Addresses 16 Koodli, Perkins, Trostle Expires 2 September 2001 [Page 1] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 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, Trostle Expires 2 September 2001 [Page 2] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 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, which could also include the mobile node's previous CoA, 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 New Router's ND cache. This message includes Binding Update as an Koodli, Perkins, Trostle Expires 2 September 2001 [Page 3] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 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 5. 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, Trostle Expires 2 September 2001 [Page 4] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 After transmitting the Handover Redirect message to the mobile node, the Previous Router sends a ICMP Handover message (see section 6 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]. The above message from the Previous Router to the New Router MAY include security keys (see section 6.1) that the latter could use when the mobile node establishes connectivity with it. Such a transfer however, assumes that there is appropriate trust relationship between the two routers. The solution we propose in this document is applicable even when there is no such trust relationship. Furthermore, the message from the Previous Router to the New Router 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. Koodli, Perkins, Trostle Expires 2 September 2001 [Page 5] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 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 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. Security Extensions The main security issues are the security of binding updates and AAA for network access. Binding updates (BU's) are authenticated with IPSEC as described in [1]. Network access AAA (or just AAA) will require authentication and key establishment between the Mobile Node and the New Router. The New Router will also require authenticated authorization attributes for the MN. The proposal in this draft for AAA is based on the requirement that the New Router will not allow the MN's data packets to flow (although packets destined to the MN may be buffered) before the MN successfully authenticates itself. With respect to AAA security, mechanisms that require public key operations on the MN during fast handover are currently considerably compute intensive. Kerberos [5] is a possibility, but it would be better to complete authentication and key establishment in a single round trip over the air interface, regardless of trust relationships and realm boundaries. We propose to use a lightweight version of Kerberos [4]. The primary benefit is that AAA can be accomplished within a single round trip over the air interface, regardless of the trust relationship between the New Router and the Previous Router. Crossrealm lightweight ticket granting tickets (TGT's) also allow AAA to occur without round trips back to the MN user's home domain, and without requiring that the same AAA keys be used on both the Previous Router and the New Router. Diameter TLV's and other authorization attributes can be carried in lightweight tickets. The session key inside the lightweight Kerberos ticket is shared by both the New Router and the MN; it can be used to create data integrity and data confidentiality keys. Security attributes are transported in the following messages: A new suboption with the principal name and realm is added to the Handover Redirect message. A new message is added which is the MN's response to the Previous Router Handover Redirect message: the Handover Redirect Ack message. It contains the lwkerb-ap-req PDU which contains a lightweight Kerberos ticket. The Previous Router will transport the lwkerb-ap-req in the ICMP Handover message to the New Router. The New Router will (with possible assistance from a KDC) process the lwkerb-ap-req and authenticate the MN user. The New Router may need to contact the KDC, depending on which of the following three cases applies: Koodli, Perkins, Trostle Expires 2 September 2001 [Page 6] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 1. Prtr and Nrtr share a long term key (which encrypts the lightweight ticket), so Nrtr doesn't have to contact the KDC when it receives the lwkerb-ap-req. It will immediately decrypt the ticket and process the lwkerb-ap-req without any network exchanges with other servers. 2. The lwkerb-ap-req contains a ticket encrypted in the key of the local KDC so Nrtr only has to contact a KDC in its own domain. So this should take less time than having to contact a KDC in the user's domain. 3. The lwkerb-ap-req contains a ticket encrypted in the key of the user's KDC. Although Nrtr will contact a KDC in its own domain, that KDC will have to contact a KDC in the user's domain (or an intermediate proxy which then contacts the user domain KDC). A new message, Authenticated-MN (Nrtr to MN), is used to send the lwkerb-ap-rep PDU from the New Router to the MN (see Figure 4). 3 Prtr ----- Nrtr \ / 1,2 \ / 4,5 \ / MN 1. Handover Redirect (from Prtr to MN) with principal name, realm 2. Handover Redirect Ack (from MN to Prtr) with lwkerb-ap-req 3. ICMP Handover Message (from Prtr to Nrtr) with lwkerb-ap-req 4. Autheticated-MN (from Nrtr to MN) with lwkerb-ap-rep 5. Message from MN to Nrtr, e.g., a SHIN message that also includes BU from the MN to Home Agent. (it is possible to switch the order of 4 and 5). Figure 4: Message flow with security extensions The MN may also send a router solicitation message with a new suboption asking for a list of adjacent realms to be sent back in the router advertisement. The list of adjacent realms can be used by the MN to precache crossrealm lightweight TGT's targeted at adjacent realms (as a background task). This performance optimization allows subsequent authentications for adjacent realms to skip exchanges with the remote user's KDC. Instead, a local KDC will be used. Koodli, Perkins, Trostle Expires 2 September 2001 [Page 7] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 4. 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. 5. 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, Trostle Expires 2 September 2001 [Page 8] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 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|S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Router IPv6 Address (128 bits) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Access Router MAC Address (64 bits) (if present) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ New Care-of Address (128 bits) (if present) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Options ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. S If the `S' bit is set, light-weight kerberos authentication sub option 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. Koodli, Perkins, Trostle Expires 2 September 2001 [Page 9] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 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 implicitly or explicitly formed as above. Such care-of address acquisition follows the Mobile IPv6 specification [1]. 5.1. Light-weight Kerberos Authentication sub option The following sub option is used when the `S' bit is set to provide Kerberos Principal Name and Realms. 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 | Length | Kerberos Principal Name ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kerberos Principal Realm ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type. To be assigned. Length 8-bit unsigned integer. The length in bytes of the option (including the type and length fields). Principal Name Kerberos Principal Name Principal Realm Kerberos Principal Realm 6. 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. Koodli, Perkins, Trostle Expires 2 September 2001 [Page 10] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 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, which we define below based on light-weight kerberos mechanism. 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 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 Koodli, Perkins, Trostle Expires 2 September 2001 [Page 11] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 subnet. The routing prefix is naturally known to the new access router, since it is the default router for that subnet. 6.1. ICMP Handover Authentication Suboption Format In this section, we define a light-weight Kerberos Authentication sub option. Its format is shown in Figure 5. This sub option is used to transport lwkerb-ap-req and lwkerb-ap-rep messages in the ICMP handover, Handover redirect ack, and Authenticated-MN messages. 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 | Length | Lightweight Kerberos Message / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Sub option for carrying light-weight Kerberos messages Type Message type. To be assigned. Length 8-bit unsigned integer. The length in bytes of the option (including the type and length fields). LKB Lightweight Kerberos protocol message as defined in [4]. The Handover Redirect ack message and the Authenticated-MN message have the following format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Options / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Code 0 Koodli, Perkins, Trostle Expires 2 September 2001 [Page 12] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 Length length of total message in bytes Options Lightweight Kerberos Message Option (see above) or other options. 6.1.1. Router Solicitation and Advertisement Options The following router solicitation message suboption is used to request that the access router return a list of adjacent realms in its router advertisement. The access router may also return a Kerberos message suboption with a reverse ticket. 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 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type. To be assigned. Length 8-bit unsigned integer. The length in bytes of the option (including the type and length fields). The following router advertisement message suboption is used to return a list of adjacent realms in the router advertisement: 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 | Length | Realm 1... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Realm 2... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ... Realm n... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Message type. To be assigned. Length 8-bit unsigned integer. The length in bytes of the option (including the type and length fields). Realm i The realm name of the ith geographically adjacent Kerberos realm. Koodli, Perkins, Trostle Expires 2 September 2001 [Page 13] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 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. 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. The security extensions presented in this document can be used to meet the security requirements described in this section. Koodli, Perkins, Trostle Expires 2 September 2001 [Page 14] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 References [1] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in progress). draft-ietf-mobileip-ipv6-13.txt, October 2000. [2] Rajeev Koodli and Charles E. Perkins. A Framework for Smooth Handovers with Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-koodli-mobileip-smoothv6-02.txt, November 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. 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). Koodli, Perkins, Trostle Expires 2 September 2001 [Page 15] Internet Draft Fast Handovers in Mobile IPv6 2 March 2001 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:Jo+1-650n625-2359athan TrostlPhone:e +1-650 625-2986 EMail:Cirajeev.koodli@nokia.comsco EMail:Sycharliep@iprg.nokia.comstem Fax:17+10650W625-2502. Tasman DriveFax: +1 650 625-2502 San Jose, CA 95134 USA Phone: +1-408-527-6201 EMail: jtrostle@cisco.com Koodli, Perkins, Trostle Expires 2 September 2001 [Page 16]