Mobile IP Working Group Rajeev Koodli, Editor INTERNET DRAFT Nokia Research Center 30 September 2002 Fast Handovers for Mobile IPv6 draft-ietf-mobileip-fast-mipv6-05.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract Mobile IPv6 describes how a Mobile Node can maintain connectivity to the Internet when it changes its Access Router for another, a process referred to as handover. During this process, there is a time period when the Mobile Node is unable to send or receive IPv6 packets both due to link switching delay and IP protocol operations. This time period is referred to as handover latency. In many instances, the handover latency resulting from standard Mobile IPv6 handover procedures could be greater than what is acceptable to support real-time or delay sensitive traffic. Furthermore, reducing the handover latency could be beneficial to non real-time, throughput-sensitive applications as well. The intent of this document is to describe protocol enhancements to reduce handover latency due to IP protocol operations as small as possible in comparison to the inevitable link switching latency. Koodli (Editor) Expires 30 March 2003 [Page i] Internet Draft Fast Handovers 30 September 2002 Contents Status of This Memo i Abstract i 1. Introduction 2 2. Terminology 2 3. Protocol Overview 4 3.1. Handover Initiation . . . . . . . . . . . . . . . . . . . 4 3.2. Tunnel Establishment . . . . . . . . . . . . . . . . . . 5 3.3. Packet Forwarding on the Tunnel . . . . . . . . . . . . . 6 4. Protocol Details 6 4.1. Handover Initiation . . . . . . . . . . . . . . . . . . . 7 4.1.1. Anticipation . . . . . . . . . . . . . . . . . . 7 4.1.2. No Anticipation . . . . . . . . . . . . . . . . . 8 4.2. Tunnel Establishment between the Access Routers . . . . . 9 4.3. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 11 4.4. Three Party Handover . . . . . . . . . . . . . . . . . . 12 4.5. Optimization using link-layer assisted features . . . . . 12 4.5.1. Renewing Tunnel Lifetime . . . . . . . . . . . . 15 4.6. Three Party Handover with Layer 2 Trigger Support . . . . 16 5. Other Considerations 20 5.1. Handover Capability Exchange . . . . . . . . . . . . . . 20 5.2. Determining New Care of Address . . . . . . . . . . . . . 22 5.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 22 5.4. DAD Handling . . . . . . . . . . . . . . . . . . . . . . 23 5.5. Fast or Erroneous Movement . . . . . . . . . . . . . . . 23 6. Message Formats 25 6.1. New Neighbor Discovery Messages . . . . . . . . . . . . . 25 6.1.1. Router Solicitation for Proxy . . . . . . . . . . 25 6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . . 26 6.1.3. Fast Neighbor Advertisement (FNA) . . . . . . . . 29 6.2. Inter-Access Router Messages . . . . . . . . . . . . . . 31 6.2.1. Handover Initiate (HI) . . . . . . . . . . . . . 31 6.2.2. Handover Acknowledge (HACK) . . . . . . . . . . . 33 6.3. Handover To Third (HTT) . . . . . . . . . . . . . . . . . 36 6.4. New Mobility Header Messages . . . . . . . . . . . . . . 36 6.4.1. Fast Binding Update (FBU) . . . . . . . . . . . . 36 6.4.2. Fast Binding Acknowledgment (FBACK) . . . . . . . 38 6.5. New ICMP Options . . . . . . . . . . . . . . . . . . . . 40 Koodli (Editor) Expires 30 March 2003 [Page ii] Internet Draft Fast Handovers 30 September 2002 6.5.1. IP Address Option . . . . . . . . . . . . . . . . 40 6.5.2. New Router Prefix Information Option . . . . . . 41 6.5.3. Link-layer Address (LLA) . . . . . . . . . . . . 42 6.5.4. Neighbor Advertisement Acknowledgment (NAACK) . . 43 6.5.5. Handover Capability Extension . . . . . . . . . . 44 7. Configurable Parameters 45 8. Security Considerations 45 9. Contributors 46 10. Acknowledgments 46 11. Contact Information 47 Koodli (Editor) Expires 30 March 2003 [Page 1] Internet Draft Fast Handovers 30 September 2002 1. Introduction Mobile IP 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 broadly involve movement detection, IP address configuration, and location update phases. The combined handover latency could be appreciable (especially) for real-time applications and throughput-sensitive applications. This document describes a protocol to reduce this latency. This document addresses the following problem: how to allow a MN to send packets as soon as it detects a new link, and how to deliver packets to a MN as soon as its presence is detected by the MN's new access router. The solution allows a MN to keep using its Care of Address until it establishes itself as a Mobile IP end-point on its new access router. The solution also allows a MN to expeditiously establish a new Care of Address. This protocol defines IP protocol messages necessary for its operation on any link technology. It does this without depending on specific link-layer features, while allowing link-specific customizations, perhaps for even improved performance. By definition, this specification considers handovers that inter-work with Mobile IP: once attached to its new access router, a MN engages in Mobile IP operations including Return Routability [3]. Hence, 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 [1]. The following terminology and abbreviations are used in this document. The reference handover scenario is illustrated in Figure 1. Mobile Node (MN) A Mobile IPv6 host Access Router (AR) The MN's default router Previous Access Router (PAR) The MN's default router prior to its handover Koodli (Editor) Expires 30 March 2003 [Page 2] Internet Draft Fast Handovers 30 September 2002 New Access Router (NAR) The MN's anticipated default router subsequent to its handover Anchor Access Router (AAR) The access router where the MN originally established its CoA (i.e., the CoA that is known to the HA and the Correspondent nodes). Anchor CoA (ACoA) The MN's Care of Address valid on AAR. Previous CoA (PCoA) The MN's Care of Address valid on PAR. The MN may reuse this address while attached to NAR until it finishes Mobile IP operations. New CoA (NCoA) The MN's Care of Address valid on NAR Handover A process of terminating existing connectivity and obtaining new IP connectivity. Router Solicitation for Proxy (RtSolPr) A message from the MN to the PAR requesting information for a potential handover Proxy Router Advertisement (PrRtAdv) A message from the PAR indicating a MN to undergo handover 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 Fast Neighbor Advertisement (FNA) A message from the MN to the NAR to confirm use of NCoA when the MN has not received FBACK Handover Initiate (HI) A message from the PAR to the NAR to initiate handover Handover Acknowledge (HACK) A message from the NAR to the PAR as a response to HI Koodli (Editor) Expires 30 March 2003 [Page 3] Internet Draft Fast Handovers 30 September 2002 Bidirectional Tunnel (BT) A tunnel for both PAR and NAR to forward packets to and from MN's PCoA. 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 The key protocol operation involves setting up a routing path between the two access routers to enable the MN to send and receive IP packets while it establishes itself as a Mobile IPv6 end-point. This tunnel establishment could be triggered by the MN requesting a handover, or by the network (i.e., PAR). Once the tunnel is established, packet forwarding on the tunnel to the MN begins when the PAR receives a Fast Binding Update message from the MN. So, there are three phases in the protocol operation: handover initiation, tunnel establishment and packet forwarding. 3.1. Handover Initiation The protocol is initiated when an event, such as a decision to handover the MN to a new point of attachment, occurs. The ``trigger'' for protocol initiation may arrive from specific L2 events or from policy rules that might determine the need for Koodli (Editor) Expires 30 March 2003 [Page 4] Internet Draft Fast Handovers 30 September 2002 handover based on factors other than link connectivity alone (e.g., cost, bandwidth changes, etc.). These triggers themselves are not specified in this document. Typically, it is the MN that responds to such a trigger by requesting its AR (i.e., PAR) to assist in handover by sending a Router Solicitation for a Proxy (RtSolPr) message in which it includes the link-layer identifier (such as a base station id or BSSID in IEEE 802.11 networks) of its prospective attachment point. In response to RtSolPr message the PAR sends a Proxy Router Advertisement (PrRtAdv) message, which provides the link-layer address, and network prefix information about the NAR, and the NCoA (especially when stateful address configuration is required). In the network-initiated handover, the PAR sends PrRtAdv message without the MN sending RtSolPr message, and provides the parameters necessary (i.e., link-layer address and IP address of the NAR) for the MN to send IP packets, as well as the network prefix for the MN to formulate a prospective new Care pf Address. The purpose of RtSolPr is to request parameters necessary for the MN to be able to send packets immeidately upon connecting to the NAR. The purpose of PrRtAdv is to supply these parameters and the network prefix information that would also allow the MN to formulate a NCoA. When the underlying link layer provides these parameters (by means outside the scope of this document), these messages are optional on such links. In addition, when appropriate link layer support to send RtSolPr is not available, the MN simply moves to a new link (without sending RtSolPr and receiving PrRtAdv in return) and then sends a Fast Binding Update to the PAR which then initiates tunnel establishment. 3.2. Tunnel Establishment When the PAR receives a RtSolPr message, it transmits a Handover Initiate (HI) message to NAR, after looking up the IP address corresponding to the link-layer identifier supplied by the MN. The mechanism that PAR uses to resolve the IP address corresponding to the supplied link-layer identifier is not specified in this document. The HI message serves two purposes. First, it initiates establishing a bidirectional tunnel between the two routers so that the MN can continue to use PCoA for its existing sessions. Second, it serves to verify if NCoA (either supplied by the PAR or determined by the NAR when using stateful address configuration), when present, can be used on NAR's link. In response to processing the HI message, the NAR sets up a host route for the MN's PCoA and responds with a Handover Acknowledge (HACK) message. When the NCoA could be used, the NAR begins to proxy that address for a short duration. Koodli (Editor) Expires 30 March 2003 [Page 5] Internet Draft Fast Handovers 30 September 2002 In the network-controlled handover, the PAR transmits HI message without receiving the RtSolPr message. 3.3. Packet Forwarding on the Tunnel After it receives a PrRtAdv message, the MN sends a Fast Binding Update (FBU). The MN may also send an FBU after attaching to the NAR. This FBU message associates the MN's PCoA with NAR's IP address so that packets arriving at the PAR can be tunneled to the NAR. After it associates PCoA with NAR's IP address for forwarding purposes, the PAR sends a Fast Binding Acknowledgment (FBACK) message to the MN. The FBACK message confirms whether NCoA could be used, only after which the MN must use NCoA on the new link. When the MN moves prior to receiving the FBACK message, it sends a Fast Neighbor Advertisement (FNA) message to the NAR requesting confirmation to use NCoA. As a response, the NAR sends a Router Advertisement with Neighbor Advertisement Acknowledge (NAACK) option that indicates whether the use of NCoA is acceptable. When the MN moves after receiving the FBACK message, it simply announces its presence through a Neighbor Advertisement message. In any case, it is allowed to use PCoA for its existing sessions with its correspondents during these operations. It is worthwhile to observe, in the light of recent Return Routability procedure for securing Binding Updates, that a correspondent node rejects packets sent with NCoA until a valid binding cache entry is established. Hence, it is highly desirable to be able to continue using an address that exists in a correspondent's binding cache until the new address can be updated. Furthermore, such an update, accomplished through the Binding Update procedure, itself should be expeditiously performed. Thus, the combined use of tunneling (packets meant for PCoA) and anticipation (of NCoA) is likely to offer performance benefits and will be elaborated in the following sections. The overall handover protocol is illustrated in Figure 2. 4. Protocol Details There are three phases in the protocol operation: handover initiation, tunnel establishment and packet forwarding on the established tunnel. We describe each of these phases separately. Koodli (Editor) Expires 30 March 2003 [Page 6] Internet Draft Fast Handovers 30 September 2002 MN PAR NAR | | | |------RtSolPr------->| | |<-----PrRtAdv--------|--------HI--------->| |------F-BU---------->|<------HACK---------| Disconnect <--F-BACK--|--F-BACK--> | | | | | forward | | packets===============>| | | | | | | Connect | | | | | send packets (including FNA)========================>| |<-----------RA (with NAACK option)--------| |<=================================== deliver packets | | Figure 2: Fast Handover Protocol Messages 4.1. Handover Initiation The handover initiation may occur while the MN is still attached to the PAR, or it may take place after it attaches to the NAR. 4.1.1. Anticipation Either the MN or the PAR may initiate a handover by sending protocol messages defined in this document. External events, such as a determination at link layer to undergo handover or a policy decision based on factors such as available bandwidth, cost etc, can cause handover initiation. Such events oblige a MN to send a RtSolPr, and the PAR to send a PrRtAdv (either in response to RtSolPr or separately as a gratuitous message). The RtSolPr message allows a MN to initiate its handover by requesting the PAR to supply the IP address, link-layer address as well as network prefix of the NAR's interface to which the MN is handing over to. In a network-controlled handover, the PAR may supply this information without the MN requesting it. In Koodli (Editor) Expires 30 March 2003 [Page 7] Internet Draft Fast Handovers 30 September 2002 either case, the PAR engages in tunnel establishment described in Section 4.2. It is possible that the PAR itself may initiate handover by gratuitously sending a PrRtAdv message. When the PAR sends such a message without the MN sending a RtSolPr message first, the MN MUST be prepared to process PrRtAdv message, and send an Fast Binding Update message in response. The PrRtAdv indicates one of the three possible conditions: 1. If the PAR does not have an entry corresponding to the new attachment point, it MUST respond indicating that the new point of attachment is unknown. The MN MUST stop fast handover protocol operations on the current link. The MN MAY send an FBU from its new link. See Section 4.2. 2. If the new point of attachment is connected to the PAR itself, PAR MUST respond indicating that the point of attachment is known but is connected to itself. This could happen, for example, when the wireless access points are bridged into a wired network. 3. If the new point of attachment is known and the PAR has information about it, then PAR MUST respond indicating that the point of attachment is known. The message MUST contain the new CoA that the MN should use or information on the network prefix that should be used to form a new CoA. If the new point of attachment is known, but does not support fast handover, the PAR MUST indicate this with Code 3 (See Section 6.1.2). The method by which Access Routers exchange information about their neighbors and thereby allow construction of PrRtAdvs with information about the new subnet is outside the scope of this document. Furthermore, this document assumes that the access routers share necessary security association established by means 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, the above messages are optional on such link layers. See Section 4.5. 4.1.2. No Anticipation Anticipating a handover is not always possible. Also, the interface between the link-layer handover mechanism and IP stack may not be Koodli (Editor) Expires 30 March 2003 [Page 8] Internet Draft Fast Handovers 30 September 2002 well-defined or is available. In such cases, the MN may change its link without engaging in protocol messages with the PAR on its previous link. The MN SHOULD send a Fast Binding Update to the PAR as soon as it establishes connectivity with the NAR. This FBU message serves to establish a tunnel between the access routers. Establishing tunnels subsequent to regaining a new link is useful, for instance, in IEEE 802.11 wireless local area networks. See Section 4.2. 4.2. Tunnel Establishment between the Access Routers A bi-directional tunnel is established between the two access routers for the following purpose. Since the MN cannot use NCoA until it completes Binding Update with its Home Agent and the correspondents, it is allowed to use PCoA until it establishes itself as a Mobile IPv6 end-point. For this purpose, the NAR tunnels packets sent with PCoA as source IP address to the PAR. And, until the correspondent nodes establish a binding cache entry for NCoA, they continue to send packets to PCoA, which need to be forwarded to the MN. The PAR tunnels these packets to the NAR, which then forwards them using a host route entry to the MN. Since it is desirable to deliver these packets independent of NCoA configuration, the PAR tunnels packets to the NAR instead of to the NCoA. However, the MN MAY include NCoA as the target address for the tunnel. The tunnel establishment is achieved through Handover Initiate (HI) and Handover Acknowledge (HAck) messages. The PAR MUST send the HI message to the NAR when PAR 1. receives RtSolPr and determines that the MN needs to attach to NAR, or 2. determines to send a gratuitous PrRtAdv message, or 3. determines through link-layer specific mechanisms that the MN is attaching to NAR without sending PrRtAdv (See Section 4.5), or 4. receives an FBU message from a MN for which it has not previously sent a HI message The HI message contains the PCoA, link-layer address and the NCoA (when known) of the MN. In response to processing the HI message, the NAR 1. MUST create a host route for PCoA that allows it to forward packets to the MN. This host route entry SHOULD be implemented such that until the MN's presence is detected, either through Koodli (Editor) Expires 30 March 2003 [Page 9] Internet Draft Fast Handovers 30 September 2002 explicit announcement by the MN or by other means, arriving packets do not invoke neighbor discovery. 2. MUST set up a tunnel for packets arriving with PCoA as source IP address to be sent to PAR. 3. MUST verify if NCoA (when) supplied in the HI message is a valid address for use, and if it is, it MUST also establish a proxy neighbor cache entry for NCoA and begin defending it. 4. MUST allocate NCoA for the MN when stateful address configuration is used, create a proxy neighbor cache entry and begin defending it. 5. MUST provide the status of handover request in Handover Acknowledge (HACK) message indicating whether the use of NCoA is acceptable. When the PAR receives HAck message, it completes the tunnel establishment. In addition, the HAck message may also indicate whether the use of NCoA is acceptable. If the MN does not engage in protocol messages on its previous link (for whatever reason(s)), it SHOULD send an FBU, with PCoA as source IP address, as soon as it regains connectivity with the NAR. The NAR SHOULD tunnel the FBU to the PAR subject to following considerations. First, the ingress filtering rules allow packets sent with PAR's prefix in a source address to be forwarded. Second, the destination IP address is that of the PAR. Note that both these conditions must be met for succesful completion of any HI and HAck message exchange in any case. When the PAR receives an FBU for which it has not received a RtSolPr message, it SHOULD send a HI message to the NAR. Upon receiving a corresponding HACK message, the PAR SHOULD send FBACK to the MN. Until the HACK is received, the PAR MAY buffer any packets arriving for the MN. The New Access Router MUST NOT tunnel packets from the MN with PCoA as source IP address destined for arbitrary correspondent nodes to PAR until a HI message is received, and the NAR MAY buffer any such packets. If the MN does not receive an FBACK message even after re-transmitting FBU for FBU_RX_TIMES, it MUST assume that fast handover support is not available and it MUST stop fast handover protocol operation. When the tunnel is established after the MN attaches to the NAR, there could be delay before packets are forwarded, and there could be Koodli (Editor) Expires 30 March 2003 [Page 10] Internet Draft Fast Handovers 30 September 2002 packet loss unless the access routers buffer packets. This delay and potential packet loss could be avoided through anticipation. 4.3. Packet Forwarding When the MN receives a PrRtAdv message, it SHOULD send a Fast Binding Update (FBU) message preferably prior to disconnecting its link. The MN MUST use PCoA as its source IP address in this message. If the MN is unable to send an FBU before leaving the PAR, it SHOULD send it as soon as it regains connectivity with the NAR. This allows the PAR to actually start tunneling packets meant for the MN's PCoA. The MN SHOULD resend FBU if it has not received an FBACK up to a maximum of FBU_RETRIES. When the PAR receives an FBU, it MUST first verify that requested handover is accepted by the NAR as indicated in the HACK message status code. Then, it MUST verify that the source IP address in FBU is PCoA for which PAR has forwarded packets previously. And, it MUST create a tunnel for forwarding packets meant for PCoA to NAR. Finally, it MUST send a Fast Binding Acknowledgment (FBACK) message to the MN. This message SHOULD be sent on the old link as well. Reception of FBACK completes the fast handover protocol operation. As soon as the MN establishes link connectivity with the NAR, it 1. MUST send a Fast Neighbor Advertisement (FNA) message (See 6.1.3) if it has not received a confirmation in an FBACK message to use NCoA. This message MUST be sent with PCoA as source IP address. Only after it receives a confirmation to use NCoA in a Router Advertisement with Neighbor Advertisement Acknowledge (NAACK) option (See 6.5.4), the MN MUST use NCoA. If the MN has received confirmation to use NCoA, it MAY send a Router Solicitation anyway with NCoA as source IP address. 2. SHOULD send a Router Solicitation in order to be able to send an FBU when not using anticipation. The source IP address in this message MUST be unspecified. When it is acceptable to use NCoA corresponding to the FNA message, the NAR MUST 1. delete the proxy neighbor cache entry. 2. create a neighbor cache entry and set its state to REACHABLE. 3. enable the host route entry so that any buffered packets could be delivered. Koodli (Editor) Expires 30 March 2003 [Page 11] Internet Draft Fast Handovers 30 September 2002 4. send a router advertisement with Neighbor Advertisement Ack (NAACK) option (See Section 6.5.4) confirming the use of NCoA. When it is not acceptable to use NCoA, NAR MUST still send a router advertisement with NAACK option in which it provides the error code. The NAR MUST still enable the host route entry to deliver any buffered packets. The MN MUST follow [6] in order to configure a new IP address, and it should use the parameters supplied in the router advertisement. Note that the MN is allowed to send packets using PCoA during the time it is involved in confirming the use of NCoA. Once the MN has confirmed its NCoA, it SHOULD send a Neighbor Advertisement message. This message updates its neighbor's cache entries with the MN's link-layer address. Once the MN completes the Binding Update procedure with its correspondent node(s), it SHOULD start using NCoA as its source IP address. In any case, the bidirectional tunnel between the access routers has a lifetime of BT_LIFETIME, after which time, packets using PCoA as source IP address will be discarded unless there is optional protocol support for tunnel lifetime renewal which will be specified in a subsequent revision of this document. 4.4. Three Party Handover The MN may move from NAR to another AR (NAR') before completing its Layer 3 handover and performing binding updates to its correspondents. If the MN moves before configuring a NCoA on NAR, PAR would still be considered its default router when it attaches to NAR'. Hence, the MN SHOULD send an FBU to PAR to set up a tunnel between PAR and NAR'. On the other hand, if the MN is able to configure a NCoA on NAR, but is unable to update all or a partial list of its correspondents, the MN MAY send an FBU to PAR. This FBU may be in addition to the FBU it sends to NAR. The result in this case is that the MN should be able to receive packets arriving at PCoA and NCoA through potentially different tunnels. If the MN returns to PAR without completing Mobile IPv6 updates, it MUST send an FBU with lifetime set to zero so that PAR can disable any outgoing tunnels. The three party handover without IP signaling messages over the air interface is described in Section 4.6. 4.5. Optimization using link-layer assisted features In this section, we describe how the tunnel between the access routers could be set up without IP signaling messages over Koodli (Editor) Expires 30 March 2003 [Page 12] Internet Draft Fast Handovers 30 September 2002 the air interface when the underlying link layer provides the functionality of handover initiation messages defined in Section 4.1. Specifically, a ``Source Link Layer Trigger'' or a ``Target Link Layer Trigger'' could be used to initiate the HI and HAck exchange. Note however, that actual packet forwarding takes place after an FBU is processed. The exact time when packet forwarding begins, after an FBU has been successfully processed, could make use of link-layer triggers. The link layer triggers are described in [4]. We denote by L2-ST a Source Trigger at PAR prior to L2 handover, by L2-TT a Target Trigger at NAR subsequent to L2 handover completion. We also denote by L2-LD a Link Down trigger at PAR that indicates when a link with the MN is terminated, and by L2-LU a Link Up trigger at NAR that indicates that a MN has (just) established a new link. The following diagram illustrates tunnel establishment without using IP messages. 1a. L2-ST ~~~~> +------+ 2. HI +------+ <~~~ 1b. L2-TT | PAR |<-------->| NAR | 4a. L2-LD~> +------+ 3. HACK +------+ <~~~ 4b. L2-LU ^ ^ old L2 | | new L2 +-------+ +-----+ | | | | V V +------+ movement 4c. L2-LU ---> | MN | ---------> +------+ Figure 3: Tunnel Establishment without IP messages The following describes the progress of a two party handover. The numbered items refer to steps in Figure 3. 1. Either the PAR or NAR receives an L2 trigger informing it that a certain MN is about to be moved. The two cases are: a. The L2 trigger is a source trigger (L2-ST) at PAR. The trigger contains the MN's L2 address and an IP identifier (L2 address that can be mapped to an IP address or the IP address directly) for NAR. Koodli (Editor) Expires 30 March 2003 [Page 13] Internet Draft Fast Handovers 30 September 2002 b. The L2 trigger is a target trigger (L2-TT) at NAR. The trigger contains the MN's L2 address and an IP identifier for PAR. 2. The AR receiving the trigger MUST send a HI to the other AR. There two cases: a. If PAR is sending the HI, the `H' bit MUST be set, indicating it is based on source trigger. The HI MUST contain a Lifetime option, an IP address option containing the MN's PCoA, and an Link Layer Address (LLA) option containing the MN's L2 address. The Lifetime option MUST contain the amount of time the PAR is willing to extend tunnel service to the MN's packets before the NAR must renew the tunnel. If the lifetime is zero, the PAR is not willing to tunnel any packets for MN. b. If NAR is sending the HI, the `T' bit MUST be set, indicating it is based on a target trigger. The HI MUST contain a Lifetime option, and an LLA option containing the MN's L2. The Lifetime option MUST contain a request for the amount of time the PAR should extend tunnel service for the MN's packets. 3. The AR receiving the HI MUST send a HAck to the other AR. There are two cases: a. If PAR is sending the HACK, the `T' bit MUST be set. The HAck MUST contain a Lifetime option, an IP address option containing the MN's PCoA, and an LLA containing the MN's L2 address. The Lifetime option MUST contain the amount of time the oAR is willing to extend tunnel service to the MN's packets before NAR must renew the request. If the lifetime is zero, the PAR is not willing to extend tunnel service to the MN. b. If NAR is sending the HAck, the `H' bit MUST be set. No additional information is required, the sequence number identifies the reply. 4. Start of L2 handover is signaled by an L2-LD trigger at PAR and MN. Completion of L2 handover is signaled by an L2-LU trigger at NAR and MN. Each handles the trigger in the following way: a. When the PAR receives the L2-LD trigger, it MUST begin forwarding MN-bound packets on the tunnel to NAR only if PAR has successfully processed an FBU. Koodli (Editor) Expires 30 March 2003 [Page 14] Internet Draft Fast Handovers 30 September 2002 b. When the NAR receives the L2-LU trigger, it MUST begin delivering packets to the MN and MUST forward any outbound packets from MN through the tunnel to PAR. c. Subsequent to establishing a new link, the MN SHOULD configure a NCoA. The MN MAY defer obtaining a NCoA, however, using PCoA after the tunnel lifetime expires would result in packet discarding unless an optional protocol support for extensing the tunnel lifetime is implemented. 5. The PAR becomes an AAR if MN should move again without having changed CoA to NAR's subnet, PCoA becomes ACoA, and NAR becomes PAR. 6. Should L2 handover fail in Step 4 and a ping-pong situation arise, the PAR MUST cancel the tunnel by sending an HI with R bit set to NAR and a Lifetime option having value zero. In this case, the PAR simply continues delivering packets to MN on the old link exactly as if no handover had been pending. The tunnel between the access routers is terminated when BT_LIFETIME expires. However, the following protocol in Section 4.5.1 can be used to renew the tunnel lifetime. 4.5.1. Renewing Tunnel Lifetime The support for protocol described in this section is optional. In order to extend the lifetime of the tunnel, the NAR MUST send a HI message including a proposed new lifetime to PAR, and PAR MUST reply with a HAck indicating whether the tunnel can be extended. An error code of 131 is returned if extension is not possible (See Section 6.2.2). In order to terminate the tunnel, either PAR or NAR MUST send a HI message with a lifetime of zero. The default tunnel lifetime is BT_LIFETIME. NAR SHOULD send a tunnel renewal message prior to the expiration of BT_LIFETIME_WARNING, in order that the MN has sufficient time to complete NCoA configuration. Whether or not the tunnel lifetime can be extended and how many times it can be extended is subject to network operator policy and SHOULD be configurable. When a tunnel can no longer be renewed upon the expiration of BT_LIFETIME_WARNING, the NAR MUST send the MN an unsolicited Router Advertisement in the event it must terminate the tunnel for any reason prior to the MN's configuring it's NCoA. The MN SHOULD Koodli (Editor) Expires 30 March 2003 [Page 15] Internet Draft Fast Handovers 30 September 2002 initiate NCoA configuration immediately upon receipt of the RA, or risk losing forwarding service to PCoA. 4.6. Three Party Handover with Layer 2 Trigger Support The support for protocol described in this section is optional. Three party handover occurs when the MN is on AAR, then moves to PAR, then moves to NAR before completing MIP registration at PAR. The lack of MIP registration may result from either a specific decision by the MN due to an ongoing real time media stream, or it may result from rapid movement between PAR and NAR that does not allow enough time for the registration to complete. This situation is shown in Figure 4 below. In this case, PAR must inform NAR to contact AAR about moving the radio directed end of the tunnel. This is performed with the Handover To Third (HTT) message. +------+ +--->| AAR |<---+ | +------+ | 4b. HI(r) | | 3. HI(t) HACK (r) | | HACK(t) | | v 2a. HI v 1a. L2-ST ~~~> +------+ HTT +------+ <~~~ 1b. L2-TT | PAR |<-------->| NAR | 4a. L2-LD ~~~> +------+ 2b. HTT +------+ <~~~ 5a. L2-LU ^ HACK ^ old L2 | | new L2 +-------+ +-----+ | | | | V V +------+ movement 5b. L2-LU ~~~> | MN | ---------> +------+ Figure 4: Three Party Handover with L2 Triggers The general idea behind the three party handover procedure is that the PAR supplies NAR with the same information it would have obtained via an L2-TT if handover had occurred with AAR, then the NAR performs an HI/HACK sequence with AAR in order to move the BT to NAR. When the L2 handover is complete, PAR sends an HI to AAR to terminate the BT. Koodli (Editor) Expires 30 March 2003 [Page 16] Internet Draft Fast Handovers 30 September 2002 The following describes the progress of a three party handover. The numbered items refer to steps in Figure 4. 1. Either the PAR or NAR receives an L2 trigger informing it that a certain MN is about to be moved. The two cases are: a. The L2 trigger is a source trigger (L2-ST) at PAR. The trigger contains the MN's L2 address and an IP identifier (L2 address that can be mapped to an IP address or the IP address directly) for NAR. b. The L2 trigger is a target trigger (L2-TT) at NAR. The trigger contains the MN's L2 address and an IP identifier for PAR. 2. The PAR and NAR exchange a HTT/HI or HACK/HTT pair. There are two cases: a. The L2 trigger is an L2-ST. The PAR MUST send HTT to NAR containing the IP address of AAR and two LLAs. The first LLA MUST contain the L2 address of the MN, the second MUST contain the L2 address of the AAR. This is enough information for NAR to perform a target trigger handover with AAR. The NAR MUST respond with a HACK. b. The L2 trigger is an L2-TT. The NAR MUST send a HI to PAR, exactly as if a two party target triggered handover were occurring. The PAR MUST responds with HTT containing the IP address of AAR and two LLAs. The first LLA MUST contain the L2 address of the MN, the second MUST contain the L2 address of the AAR. This is enough information for NAR to perform a target trigger handover with AAR. 3. The NAR MUST first check its routing tables to see whether it is already tunneling for MN. If so, Step 6 is performed. If not, NAR MUST perform a target trigger handover with AAR, exactly as in Section 3.3, exchanging a HI/HACK pair. Because AAR receives no L2 trigger indicating when to start handover, it MAY place the BT to NAR upon transmission of the HACK, or alternatively it MUST wait to establish the BT with NAR until PAR signals that L2 handover has begun in Step 4. 4. At the start of L2 handover, AAR and PAR exchange messages canceling tunnel service between AAR and PAR and allowing AAR to start the tunnel with NAR. a. The start of L2 handover is signaled at PAR by L2-LD. b. The PAR MUST exchange a HI/HACK pair with AAR with a Koodli (Editor) Expires 30 March 2003 [Page 17] Internet Draft Fast Handovers 30 September 2002 Lifetime option having value zero. This cancels tunnel service between PAR and AAR. If AAR has not already placed a BT to NAR, it MUST do so immediately upon receipt of the HI. 5. Completion of L2 handover is signaled by an L2-LU trigger at NAR and MN. The NAR and MN handle the trigger in the following ways: a. The NAR MUST begin delivering packets to the MN, and MUST tunnel any CN-bound packets from the MN to aFA. b. Based on its current movement and traffic pattern, MN MAY either defer obtaining a nCoA or begin the process of obtaining an nCoA. 6. In the special case where NAR and AAR are the same, AAR recognizes that it is tunneling to PAR when it checks its routing tables in Step 3. In this case, there is no need for AAR to send the HI/HACK with itself in Step 3. Upon receipt of the L2-LU trigger on handover completion, the AAR MUST begin routing packets directly to MN and the tunnel to NAR MUST be torn down. The AR MUST still exchangesthe HI/HACK with PAR in Step 4b because PAR can't know a priori that AAR and NAR are the same, but AAR MUST NOT need not gate old tunnel tear down or delivery of MN packets on this exchange. Unlike two party handover, the timing of BT establishment between AAR and NAR cannot fully depend on the availability of L2 trigger information because AAR does not receive an L2 trigger when L2 handover begins. The two timing extremes at which AAR can place the BT with NAR are: 1. At the earliest, AAR MAY establish the BT with PAR after sending the HACK(t) to NAR in response to the request for target-triggered handover, 2. At the latest, AAR MUST establish the BT with NAR and tear down the BT with PAR when receiving the HI(r) from PAR indicating the L2 handover has begun. In addition, AAR MAY contine tunnel service with PAR if 1) is selected, until the HI is received. If 1) is selected and the AAR continues to tunnel to PAR, the result may be duplicated packets at the MN, because the MN will receive packets through PAR on the old L2 until L2 handover begins. If 2) is selected, the additional latency of the HI added to the L2 handover latency may result in additional packets being dropped while the MN is not receiving L3 networking service. Of course, AAR can choose to place the BT some time between Koodli (Editor) Expires 30 March 2003 [Page 18] Internet Draft Fast Handovers 30 September 2002 1) and 2) if the network can give reasonable bounds. The exact selection of when to establish the BT is likely to be influenced by network engineering and implementation considerations, including whether a handover smoothing solution is deployed, and is beyond the scope of this specification. Figure 5 and Figure 6 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) three party handover, respectively in order to further illustrate the protocol shown in Figure 4. Koodli (Editor) Expires 30 March 2003 [Page 19] Internet Draft Fast Handovers 30 September 2002 MN NAR PAR AAR | | | | | | L2-ST ~~~~~> | | | | | | | |<-------------| | | | HTT | | | |------------->| | | | HACK(s) | | | | | | | |------------------------------>| | | HI(t) | | | | | | | |<------------------------------| | | HACK(t) | | | | | | ----------------------------------<~~~ L2-LD | |--------------->| L2 Handover | HI(r) | | | |<---------------| | HACK(r) | | | ----------------------------------<~~~ L2-LU | | | | | |<-------------->| | | | MN's traffic | | | | on aCoA | | | | | | | Figure 5: Three Party Source Trigger Handover Timing 5. Other Considerations 5.1. Handover Capability Exchange A MN, when it attaches to its access router needs to know whether the access router supports fast handover. Similarly, the access router needs to know whether the MN is capable of fast handover protocol. For this purpose, a new Hanodver Capability Extension is defined. See Section 6.5.5. The MN MUST include this extension in a Router Solicitation message if it supports fast handover protocol. The access router MUST include the extension in the corresponding Router Advertisement if it supports the fast handover protocol. Koodli (Editor) Expires 30 March 2003 [Page 20] Internet Draft Fast Handovers 30 September 2002 MN NAR PAR AAR | | | | | |<~~~ L2-TT | | | | | | | |------------->| | | | HI(t) | | | |<-------------| | | | HTT | | | |------------------------------>| | | HI(t) | | | | | | | |<------------------------------| | | HACK(t) | | | | | | ----------------------------------<~~~ L2-LD | |--------------->| L2 Handover | HI(r) | | | |<---------------| | HACK (r) | | | ----------------------------------<~~~ L2-LU | | | | | |<-------------->| | | | MN's traffic | | | | on aCoA | | | Figure 6: Three Party Target Trigger Handover Timing The access router MUST NOT send a gratuitous PrRtAdv message if the MN does not include the Handover Capability Extension. If the Router Advertisement does not include the Handover Capability Extension, the MN MUST not send a RtSolPr message. Even if a MN's current access router is capable of fast handover, the access router into which the MN is handing over to may not be capable of fast handover. This is indicated to the MN during ``runtime'', through the PrRtAdv message with a Code value of 3. See Section 6.1.2. Koodli (Editor) Expires 30 March 2003 [Page 21] Internet Draft Fast Handovers 30 September 2002 5.2. Determining New Care of Address When stateless address configuration is used, the PAR MUST formulate NCoA using the MN's interface identifier and the NAR's subnet prefix according to [6] and include NCoA in the HI message. The New Access Router MUST verify that NCoA is unique before beginning to defend that address. If the address is not unique, a status code in the required HACK message indicates it. And, PAR MUST convey that the proposed NCoA is not acceptable to MN in the FBACK message. If stateful address configuration is being used, NCoA is returned by the NAR, instead of being proposed by the PAR. The HI and HACK message exchange precedes the transmission of PrRtAdv from the PAR to the MN, because NAR allocates the new IP address. The rest of the process is identical to the stateless approach. If the MN is unable to use anticipation to form a NCoA when attached to PAR, it SHOULD begin the process of configuring its NCoA as soon as it determines that it has moved to NAR. The NCoA configuration process follows either stateless (which could include DAD) or statefull IPv6 address configuration procedure. In order to use NCoA with its correspondents however, the MN has to first send a BU to its Home Agent, and perform return routability prior to sending BU to its correspondents with which the MN is interested in route optimization. These steps are specified in [3]. The MN MAY defer NCoA configuration for some period of time if the MN's traffic conditions or movement patterns do not allow it to perform NCoA configuration. An example of such a condition is if the MN would be required to linger on the link solely in order to complete NCoA configuration. If the MN moves to another AR before completion of CoA configuration, either during the configuration process or prior to beginning the process, the considerations in Section 4.4, and Section 4.6 apply. In particular, if protocol support specified in Section 4.6 is available, the NAR SHOULD arrange for the MN's tunnel to be handed over to the MN's next destination router. The NAR MUST send the MN an unsolicited RA in the event it must terminate the tunnel for any reason prior to the MN's configuring it's NCoA. The MN SHOULD initiate NCoA configuration immediately upon receipt of the RA, or risk losing forwarding service to PCoA. 5.3. Packet Loss Handover involves link switching. It is understandably difficult to exactly co-ordinate fast handover signaling with link switching. Furthermore, arrival pattern of packets is dependent on many factors, Koodli (Editor) Expires 30 March 2003 [Page 22] Internet Draft Fast Handovers 30 September 2002 including application characteristics, network queuing behavior etc. Hence, packets may arrive at NAR before the MN is able to attach to it. 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 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 the PAR does request this feature, it SHOULD also provide its own support for buffering. 5.4. DAD Handling Duplicate Address Detection (DAD) was defined in [6] 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 autoconfiguration may add delays to a MIPv6 handover. The probability of an interface identifier duplication on the same subnet is very low, however it can not be ignored. In this draft certain precautions are proposed to minimize the effects of a duplicate address occurrence. On links wherein the uniqueness of the interface identifier is ensured within the subnet (by means beyond the scope of this document), DAD handling procedures SHOULD be avoided. 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, the NAR can have a list of all nodes on its subnet, perhaps for access control, and by searching this list, it can confirm whether the MN's address is a duplicate or not. The result of this search is sent back to the PAR in the HACK message. If such knowledge is not available at the NAR, it may indicate this by not confirming NCoA in the HACK message. In such a case, the MN would have to follow stateless address configuration rules after attaching to the NAR. Since this specification allows the MN to continue to use PCoA, the delay due to DAD is not a concern. However, the transmission epoch of Binding Update to the Home Agent will be delayed. 5.5. 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 and but it is Koodli (Editor) Expires 30 March 2003 [Page 23] Internet Draft Fast Handovers 30 September 2002 either moved to a different one or it 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 be in a frequency that allows enough time for the MN to update the binding of, at least, its HA and preferably that of every CN with which it is in communication. A MN that moves faster than necessary for this signaling to complete may start losing packets and ultimately connectivity. The signaling overhead over the air and in the network may increase significantly, especially in the case of rapid movement between two access routers. To avoid the signaling overhead, the following measures are suggested. A MN returning to the PAR before updating the necessary bindings in the 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 from it to the NAR. The PAR, on receiving this Fast Binding Update, will check its set of outgoing (temporary fast handover) tunnels and if it finds a match it SHOULD drop that tunnel; i.e., stop forwarding packets for this MN and start delivering packets directly to the node instead. The MN SHOULD NOT make any attempt to use any of the fast handover mechanisms described in this specification and SHOULD revert back to standard Mobile IPv6. Temporary tunnels for the purposes of fast handovers should use short lifetimes (in 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. A long life times increases the chance of a circular tunnel from PAR to NAR and back again to PAR which could essentially result in a routing loop, especially if the PCoA is used with tunnels between ARs themselves, rather than forwarding to NCoA. Erroneous movement is not likely to damage the network but it may cause loss of packets since routing can change and the PAR may forward packets towards another AR before the MN actually connects to that AR. If the MN discovers itself on the wrong AR, a Fast Binding Update to the PAR SHOULD be sent. Since Fast Binding Updates are authenticated, they MUST supersede the existing binding and packets SHOULD be redirected to the new confirmed location of the MN. No attempt should be made to recover packets from the AR the MN was supposed to connect to. Koodli (Editor) Expires 30 March 2003 [Page 24] Internet Draft Fast Handovers 30 September 2002 6. Message Formats 6.1. New Neighbor Discovery Messages 6.1.1. Router Solicitation for Proxy Mobile Nodes send Router Solicitation for Proxy in order to prompt routers for Proxy Router Advertisements. For all the ICMP messages, the checksum is defined in [2]. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 7: Router Solicitation for Proxy (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 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Type TBA Koodli (Editor) Expires 30 March 2003 [Page 25] Internet Draft Fast Handovers 30 September 2002 Code 0 Checksum The ICMP checksum. Identifier MUST be set by the sender so that replies can be matched to this Solicitation. Reserved MUST be set to zero by the sender and ignored by the receiver. Valid Options: Source link-layer address The link-layer address of the sender, if known. It SHOULD be included on link layers that have addresses. New Attachment Point Link-Layer Address The link-layer address or identification of the attachment point for which the MN requests routing advertisement information. It MUST be included in all RtSolPr messages. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the rest of the message. A MN sends this message if it wishes to initiate fast handover. It indicates its destination with the New Attachment Point Link-Layer Address. A Proxy Router Advertisement message should be received in response. 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 ms if RTT is not known, it SHOULD resend RtSolPr message at most twice, waiting for the same time during each instance of retransmission. If Proxy Router Advertisement is not received by the time the MN disconnects from the PAR, the MN SHOULD attempt to send FBU as described in Section 4.2. 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. IP Fields: Koodli (Editor) Expires 30 March 2003 [Page 26] Internet Draft Fast Handovers 30 September 2002 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 8: Proxy Router Advertisement (PrRtAdv) Message 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 or the address of the node the Access Router is instructing to handover. Hop Limit 255 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Type TBA Code 0, 1, or 2 Checksum The ICMP checksum. Identifier Copied from Router Solicitation for Proxy or set to Zero if unsolicited. Reserved MUST be set to zero by the sender and ignored by the receiver. Koodli (Editor) Expires 30 March 2003 [Page 27] Internet Draft Fast Handovers 30 September 2002 Valid Options: Source link-layer address The link-layer address of the sender, if known. It SHOULD be included on link layers that have addresses. Link-layer address of proxied originator (i.e., NAR) The link-layer address of the Access Router for which this message is proxied for. This option MUST be included when Code is 0. New Router Prefix Information Option. These options specify the prefixes of the Access Router the message is proxied for and are used for address autoconfiguration. This option SHOULD be included when Code is 0. New CoA Option In stateful configuration, this option MUST be sent to allocate an address on behalf of the Access Router this message is proxied for (i.e.,NAR). In stateless address auto-configuration this option MAY be present. 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. A Proxy Router Advertisement with Code 0 but without a New CoA Option means that the MN SHOULD construct a NCoA out of its Interface ID (used in the Destination Address in this Proxy Router Advertisement) and the Prefix in the New Router Prefix Information Option (See Section 6.5.2. A Proxy Router Advertisement with Code 0 and a New CoA Option means that the MN SHOULD use the CoA indicated as a NCoA at the NAR. The New CoA MUST be used when Stateful CoA configuration is indicated and MAY be used to assist the PAR and MN calculate the same NCoA when Stateless address configuration is used. A Proxy Router Advertisement with Code 1 is sent if handover to the New Attachment Point, as indicated by the New Attachment Point Link Layer address in the corresponding RtSolPr message, does not require change of CoA. No options are required in this case. A Proxy Router Advertisement with Code 2 means that the 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. Processing Koodli (Editor) Expires 30 March 2003 [Page 28] Internet Draft Fast Handovers 30 September 2002 of such a FBU follows the description in Section 4.2. No options are required in this case. A Proxy Router Advertisement with Code 3 means that the NAR does not support fast handover. The MN MUST stop fast handover protocol operations. No options are required in this case. 6.1.3. Fast Neighbor Advertisement (FNA) A MN sends a Fast Neighbor Advertisement to announce itself to the NAR. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 9: Fast Neighbor Advertisement (FNA) Message IP Fields: Source Address MUST be the MN's PCoA. Destination Address NAR's IP address or the all-router's multicast address. Hop Limit 255 Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Koodli (Editor) Expires 30 March 2003 [Page 29] Internet Draft Fast Handovers 30 September 2002 Type TBD Code 0 Checksum The ICMP checksum. R flag The isRouter flag. MUST be set to zero. S flag The solicited flag. MUST be set to zero. O flag The override flag. MUST be set to one. Reserved 32-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Possible options: Target link-layer address The link-layer address for the target, i.e., the sender of the advertisement. This option MUST be included in all FNA messages. Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the rest of the message. The MN sends Fast Neighbor Advertisement to the NAR, as soon as it gains connectivity on the new link, when the Fast Binding Acknowledgment has not been received. The Fast Neighbor Advertisement is sent because the MN is still unsure about the NCoA it should be using on its new link. Using PCoA and the MN's link-layer address, the NAR checks its host route entry and proxy neighbor cache. The NAR SHOULD enable the host route entry so that packets sent to PCoA can be forwarded. If a proxy neighbor cache entry is found, the NAR SHOULD create a neighbor cache entry, set it to REACHABLE state and then delete the proxy neighbor cache entry. In any case, the NAR MUST send a Router Advertisement to PCoA as destination address with NAACK option(See Section 6.5.4). The NAACK option indicates if it is acceptable to use NCoA or not. When use of NCoA is not acceptable, the MN MUST fallback to IPv6 address configuration. Koodli (Editor) Expires 30 March 2003 [Page 30] Internet Draft Fast Handovers 30 September 2002 6.2. Inter-Access Router Messages 6.2.1. Handover Initiate (HI) The Handover Initiate (HI) is a new 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier |S|U|H|T|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 10: Handover Initiate (HI) Message IP Fields: Source Address The IP address of the PAR Destination Address The IP address of the NAR Hop Limit 255 Authentication Header A Security Association MUST exist between the sender and the receiver of this message. This message MUST be authenticated and so the authentication header MUST be used when this message is sent. ICMP Fields: Type TBA Code 0 Koodli (Editor) Expires 30 March 2003 [Page 31] Internet Draft Fast Handovers 30 September 2002 Checksum The ICMP checksum. Identifier MUST be set by the sender so replies can be matched to this message. S Stateful address configuration flag. When set, this message requests a new CoA to be returned by the destination. U Buffer flag. When set, the destination SHOULD buffer any packets towards the node indicated in the options of this message. Reserved MUST be set to zero by the sender and ignored by the receiver. Valid Options: Link-layer address of MN The link-layer address of the MN that is undergoing handover to the destination. This option SHOULD be included to help the destination recognize the MN when it connects to the destination. Previous Care of Address The IP address used by the MN while attached to the originating router. This option MUST be included so that packets sent to PCoA can always be redirected to NAR. New Care of Address The IP address the MN wishes to use when connected to the destination. Used in stateless configuration to request NAR to confirm whether the MN can use this address. When the `S' bit is zero, and if this option is not present, it indicates that the MN is not anticipating a new CoA through this message. This is useful when PAR has to initiate a HI after the MN attaches to NAR and sends FBU. In addition, the following additional flags in the Reserved field are present and the Lifetime option MAY be present when the tunnel is established using the link layer triggers. The default lifetime for the bidirectional tunnel between the access routers is BT_LIFETIME. H Set if the message was triggered by an L2-ST in a two party handover. All other bits are unset. Koodli (Editor) Expires 30 March 2003 [Page 32] Internet Draft Fast Handovers 30 September 2002 T Set if the message was triggered by an L2-TT. All other bits are unset. R Set if a request to extend or cancel tunnel service. All other bits are unset. Lifetime Option The lifetime, in seconds, for which the requester would like tunnel service extended. If the field is zero, the request is to cancel tunnel service. If the field is 0xffffffff, the request is for infinity. If Handover Acknowledge (HACK) message is not received as a response, the Handover Initiate SHOULD be resent up to HI_RETRIES times using a short retransmission timer with a value no less than twice the round trip time between source and destination or 100 ms if RTT is not known. Failure to receive a Handover Acknowledgment means that no fast handover can be performed (See Section 4.2). 6.2.2. Handover Acknowledge (HACK) The Handover Acknowledgment message is a new ICMPv6 message that MUST be sent (typically by NAR to PAR) in reply to the Handover Initiate message. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier |H|T|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 11: Handover Acknowledge (HAck) Message IP Fields: Koodli (Editor) Expires 30 March 2003 [Page 33] Internet Draft Fast Handovers 30 September 2002 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. Hop Limit 255 Authentication Header A Security Association MUST exist between the sender and the receiver of this message. This message MUST be authenticated and so the authentication header MUST be used when this message is sent. ICMP Fields: Type TBA Code 0: Handover Accepted, NCoA valid 1: Handover Accepted, NCoA not valid 2: Handover Accepted, NCoA in use 3: Handover Accepted, NCoA assigned (Stateful) 4: Handover Accepted, NCoA not assigned (Stateful) 128: Handover Not Accepted, reason unspecified 129: Administratively prohibited 130: Insufficient resources 131: Tunnel Lifetime Renewal failed Checksum The ICMP checksum. Identifier Copied from the corresponding field in the Handover Initiate message this message is in response to. Reserved MUST be set to zero by the sender and ignored by the receiver. 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. Koodli (Editor) Expires 30 March 2003 [Page 34] Internet Draft Fast Handovers 30 September 2002 In addition, the following flags are present Lifetime option MAY be present when using link layer triggers. The default lifetime for the bidirectional tunnel between the access routers is BT_LIFETIME. H Set if in response to HRqst(s) in a two party handover. All other bits are unset. T Set if in response to an HRqst(t) in a two party handover, or when sent by aAR in a three party handover. All other bits are unset. R Set if in response to a HRqst(r). All other bits are unset. Lifetime Option The lifetime, in seconds, for which the sender is willing to grant tunnel service. If the field is zero, the request for tunnel service is denied. If the field is 0xffffffff, the tunnel service is guaranteed until canceled. Upon receiving the 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 of 3. If the `S' flag is not set in the HI message, the NAR MUST check the validity of the NCoA when sent with HI, and reply with appropriate Code values enumerated above. If NCoA is valid, the NAR SHOULD insert NCoA in its Proxy Neighbor Cache and defend NCoA for PROXY_ND_LIFETIME period of time during which the MN is expected to connect to NAR. If the NCoA is not valid or not assigned, the NAR MUST respond with an appropriate Code value. If the `S' flag is not set and NCoA is not present, it indicates that the PAR is requesting NAR to neither verify NCoA nor allocate one. In any case, the NAR MUST establish a host route entry for PCoA and set up a tunnel to the PAR to forward MN's packets 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. Finally, the new access router can always refuse handover, in which case it should indicate the reason in one of the available Code values. Koodli (Editor) Expires 30 March 2003 [Page 35] Internet Draft Fast Handovers 30 September 2002 6.3. Handover To Third (HTT) This is a message used in the optional Three Party Handover protocol described in Section 4.6. HTT message is an extension of both HI and HACK. If HTT is triggered by an L2-ST, then it is an extension of HI. If HTT is sent in response to an HI with T bit set, then it is an extension of the HACK. The message can be distinguished as an HTT because it has both the H and T bits set regardless of whether it is received as a request or sent as a reply. No other bits are set in HTT. In addition, the HTT MUST contain the following options in the specified order: Valid Options: IP Address Option containing AAR's Address. LLA Option containing the L2 address of the MN. LLA Option containing the L2 address of AAR. 6.4. New Mobility Header Messages Mobile IPv6 uses a new IPv6 header type called Mobility Header [3]. The Fast Binding Update and Fast Binding Acknowledgment messages both use the Mobility Header. 6.4.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. The Mobility Header Type value for FBU is 8. IP fields: Source address The PCoA 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 Acknowledgement message. Koodli (Editor) Expires 30 March 2003 [Page 36] Internet Draft Fast Handovers 30 September 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|S|D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Fast Binding Update (FBU) Message `H' flag MUST be set to one. See [3]. `S' flag See [3]. `D' flag SHOULD be set to zero (since ``home address'' is the address in use (i.e., PCoA). Reserved This field is unused. MUST be set zero. Sequence Number A 16-bit number used by the receiving node to sequence Fast Binding Updates and by the sending node to match a returned Fast Binding Acknowledgment with this Fast Binding Update. Each Fast Binding Update sent by a mobile node MUST use a Sequence Number greater than the Sequence Number value sent in the previous Fast Binding Update (if any) to the same destination Koodli (Editor) Expires 30 March 2003 [Page 37] Internet Draft Fast Handovers 30 September 2002 address (modulo 2**16, as defined in [3]). The processing rules for this field are the same as those described in [3]. Lifetime 32-bit unsigned integer. The number of seconds remaining before the binding MUST be considered expired. A value of all one bits (0xffffffff) indicates infinity. A value of zero indicates that the binding for the mobile node MUST be deleted. Home Address The Previous Care of Address. Mobility Options MUST contain alternate CoA option set to NAR's IP address. The MN MUST send a FBU message after receiving a PrRtAdv message. If the MN moves prior to receiving a PrRtAdv message, it SHOULD send a FBU to the PAR. Since the source IP address in FBU is PCoA, then the Home Address field is redundant. In addition, if FBU is sent after PrRtAdv is received, PAR can determine the target address for traffic redirection, namely the NAR's IP address from the HI and HACK sequence. Since both of these addresses can be inferred, these fields MAY be omitted in a FBU message providing that a PrRtAdv message has been received. The absence of these fields can be determined by observing the Option Length value in the Mobility Header. The Previous Access Router SHOULD process a FBU that does not contain these fields. A FBU message MUST be protected in a way appropriate for MN and PAR communication. That is, PAR MUST be able to determine that the FBU message is sent by a genuine MN. 6.4.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. The Fast Binding Acknowledgment message MUST NOT be sent to the MN before the PAR receives a Handover Acknowledge message from the NAR. If HACK contains a validation of NCoA, FBACK MUST be sent with the MN's PCoA as the destination address with a status code 0. The Fast Binding Acknowledgment MAY also be sent to the MN on the old link. The Mobility Header Type value for FBACK is 9. Koodli (Editor) Expires 30 March 2003 [Page 38] Internet Draft Fast Handovers 30 September 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Fast Binding Acknowledgment (FBACK) Message IP fields: Source address The IP address of the Previous Access Router Destination Address The 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 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 Koodli (Editor) Expires 30 March 2003 [Page 39] Internet Draft Fast Handovers 30 September 2002 131 Incorrect interface identifier length 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 Currently, none specified. 6.5. New ICMP Options 6.5.1. IP Address Option This option is sent in the Proxy Router Advertisement, the Handover Initiate and Handover Acknowledge messages. The Proxy Router Advertisement and Handover Acknowledgment messages only contain the NCoA while the Handover Initiate message may include both NCoA and PCoA. The format is based on [5]. 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 | Sub-Type | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: IPv6 Address Option Koodli (Editor) Expires 30 March 2003 [Page 40] Internet Draft Fast Handovers 30 September 2002 Type TBA Length size of this option units of 8 octets (i.e., 3) Sub-Type 1 Old Care-of Address 2 New Care-of Address Prefix Length The Length of the IPv6 Address Prefix IPv6 address The IP address for the unit defined by the Type field. 6.5.2. New Router Prefix Information Option This option is sent in the PrRtAdv message in order to provide the prefix information valid on the NAR. 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 | Sub-Type | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: New Router Prefix Information Option Type TBA Koodli (Editor) Expires 30 March 2003 [Page 41] Internet Draft Fast Handovers 30 September 2002 Length The length of the option (including the type, sub-type and length fields) in units of 8 octets. Sub-Type 0 Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. Prefix An IP address or a prefix of an IP address. 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. 6.5.3. Link-layer Address (LLA) The format of this message is based on [5]. 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 | Sub-Type | LLA ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: Link-Layer Address Option Type TBA Length The length of the option (including the type, sub-type and length fields) in units of 8 octets. Sub-Type 1 for the Link-layer Address of the new Attachment Point. 2 for the Link-layer Address of the MN. 3 for the Link-layer Address of the Proxied Originator Koodli (Editor) Expires 30 March 2003 [Page 42] Internet Draft Fast Handovers 30 September 2002 LLA The variable length link-layer address. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. The New Attachment Point Link Layer address contains the link-layer address of the attachment point for which handover is about to be attempted. This is used in the Router Solicitation for Proxy message. The MN Link-Layer address option contains the link-layer address of a MN. It is used in the Handover Initiate message. The Proxied Originator Link-Layer address option contains the Link Layer address of the Access Router for which the Proxy Router Solicitation message refers. These options MUST be silently ignored when used with other Neighbor Discovery messages. 6.5.4. 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 | Sub-Type | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: Neighbor Advertisement Acknowledgment Option Type TBA Length 8-bit unsigned integer. Length of the option, in 8 octets, excluding the Option Type and Option Length fields. Sub-Type 0 Status Koodli (Editor) Expires 30 March 2003 [Page 43] Internet Draft Fast Handovers 30 September 2002 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 The New CoA is valid 1 The New CoA is invalid 128 Link Layer Address unrecognized The NAR uses NAACK option, to confirm the validity of NCoA, in a Router Advertisement sent as a response the FNA message. The PAR also provides such a confirmation in the FBACK message. If the NCoA is valid, the Router Advertisement MUST use NCoA as the destination address and the MN SHOULD use it as its new CoA as defined in [3]. If the NCoA is invalid, the Router Advertisement MUST use the PCoA as the destination address. The MN MAY use PCoA as source address, however, it SHOULD start the process of obtaining a NCoA at the NAR. If the NAACK indicates that the Link Layer Address is unrecognized the MN MUST NOT use the NCoA or the PCoA and SHOULD start immediately the process of acquiring a NCoA at the NAR. In the future, new option types may be defined. 6.5.5. Handover Capability Extension The Handover Capabilities extension is used in the IPv6 Router Solicitation and Router Advertisement to indicate whether or not a MN and its access router are capable of supporting fast handovers. 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 | Sub-Type | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: Handover Capability Extension Option Type TBD Length The length of the option (including the type, sub-type and Koodli (Editor) Expires 30 March 2003 [Page 44] Internet Draft Fast Handovers 30 September 2002 length fields) in units of 8 octets. Sub-Type 0 Code 0 The node supports fast handover 7. Configurable Parameters Parameter Name Default Value Definition ------------------- ---------------------- ------- FBU_RETRIES 3 Section 4 BT_LIFETIME 2 seconds Section 4 BT_LIFETIME_WARNING 500 ms Section 4.5.1 PROXY_ND_LIFETIME 1 second Section 6.2.2 HI_RETRIES 4 Section 6.2.1 8. Security Considerations The PAR MUST ensure that the FBU packet arrived from a node that legitimately owns the PCoA. Otherwise, a bogus node, either on-link or off-link, could attempt to disrupt packets meant for the MN and redirect them to some access router. When FBU is sent on-link (i.e., it is not tunneled), the default security is what Neighbor Discovery offers. The access router and its hosts may use any available mechanism to establish a security association. When a pre-established security association is available, it MUST be used to secure FBU. If an access router can ensure that the source IP address in an arriving packet could only have originated from the node whose link-layer address is in the router's neighbor cache, then a bogus node cannot use a victim's IP address for malicious redirection of traffic. Such an operation should be performed at least on neighbor discovery messages including the RtSolPr message. When FBU is sent off-link (i.e., arrives in a tunnel), it MUST be protected by a security association established between the node sending FBU and the PAR. The target of malicious traffic redirection is limited to an access router only with which the PAR has a security association. Because of this, traffic could only be redirected to NAR's IP address Koodli (Editor) Expires 30 March 2003 [Page 45] Internet Draft Fast Handovers 30 September 2002 (and not to any other address), and the possibility of spamming an unsuspecting node is eliminated. 9. Contributors This document originated from the fast handover design team effort. The members of this design team in alphabetical order are; Gopal Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, George Tsirtsis and Alper Yegin. 10. Acknowledgments The editor would like to thank the design team for all their hard work. The Design Team would like to recognize Hesham Soliman's valuable contribution to this work. Also, warm thanks to Basavaraj Patil and Phil Roberts for supporting this effort and the whole Mobile IP WG for participating in the initial discussion. The WG would like to thank James Kempf, Pat Calhoun, Gopal Dommety, Sebastian Thalanany, Ajoy Singh, Peter J. McCann and Tom Hiller for proposing the BETH method which is the basis of Section 4.5 and Section 4.6. James Kempf also contributed text in Section 4.5.1 and Section 5.2. References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [2] A. Conta and S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. Request for Comments (Draft Standard) 2463, Internet Engineering Task Force, December 1998. [3] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force, 2002. [4] (editor) Kempf, J. Requirements for Layer 2 Protocols to Support Optimized Handover for IP Mobility (work in progress). Internet Draft, Internet Engineering Task Force. draft-manyfolks-l2-mobilereq-00.txt, January 2000. [5] M. Khalil, R. Narayanan, H. Akhtar, and E. Qaddoura. Mobile IP Extensions Rationalization (MIER) (work in progress). Internet Koodli (Editor) Expires 30 March 2003 [Page 46] Internet Draft Fast Handovers 30 September 2002 Draft, Internet Engineering Task Force. draft-ietf-mobileip-mier-05.txt, February 2000. [6] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments (Draft Standard) 2462, Internet Engineering Task Force, December 1998. 11. Contact Information The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Megisto Systems,Inc 6000 Connection Drive 20251 Century Blvd M/S M8-540 Germantown, MD 20874 Irving, Texas 75039 USA USA Phone: +1 301-444-1700 Phone: +1 972-894-6709 Fax: +1 301-515-3675 Fax : +1 972-894-5349 E-Mail: proberts@megisto.com E-Mail: Basavaraj.Patil@nokia.com The design team member's contact information: Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone:+1 408 525 1404 E-Mail: gdommety@cisco.com Karim El Malki Ericsson Radio Systems AB LM Ericssons Vag. 8 126 25 Stockholm SWEDEN Phone: +46 8 7195803 Fax: +46 8 7190170 E-mail: Karim.El-Malki@era.ericsson.se Mohamed Khalil Nortel Networks E-Mail: mkhalil@nortelnetworks.com Charles E. Perkins Communications Systems Lab Koodli (Editor) Expires 30 March 2003 [Page 47] Internet Draft Fast Handovers 30 September 2002 Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 E-Mail: charliep@iprg.nokia.com Fax: +1 650 625-2502 George Tsirtsis Flarion Technologies E-Mail: G.Tsirtsis@flarion.com Alper E. Yegin Sun Microsystems 901 San Antonio Rd, UMPK17-202 Palo Alto, CA, 94303,USA Phone: +1 650 786 4013 E-mail: alper.yegin@sun.com The editor's contact information: Rajeev Koodli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Phone: +1 650 625 2359 Fax: +1 650 625 2502 E-Mail: Rajeev.Koodli@nokia.com Koodli (Editor) Expires 30 March 2003 [Page 48]