Fast Handovers for Proxy Mobile IPv6
Extracted elements (30)
The default inter-MAG encapsulation is set to match the LMA-MAG tunnel mechanism so that PMAG and NMAG automatically interoperate without special configuration or dynamic negotiation; this avoids the need for an additional tunnel negotiation protocol.
The NMAG SHOULD send a Router Advertisement with HNP(s) immediately upon detecting the mobile node's link attachment, because in reactive handover the MN may arrive before context transfer completes and will otherwise be unable to send uplink packets without first receiving prefix information.
The 'P' flag was introduced specifically to distinguish the proxy-mode HI/HAck messages from their RFC 5568 counterparts. Without this flag, a receiving router could not determine whether it is interacting with a standard FMIPv6 node or a PMIPv6-aware MAG.
The protocol is intentionally transparent to the LMA: no new functional requirements or message changes are imposed on the LMA, allowing fast handover to be deployed incrementally by upgrading only the MAGs.
Both MAGs SHOULD support the encapsulation modes defined for the LMA-MAG tunnel in RFC 5844 (IPv4/IPv6-over-IPv6, IPv4/IPv6-over-IPv4, UDP tunneling) and RFC 5845 (TLV-header UDP and GRE with or without keys), ensuring compatibility with the broader PMIPv6 domain configuration.
The MN-initiated FMIPv6 messages from RFC 5568 — RtSolPr, PrRtAdv, FBU, FBack, and UNA — are not applicable in the PMIPv6 context. A MAG receiving RtSolPr or FBU from a mobile node SHOULD either behave as if FMIPv6 is not implemented or serve that node per RFC 5568.
When GRE tunneling with keys is used, the NMAG selects the GRE key for downlink packets and the PMAG selects the key for uplink packets; these are exchanged via the GRE Key option (RFC 5845) in the HI and HAck messages respectively.
All MAGs MUST have the capability and sufficient resources to buffer packets for the mobile nodes accommodated by them, to alleviate packet loss during handover when the mobile node is detached from both links.
For predictive fast handover to work effectively, the mobile node MUST be capable of reporting lower-layer information to the access network at a short enough interval, and the access network MUST be capable of sending the Handover indication to the PMAG at an appropriate timing.
HI and HAck messages exchanged between the PMAG and NMAG MUST be protected using end-to-end security associations offering integrity and data origin authentication. Both MAGs MUST implement IPsec (RFC 4301) for this purpose.
If the HAck from the PMAG returns a different HNP or the subsequent PMIPv6 binding registration fails, the NMAG MUST withdraw the advertised HNP by sending a Router Advertisement with zero prefix lifetime for that HNP, per Section 6.12 of RFC 5213.
In predictive mode, the HI message sent by the PMAG to the NMAG MUST have the 'P' flag set and MUST include the MN ID, the Home Network Prefix(es), and the LMA address currently serving the mobile node. If a valid MN link-layer identifier exists, it MUST also be included.
In reactive mode, the HI message from the NMAG to the PMAG MUST have the 'P' flag set and include the MN ID. The HAck reply MUST include HNP(s) and/or IPv4-MN-HoA; if requested context is unavailable, Code 131 MUST be returned, and if forwarding is not executable, Code 132 MUST be returned.
In the HI message, the Mobile Node Identifier option MUST be present to uniquely identify the target mobile node, and the context transferred MUST be for one mobile node per message.
The necessary information (HNP(s), IPv4-MN-HoA, and/or GRE key(s)) MUST be transferred in the HI/HAck messages to determine whether a mobile node's packets should be forwarded immediately or at a later time.
The 'P' flag MUST be set in all new HI and HAck message formats defined in this document to distinguish them from the corresponding messages in RFC 5568. The 'S' flag MUST be set to zero in the HI message under this specification.
The PMAG and NMAG MUST use the same tunneling mechanism for data traffic tunneled between them. The encapsulation mode SHOULD be configurable, and the default is to match the encapsulation used on the PMIPv6 LMA-MAG tunnel.
When a MAG receives an HI message with the 'U' (buffer) flag set, it MUST be followed by another HI message with the 'F' (forwarding) flag set at an appropriate time to forward the buffered packets.
Context Request Option (type 40) is sent in the HI message to request specific context information from the PMAG. The default requested context is the Home Network Prefix option; if link-layer addressing is used, the MN Link-layer Identifier option MUST also be requested.
Predictive fast handover mode: the PMAG initiates the HI/HAck exchange and establishes a bidirectional tunnel to the NMAG before the mobile node attaches to the new link, enabling packet forwarding and/or buffering before the mobile node arrives.
Reactive fast handover mode: the NMAG sends the HI message to the PMAG after the mobile node has already attached to the new link, retrieving context (MN ID, HNP(s), LMA address) and optionally establishing the inter-MAG forwarding tunnel.
The 'F' (Forwarding) flag in the HI and HAck messages requests establishment of the inter-MAG tunnel for packet forwarding. HI Code value 2 signals completion of forwarding, allowing both ends to tear down the forwarding tunnel synchronously.
Four new IANA registries are created for HI Flags (S=0x80, U=0x40, P=0x20, F=0x10), HAck Flags (U=0x80, P=0x40, F=0x20), HI Status Codes (0–3 defined, 4–255 unassigned), and HAck Status Codes (0–6 and 128–132 defined). All require Standards Action or IESG approval for new values.
Three new Mobility Option type values are assigned: 40 (Context Request Option), 41 (Local Mobility Anchor Address Option), and 42 (Mobile Node Link-local Address Interface Identifier Option). New values require Standards Action or IESG approval.
IPsec ESP (RFC 4303) in transport mode with mandatory integrity protection SHOULD be used for HI/HAck signaling. Confidentiality SHOULD be added when sensitive mobile node context is transferred. ESP in tunnel mode SHOULD protect forwarded data packets if the inter-MAG link exposes them to additional threats.
The Context Request Option (type 40) encodes an ordered list of (Req-type-n, Req-length-n, Req-option-n) tuples. When Req-length-n is zero, no additional qualifier data follows; otherwise, the qualifier (e.g., Vendor-ID and Sub-Type for vendor-specific options) immediately follows Req-length-n.
The extended HAck message carries a 16-bit Sequence number, three flag bits (U, P, F), an 8-bit Code field, and a variable-length Mobility options block. Code values 5, 6, 131, and 132 are newly defined by this specification.
The extended HI message carries a 16-bit Sequence number, four flag bits (S, U, P, F) in the first nibble, an 8-bit Code field, and a variable-length Mobility options block. The 'P' flag value 0x20 marks this as a proxy-mode message.
The LMAA Option (type 41) has length 18 (IPv6) or 6 (IPv4), an 8-bit Option-Code (1 = IPv6 LMAA, 2 = IPv4-LMAA), an 8-bit Reserved field, and the LMA address. It conveys the address of the LMA currently serving the mobile node from PMAG to NMAG.
The MN LLA-IID Option (type 42) has a fixed length of 10 octets and carries the 64-bit Interface Identifier used for the mobile node's IPv6 link-local address in the previous access network, enabling the NMAG to preserve the same identifier after handover.