Mobility Support in IPv6
obsoleted by
- rfc-6275 — Mobility Support in IPv6
Extracted elements (30)
Mobile IPv6 eliminates the need for foreign agents required by Mobile IPv4 by leveraging IPv6 stateless address autoconfiguration. Mobile nodes can acquire care-of addresses and operate on any link without special router support, enabling truly decentralized deployment.
Route optimization sends packets via IPv6 routing headers rather than IP encapsulation (as in Mobile IPv4), reducing per-packet overhead and eliminating the need to manage tunnel soft state. This was feasible because IPv6 integrates routing headers natively and defines a new type 2 variant that avoids generic routing header security vulnerabilities.
The return routability procedure was chosen for correspondent node binding authorization because it requires no pre-arranged security associations or PKI between mobile nodes and correspondent nodes, enabling global-scale deployment. The accepted trade-off is that on-path adversaries are not mitigated, since they can already redirect traffic without Mobile IPv6.
Mobile IPv6 uses IPv6 Neighbor Discovery instead of ARP, decoupling the protocol from any particular link layer and allowing operation across heterogeneous media (Ethernet, wireless LAN, etc.) without link-layer-specific adaptations. IPv6 Neighbor Unreachability Detection also assures symmetric reachability between the mobile node and its default router.
Bindings established with correspondent nodes via return routability MUST NOT exceed MAX_RR_BINDING_LIFETIME seconds. Expired nonce values MUST be discarded; messages referencing stale or unknown nonce indices MUST be rejected.
Correspondent nodes MUST NOT accept nonces beyond MAX_NONCE_LIFETIME seconds after first use. Each nonce SHOULD remain acceptable for at least MAX_TOKEN_LIFETIME seconds after first use, and a new nonce SHOULD be generated every 30 seconds.
Home and care-of addresses MUST be unicast routable addresses (global or site-local scope, not link-local). Site-local addresses SHOULD NOT be used due to ambiguity risks when home and visited networks share the same address space.
Mobile Prefix Solicitations and Advertisements SHOULD be protected by IPsec. Both mobile nodes and home agents MUST support and SHOULD use ESP in transport mode with a non-NULL authentication algorithm for mobile prefix discovery.
The correspondent node's node key (Kcn) MUST be a random number exactly 20 octets in length and MUST NOT be shared with any other entity. It is used to produce keygen tokens for the return routability procedure.
The home agent MUST check that a given home address has been used with the correct IPsec security association, preventing a mobile node from using its SA to send Binding Updates on behalf of another mobile node sharing the same home agent.
The mobile node and home agent MUST use an IPsec security association to protect the integrity and authenticity of Binding Updates and Acknowledgements. Both MUST support and SHOULD use ESP in transport mode with a non-NULL payload authentication algorithm providing data origin authentication and connectionless integrity.
The Mobility Header length MUST be a multiple of 8 octets and MUST be aligned on an 8-octet boundary. Mobility Header messages MUST NOT be sent with a type 2 routing header (except Binding Acknowledgement per Section 9.5.4) and MUST NOT use a Home Address destination option (except Binding Update per Sections 11.7.1 and 11.7.2).
When IKEv1 is used with preshared secret authentication between the mobile node and home agent, aggressive mode MUST be used. The ID_IPV6_ADDR Identity Payload MUST NOT be used in IKEv1 phase 1.
A Binding Acknowledgement is sent in response to a Binding Update when an acknowledgement was requested, the update was sent to a home agent, or an error occurred. It echoes the sequence number and includes a MAC computed over Kbm to authenticate the response.
A Binding Update is sent by a mobile node to notify a correspondent node or home agent of its current care-of address. Home registrations are protected by IPsec; correspondent registrations are authorized by a Binding Authorization Data option keyed with Kbm derived from the return routability procedure.
The Binding Cache is a conceptual data structure maintained by home agents and correspondent nodes storing bindings (home address to care-of address with remaining lifetime). The Binding Update List is maintained by each mobile node to track all bindings it has or is attempting to establish.
The Home Address destination option (a new IPv6 destination option) carries the mobile node's home address in packets sent from the care-of address, making care-of address use transparent to transport and higher layers. Its use is restricted to packets where the correspondent node has an existing Binding Cache entry for the home address.
The Mobility Header is a new IPv6 extension header (Next Header value 135) used by mobile nodes, correspondent nodes, and home agents for all binding management messaging. It carries eight message types: Binding Refresh Request (0), Home Test Init (1), Care-of Test Init (2), Home Test (3), Care-of Test (4), Binding Update (5), Binding Acknowledgement (6), and Binding Error (7).
The Return Routability Procedure uses four messages (HoTI, CoTI, HoT, CoT) to verify that the mobile node is reachable at both its home address and care-of address before authorizing a Binding Update to a correspondent node. It produces binding management key Kbm = SHA1(home keygen token | care-of keygen token), computed using HMAC_SHA1 over the node key and nonces.
The Type 2 Routing Header carries the mobile node's home address in packets routed directly to the care-of address during route optimization. It is a Mobile IPv6-specific routing header type that provides the necessary functionality without the generic routing header vulnerabilities.
RFC 3775 allocates Next Header value 135 for the Mobility Header and creates an IANA registry for Mobility Header (MH) Type values: 0=Binding Refresh Request, 1=Home Test Init, 2=Care-of Test Init, 3=Home Test, 4=Care-of Test, 5=Binding Update, 6=Binding Acknowledgement, 7=Binding Error. Values 8–255 are unassigned.
RFC 3775 creates an IANA registry for Mobility Options used within Mobility Header messages, initially defining: Pad1 (type 0), PadN (type 1), Binding Refresh Advice (type 2), Alternate Care-of Address (type 3), Nonce Indices (type 4), and Binding Authorization Data (type 5).
RFC 3775 registers four new ICMPv6 message types for Mobile IPv6: Home Agent Address Discovery Request, Home Agent Address Discovery Reply (used for dynamic home agent discovery), Mobile Prefix Solicitation, and Mobile Prefix Advertisement (used for home network renumbering and prefix configuration).
Home Test messages (carrying the home keygen token) are tunneled from the home agent to the mobile node; to prevent passive inspection, they SHOULD be encrypted with IPsec ESP in tunnel mode between home agent and mobile node. This limits exposure of the keygen token to active on-path attackers.
The return routability procedure does not protect against attackers on the path between the home network and the correspondent node. However, such on-path attackers can perform the same traffic redirection attacks without Mobile IPv6; the procedure limits the attack surface to a single specific Internet path rather than anywhere on the Internet.
To prevent replay attacks, correspondent nodes MUST retain bindings and associated sequence number information at least as long as the nonces used in their authorization remain valid. Deleting a binding prematurely can allow replay of old Binding Updates.
The Binding Authorization Data mobility option carries a MAC computed as First(96, HMAC_SHA1(Kbm, care-of_address|correspondent|MH_data)). The Nonce Indices option carries home and care-of nonce indices allowing the correspondent node to recompute Kbm without storing per-mobile state.
The Home Test Init message (MH Type 1) contains a 16-bit Reserved field followed by a 64-bit Home Init Cookie (random value). The Care-of Test Init message (MH Type 2) has the same layout with a 64-bit Care-of Init Cookie. Header Len is 1 when no mobility options are present.
The Home Test message (MH Type 3) contains a 16-bit Home Nonce Index, a 64-bit Home Init Cookie (echoed), and a 64-bit Home Keygen Token (= First(64, HMAC_SHA1(Kcn, home_address|nonce|0x00))). The Care-of Test message (MH Type 4) mirrors this with Care-of Nonce Index, Care-of Init Cookie, and Care-of Keygen Token (using 0x01 suffix).
The Mobility Header is identified by Next Header value 135 and contains: 8-bit Payload Proto, 8-bit Header Len (units of 8 octets, excluding first 8 octets), 8-bit MH Type, 8-bit Reserved (must be initialized to zero), 16-bit Checksum (one's complement of pseudo-header plus full header), and variable-length Message Data.