Mobile IPv6 Fast Handovers
obsoleted by
- rfc-5568 — Mobile IPv6 Fast Handovers
obsoletes
- rfc-4068 — Fast Handovers for Mobile IPv6
Extracted elements (32)
DAD on the NAR introduces handover delay, but the protocol preserves correctness: the NAR SHOULD perform a DAD probe before proxying the NCoA unless DupAddrDetectTransmits is set to zero. This setting is appropriate only where address collision probability is negligible, balancing latency against uniqueness guarantees.
The Fast Neighbor Advertisement (FNA) message from RFC 4068 is deprecated in favor of the standard Unsolicited Neighbor Advertisement (UNA) with the 'O' bit cleared. This eliminates a separate message type while retaining the same fast attachment-notification semantics using existing Neighbor Discovery infrastructure.
The protocol deliberately avoids modifying base Mobile IPv6, IPv6 SLAAC, or DHCP. It introduces only a minimal optional extension to Neighbor Discovery (a Router Advertisement in response to UNA), keeping the fast handover mechanism as an orthogonal optimization layer.
This document obsoletes RFC 4068. The FNA message defined in RFC 4068 is deprecated; implementations MUST use UNA instead. Section 8 details behavioral changes including BADF replacing the prior security mechanism and revised retransmission rules.
An FBU message MUST contain the Binding Authorization Data for FMIPv6 (BADF) option to ensure that only a legitimate MN owning the PCoA can establish a binding. This applies whether the FBU is sent from the PAR's link or the NAR's link.
An MN returning to the PAR before completing binding updates MUST send a Fast Binding Update with Home Address equal to PCoA and a lifetime of zero to the PAR, triggering tunnel teardown.
Both HI and HAck messages SHOULD be used between access routers. The access routers MUST have the necessary security association established by means outside the scope of this document.
If an assigned NCoA is returned in HAck, it MUST be included in the FBack message, and the MN MUST use the assigned address (rather than the proposed NCoA in the FBU) upon attaching to the NAR.
If PAR implements FIFO buffering, it MUST continue forwarding packets to the PCoA (buffer and forward). When buffering draining begins, a maximum of 5 packets MAY be sent back-to-back; all subsequent packets SHOULD use a sending rate metered by the original arrival rate.
If the MN receives an IP address in the NAACK option, it MUST use it and send an FBU using the new CoA. If the address in NAACK is the PCoA itself, the MN MUST NOT send any more FBUs.
In network-initiated handover, the MN MUST process an unsolicited PrRtAdv to configure a new CoA and MUST send an FBU to the PAR prior to switching to the new link. The PAR MUST continue forwarding packets to the MN on the current link until the FBU is received.
RtSolPr retransmissions MUST use exponential backoff (doubling the timeout of 2×RTT or 100 ms) up to RTSOLPR_RETRIES. When sent more than once, they MUST be rate limited to MAX_RTSOLPR_RATE per second.
The BADF option MUST be the last Mobility Option present in an FBU or FBack message. The default MAC is HMAC-SHA1 with the first 96 bits used; other algorithms such as HMAC-SHA256 are permitted via the Option Length field.
The Source Address in the UNA message MUST be the NCoA. The Target Address MUST include the NCoA and the Target link-layer address MUST include the MN's LLA.
When feasible, the MN SHOULD send the Fast Binding Update (FBU) from the PAR's link prior to disconnecting. If not feasible, the MN MUST send the FBU immediately after attaching to the NAR and sending the UNA message.
When the PAR does not have an entry for the new access point, it MUST respond indicating the AP is unknown and the MN MUST stop fast handover protocol operations on the current link. The MN MAY send an FBU from the new link.
When the PAR receives a reverse-tunneled packet, it MUST forward the inner packet to its destination (the MN's correspondent). The reverse tunnel ensures PCoA-sourced packets are not dropped by ingress filtering at the PAR.
Fast Binding Acknowledgment (FBack): a Mobility Header message (type 9) sent by PAR acknowledging the FBU. Status values below 128 indicate acceptance; 128–131 indicate rejection. MUST carry the BADF option and, if Status is 1, an alternate CoA option.
Fast Binding Update (FBU): a Mobility Header message (type 8) sent by the MN to authorize the PAR to bind PCoA to NCoA and begin tunneling. The 'A' flag requests FBack; 'H' flag MUST be set. MUST carry an alternate CoA option (set to NCoA) when sent from PAR's link, plus the BADF option.
Handover Acknowledge (HAck): an ICMPv6 message (Type 154, Subtype 5) sent by NAR to PAR in reply to HI. Status codes 0–4 indicate acceptance variants (NCoA valid, assigned, use PCoA, etc.); codes 128–130 indicate rejection with reason.
Handover Initiate (HI): an ICMPv6 message (Type 154, Subtype 4) sent from PAR to NAR to initiate an MN's handover. The 'S' flag requests assigned address configuration; the 'U' flag requests buffering. Code 0 is used for FBU sent from PAR's link; Code 1 for FBU sent from NAR's link.
Proxy Router Advertisement (PrRtAdv): an ICMPv6 message (Type 154, Subtype 3) sent by the PAR in response to RtSolPr or unsolicited for network-initiated handover. Code values 0–5 indicate whether neighbor AP info, DHCP usage, or lack of fast handover support apply.
Router Solicitation for Proxy Advertisement (RtSolPr): an ICMPv6 message (Type 154, Subtype 2) sent by the MN to the PAR to resolve one or more access point identifiers to [AP-ID, AR-Info] tuples, enabling pre-handover NCoA formulation.
IANA assignments include: ICMPv6 Type 154 (shared with RFC 4068) with new Subtypes 2 (RtSolPr), 3 (PrRtAdv), 4 (HI), 5 (HAck); Mobility Header types 8 (FBU) and 9 (FBack); and Neighbor Discovery option types 17 (IP Address/Prefix), 19 (LLA), 20 (NAACK), and 21 (BADF).
Access routers (PAR and NAR) exchanging HI/HAck messages MUST have a pre-established security association (e.g., via IKEv2). The inter-AR security association allows the NAR to trust the PAR's attestation about the MN, enabling it to create forwarding state on the MN's behalf.
The BADF option protects FBU messages by computing a MAC (HMAC-SHA1 by default) using a shared key between the MN and the PAR. This ensures only the legitimate owner of the PCoA can redirect traffic, preventing hijacking of the forwarding tunnel.
Two handover modes: (1) Predictive — MN receives FBack on the PAR's link before disconnecting, so tunneling is active upon NAR attachment; MN sends UNA immediately on connecting. (2) Reactive — MN did not receive FBack on PAR's link; MN sends UNA then immediately (re)sends FBU to PAR after attaching to NAR.
Upon receiving a UNA, the NAR transitions any proxy or INCOMPLETE neighbor cache entry to STALE state per RFC 4861 and immediately forwards arriving and buffered packets to the MN. If the NAR prefers to assign a different address, it sends a Router Advertisement with the NAACK option.
Binding Authorization Data for FMIPv6 (BADF) option (Type 21): variable-length Mobility Header option containing a 4-byte SPI and a variable-length Authenticator (HMAC-SHA1, first 96 bits). SPI=0 is reserved for SEND-based handover keys.
IP Address/Prefix option (Type 17): 24-byte option used in PrRtAdv, HI, and HAck, carrying a 128-bit IPv6 address and an 8-bit Prefix Length. Option-Code distinguishes Old CoA (1), New CoA (2), NAR IP address (3), and NAR prefix (4).
Link-Layer Address (LLA) option (Type 19): variable-length Neighbor Discovery option carrying a link-layer address of variable size. Option-Code 0 is a wildcard; codes 1–7 specify the role of the LLA (new AP, MN, NAR, source, same-interface AP, no-prefix, no-FMIPv6).
Neighbor Advertisement Acknowledgment (NAACK) option (Type 20): 8-byte Neighbor Discovery option with an 8-bit Status field. Status values 1–4 direct the MN to reconfigure its CoA; Status 128 indicates unrecognized link-layer address. Length is 3 when a new CoA is present.