MIPSHOP Working Group Rajeev. Koodli (Editor) Internet-Draft February 25, 2008 Intended status: Standards Track Expires: August 28, 2008 Mobile IPv6 Fast Handovers draft-ietf-mipshop-fmipv6-rfc4068bis-06.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from an Access Router to another, a process referred to as handover. During this time, the Mobile Node is unable to send or receive packets due to both link switching delay and IP protocol operations. The "handover latency" resulting from standard Mobile IPv6 procedures, namely, movement detection, new Care of Address configuration and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover Koodli (Editor) Expires August 28, 2008 [Page 1] Internet-Draft MIP6 Fast Handovers February 2008 latency could be beneficial to non real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. Koodli (Editor) Expires August 28, 2008 [Page 2] Internet-Draft MIP6 Fast Handovers February 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Addressing the Handover Latency . . . . . . . . . . . . . 6 3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . . 9 3.3. Protocol Operation during Network-initiated Handover . . . 10 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 12 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 16 5.1. Handover Capability Exchange . . . . . . . . . . . . . . . 16 5.2. Determining New Care of Address . . . . . . . . . . . . . 16 5.3. Prefix Management . . . . . . . . . . . . . . . . . . . . 17 5.4. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17 5.5. DAD Handling . . . . . . . . . . . . . . . . . . . . . . . 18 5.6. Fast or Erroneous Movement . . . . . . . . . . . . . . . . 18 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. New Neighborhood Discovery Messages . . . . . . . . . . . 19 6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) . . . . . . . . . . . . . . . . . . . . . . 19 6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . 21 6.2. Inter-Access Router Messages . . . . . . . . . . . . . . . 25 6.2.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 25 6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 26 6.3. New Mobility Header Messages . . . . . . . . . . . . . . . 28 6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . 28 6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . . . 30 6.4. Unsolicited Neighbor Advertisement (UNA) . . . . . . . . . 31 6.5. New Options . . . . . . . . . . . . . . . . . . . . . . . 32 6.5.1. IP Address/Prefix Option . . . . . . . . . . . . . . . 33 6.5.2. Link-layer Address (LLA) Option . . . . . . . . . . . 34 6.5.3. Mobility Header Link-layer Address (MH-LLA) Option . . 35 6.5.4. Binding Authorization Data for FMIPv6 (BADF) . . . . . 36 6.5.5. Neighbor Advertisement Acknowledgment (NAACK) . . . . 37 7. Related Protocol and Device Considerations . . . . . . . . . . 38 8. Configurable Parameters . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 9.1. Peer Authorization Database Entries when using IKEv2 . . . 40 9.2. Security Policy Database Entries . . . . . . . . . . . . . 41 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 12.1. Normative References . . . . . . . . . . . . . . . . . . . 43 12.2. Informative References . . . . . . . . . . . . . . . . . . 44 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 44 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 Intellectual Property and Copyright Statements . . . . . . . . . . 48 Koodli (Editor) Expires August 28, 2008 [Page 3] Internet-Draft MIP6 Fast Handovers February 2008 1. Introduction Mobile IPv6 [rfc3775] describes the protocol operations for a mobile node to maintain connectivity to the Internet during its handover from one access router to another. These operations involve link layer procedures, movement detection, IP address configuration, and location update. The combined handover latency is often sufficient to affect real-time applications. Throughput-sensitive applications can also benefit from reducing this latency. This document describes a protocol to reduce the handover latency. This specification addresses the following problem: how to allow a mobile node to send packets as soon as it detects a new subnet link, and how to deliver packets to a mobile node as soon as its attachment is detected by the new access router. The protocol defines IP protocol messages necessary for its operation regardless of link technology. It does this without depending on specific link-layer features while allowing link-specific customizations. By definition, this specification considers handovers that interwork with Mobile IP: once attached to its new access router, a MN engages in Mobile IP operations including Return Routability [rfc3775]. There are no special requirements for a mobile node to behave differently with respect to its standard Mobile IP operations. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "silently ignore" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The following terminology and abbreviations are used in this document in addition to those defined in [rfc3775]. The reference handover scenario is illustrated in Figure 1. Mobile Node (MN): A Mobile IPv6 host Access Point (AP): A Layer 2 device connected to an IP subnet that offers wireless connectivity to a MN. An Access Point Identifier (AP-ID) refers the AP's L2 address. Sometimes, AP-ID is also referred to as a Basic Service Set IDentifier (BSSID). Access Router (AR): The MN's default router Previous Access Router (PAR): The MN's default router prior to its handover Koodli (Editor) Expires August 28, 2008 [Page 4] Internet-Draft MIP6 Fast Handovers February 2008 New Access Router (NAR): The MN's anticipated default router subsequent to its handover Previous CoA (PCoA): The MN's Care of Address valid on PAR's subnet New CoA (NCoA): The MN's Care of Address valid on NAR's subnet Handover: A process of terminating existing connectivity and obtaining new IP connectivity Router Solicitation for Proxy Advertisement (RtSolPr): A message from the MN to the PAR requesting information for a potential handover Proxy Router Advertisement (PrRtAdv): A message from the PAR to the MN that provides information about neighboring links facilitating expedited movement detection. The message can also act as a trigger for network-initiated handover. (AP-ID, AR-Info) tuple: Contains an access router's L2 and IP addresses, and prefix valid on the interface to which the Access Point (identified by AP-ID) is attached. The triplet [Router's L2 address, Router's IP address and Prefix] is called "AR-Info". See also Section 5.3. Neighborhood Discovery: The process of resolving neighborhood AP- IDs to AR-Info Assigned Addressing: A particular type of NCoA configuration in which the NAR assigns an IPv6 address for the MN. The method by which NAR manages its address pool is not specified in this document. Fast Binding Update (FBU): A message from the MN instructing its PAR to redirect its traffic (towards NAR) Fast Binding Acknowledgment (FBack): A message from the PAR in response to FBU Predictive Fast Handover: The fast handover in which a MN is able to send FBU when it is attached to the PAR, which then establishes forwarding for its traffic (even before the MN attaches to the NAR) Koodli (Editor) Expires August 28, 2008 [Page 5] Internet-Draft MIP6 Fast Handovers February 2008 Reactive Fast Handover: The fast handover in which a MN is able to send the FBU only after attaching to the NAR Unsolicited Neighbor Advertisement (UNA): The message in [rfc4861] with 'O' bit cleared Fast Neighbor Advertisement (FNA): This message from RFC4068 [rfc4068] is deprecated. The UNA message above is the preferred message in this specification. Handover Initiate (HI): A message from the PAR to the NAR regarding a MN's handover Handover Acknowledge (HAck): A message from the NAR to the PAR as a response to HI v +--------------+ +-+ | Previous | < | | ------------ | Access | ------- >-----\ +-+ | Router | < \ MN | (PAR) | \ | +--------------+ +---------------+ | ^ IP | Correspondent | | | Network | Node | V | +---------------+ v / v +--------------+ / +-+ | New | < / | | ------------ | Access | ------- >-----/ +-+ | Router | < MN | (NAR) | +--------------+ Figure 1: Reference Scenario for Handover 3. Protocol Overview 3.1. Addressing the Handover Latency The ability to immediately send packets from a new subnet link depends on the "IP connectivity" latency, which in turn depends on the movement detection latency and the new CoA configuration latency. Once a MN is IP-capable on the new subnet link, it can send a Binding Update to its Home Agent and one or more correspondents. Once its correspondents successfully process the Binding Update, which Koodli (Editor) Expires August 28, 2008 [Page 6] Internet-Draft MIP6 Fast Handovers February 2008 typically involves the Return Routability procedure, the MN can receive packets at the new CoA. So, the ability to receive packets from correspondents directly at its new CoA depends on the Binding Update latency as well as the IP connectivity latency. The protocol enables a MN to quickly detect that it has moved to a new subnet by providing the new access point and the associated subnet prefix information when the MN is still connected to its current subnet (i.e., PAR in Figure 1). For instance, a MN may discover available access points using link-layer specific mechanisms (e.g., a "scan" in WLAN) and then request subnet information corresponding to one or more of those discovered access points. The MN may do this after performing router discovery. The MN may also do this at any time while connected to its current router. The result of resolving an identifier associated with an access point is a [AP-ID, AR-Info] tuple, which a MN can use in readily detecting movement: when attachment to an access point with AP-ID takes place, the MN knows the corresponding new router's co-ordinates including its prefix, IP address and L2 address. The "Router Solicitation for Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement (PrRtAdv)" messages in Section 6.1 are used for aiding movement detection. Through the RtSolPr and PrRtAdv messages, the MN also formulates a prospective new CoA (NCoA), when it is still present on the PAR's link. Hence, the latency due to new prefix discovery subsequent to handover is eliminated. Furthermore, this prospective address can be used immediately after attaching to the new subnet link (i.e., NAR's link) when the MN has received a "Fast Binding Acknowledgment (FBack)" (see Section 6.3.2) message prior to its movement. In the event it moves without receiving an FBack, the MN can still start using NCoA after announcing its attachment through an unsolicited Neighbor Advertisement message (with the 'O' bit set to zero) message [rfc4861]; NAR responds to to this UNA message in case it wishes to provide a different IP address to use. In this way, NCoA configuration latency is reduced. The information provided in the PrRtAdv message can be used even when DHCP [rfc3315] is used to configure an NCoA on the NAR's link. In this case, the protocol supports forwarding using PCoA, and the MN performs DHCP once it attaches to the NAR's link. The MN still formulates an NCoA for FBU processing; however, it MUST NOT send packets using this NCoA. In order to reduce the Binding Update latency, the protocol specifies a binding between the Previous CoA (PCoA) and NCoA. A MN sends a "Fast Binding Update" (see Section 6.3.1) message to its Previous Access Router to establish this tunnel. When feasible, the MN SHOULD Koodli (Editor) Expires August 28, 2008 [Page 7] Internet-Draft MIP6 Fast Handovers February 2008 send FBU from PAR's link. Otherwise, it should send it immediately after detecting attachment to NAR. An FBU message MUST contain the Binding Authorization Data for FMIPv6 (BADF) option (see Section 6.5.4) in order to ensure that only a legitimate MN that owns the PCoA is able to establish a binding. Subsequent sections describe the protocol mechanics. In any case, the result is that PAR begins tunneling packets arriving for PCoA to NCoA. Such a tunnel remains active until the MN completes the Binding Update with its correspondents. In the opposite direction, the MN SHOULD reverse tunnel packets to PAR, again until it completes Binding Update. And, PAR SHOULD forward the inner packet in the tunnel to its destination (i.e., to the MN's correspondent). Such a reverse tunnel ensures that packets containing PCoA as source IP address are not dropped due to ingress filtering. Even though the MN is IP-capable on the new link, it cannot use NCoA directly with its correspondents without the correspondents first establishing a binding cache entry (for NCoA). Forwarding support for PCoA is provided through a reverse tunnel between the MN and the PAR. Setting up a tunnel alone does not ensure that the MN receives packets as soon as attaching to a new subnet link, unless NAR can detect the MN's presence. A neighbor discovery operation involving a neighbor's address resolution (i.e., Neighbor Solicitation and Neighbor Advertisement) typically results in considerable delay, sometimes lasting multiple seconds. For instance, when arriving packets trigger NAR to send Neighbor Solicitation before the MN attaches, subsequent re-transmissions of address resolution are separated by a default period of one second each. In order to circumvent this delay, a MN announces its attachment immediately with an UNA message that allows NAR to forward packets to the MN right away. Through tunnel establishment for PCoA and fast advertisement, the protocol provides expedited forwarding of packets to the MN. The protocol also provides the following important functionalities. The access routers can exchange messages to confirm that a proposed NCoA is acceptable. For instance, when a MN sends FBU from PAR's link, FBack can be delivered after NAR considers NCoA acceptable to use. This is especially useful when addresses are assigned by the access router. The NAR can also rely on its trust relationship with PAR before providing forwarding support for the MN. That is, it may create a forwarding entry for NCoA subject to "approval" from PAR which it trusts. In addition, buffering for handover traffic may be desirable. Even though the Neighbor Discovery protocol provides a small buffer (typically one or two packets) for packets awaiting address resolution, this buffer may be inadequate for traffic such as VoIP already in progress. The routers may also wish to maintain a separate buffer for servicing the handover traffic. Finally, the access routers could transfer network-resident contexts, such as Koodli (Editor) Expires August 28, 2008 [Page 8] Internet-Draft MIP6 Fast Handovers February 2008 access control, QoS, header compression, in conjunction with handover (although the context transfer process itself is not specified in this document). For all these operations, the protocol provides "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages (see Section 6.2). Both of these messages SHOULD be used. The access routers MUST have necessary security association established by means outside the scope of this document. 3.2. Protocol Operation The protocol begins when a MN sends RtSolPr to its access router to resolve one or more Access Point Identifiers to subnet-specific information. In response, the access router (e.g., PAR in Figure 1) sends a PrRtAdv message which contains one or more [AP-ID, AR-Info] tuples. The MN may send RtSolPr at any convenient time, for instance as a response to some link-specific event (a ``trigger'') or simply after performing router discovery. However, the expectation is that prior to sending RtSolPr, the MN has discovered the available APs by link-specific methods. The RtSolPr and PrRtAdv messages do not establish any state at the access router, and their packet formats are defined in Section 6.1. With the information provided in the PrRtAdv message, the MN formulates a prospective NCoA and sends an FBU message. The purpose of FBU is to authorize PAR to bind PCoA to NCoA, so that arriving packets can be tunneled to the new location of the MN. The FBU should be sent from PAR's link whenever feasible. For instance, an internal link-specific trigger could enable FBU transmission from the previous link. When it is not feasible, FBU is sent from the new link. The format and semantics of FBU processing are specified in Section 6.3.1. The FBU message MUST contain the BADF option (see Section 6.5.4) to secure the message. Depending on whether an FBack is received or not on the previous link, which clearly depends on whether FBU was sent in the first place, there are two modes of operation. 1. The MN receives FBack on the previous link. This means that packet tunneling would already be in progress by the time the MN handovers to NAR. The MN SHOULD send UNA immediately after attaching to NAR, so that arriving as well as buffered packets can be forwarded to the MN right away. Before sending FBack to MN, PAR can determine whether NCoA is acceptable to NAR through the exchange of HI and HAck messages. When assigned addressing (i.e., addresses are assigned by the Koodli (Editor) Expires August 28, 2008 [Page 9] Internet-Draft MIP6 Fast Handovers February 2008 router) is used, the proposed NCoA in FBU is carried in HI, and NAR MAY assign the proposed NCoA. Such an assigned NCoA MUST be returned in HAck, and PAR MUST in turn provide the assigned NCoA in FBack. If there is an assigned NCoA returned in FBack, the MN MUST use the assigned address (and not the proposed address in FBU) upon attaching to NAR. 2. The MN does not receive FBack on the previous link. One reason for this is that the MN has not sent the FBU. The other is that the MN has left the link after sending the FBU, which may be lost, but before receiving an FBack. Without receiving an FBack in the latter case, the MN cannot ascertain whether PAR has successfully processed the FBU. Hence, the MN (re)sends FBU immediately after sending the UNA message. If NAR chooses to supply a different IP address to use than the NCoA, it MAY sends a Router Advertisement with "Neighbor Advertisement Acknowledge (NAACK)" option in which it includes an alternate IP address for the MN to use. Detailed UNA processing rules are specified in Section 6.4. The scenario in which a MN sends FBU and receives FBack on PAR's link is illustrated in Figure 2. For convenience, this scenario is called "predictive" mode of operation. The scenario in which the MN sends FBU from NAR's link is illustrated in Figure 3. For convenience, this scenario is called "reactive" mode of operation. Note that the reactive mode also includes the case when FBU has been sent from PAR's link but FBack has not been received yet. The Figure is intended to illustrate that the FBU is forwarded through NAR, but it is processed only by the PAR. Finally, the PrRtAdv message may be sent unsolicited, i.e., without the MN first sending RtSolPr. This mode is described in Section 3.3. 3.3. Protocol Operation during Network-initiated Handover In some wireless technologies, the handover control may reside in the network even though the decision to undergo handover may be arrived at by cooperation between the MN and the network. In such networks, the PAR can send an unsolicited PrRtAdv containing the link layer address, IP address and subnet prefix of the NAR when the network decides that a handover is imminent. The MN MUST process this PrRtAdv to configure a new care of address on the new subnet, and MUST send an FBU to PAR prior to switching to the new link. After transmitting PrRtAdv, the PAR MUST continue to forward packets to the MN on its current link until the FBU is received. The rest of the operation is the same as that described in Section 3.2. Koodli (Editor) Expires August 28, 2008 [Page 10] Internet-Draft MIP6 Fast Handovers February 2008 The unsolicited PrRtAdv also allows the network to inform the MN about geographically adjacent subnets without the MN having to explicitly request that information. This can reduce the amount of wireless traffic required for the MN to obtain a neighborhood topology map of links and subnets. Such usage of PrRtAdv is decoupled from the actual handover. See Section 6.1.2. MN PAR NAR | | | |------RtSolPr------->| | |<-----PrRtAdv--------| | | | | |------FBU----------->|----------HI--------->| | |<--------HAck---------| | <--FBack---|--FBack---> | | | | disconnect forward | | packets ===============>| | | | | | | connect | | | | | |------------UNA --------------------------->| |<=================================== deliver packets | | Figure 2: Predictive Fast Handover Koodli (Editor) Expires August 28, 2008 [Page 11] Internet-Draft MIP6 Fast Handovers February 2008 MN PAR NAR | | | |------RtSolPr------->| | |<-----PrRtAdv--------| | | | | disconnect | | | | | | | | connect | | |-------UNA-----------|--------------------->| |-------FBU-----------|---------------------)| | |<-------FBU----------)| | |<------HI/HAck------->| | | (if necessary) | | forward | | packets(including FBAck)=====>| | | | |<=================================== deliver packets | | Figure 3: Reactive Fast Handover 4. Protocol Details All description makes use of Figure 1 as the reference. After discovering one or more nearby access points, the MN sends RtSolPr in order to resolve access point identifiers to subnet router information. A convenient time to do this is after performing router discovery. However, the MN can send RtSolPr at any time, e.g., when one or more new access points are discovered. The MN can also send RtSolPr more than once during its attachment to PAR. The trigger for sending RtSolPr can originate from a link-specific event, such as the promise of a better signal strength from another access point coupled with fading signal quality with the current access point. Such events, often broadly referred to as "L2 triggers", are outside the scope of this document. Nevertheless, they serve as events that invoke this protocol. For instance, when a "link up" indication is obtained on the new link, protocol messages (e.g., UNA) can be immediately transmitted. Implementations SHOULD make use of such triggers whenever available. The RtSolPr message contains one or more AP-IDs. A wildcard requests all available tuples. As a response to RtSolPr, PAR sends a PrRtAdv message which indicates Koodli (Editor) Expires August 28, 2008 [Page 12] Internet-Draft MIP6 Fast Handovers February 2008 one of the following possible conditions. 1. If the PAR does not have an entry corresponding to the new access point, it responds indicating that the new access point is unknown. The MN MUST stop fast handover protocol operations on the current link. The MN MAY send an FBU from its new link. 2. If the new access point is connected to the PAR's current interface (to which MN is attached), PAR responds with a Code value indicating that the new access point is connected to the current interface, but not send any prefix information. This scenario could arise, for example, when several wireless access points are bridged into a wired network. No further protocol action is necessary. 3. If the new access point is known and the PAR has information about it, then PAR responds indicating that the new access point is known and supply the [AP-ID, AR-Info] tuple. If the new access point is known, but does not support fast handover, the PAR MUST indicate this with Code 3 (see Section 6.1.2). 4. If a wildcard is supplied as an identifier for the new access point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples subject to path MTU restrictions (i.e., provide any 'n' tuples without exceeding the link MTU). When further protocol action is necessary, some implementations may choose to provide buffering support at PAR to address the scenario in which a MN leaves without sending an FBU message from the PAR's link. While the protocol does not forbid such an implementation support, care must be taken to ensure that the PAR continues forwarding packets to the PCoA (i.e., uses a buffer and forward approach). The PAR should also stop buffering once it processes the FBU message. The method by which Access Routers exchange information about their neighbors and thereby allow construction of Proxy Router Advertisements with information about neighboring subnets is outside the scope of this document. The RtSolPr and PrRtAdv messages MUST be implemented by a MN and an access router that supports fast handovers. However, when the parameters necessary for the MN to send packets immediately upon attaching to the NAR are supplied by the link layer handover mechanism itself, use of above messages is optional on such links. After a PrRtAdv message is processed, the MN sends FBU and includes the proposed NCoA. The MN SHOULD send FBU from PAR's link whenever Koodli (Editor) Expires August 28, 2008 [Page 13] Internet-Draft MIP6 Fast Handovers February 2008 "anticipation" of handover is feasible. When anticipation is not feasible or when it has not received an FBack, the MN sends FBU immediately after attaching to NAR's link. In response to FBU, PAR establishes a binding between PCoA ("Home Address") and NCoA, and sends FBack to MN. Prior to establishing this binding, PAR SHOULD send a HI message to NAR, and receive HAck in response. In order to determine the NAR's address for the HI message, the PAR can perform longest prefix match of NCoA (in FBU) with the prefix list of neighboring access routers. When the source IP address of FBU is PCoA, i.e., the FBU is sent from the PAR's link, the HI message MUST have a Code value set to 0. See Section 6.2.1. When the source IP address of FBU is not PCoA, i.e., the FBU is sent from the NAR's link, the HI message MUST have a Code value of 1. See Section 6.2.1. The HI message contains the PCoA, link-layer address and the NCoA of the MN. In response to processing a HI message with Code 0, the NAR 1. determines whether NCoA supplied in the HI message is unique before beginning to defend it. It sends a DAD probe [rfc4862] for NCoA to verify uniqueness. However, in deployments where the probability of address collisions is considered extremely low (and hence not an issue), the parameter DupAddrDetectTransmits (see [rfc4862]) is set to zero on NAR, allowing it to avoid performing DAD on NCoA. The NAR similarly sets DupAddrDetectTransmits to zero in other deployments where DAD is not a concern. Once NCoA is determined to be unique, NAR starts proxying [rfc4861] the address for PROXY_ND_LIFETIME during which the MN is expected to connect to NAR. In case there is already an NCoA present in its data structure (for instance, it has already processed a HI message earlier), NAR may verify if the LLA is the same as its own or that of the MN itself. If so, NAR may allow the use of NCoA. 2. allocates NCoA for the MN when assigned addressing is used, creates a proxy neighbor cache entry and begins defending it. The NAR MAY allocate the NCoA proposed in HI. 3. MAY create a host route entry for PCoA (on the interface to which the MN is attaching to) in case NCoA cannot be accepted or assigned. This host route entry SHOULD be implemented such that until the MN's presence is detected, either through explicit announcement by the MN or by other means, arriving packets do not invoke neighbor discovery. The NAR SHOULD also set up a reverse tunnel to PAR in this case. 4. provides the status of handover request in Handover Acknowledge (HAck) message. Koodli (Editor) Expires August 28, 2008 [Page 14] Internet-Draft MIP6 Fast Handovers February 2008 When the Code value in HI is 1, NAR MUST skip the above operations. However, it SHOULD be prepared to process any other options which may be defined in the future. Sending a HI message with Code 1 allows NAR to validate the neighbor cache entry it creates for the MN during UNA processing. That is, NAR can make use of the knowledge that its trusted peer (i.e., PAR) has a trust relationship with the MN. If HAck contains an assigned NCoA, it must be included in FBack, and the MN MUST use it. The PAR MAY send FBack to the previous link as well to facilitate faster reception in the event the MN be still present there. The result of FBU and FBack processing is that PAR begins tunneling MN's packets to NCoA. If the MN does not receive an FBack message even after re-transmitting FBU for FBU_RETRIES, it must assume that fast handover support is not available and stop the protocol operation. As soon as the MN establishes link connectivity with the NAR, it 1. sends a UNA message (see Section 6.4). If the MN has not received an FBack by the time UNA is being sent, it SHOULD send an FBU message following the UNA message. 2. joins the all-nodes multicast group and the solicited-node multicast group corresponding to the NCoA 3. starts a DAD probe for NCoA. See [rfc4862]. When a NAR receives a UNA message, it 1. deletes its proxy neighbor cache entry, if it exists, updates the state to STALE, and forwards arriving and buffered packets. 2. updates an entry in INCOMPLETE state, if it exists, to STALE and forwards arriving and buffered packets. This would be the case if NAR had previously sent a Neighbor Solicitation which went unanswered perhaps because the MN had not yet attached to the link. The buffer for handover traffic should be linked to this UNA processing. The exact mechanism is implementation dependent. The NAR may choose to provide different IP address other than the NCoA. This is possible if it is proxying the NCoA. In such a case, it Koodli (Editor) Expires August 28, 2008 [Page 15] Internet-Draft MIP6 Fast Handovers February 2008 1. MAY send a Router Advertisement with the NAACK option in which it includes an alternate IP address for use. This message MUST be sent to the source IP address present in UNA using the same Layer 2 address present in UNA. If the MN receives an IP address in the NAACK option, it MUST use it and send an FBU using the new CoA. As a special case, the address supplied in NAACK could be PCoA itself, in which case the MN MUST NOT send any more FBUs. The Status codes for NAACK option are specified in Section 6.5.5. Once the MN has confirmed its NCoA (either through DAD or when provided for by the NAR), it SHOULD send a Neighbor Advertisement message with the 'O' bit set, to the all-nodes multicast address. This message allows MN's neighbors to update their neighbor cache entries. For data forwarding, the PAR tunnels packets using its global IP address valid on the interface to which the MN was attached. The MN reverse tunnels its packets to the same global address of PAR. The tunnel end-point addresses must be configured accordingly. When PAR receives a reverse tunneled packet, it must verify if a secure binding exists for the MN identified by PCoA in the tunneled packet, before forwarding the packet. 5. Other Considerations 5.1. Handover Capability Exchange The MN expects a PrRtAdv in response to its RtSolPr message. If the MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it must assume that PAR does not support the fast handover protocol and stop sending any more RtSolPr messages. Even if a MN's current access router is capable of providing fast handover support, the new access router may not be capable of providing such support. This is indicated to the MN during "runtime", through the PrRtAdv message with a Code value of 3 (see Section 6.1.2). 5.2. Determining New Care of Address Typically, the MN formulates its prospective NCoA using the information provided in a PrRtAdv message, and sends FBU. This NCoA can be provided to NAR in the HI message. NAR provides a disposition of HI, and hence the NCoA itself, in the HAck message indicating Koodli (Editor) Expires August 28, 2008 [Page 16] Internet-Draft MIP6 Fast Handovers February 2008 whether NCoA is acceptable. However, the MN itself does not have to wait on PAR's link for this exchange to take place. It can handover any time after sending the FBU message; sometimes it may be forced to handover without sending the FBU. In any case, it can still confirm using NCoA from NAR's link by sending the UNA message. If PrRtAdv message carries a NCoA, the MN MUST use it as its prospective NCoA. When DHCP is used, the protocol supports forwarding for PCoA only. In this case, the MN MUST perform DHCP operations once it attaches to the NAR even though it formulates an NCoA for transmitting the FBU. This is indicated in the PrRtAdv message with Code = 5. 5.3. Prefix Management As defined in Section 2, the Prefix part of ``AR-Info'' is the prefix valid on the interface to which the AP is attached. This document does not specify how this Prefix is managed, it's length and assignment policies. The protocol operation specified in this document works regardless of these considerations. Often, but not necessarily always, this Prefix may be the aggregate prefix (such as /48) valid on the interface. In some deployments, each MN may have its own per-mobile prefix (such as a /64) used for generating the NCoA. Some point-to-point links may use such a deployment. When per-mobile prefix assignment is used, the ``AR-Info'' advertised in PrRtAdv still includes the (aggregate) prefix valid on the interface to which the target AP is attached, unless the access routers communicate with each other (using HI and HAck messages) to manage per-mobile prefix. The MN still formulates an NCoA using the aggregate prefix. However, an alternate NCoA based on the per-mobile prefix is returned by NAR in the HAck message. This alternate NCoA is provided to the MN in either the FBack message or in the NAACK option. 5.4. Packet Loss Handover involves link switching, which may not be exactly co- ordinated with fast handover signaling. Furthermore, the arrival pattern of packets is dependent on many factors, including application characteristics, network queuing behaviors etc. Hence, packets may arrive at NAR before the MN is able to establish its link there. These packets will be lost unless they are buffered by the NAR. Similarly, if the MN attaches to NAR and then sends an FBU message, packets arriving at PAR until FBU is processed will be lost unless they are buffered. This protocol provides an option to indicate request for buffering at the NAR in the HI message. When Koodli (Editor) Expires August 28, 2008 [Page 17] Internet-Draft MIP6 Fast Handovers February 2008 the PAR requests this feature (for the MN), it SHOULD also provide its own support for buffering. 5.5. DAD Handling Duplicate Address Detection (DAD) was defined in [rfc4862] to avoid address duplication on links when stateless address auto- configuration is used. The use of DAD to verify the uniqueness of an IPv6 address configured through stateless auto-configuration adds delays to a handover. The probability of an interface identifier duplication on the same subnet is very low, however it cannot be ignored. So, this protocol SHOULD only be used in deployments where the probability of such address collisions is extremely low or it is not a concern (because of the address management procedure deployed). The protocol requires the NAR to send a DAD probe before it starts defending NCoA. However, this DAD delay can be turned off by setting DupAddrDetectTransmits to zero on NAR ([rfc4862]). This document specifies messages which can be used to provide duplicate-free addresses but the document does not specify how to create or manage such duplicate-free addresses. In some cases the NAR may already have the knowledge required to assess whether the MN's address is a duplicate or not before the MN moves to the new subnet. For example, in some deployments, the NAR may maintain a pool of duplicate-free addresses in a list for handover purposes. In such cases, the NAR can provide this disposition in the HAck message (see Section 6.2.2) or in the NAACK option (see Section 6.5.5). 5.6. Fast or Erroneous Movement Although this specification is for fast handover, the protocol has its limits in terms of how fast a MN can move. A special case of fast movement is ping-pong, where a MN moves between the same two access points rapidly. Another instance of the same problem is erroneous movement i.e., the MN receives information prior to a handover that it is moving to a new access point but it either moves to a different one or aborts movement altogether. All of the above behaviors are usually the result of link layer idiosyncrasies and thus are often tackled at the link layer itself. IP layer mobility, however, introduces its own limits. IP layer handovers should occur at a rate suitable for the MN to update the binding of, at least, its Home Agent and preferably that of every CN with which it is in communication. A MN that moves faster than necessary for this signaling to complete, which may be of the order of few seconds, may start losing packets. The signaling overhead over the air and in the network may increase significantly, especially in the case of rapid movement between several access Koodli (Editor) Expires August 28, 2008 [Page 18] Internet-Draft MIP6 Fast Handovers February 2008 routers. To avoid the signaling overhead, the following measures are suggested. A MN returning to the PAR before updating the necessary bindings when present on NAR MUST send a Fast Binding Update with Home Address equal to the MN's PCoA and a lifetime of zero, to the PAR. The MN should have a security association with the PAR since it performed a fast handover to the NAR. The PAR, on receiving this Fast Binding Update, will check its set of outgoing (temporary fast handover) tunnels. If it finds a match it SHOULD terminate that tunnel; i.e., start delivering packets directly to the node instead. In order for PAR to process such an FBU, the lifetime of the security association has to be at least that of the tunnel itself. Temporary tunnels for the purposes of fast handovers should use short lifetimes (of the order of a small number of seconds or less). The lifetime of such tunnels should be enough to allow a MN to update all its active bindings. The default lifetime of the tunnel should be the same as the lifetime value in the FBU message. The effect of erroneous movement is typically limited to loss of packets since routing can change and the PAR may forward packets towards another router before the MN actually connects to that router. If the MN discovers itself on an unanticipated access router, it SHOULD send a new Fast Binding Update to the PAR. This FBU supersedes the existing binding at PAR and the packets will be redirected to the new confirmed location of the MN. 6. Message Formats All the ICMPv6 messages have a common Type specified in [rfc2463]. The messages are distinguished based on the Subtype field (see below). For all the ICMPv6 messages, the checksum is defined in [rfc2463]. 6.1. New Neighborhood Discovery Messages 6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) Mobile Nodes send Router Solicitation for Proxy Advertisement in order to prompt routers for Proxy Router Advertisements. All the link-layer address options have the format defined in Section 6.5.2. Koodli (Editor) Expires August 28, 2008 [Page 19] Internet-Draft MIP6 Fast Handovers February 2008 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 4: Router Solicitation for Proxy Advertisement (RtSolPr) Message IP Fields: Source Address: An IP address assigned to the sending interface Destination Address: The address of the Access Router or the all routers multicast address. Hop Limit: 255. See RFC 2461. ICMP Fields: Type: To be assigned by IANA Code: 0 Checksum: The ICMPv6 checksum. Subtype: 2 Reserved: MUST be set to zero by the sender and ignored by the receiver. Identifier: MUST be set by the sender so that replies can be matched to this Solicitation. Valid Options: Source Link-layer Address: When known, the link-layer address of the sender SHOULD be included using the Link-Layer Address option. See LLA option format below. Koodli (Editor) Expires August 28, 2008 [Page 20] Internet-Draft MIP6 Fast Handovers February 2008 New Access Point Link-layer Address: The link-layer address or identification of the access point for which the MN requests routing advertisement information. It MUST be included in all RtSolPr messages. More than one such address or identifier can be present. This field can also be a wildcard address. See LLA Option below. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options that they do not recognize and continue processing the rest of the message. Including the source LLA option allows the receiver to record the sender's L2 address so that neighbor discovery, when the receiver needs to send packets back to the sender (of RtSolPr message), can be avoided. When a wildcard is used for New Access Point LLA, no other New Access Point LLA options must be present. A Proxy Router Advertisement (PrRtAdv) message should be received by the MN as a response to RtSolPr. If such a message is not received in a short time period but no less than twice the typical round trip time (RTT) over the access link or 100 milliseconds if RTT is not known, it SHOULD resend RtSolPr message. Subsequent retransmissions can be up to RTSOLPR_RETRIES, but MUST use an exponential backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled prior to each instance of retransmission. If Proxy Router Advertisement is not received by the time the MN disconnects from the PAR, the MN SHOULD send FBU immediately after configuring a new CoA. When RtSolPr messages are sent more than once, they MUST be rate limited with MAX_RTSOLPR_RATE per second. During each use of RtSolPr, exponential backoff is used for retransmissions. 6.1.2. Proxy Router Advertisement (PrRtAdv) Access routers send out Proxy Router Advertisement message gratuitously if the handover is network-initiated or as a response to RtSolPr message from a MN, providing the link-layer address, IP address and subnet prefixes of neighboring routers. All the link- layer address options have the format defined in 6.4.3. Koodli (Editor) Expires August 28, 2008 [Page 21] Internet-Draft MIP6 Fast Handovers February 2008 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 5: Proxy Router Advertisement (PrRtAdv) Message IP Fields: Source Address: MUST be the link-local address assigned to the interface from which this message is sent. Destination Address: The Source Address of an invoking Router Solicitation for Proxy Advertisement or the address of the node the Access Router is instructing to handover. Hop Limit: 255. See RFC 2461. ICMP Fields: Type: To be assigned by IANA Code: 0, 1, 2, 3, 4 or 5. See below. Checksum: The ICMPv6 checksum. Subtype: 3 Reserved: MUST be set to zero by the sender and ignored by the receiver. Identifier: Copied from Router Solicitation for Proxy Advertisement or set to Zero if unsolicited. Valid Options in the following order: Source Link-layer Address: When known, the link-layer address of the sender SHOULD be included using the Link-Layer Address option. See LLA option format below. Koodli (Editor) Expires August 28, 2008 [Page 22] Internet-Draft MIP6 Fast Handovers February 2008 New Access Point Link-layer Address: The link-layer address or identification of the access point is copied from RtSolPr message. This option MUST be present. New Router's Link-layer Address: The link-layer address of the Access Router for which this message is proxied for. This option MUST be included when Code is 0 or 1. New Router's IP Address: The IP address of NAR. This option MUST be included when Code is 0 or 1. New Router Prefix Information Option: Specifies the prefix of the Access Router the message is proxied for and is used for address auto-configuration. This option MUST be included when Code is 0 or 1. However, when this prefix is the same as what is used in the New Router's IP Address option (above), the Prefix Information option need not be present. New CoA Option: MAY be present when PrRtAdv is sent unsolicited. PAR MAY compute new CoA using NAR's prefix information and the MN's L2 address, or by any other means. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. Currently, Code values 0, 1, 2, 3, 4 and 5 are defined. A Proxy Router Advertisement with Code 0 means that the MN should use the [AP-ID, AR-Info] tuple (present in the options above) for movement detection and NCoA formulation. The Option-Code field in the New Access Point LLA option in this case is 1 reflecting the LLA of the access point for which the rest of the options are related. Multiple tuples may be present. A Proxy Router Advertisement with Code 1 means that the message is sent unsolicited. If a New CoA option is present following the New Router Prefix Information option, the MN SHOULD use the supplied NCoA and send FBU immediately or else stand to lose service. This message acts as a network-initiated handover trigger. See Section 3.3. The Option-Code field in the New Access Point LLA option (see below) in this case is 1 reflecting the LLA of the access point for which the rest of the options are related. A Proxy Router Advertisement with Code 2 means that no new router information is present. Each New Access Point LLA option contains an Koodli (Editor) Expires August 28, 2008 [Page 23] Internet-Draft MIP6 Fast Handovers February 2008 Option-Code value (described below) which indicates a specific outcome. When the Option-Code field in the New Access Point LLA option is 5, handover to that access point does not require change of CoA. This would be the case, for instance, when a number of access points are connected to the same router interface, or when network based mobility management mechanisms ensure that the specific mobile node always observes the same prefix regardless of whether there is a separate router attached to the target access point. No other options are required in this case. When the Option-Code field in the New Access Point LLA option is 6, PAR is not aware of the Prefix Information requested. The MN SHOULD attempt to send FBU as soon as it regains connectivity with the NAR. No other options are required in this case. When the Option-Code field in the New Access Point LLA option is 7, it means that the NAR does not support fast handover. The MN MUST stop fast handover protocol operations. No other options are required in this case. A Proxy Router Advertisement with Code 3 means that new router information is present only for a subset of access points requested. The Option-Code field values (defined above including a value of 1) distinguish different outcomes for individual access points. A Proxy Router Advertisement with Code 4 means that the subnet information regarding neighboring access points is sent unsolicited, but the message is not a handover trigger, unlike when the message is sent with Code 1. Multiple tuples may be present. A Proxy Router Advertisement with Code 5 means that the MN may use the new router information present for detecting movement to a new subnet, but the MN must perform DHCP [rfc3315] upon attaching to the NAR's link. The PAR and NAR will forward packets to the PCoA of the MN. The MN must still formulate an NCoA for transmitting FBU (using the information sent in this message), but that NCoA will not be used for forwarding packets. When a wildcard AP identifier is supplied in the RtSolPr message, the PrRtAdv message should include any 'n' [Access Point Identifier, Link-layer address option, Prefix Information Option] tuples corresponding to the PAR's neighborhood. Koodli (Editor) Expires August 28, 2008 [Page 24] Internet-Draft MIP6 Fast Handovers February 2008 6.2. Inter-Access Router Messages 6.2.1. Handover Initiate (HI) The Handover Initiate (HI) is an ICMPv6 message sent by an Access Router (typically PAR) to another Access Router (typically NAR) to initiate the process of a MN's handover. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype |S|U| Reserved | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 6: Handover Initiate (HI) Message IP Fields: Source Address: The IP address of the PAR Destination Address: The IP address of the NAR ICMP Fields: Type: To be assigned by IANA Code: 0 or 1. See below Checksum: The ICMPv6 checksum. Subtype: 4 'S' flag: Assigned address configuration flag. When set, this message requests a new CoA to be returned by the destination. May be set when Code = 0. MUST be 0 when Code = 1. 'U' flag: Buffer flag. When set, the destination SHOULD buffer any packets towards the node indicated in the options of this message. Used when Code = 0, SHOULD be set to 0 when Code = 1. Koodli (Editor) Expires August 28, 2008 [Page 25] Internet-Draft MIP6 Fast Handovers February 2008 Reserved: MUST be set to zero by the sender and ignored by the receiver. Identifier: MUST be set by the sender so replies can be matched to this message. Valid Options: Link-layer address of MN: The link-layer address of the MN that is undergoing handover to the destination (i.e., NAR). This option MUST be included so that the destination can recognize the MN. Previous Care of Address: The IP address used by the MN while attached to the originating router. This option SHOULD be included so that host route can be established in case necessary. New Care of Address: The IP address the MN wishes to use when connected to the destination. When the `S' bit is set, NAR MAY assign this address. The PAR uses a Code value of 0 when it processes an FBU with PCoA as source IP address. The PAR uses a Code value of 1 when it processes an FBU whose source IP address is not PCoA. If Handover Acknowledge (HAck) message is not received as a response in a short time period but no less than twice the typical round trip time (RTT) between source and destination, or 100 milliseconds if RTT is not known, the Handover Initiate SHOULD be re-sent. Subsequent retransmissions can be up to HI_RETRIES, but MUST use exponential backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled during each instance of retransmission. 6.2.2. Handover Acknowledge (HAck) The Handover Acknowledgment message is a new ICMPv6 message that MUST be sent (typically by NAR to PAR) as a reply to the Handover Initiate message. Koodli (Editor) Expires August 28, 2008 [Page 26] Internet-Draft MIP6 Fast Handovers February 2008 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | Reserved | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 7: Handover Acknowledge (HAck) Message IP Fields: Source Address: Copied from the destination address of the Handover Initiate Message to which this message is a response. Destination Address: Copied from the source address of the Handover Initiate Message to which this message is a response. ICMP Fields: Type: To be assigned by IANA Code: 0: Handover Accepted, NCoA valid 1: Handover Accepted, NCoA not valid or in use 2: Handover Accepted, NCoA assigned (used in Assigned addressing) 3: Handover Accepted, use PCoA 4: Message sent unsolicited, usually to trigger a HI message 128: Handover Not Accepted, reason unspecified 129: Administratively prohibited 130: Insufficient resources Checksum: The ICMPv6 checksum. Subtype: 5 Reserved: MUST be set to zero by the sender and ignored by the receiver. Identifier: Copied from the corresponding field in the Handover Initiate message this message is in response to. Koodli (Editor) Expires August 28, 2008 [Page 27] Internet-Draft MIP6 Fast Handovers February 2008 Valid Options: New Care of Address: If the S flag in the Handover Initiate message is set, this option MUST be used to provide NCoA the MN should use when connected to this router. This option MAY be included even when `S' bit is not set, e.g., Code 2 above. Upon receiving a HI message, the NAR MUST respond with a Handover Acknowledge message. If the `S' flag is set in the HI message, the NAR SHOULD include the New Care of Address option and a Code 3. The NAR MAY provide support for PCoA (instead of accepting or assigning NCoA), using a host route entry to forward packets to the PCoA, and using a tunnel to the PAR to forward packets from the MN (sent with PCoA as source IP address). This host route entry SHOULD be used to forward packets once the NAR detects that the particular MN is attached to its link. The NAR indicates forwarding support for PCoA using Code value 3 in the HAck message. Subsequently, PAR establishes a tunnel to NAR in order to forward packets arriving for PCoA. When responding to a HI message containing a Code value 1, the Code values 1, 2, and 4 in the HAck message are not relevant. Finally, the new access router can always refuse handover, in which case it should indicate the reason in one of the available Code values. 6.3. New Mobility Header Messages Mobile IPv6 uses a new IPv6 header type called Mobility Header [rfc3775]. The Fast Binding Update, Fast Binding Acknowledgment and Fast Neighbor Advertisement messages use the Mobility Header. 6.3.1. Fast Binding Update (FBU) The Fast Binding Update message is identical to the Mobile IPv6 Binding Update (BU) message. However, the processing rules are slightly different. Koodli (Editor) Expires August 28, 2008 [Page 28] Internet-Draft MIP6 Fast Handovers February 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Fast Binding Update (FBU) Message IP Fields: Source address: The PCoA or NCoA Destination Address: The IP address of the Previous Access Router `A' flag: MUST be set to one to request PAR to send a Fast Binding Acknowledgment message. `H' flag: MUST be set to one. See [rfc3775]. `L' flag: See [rfc3775]. `K' flag: See [rfc3775]. Reserved: This field is unused. MUST be set zero. Sequence Number: See See [rfc3775]. Lifetime: The requested time in seconds for which the sender wishes to have a binding. Mobility Options: MUST contain alternate CoA option set to NCoA when FBU is sent from PAR's link. MUST contain the Binding Authorization Data for FMIP (BADF) option. See Section 6.5.4. MAY contain the Mobility Header LLA option (see Section 6.5.3). The MN sends FBU message any time after receiving a PrRtAdv message. If the MN moves prior to receiving a PrRtAdv message, it SHOULD send a FBU to the PAR after configuring NCoA on the NAR according to Koodli (Editor) Expires August 28, 2008 [Page 29] Internet-Draft MIP6 Fast Handovers February 2008 Neighbor Discovery and IPv6 Address Configuration protocols. When the MN moves without having received a PrRtAdv message, it cannot transmit a UNA message upon attaching to the NAR's link. The source IP address is PCoA when FBU is sent from PAR's link, and the source IP address is NCoA when sent from NAR's link. When source IP address is PCoA, the MN MUST include the alternate CoA option set to NCoA. The PAR MUST process the FBU even though the address in the alternate CoA option is different from that in the source IP address, and ensure that the address in the alternate CoA option is used in the New CoA option in the HI message to NAR. The FBU MUST also include the Home Address Option set to PCoA. A FBU message MUST be protected so that PAR is able to determine that the FBU message is sent by a MN that legitimately owns the PCoA. 6.3.2. Fast Binding Acknowledgment (FBack) The Fast Binding Acknowledgment message is sent by the PAR to acknowledge receipt of a Fast Binding Update message in which the `A' bit is set. If PAR sends a HI message to the NAR after processing an FBU, the FBack message SHOULD NOT be sent to the MN before the PAR receives a HAck message from the NAR. The PAR MAY send the FBack immediately in the reactive mode however. The Fast Binding Acknowledgment MAY also be sent to the MN on the old link. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Fast Binding Acknowledgment (FBack) Message IP Fields: Source address: The IP address of the Previous Access Router Koodli (Editor) Expires August 28, 2008 [Page 30] Internet-Draft MIP6 Fast Handovers February 2008 Destination Address: The NCoA, and optionally PCoA Status: 8-bit unsigned integer indicating the disposition of the Fast Binding Update. Values of the Status field less than 128 indicate that the Binding Update was accepted by the receiving node. The following such Status values are currently defined: 0 Fast Binding Update accepted 1 Fast Binding Update accepted but NCoA is invalid. Use NCoA supplied in ``alternate'' CoA Values of the Status field greater than or equal to 128 indicate that the Binding Update was rejected by the receiving node. The following such Status values are currently defined: 128: Reason unspecified 129: Administratively prohibited 130: Insufficient resources 131: Incorrect interface identifier length `K' flag: See See [rfc3775]. Reserved: An unused field. MUST be set to zero. Sequence Number: Copied from FBU message for use by the MN in matching this acknowledgment with an outstanding FBU. Lifetime: The granted lifetime in seconds for which the sender of this message will retain a binding for traffic redirection. Mobility Options: MUST contain ``alternate'' CoA if Status is 1. MUST contain the Binding Authorization Data for FMIP (BADF) option. See 6.4.5. 6.4. Unsolicited Neighbor Advertisement (UNA) This is the same message as in [rfc4861] with the requirement that the 'O' bit is always set to zero. Since this is an unsolicited message, the 'S' bit is zero, and since this is sent by a MN, the 'R' bit is also zero. If NAR is proxying the NCoA (as a result of HI and HAck exchange), then UNA processing has additional steps (see below). If NAR is not proxying the NCoA (for instance, HI and HAck exchange has not taken Koodli (Editor) Expires August 28, 2008 [Page 31] Internet-Draft MIP6 Fast Handovers February 2008 place), then UNA processing follows the same procedure as specified in [rfc4861]. Implementations MAY retransmit UNA subject to the specification in [rfc4861] (Section 7.2.6) while noting that the default RetransTimer value is large for handover purposes. The Source Address in UNA MUST be the NCoA. The Destination Address is typically the all-nodes multicast address; however, some deployments may not prefer transmission to a multicast address. In such cases, the Destination Address SHOULD be the NAR's IP address. The Target Address MUST include the NCoA, and Target link-layer address MUST include the MN's LLA. The MN sends a UNA message to the NAR, as soon as it regains connectivity on the new link. Arriving or buffered packets can be immediately forwarded. If NAR is proxying NCoA, it creates a neighbor cache entry in STALE state but forwards packets as it determines bidirectional reachability according to the standard Neighbor Discovery procedure. If there is an entry in INCOMPLETE state without a link-layer address, it sets it to STALE, again according to the procedure in [rfc4861]. The NAR MAY wish to provide a different IP address to the MN than the one in UNA message. In such a case, NAR MUST delete the proxy entry for NCoA and send a Router Advertisement with NAACK option containing the new IP address. The combination of NCoA (present in source IP address) and the Link- Layer Address (present as a Target LLA) SHOULD be used to distinguish the MN from other nodes. 6.5. New Options All the options are of the form shown in Figure 10. The Type values are defined from the Neighbor Discovery options space. The Length field is in units of 8 octets, except for the Mobility Header Link-Layer Address option, whose Length field is in units of octets in accordance with Section 6.2 in [rfc3775]. And, Option-Code provides additional information for each of the options (see individual options below). Koodli (Editor) Expires August 28, 2008 [Page 32] Internet-Draft MIP6 Fast Handovers February 2008 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 | Option-Code | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Option Format 6.5.1. IP Address/Prefix Option This option is sent in the Proxy Router Advertisement, the Handover Initiate, and Handover Acknowledge 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 | Option-Code | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: IPv6 Address/Prefix Option Type: 17 Length: The size of this option in 8 octets including the Type, Option-Code and Length fields. Option-Code: 1: Old Care-of Address 2: New Care-of Address Koodli (Editor) Expires August 28, 2008 [Page 33] Internet-Draft MIP6 Fast Handovers February 2008 3: NAR's IP address 4: NAR's Prefix, sent in PrRtAdv. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. Prefix Length: 8-bit unsigned integer that indicates the length of the IPv6 Address Prefix. The value ranges from 0 to 128. Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver. IPv6 address: The IP address defined by the Option-Code field. 6.5.2. Link-layer Address (LLA) Option 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 | Option-Code | LLA... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Link-Layer Address Option Type: 19 Length: The size of this option in 8 octets including the Type, Option-Code and Length fields. Option-Code: 0: wildcard requesting resolution for all nearby access points 1: Link-layer Address of the New Access Point 2: Link-layer Address of the MN 3: Link-layer Address of the NAR (i.e., Proxied Originator) 4: Link-layer Address of the source of RtSolPr or PrRtAdv message 5: The access point identified by the LLA belongs to the current interface of the router 6: No prefix information available for the access point identified by the LLA Koodli (Editor) Expires August 28, 2008 [Page 34] Internet-Draft MIP6 Fast Handovers February 2008 7: No fast handovers support available for the access point identified by the LLA LLA: The variable length link-layer address. The LLA Option does not have a length field for the LLA itself. The implementations must consult the specific link layer over which the protocol is run in order to determine the content and length of the LLA. Depending on the size of individual LLA option, appropriate padding MUST be used to ensure that the entire option size is a multiple of 8 octets. The New Access Point Link Layer address contains the link-layer address of the access point for which handover is about to be attempted. This is used in the Router Solicitation for Proxy Advertisement message. The MN Link-Layer address option contains the link-layer address of a MN. It is used in the Handover Initiate message. The NAR (i.e., Proxied Originator) Link-Layer address option contains the Link Layer address of the Access Router for which the Proxy Router Solicitation message refers to. 6.5.3. Mobility Header Link-layer Address (MH-LLA) Option This option is identical to the LLA option, but is carried in the Mobility Header messages, e.g., FBU. In the future, other Mobility Header messages may also make use of this option. The format of the option is shown in Figure 13. There are no alignment requirements for this option. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option-Code | LLA .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Mobility Header Link-Layer Address Option Koodli (Editor) Expires August 28, 2008 [Page 35] Internet-Draft MIP6 Fast Handovers February 2008 Type: 7 Length: The size of this option in octets not including the Type and Length fields. Option-Code: 2 Link-layer Address of the MN LLA: The variable length link-layer address. 6.5.4. Binding Authorization Data for FMIPv6 (BADF) This option MUST be present in FBU and FBack messages. The security association between the MN and the PAR is established by companion protocols [rfc-ho-send]. This option specifies how to compute and verify a MAC using the established security association. The format of this option is shown in Figure 14. 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 | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Authenticator | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Binding Authorization Data for FMIPv6 (BADF) Option Type: To be assigned by IANA Option Length: The length of the Authenticator in bytes SPI: Security Parameter Index. SPI = 0 is reserved for the Authenticator computed using SEND-based handover keys. Authenticator: Same as in RFC 3775, with "correspondent" replaced by PAR's IP address, and Kbm replaced by the shared key between the MN and the PAR. Koodli (Editor) Expires August 28, 2008 [Page 36] Internet-Draft MIP6 Fast Handovers February 2008 The default MAC calculation is done using HMAC_SHA1 with the first 96 bits used for the MAC. Since there is an Option Length field, implementations can use other algorithms such as HMAC_SHA256 for instance. This option MUST be the last Mobility Option present. 6.5.5. Neighbor Advertisement Acknowledgment (NAACK) 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 | Option-Code | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: Neighbor Advertisement Acknowledgment Option Type: 20 Length: 8-bit unsigned integer. Length of the option, in 8 octets. The length is 1 when a new CoA is not supplied. The length is 3 when a new CoA is present (immediately following the Reserved field) Option-Code: 0 Status: 8-bit unsigned integer indicating the disposition of the Unsolicited Neighbor Advertisement message. The following Status values are currently defined: 1: NCoA is invalid, perform address configuration 2: NCoA is invalid, use the supplied NCoA. The supplied NCoA (in the form of an IP Address Option) MUST be present following the Reserved field. 3: NCoA is invalid, use NAR's IP address as NCoA in FBU 4: PCoA supplied, do not send FBU 128: Link Layer Address unrecognized Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver. Koodli (Editor) Expires August 28, 2008 [Page 37] Internet-Draft MIP6 Fast Handovers February 2008 The NAR responds to UNA with the NAACK option to notify the MN to use a different NCoA than the one that the MN has used. If the NAR proposes a different NCoA, the Router Advertisement MUST use the source IP address in the UNA message as the destination address, and use the L2 address present in UNA. The MN MUST use the NCoA if it is supplied with the NAACK option. If the NAACK indicates that the Link Layer Address is unrecognized, for instance if the MN uses an LLA valid on PAR's link but the same LLA is not valid on NAR's link due to a different access technology, the MN MUST NOT use the NCoA or the PCoA and SHOULD start immediately the process of acquiring different NCoA at the NAR. In the future, new option types may be defined. 7. Related Protocol and Device Considerations The protocol specified here, as a design principle, introduces no or minimal changes to related protocols. For example, no changes to the base Mobile IPv6 protocol are needed in order to implement this protocol. Similarly, no changes to the IPv6 stateless address autoconfiguration protocol [rfc4862] and DHCP [rfc3315] are introduced. The protocol specifies an optional extension to Neighbor Discovery [rfc4861] in which an access router may send a router advertisement as a response to the UNA message (see Section Section 6.4). Other than this extension, the specfication does not modify Neighbor Discovery behavior (including the procedures performed when attached to the PAR and when attaching to the NAR). The protocol does not require changes to any intermediate layer 2 device between a MN and its access router which support this specification. This includes the wireless access points, switches, snooping devices and so on. 8. Configurable Parameters +-------------------+---------------+---------------+ | Parameter Name | Default Value | Definition | +-------------------+---------------+---------------+ | RTSOLPR_RETRIES | 3 | Section 6.1.1 | | MAX_RTSOLPR_RATE | 3 | Section 6.1.1 | | FBU_RETRIES | 3 | Section 6.3.1 | | PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.2 | | HI_RETRIES | 3 | Section 6.2.1 | +-------------------+---------------+---------------+ Koodli (Editor) Expires August 28, 2008 [Page 38] Internet-Draft MIP6 Fast Handovers February 2008 9. Security Considerations The following security vulnerabilities are identified, and suggested solutions mentioned. Insecure FBU: in this case, packets meant for one address could be stolen, or redirected to some unsuspecting node. This concern is the same as that in a MN and Home Agent relationship. Hence, the PAR MUST ensure that the FBU packet arrived from a node that legitimately owns the PCoA. The access router and its hosts may use any available mechanism to establish a security association which MUST be used to secure FBU. The current version of this protocol relies on a companion protocol [rfc-ho-send]. to establish such a security association. Using the shared handover key from [rfc-ho-send], the Authenticator in BADF option (see Section 6.5.4) MUST be computed, and the BADF option included in FBU and FBack messages. Secure FBU, malicious or inadvertent redirection: in this case, the FBU is secured, but the target of binding happens to be an unsuspecting node either due to inadvertent operation or due to malicious intent. This vulnerability can lead to a MN with genuine security association with its access router redirecting traffic to an incorrect address. However, the target of malicious traffic redirection is limited to an interface on an access router with which the PAR has a security association. The PAR MUST verify that the NCoA to which PCoA is being bound actually belongs to NAR's prefix. In order to do this, HI and HAck message exchanges are to be used. When NAR accepts NCoA in HI (with Code = 0), it proxies NCoA so that any arriving packets are not sent on the link until the MN attaches and announces itself through UNA. So, any inadvertent or malicious redirection to a host is avoided. It is still possible to jam NAR's buffer with redirected traffic. However, since NAR's handover state corresponding to NCoA has a finite (and short) lifetime corresponding to a small multiple of anticipated handover latency, the extent of this vulnerability is arguably small. Sending FBU from NAR's link: a malicious node may send FBU from NAR's link providing an unsuspecting node's address as NCoA. This is similar to base Mobile IP where the MN can provide some other node's IP address as its CoA to its Home Agent; here the PAR acts like a "temporary Home Agent" having a security association with the Mobile Node, and providing forwarding support for the handover traffic. As in base Mobile IP, this misdelivery is traceable to the MN which has a security association with the router. So, it is possible to isolate such an MN if it continues to misbehave. Similarly, a MN which has a security association with the PAR may Koodli (Editor) Expires August 28, 2008 [Page 39] Internet-Draft MIP6 Fast Handovers February 2008 provide the LLA of some other node on NAR's link, which can cause misdelivery of packets (meant for NCoA) to an unsuspecting node. It is possible to trace the MN in this case as well. Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv (Section 6.1.2) messages inherit the weaknesses of Neighbor Discovery protocol [rfc4861]. Specifically, when its access router is compromised, the MN's RtSolPr message may be answered by an attacker that provides a rogue router as the resolution. Should the MN attach to such a rogue router, its communication can be compromised. Similarly, a network-initiated PrRtAdv message (see Section 3.3) from an attacker could cause a MN to handover to a rogue router. Where these weaknesses are a concern, a solution such as Secure Neighbor Discovery (SEND) [rfc3971] SHOULD be considered. The Handover Initiate (HI) and Handover Acknowledgement (HAck) messages exchanged between the PAR and NAR MUST be protected using end-to-end security association(s) offering integrity and data origin authentication. The PAR and the NAR MUST implement IPsec [rfc4301] for protecting the HI and HAck messages. IPsec ESP [rfc4303] in transport mode with mandatory integrity protection SHOULD be used for protecting the signaling messages. Confidentiality protection of these messages is not required. The security associations can be created by using either manual IPsec configuration or a dynamic key negotiation protocol such as IKEv2 [rfc4306]. If IKEv2 is used, the PAR and the NAR can use any of the authentication mechanisms, as specified in RFC 4306, for mutual authentication. The following sections describe the Peer Authorization Database (PAD) and Security Policy Database (SPD) entries specified in [rfc4301] when IKEv2 is used for setting up the required IPsec security associations. 9.1. Peer Authorization Database Entries when using IKEv2 This section describes PAD entries on the PAR and the NAR. The PAD entries are only example configurations. Note that the PAD is a logical concept and a particular PAR or NAR implementation can implement the PAD in any implementation specific manner. The PAD state may also be distributed across various databases in a specific implementation. PAR PAD: Koodli (Editor) Expires August 28, 2008 [Page 40] Internet-Draft MIP6 Fast Handovers February 2008 - IF remote_identity = nar_identity_1 THEN authenticate (shared secret/certificate/EAP) and authorize CHILD_SA for remote address nar_address_1 NAR PAD: - IF remote_identity = par_identity_1 THEN authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for remote address par_address_1 The list of authentication mechanisms in the above examples is not exhaustive. There could be other credentials used for authentication stored in the PAD. 9.2. Security Policy Database Entries This section describes the security policy entries on the PAR and the NAR required to protect the HI and HAck messages. The SPD entries are only example configurations. A particular PAR or NAR implementation could configure different SPD entries as long as they provide the required security. In the examples shown below, the identity of the PAR is assumed to be par_1, the address of the PAR is assumed to be par_address_1, and the address of the NAR is assumed to be nar_address_1. PAR SPD-S: - IF local_address = par_address_1 & remote_address = nar_address_1 & proto = ICMPv6 & local_icmpv6_type = HI & remote_icmpv6_type = HAck THEN use SA ESP transport mode Initiate using IDi = par_1 to address nar_address_1 NAR SPD-S: - IF local_address = nar_address_1 & remote_address = par_address_1 & proto = ICMPv6 & local_icmpv6_type = HAck & remote_icmpv6_type = HI THEN use SA ESP transport mode 10. IANA Considerations This document defines the following ICMPv6 messages, all of which can share a single ICMPv6 Type from the registry in http://www.iana.org/assignments/icmpv6-parameters. Koodli (Editor) Expires August 28, 2008 [Page 41] Internet-Draft MIP6 Fast Handovers February 2008 +------+-------------+---------------+ | Type | Description | Reference | +------+-------------+---------------+ | TBD | RtSolPr | Section 6.1.1 | | TBD | PrRtAdv | Section 6.1.2 | | TBD | HI | Section 6.2.1 | | TBD | HAck | Section 6.2.2 | +------+-------------+---------------+ The document defines a new Mobility Option which needs Type assignment from the Mobility Options Type registry at http://www.iana.org/assignments/mobility-parameters: 1. Binding Authorization Data for FMIPv6 (BADF) option, described in Section 6.5.4 The document has already received Type assignments for the following (see [rfc4068]): The document defines the following Neighbor Discovery [rfc4861] options which have received Type assignment from IANA. +---------+-----------------------------------------+---------------+ | Subtype | Description | Reference | +---------+-----------------------------------------+---------------+ | 17 | IP Address/Prefix Option | Section 6.5.1 | | 19 | Link-layer Address Option | Section 6.5.2 | | 20 | Neighbor Advertisement Acknowledgment | Section 6.5.5 | | | Option | | +---------+-----------------------------------------+---------------+ The document defines the following Mobility Header messages which have received Type allocation from the Mobility Header Types registry at http://www.iana.org/assignments/mobility-parameters: 1. Fast Binding Update, described in Section 6.3.1 2. Fast Binding Acknowledgment, described in Section 6.3.2 The document defines the following Mobility Option which has received Type assignment from the Mobility Options Type registry at http://www.iana.org/assignments/mobility-parameters: 1. Mobility Header Link-Layer Address option, described in Section 6.5.3 Koodli (Editor) Expires August 28, 2008 [Page 42] Internet-Draft MIP6 Fast Handovers February 2008 11. Acknowledgments The editor would like to thank all those who have provided feedback on this specification, and acknowledges the following people: Vijay Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj Premec, Subba Reddy, K. Raghav, Ranjit Wable and Jonathan Wood. Behcet Sarikaya and Frank Xia are acknowledged for the feedback on operation over point-point links. The editor would like to acknowledge the contribution from James Kempf to improve this specification. Vijay Devarapalli provided text for the security configuration between access routers in Section 9. Thanks to Jari Arkko for the detailed AD Review which has improved this document. The editor would also like to thank [mipshop] working group chair Gabriel Montenegro and the erstwhile [mobile ip] working group chairs Basavaraj Patil and Phil Roberts for providing much support for this work. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [rfc-ho-send] Kempf, J. and R. Koodli, "Distributing a Symmetric FMIPv6 Handover Key using SEND (work in progress)", September 2007. [rfc2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998, . [rfc3315] Droms (Editor), R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003, . [rfc3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004, . Koodli (Editor) Expires August 28, 2008 [Page 43] Internet-Draft MIP6 Fast Handovers February 2008 [rfc4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005, . [rfc4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005, . [rfc4306] Kaufman (Editor), C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005, . [rfc4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 2007, . [rfc4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007, . 12.2. Informative References [rfc3971] Arkko (Editor), J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [rfc4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, June 2004. [rfc4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. Appendix A. Contributors This document has its origins in the fast handover design team in the erstwhile [mobile ip] working group. The members of this design team in alphabetical order were; Gopal Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis and Alper Yegin. Appendix B. Change Log The following revisions were done as part of the AD review (major revisions from v04 -> v05, v06 are listed). Koodli (Editor) Expires August 28, 2008 [Page 44] Internet-Draft MIP6 Fast Handovers February 2008 - added text about Alt-CoA check in FBU in 'FBU Section' - added inter-access router security configuration text in 'Security Considerations' - Clarified that ND operations are a must in 'Related Proto Considerations' - clarified usage with DHCP in 'Protocol Overview' - added NETLMM case for Option-Code 5 in PrRtAdv - added clarification about unrecognized LLA in NAACK Section - clarified "PAR = temporary HA" for FBUs sent by a genuine MN to an unsuspecting CoA - added description of DAD requirement on NAR when determining NCoA uniqueness - Section 'Protocol Details' - Following are the changes in AD review from v03 -> v04 - added a section on "Related Protocol and Node Considerations" - clarified usage of UNA, which can now update an entry and send an RA only if NAR is proxying NCoA. Recommendation to create an entry in STALE state, when none exists, is removed. (Section 6.4, Section 4) - clarified protocol usage when DHCP is used for NCoA formulation (Sections 6.1.2, 3.1, 5.2). Added a new Code value (5) in PrRtAdv (Section 6.1.2) - revised Security Considerations - clarified using HoA in FBU when sent with PCoA as source IP address - editorial revisions - LC comments for 4068bis - RFC4068bis: all the issues in the tracker since the publication of RFC 4068. (http://www.mip4.org/issues/tracker/mipshop) The following changes pre-date RFC 4068 publication. So, the section numbers probably do not match. Koodli (Editor) Expires August 28, 2008 [Page 45] Internet-Draft MIP6 Fast Handovers February 2008 - Added IPSec AH reference. - Changed options format to make use of RFC 2461 options Type space. Revised IANA Considerations section accordingly. - Added exponential backoff for retransmissions. Added rate limiting for RtSolPr message. - Replaced ``attachment point'' with ``access point'' for consistency. - Clarified [AP-ID, AR-Info] in terminology. Clarified use of Prefix Information Option - Separated MH-LLA from LLA to future-proof LLA option. The following changes refer up to version 02 (under mipshop). The Section numbers refer to version 06 (under mobile ip). - New ICMPv6 format incorporated. ID Nits conformance. - Last Call comments incorporated - Revised the security considerations section in v07 - Refined and added a section on network-initiated handover v07 - Section 3 format change - Section 4 format change (i.e., no subsections). - Description in Section 4.4 merged with ``Fast or Erroneous Movement'' - Section 4.5 deprecated - Section 4.6 deprecated - Revision of some message formats in Section 6 Koodli (Editor) Expires August 28, 2008 [Page 46] Internet-Draft MIP6 Fast Handovers February 2008 Author's Address Rajeev Koodli (Editor) USA Email: rajeev.koodli@gmail.com Koodli (Editor) Expires August 28, 2008 [Page 47] Internet-Draft MIP6 Fast Handovers February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Koodli (Editor) Expires August 28, 2008 [Page 48]