James Kempf Internet Draft Jonathan Wood Document: draft-kempf-mobileip-fmipv6-sem-00.txt DoCoMo Communications Laboratories USA Expires: April 2003 November 2002 Improving the Architectural Alignment for FMIPv6 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This draft is an individual submission to the Mobile IP working group. 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 The FMIPv6 draft proposes a number of changes in the local link and routing information exchange architecture for wireless networks that are not quite aligned with standard IETF protocols, including the base MIPv6 protocol itself. This draft proposes modifications of FMIPv6 to tighten the semantics of anticipated care-of address configuration around the prehandover signaling as a logical extension of Router Discovery, and around the HI/HAck exchange as a logical extension of routing information propagation. It also proposes some extensions to Router Discovery for reactive handover to piggyback signaling for quickly establishing a tunnel to the Previous Access Router on top of standard RFC 2461 Router Discovery signaling. Table of Contents 1.0 INTRODUCTION....................................................2 2.0 PROBLEMS WITH FMIPV6............................................3 Kempf and Wood Informational [Page 1] Internet Draft Aligning FMIPv6 November, 2002 3.0 ARCHITECTURAL ALIGNMENT POINTS..................................5 4.0 PROPOSED PROTOCOL MODIFICATIONS.................................7 5.0 SECURITY CONSIDERATIONS.........................................9 6.0 REFERENCES.....................................................10 7.0 AUTHOR'S CONTACT INFORMATION...................................10 8.0 FULL COPYRIGHT STATEMENT.......................................11 1.0 Introduction FMIPv6 [1] describes a protocol to replace the standard Mobile IPv6 [2] movement detection algorithm. Conceptually, the protocol consists of two phases: 1) Prior to the link switch, anticipating care-of address change by performing as much of the care-of address change as possible on the old link, 2) Repair of the routing failure due to the link switch so that the Mobile Node can continue to receive packets while it completes the care-of address change on the new link. The first phase is optional, and depends on the availability of prehandover information about the Mobile Node's next destination. The implementations of some link layers, for example 802.11 [3][4], may not provide enough information or IP stack control prior to handover to achieve anticipated care-of address configuration. The first phase may also not be necessary if the link layer (for example [5]) securely conveys enough information between the Mobile Node and the Previous Access Router prior to the handover that the Previous and New Access Routers can complete the second phase without any wireless IP signaling. The second phase consists of two steps: 1) Establishing a bidirectional tunnel between the Previous Access Router and the New Access Router prior to the link switch, if possible, or as soon as possible after the link switch, if necessary, 2) Forwarding of packets between the old link and new through the bidirectional tunnel so the Mobile Node can send and receive packets under its old care-of address while on the new link. Kempf and Wood Informational [Page 2] Internet Draft Aligning FMIPv6 November, 2002 If prehandover information is available, the tunnel can be set up prior to the handover. If not, the Mobile Node will lose packets during the link switch (unless they are buffered by the Previous Access Router), but quick action on the part of the Mobile Node or the Access Router after the link switch can establish the tunnel. In either case, the tunnel maintains the flow of packets while the Mobile Node undergoes the time-consuming process of changing its care-of address binding at the Home Agent and performing route optimization with any Correspondent Nodes. In this draft, we describe some cases in which the FMIPv6 design is not well aligned with the base IPv6 local link routing protocol [6], standard IPv6 routing information exchange, and the base MIPv6 protocol [2]. We suggest a few minor changes to tighten the semantics of anticipated care-of address configuration around the Router Solicitation for Proxy (RtSolPrxy) and Proxy Router Advert (PrxyRtAdv) messages, and to align posthandover routing information propagation with standard IPv6 Neighbor Discovery [6]. We view this approach as an extension of the base MIPv6 philosophy of not introducing any novel MIPv6-specific features into the access link, but rather confining MIPv6-specific features to the home network and utilizing standard IPv6 access link features (or, in this case, modest extensions) for handover. We consider in this draft the cases where anticipated care-of address change is necessary or where it is not possible due to lack of enough link layer information prior to the link switch. We do not consider the case in which enough prehandover information is available from the link layer to avoid the need for anticipated care-of address change. 2.0 Problems with FMIPv6 Some of the problems in FMIPv6 are involved in proposed changes in binding update semantics. The base MIPv6 draft [2] has two uses of binding update: 1) From the Mobile Node to the Home Agent after the Mobile Node has completed care-of address configuration on the local link, to change the routing at the Home Agent to the new care-of address. The Mobile Node uses an IPsec security association between the Mobile Node and Home Agent for security. 2) From the Mobile Node to the Correspondent Node after the Mobile Node has completed care-of address configuration, and concurrently with Home Agent binding update, to change the Correspondent Node's routing to the new care-of address. The Mobile Node uses return routability by default for security. In both cases, the Mobile Node is in the topologically correct place for the routing update (i.e. the source address of the packet is on the local link), and there is a clearly defined security algorithm for securing the routing change. Kempf and Wood Informational [Page 3] Internet Draft Aligning FMIPv6 November, 2002 The following subsections detail specific problems with FMIPv6. 2.1 Lack of Confirmed Prehandover Care-of Address Configuration The FMIPv6 draft contains a message, Fast Neighbor Discovery (FND), which the Mobile Node is specified to use when it moves onto a new link and is still "unsure" whether it should uses the anticipated care-of address. The reason for this message is unclear, but it seems to relate to the lack of a specific invariant in the prehandover RtSolPrxy/PrxyRtAdv message sequence which assures the Mobile Node that it can use the preconfigured new care-of address for initiating binding changes at the Home Agent and Correspondent Nodes immediately after it has switched links. 2.2 Bidirectional Tunnel Activation Times Unclear The FMIPv6 draft specifies that FBU should be sent immediately after the PrxyRtAdv is received, and that the Previous Access Router should wait to activate the bidirectional tunnel to the New Access Router until an FBU is received. The source address in the FBU is specified to be the previous care-of address. If the Mobile Node is still on the old link, then the FBU source address is topologically correct, and the routing information from the Previous Access Router is current so that the FBU is being routed properly. If, however, the Mobile Node has moved to the New Access Router, the FBU source address is no longer topologically correct. If the bidirectional tunnel were active, this would not be a problem, however, the tunnel is not activated until *after* the FBU is received at the Previous Access Router. The relationship between when the routing tunnel is activated from the New Access Router and from the Previous Access Router is thus unclear. The tunnel from the Previous Access Router to the New Access Router is only activated by the FBU, but the tunnel from the New Access Router to the Previous Access Router is presumed to be activated by the HI/HAck sequence, otherwise the FBU with the Previous Care of Address could not be sent to the Previous Access Router, though this is not stated in the draft. The draft is unclear why routing in one direction on the tunnel should be activated after routing in the other, and why explicit signaling is required to activate the tunnel on the Previous Access Router but not on the New Access Router. 2.3 Unclear Security on FBU The FMIPv6 draft states that the Mobile Node should use Neighbor Discovery security if the FBU is sent while the Mobile Node is still on the old link, but if the FBU is sent when the Mobile Node moves to the new link, Neighbor Discovery security cannot be used because the Previous Access Router is now more than one hop removed from the Kempf and Wood Informational [Page 4] Internet Draft Aligning FMIPv6 November, 2002 Mobile Node. The draft is not clear how the FBU should be secured in this case. 2.4 New Access Router Address Not Secured In order to use an address as an alternate care-of address, the Mobile Node MUST perform the return routability test with the address used in the Alternate Care-of Address option ([2] Section 5.2.6). The FBU uses the New Access Router as an alternate care-of address, in the FBU sent to the Previous Access Router to activate the tunnel. However, the Mobile Node is not required to perform return routability with the New Access Router, nor is it entirely clear whether this would be such a good idea, since it would result in performance degradation. The Mobile Node cannot use Neighbor Discovery security because the FBU may be sent while the Mobile Node is on the old link. 2.5 Practicality of FBU Signaling Although this is not an architectural point, the practicality of the FBU signaling is entirely unclear. If the FBU is sent when the Mobile Node is still on the Previous Access Router, the tunnel is activated and the Mobile Node can no longer send and receive packets until it moves to the new link. The FBU is largely useless in this case, because the tunnel could just as well have been activated by the HI/HAck. If the FBU is sent after the Mobile Node moves, it delays activation of the tunnel for some period of time until the Previous Access Router responds. During this time, the Mobile Node can lose packets if the Previous Access Router drops them. If the FBU transmission is interrupted by the handover, the Mobile Node must resend after switching links. The FBU thus increases the number of messages that must successfully negotiate the wireless link during the difficult transmission and reception conditions around handover without really contributing much, if anything, to accelerating handover. 3.0 Architectural Alignment Points This section contains a few points that align FMIPv6 more closely with the standard IPv6 on-link routing and routing information distribution architecture. 3.1 New Care-of Address Invariant After the completion of RtSolPrxy/PrxyRtAdv, an invariant is established: either the Mobile Node has a confirmed care-of address on the new link or it doesn't. If the Mobile Node has a confirmed new care-of address, it can use the address to begin changing bindings on the Home Agent and Correspondent Nodes immediately when it reaches the new link. If the Mobile Node doesn't have a new care- of address, the optimization is considered to have failed and the MN Kempf and Wood Informational [Page 5] Internet Draft Aligning FMIPv6 November, 2002 must perform standard Mobile IP movement detection, considerably simplifing error handling If the handover is anticipated and network triggered (i.e. a gratuitous PrxyRtAdv is sent), the Previous Access Router sends the MN's current host identifier in the HI, the New Access Router replies with a confirmed address that it is prepared to defend. If the handover is anticipated and mobile triggered, the MN sends its desired host identifier in the RtSolPrxy, the Previous Access Router forwards that to the New Access Router, and the New Access Router returns the confirmed address. If the handover is reactive (i.e. there is no prehandover signaling), the MN sends its desired host identifier in the Router Solicitation (RS) and the New Access Router sends a confirmed address back in the Router Advertisement (RA). Note that this requires the New Access Router to be able to quickly determine whether a proposed new care-of address would not result in a collision on the link. The suggested way for the New Access Router to achieve this is for the neighbor cache data structure defined in [6] to be a neighbor table, that is, for the neighbor cache entries to be locked down so that they constitute a complete map of the IP addresses and Layer 2 identifiers of all hosts on the link. This technique is used in Mobile IPv4 at the Foreign Agent to lock down the ARP cache entry until the MN deregisters [8]. 3.2 HI/HAck Constitutes Routing Information Propagation The HI/HAck message exchange between the Previous and New Access Routers constitutes the exchange of routing information, specifically, the propagation of a source route from the Previous Access Router to the New Access Router for purposes of establishing a bidirectional tunnel. As such, the exchange MUST be secured with the same security association as is used for exchanging routing information through the Interior Gateway Protocol between the two routers. This assures that any redirection of packets between the routers is the result of information obtained from an authentic source. Furthermore, once the HI/HAck message completes, the bidirectional tunnel is (logically) activated and packets to/from the Mobile Node's previous care-of address are routed through the tunnel. As a practical matter, the Previous Access Router may obtain information from the link layer, in a secure fashion, that allows a finer grained determination of when to activate the tunnel. In addition, the New Access Router may perform additional buffering, beyond the simple 3 packet buffer of Neighbor Discovery, in order to smooth the handover. These are additional optimizations that may be available in specific implementations. 3.3 On-Link Signaling Extends Neighbor Discovery The RtSolPrxy/PrxyRtAdv signaling prior to handover to establish the care-of address and signaling after handover to start or terminate the tunnel is an extension of the on-link routing protocol defined Kempf and Wood Informational [Page 6] Internet Draft Aligning FMIPv6 November, 2002 by Neighbor Discovery. As such, any exchanges MUST be secured with the same security association as is used for standard IPv6 Neighbor Discovery. RFC 2461 [6] specifies that IPsec AH headers MUST be included on all Neighbor Discovery packets, but the specification is not complete and there is ongoing work in the IETF to define Neighbor Discovery security more precisely. Furthermore, all signaling to change routing is done between the Mobile Node and its current on-link router. This allows the local Neighbor Discovery security to be used, and avoids the need for defining how to set up a different kind of security association. 4.0 Proposed Protocol Modifications This section describes a modification of FMIPv6 to align the protocol more closely with the architectural points in Section 3.0. 4.1 Anticipated Care-of Address Configuration Prior to the link switch, the Mobile Node and/or the Previous Access Router can optionally perform anticipated care-of address configuration if supported by sufficient link layer information. The following steps are followed: 1) If the handover is mobile-triggered, the Mobile Node sends a RtSolPrxy to the Previous Access Router with the following extensions: an (optional) proposed host identifier for the last 64 bits of the Mobile Node's new care-of address and a (required) Layer 2 address for the access point to which the Mobile Node will be connecting. The source address is the Mobile Node's current care-of address. 2) The Previous Access Router uses the Layer 2 address of the new access point to determine the Subnet Router Anycast Address [9] for the subnet corresponding to the access point Layer 2 address. The method whereby the Previous Access Router obtains the mapping between access point Layer 2 addresses and router addresses is outside the scope of this specification. 3) The Previous Access Router sends a HI message to the New Access Router containing the Layer 2 address of the Mobile Node, the previous care-of address of the Mobile Node, and the proposed Mobile Node new care-of address host identifier. If the Mobile Node did not send a host identifier, or if the handover was triggered at the Previous Access Router (i.e. network- triggered), the Previous Access Router uses the same host identifier as the Mobile Node used in its current care-of address. 4) The New Access Router forms a care-of address for the Mobile Node and checks its neighbor table to determine if the proposed care-of address is in use. If the address is not in use, the New Access Router returns a HAck indicating that the address is OK. If the address is in use, the New Access Router returns an Kempf and Wood Informational [Page 7] Internet Draft Aligning FMIPv6 November, 2002 indication that the address is not OK, terminating the optimization. 5) The New Access Router defends the proposed address until the Mobile Node arrives on the link and announces that it has completed care-of address configuration. 4.2 Tunnel Establishment and Activation The HI/HAck exchange triggered by anticipated care of address establishment between the Previous Access Router and New Access router both establishes and activates the tunnel. Upon receipt of the HAck, The Previous Access Router establishes a forward host route for the previous care-of address to the tunnel. Upon sending the HAck, the New Access Routers installs a reverse host route for the previous care-of address to the tunnel and a forward host route for the previous care-of address to the Layer 2 address on the link. The New Access Router modifies its ingress filter to install a /128 prefix for passing the Mobile Node's previous care-of address, while the Previous Access Router modifies its ingress filter to exclude packets having the Mobile Node's previous care-of address. Upon completion of the HI/HAck exchange, packets with destination address being the Mobile Node's previous care-of address arriving at the Previous Access Router's wired interface are tunneled to the New Access Router, and packets arriving at the New Access Router's wireless interface having the Mobile Node's source address are tunneled to the Previous Access Router. As a practical matter, the Mobile Node may still be on the old link and the Previous Access Router may delay activating the tunnel and modifying its ingress filter until the Mobile Node leaves the link. Similarly, the New Access Router may delay activating the tunnel and modifying its ingress filter until the Mobile Node arrives on the link. The New Access Router may also buffer traffic to the Mobile Node received down the tunnel if it has not yet received link layer notification that the Mobile Node has arrived. If anticipated care-of address configuration is not possible, the Mobile Node may trigger tunnel establishment from the new link. Immediately upon arrival on the new link, if the Mobile Node has not performed anticipated care-of address configuration, the Mobile Node sends a Router Advertisement Solicatitation message to the All Routers Multicast Address, containing the Subnet Router Anycast Address of the Previous Access Router, the Mobile Node's previous care-of address, and the Mobile Node's Layer 2 identifier, and a proposed host identifier for the new care-of address. A designated default router on the link assumes the role of the New Access Router, and contacts the Previous Access Router by sending a HI message, including the Mobile Node's previous care-of address and Layer 2 identifier. If that information matches one of the Previous Access Router's neighbor table entries, the Previous Access Router responds with a HAck confirming the tunnel request, and the tunnel is activated. Kempf and Wood Informational [Page 8] Internet Draft Aligning FMIPv6 November, 2002 In addition, the New Access Router includes a proposed new care-of address in the Router Advertisement that it sends back to the Mobile Node. The Mobile Node can get a jumpstart on configuring the new care-of address and start sending the BUs to the HA and CNs right away, rather than having to go through DAD (optimized or unoptimized). If the Mobile Node would prefer a different subnet prefix, it can discard the proposed new care-of address and form a different one. The Router Advertisement also includes an indication that the tunnel establishement succeeded. If the tunnel did not succeed, the Mobile Node should refrain from sending out any packets under the previous care-of address and fall back to standard MIPv6 handover, waiting until all binding updates are complete. 4.3 Tunnel Termination After anticipated handover signaling, once the Mobile Node is on the new link it either has a new care-of address that it can use to start updating routing on the Home Agent and Correspondent Nodes or it doesn't. If it doesn't, then it SHOULD use standard IPv6 Address Autoconfiguration or stateful address configuration to obtain a new address. The Mobile Node MAY continue to use the old care-of address for some period of time. The New Access Router continues to renew the tunnel until the Mobile Node has completed care-of address configuration, subject to network operator policy. If the tunnel must be terminated for any reason, the New Access Router sends the Mobile Node a Router Advertisement with a tunnel termination extension containing the remaining lifetime of the tunnel. At this point, the Mobile Node MUST complete configuration of the new care- of address by the time the tunnel expires, or risk losing IP service. When the Mobile Node is ready to terminate the tunnel, it sends a Neighbor Advertisment message to the All Router's Multicast Address with an extension that includes the Subnet Router Anycast Address of the Previous Access Router and the Previous care-of address indicating that it is fully up on the link. If the New Access Router finds a source route for the Mobile Node to the indicated Previous Access Router IP address, the New Access Router sends a HI message to the Previous Access Router indicating that the tunnel should be terminated. 5.0 Security Considerations There are two kinds of trust relationships involved in the proposed modifications to FMIPv6: Kempf and Wood Informational [Page 9] Internet Draft Aligning FMIPv6 November, 2002 1) A trust relationship between a node and its access router. This relationship only lasts as long as the node is on-link and the access router is acting as the next hop router for the node. 2) A trust relationship between two routers within an interior routing domain. A node asking its access router for a modification in its routing is verified using a security association for the first trust relationship. If the request is authentic, then the second trust relationship is activated when the access router asks the proposed new access router for the routing change. The new router utilizes the security association for the second trust relationship to verify the routing request. Additional simple security measures can reduce the need for expensive cryptographic computation as an adjunct to security associations for the two trust relationships. Setting the TTL to 255 for on-link signaling, such as is done in Neighbor Discovery, allows the router or host to quickly check that no off-link node can change the routing for an on-link host. Requiring the New Access Router to check the IP address of the Previous Access Router before terminating a tunnel avoids a denial of service attack. Other such simple measures are possible and should be included in the design. 6.0 References [1] Koodli, R., editor, "Fast Handovers for Mobile IPv6," draft- ietf-mobileip-fast-mipv6-05.txt, a work in progress. [2] Johnson, D., et. al. " Mobility Support in IPv6," draft-ietf- mobileip-ipv6-17.txt, a work in progress. [3] McCann, P., " Mobile IPv6 Fast Handovers for 802.11 Networks," draft-mccann-mobileip-80211fh-00.txt, a work in progress. [4] IEEE, " Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications," ISO/IEEE 8802-11, 1999. [5] 3GPP2, "Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum Systems," 3GPP2 C.S0005-C, Version 1.0, May 28, 2002. [6] Narten, T., Nordmark, E., and Simson, W., "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December, 1998. [7] Thompson, S., and Narten, T., " IPv6 Stateless Address Autoconfiguration," RFC 2462, December 1998. [8] Perkins, C., "IP Mobility Support for IPv4," RFC 3220, January 2002. [9] Hinden, R., and Deering, S., "IP Version 6 Addressing Architecture," draft-ietf-ipngwg-addr-arch-v3-10.txt, a work in progress. 7.0 Author's Contact Information Kempf and Wood Informational [Page 10] Internet Draft Aligning FMIPv6 November, 2002 James Kempf Phone: +1 408 451 4711 DoCoMo Communications Email: kempf@docomolabs-usa.com Laboratories USA 180 Metro Drive Suite 300 San Jose, CA USA 95430 Jonathan Wood Email: wood@docomolabs-usa.com DoCoMo Communications Laboratories USA 180 Metro Drive Suite 300 San Jose, CA USA 95430 8.0 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kempf and Wood Informational [Page 11]