Mobile IPv6 Support for Dual Stack Hosts and Routers
updated by
- rfc-8553 — DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names
Extracted elements (30)
Dynamic IPv4 home address allocation is signaled by the mobile node placing 0.0.0.0 in the IPv4 Home Address Option; the home agent allocates an address and returns it in the IPv4 Address Acknowledgement Option. The binding lifetime is bound to the minimum of the IPv6 binding lifetime and the IPv4 address lease time.
The specification uses Mobile IPv6 exclusively for dual-stack mobility rather than running both Mobile IPv4 and Mobile IPv6 simultaneously, because IPv6's large address space enables globally unique care-of addresses (eliminating NAT for IPv6), and route optimization and dynamic home agent discovery are only available in Mobile IPv6.
UDP encapsulation for IPv6 care-of addresses is designated a last-resort mechanism for cases where IP-in-IP tunneling fails due to local firewalling policies. It should not be used in normal IPv6-enabled network operation to avoid unnecessary overhead.
All binding update and binding acknowledgement extensions defined in this specification also apply when the mobile node communicates with a Mobility Anchor Point (MAP) as defined in RFC 5380; however, NAT traversal is unlikely to be needed with a MAP since it is expected to be in the same address domain.
Route optimization as specified in RFC 3775 is not possible for IPv4 traffic (traffic addressed to the mobile node's IPv4 home address) or when the mobile node is in an IPv4-only network, because the return-routability test cannot be performed; all such traffic must flow through the home agent.
This specification does not support mobile nodes returning home while using IPv4; IPv4 support is defined only for mobile nodes located in a visited network. Movement detection in IPv4-only networks SHOULD use RFC 4436 (DNAv4) since IPv6-specific Neighbor Discovery triggers are unavailable.
A mobile node MUST always tunnel binding updates in UDP when located in an IPv4-only network; this perpetual UDP encapsulation enables ongoing NAT detection on every binding update exchange.
After accepting a binding update that includes an IPv4 home address option, the home agent MUST include the IPv4 address acknowledgement option in the binding acknowledgement; if absent, the mobile node MUST assume the home agent does not support the IPv4 home address option and SHOULD NOT include it in future binding updates to that home agent.
If the NAT detection option is present in the binding acknowledgement, the mobile node MUST tunnel all future packets to the home agent in UDP and IPv4, and this MUST be reflected in the binding update list.
The binding update message MUST be protected using ESP transport mode. When the mobile node and home agent both support port 4500, the mobile node MUST establish the IPsec security association over port 4500 regardless of NAT presence, to avoid disruptive port switching between 500 and 4500.
The home agent MUST be able to find the IPv4 home address of a mobile node when given the IPv6 home address; if a dynamic IPv4 address was requested, the home agent MUST store the allocated address associated with the IPv6 home address.
The home agent MUST create separate binding cache entries for each of the mobile node's home addresses (IPv4 and IPv6), and all entries MUST point to the mobile node's care-of address included in the binding update.
To accommodate ECN, it is RECOMMENDED that ECN and DSCP information be copied between the inner and outer headers as defined in RFC 3168 and RFC 2983, using the full-functionality option for ECN.
When a binding update is encapsulated in UDP due to NAT traversal, the home agent MUST store the source UDP port numbers from the packet carrying the binding update and MUST encapsulate binding acknowledgements in UDP back to that source address and port.
When a mobile node located in an IPv4-only network sends a Mobile Prefix Solicitation, it MUST use its IPv6 home address in the source address field of the IPv6 packet (in addition to the home address option), because it has no IPv6 address assigned by the local network.
When the mobile node is in a dual-stack visited network and acquires both IPv4 and IPv6 care-of addresses, it SHOULD prioritize the IPv6 care-of address for its MIPv6 binding; after three failed IPv6 binding update attempts, it SHOULD fall back to the IPv4 care-of address.
The F flag in the Binding Update message, when set, requests forced UDP encapsulation regardless of NAT presence on the path between the mobile node and the home agent. It SHOULD NOT be set when the mobile node has an IPv6 care-of address except in specific fallback scenarios.
The IPv4 Address Acknowledgement Option (Type 30) is carried in the binding acknowledgement mobility header. It contains a Status field (0–127 success, 128+ failure), a Pref-len field for the allocated prefix length, and the IPv4 home address. Defined status codes include 128 (unspecified failure), 130 (incorrect address), 131 (invalid address), 132 (dynamic allocation unavailable), and 133 (prefix allocation unauthorized).
The IPv4 Care-of Address Option (Type 32) is carried in the binding update mobility header when the mobile node is located in an IPv4-only network. It contains a Reserved field and a 32-bit IPv4 care-of address representing the mobile node's current IPv4 address in the visited network.
The IPv4 Home Address Option (Type 29) is carried in the mobility header of the binding update. It contains a 6-bit Prefix-len field, a P flag (mobile network prefix request), a Reserved field, and a 32-bit IPv4 home address. The value 0.0.0.0 requests dynamic address allocation from the home agent.
The NAT Detection Option (Type 31) is sent by the home agent in the binding acknowledgement to indicate whether a NAT was detected. It includes an F flag (forces UDP encapsulation even without NAT) and a Refresh Time field (in seconds) suggesting how often the mobile node should send keepalives; all-1s means no keepalives needed.
A new IANA registry 'DSMIPv6 IPv4 Home Address Option Status Codes' was created for the Status field in the IPv4 Address Acknowledgement Option. New values require IETF review; assignments from outside IETF require publication of an IETF document.
IANA allocated UDP port 4191 (named 'dsmipv6') for the DSMIPv6 NAT traversal mechanism. IANA also assigned mobility header option type values: 29 (IPv4 Home Address Option), 30 (IPv4 Address Acknowledgement Option), 31 (NAT Detection Option), and 32 (IPv4 Care-of Address Option).
DSMIPv6 keepalives (binding updates to refresh NAT bindings) do not replace IKEv2 keepalives over UDP port 4500 needed for IKE dead-peer detection; both mechanisms must be maintained independently when the mobile node is behind a NAT.
NAT traversal in DSMIPv6 shares the vulnerability of RFC 3519: the outer IPv4 header is unauthenticated, enabling a man-in-the-middle attack where an attacker who can modify the outer IPv4 header can divert a legitimate mobile node's traffic to an illegitimate receiver independently of the binding update's authenticity.
The security of an IPv4 home address binding relies entirely on the IPsec SA established for the IPv6 home address. The home agent authorizes the IPv4 binding by verifying that the IPv6 binding update is authentic and that the IPv4 address is pre-associated with that IPv6 home address, rather than establishing a separate SA for IPv4.
The complete binding update packet format when encapsulated through NAT is: IPv4 header (src=V4ADDR, dst=HA_V4ADDR), UDP header, IPv6 header (src=V6HOA, dst=HAADDR), ESP header in transport mode, Mobility header, BU with IPv4 HAO and IPv4 CoA option. The binding acknowledgement reverses source and destination accordingly.
The IPv4 Home Address Option is 8 bytes total: 1-byte Type (29), 1-byte Length (6), a 6-bit Prefix-len, a 1-bit P flag, 9 reserved bits, followed by a 32-bit IPv4 home address. Alignment requirement is 4n.
The UDP tunneling format used for NAT traversal orders headers as: outer IPv4/v6, UDP, inner IP (v4 or v6), then upper-layer headers. An ESP-secured variant inserts an ESP header between UDP and the inner IP header. The receiver inspects the IP version field following the UDP header to determine the inner protocol.
When sending IPv4 data packets from an IPv4-only visited network, the format is: outer IPv4 header (src=V4CoA, dst=HA_V4ADDR), optional UDP header (if NAT detected or forced), inner IPv4 header (src=V4HoA, dst=V4CN), upper-layer protocols. The UDP header is omitted when IP-in-IP is sufficient.