Dual-Stack Mobile IPv4
Extracted elements (25)
DSMIPv4 keeps Mobile IPv4 as an IPv4-only signaling protocol while enabling it to set up IPv6 tunnels over IPv4. This design allows dual-stack nodes to use a single mobility protocol for both address families and serves as a controlled IPv6-over-IPv4 transition mechanism without requiring all network nodes to support IPv6.
IPv6 care-of address registration is explicitly a non-goal. The specification only supports IPv4 CoA registration (inherited from MIPv4) and IPv6 home prefix registration, not IPv6-addressed care-of addresses.
Route optimization in the style of Mobile IPv6 (RFC 3775) is explicitly out of scope because DSMIPv4 relies on Mobile IPv4 signaling, which does not provide route optimization capability.
A registration reply lacking an IPv6 prefix reply extension, in response to a request that included at least one IPv6 prefix request extension, is a backward-compatibility signal indicating the home agent does not support DSMIPv4 extensions (it silently skipped the skippable extensions).
Minimal Encapsulation (RFC 2004) CANNOT be used to carry IPv6 traffic over the Mobile IPv4 tunnel because RFC 2004 does not support an IPv6 inner header. Only IPinIP (RFC 4213) and GRE (RFC 2784) are compatible.
A home agent MUST NOT include more than one IPv6 prefix reply extension for the same prefix in a registration reply.
A mobile node MUST NOT include an IPv6 tunneling mode extension if it uses the foreign agent care-of address mode; doing so may cause the HA to tunnel IPv6 packets to the FA, which will likely drop them for lack of appropriate state.
A mobile node that receives a registration reply without any IPv6 prefix reply extensions (in response to a request containing IPv6 prefix request extensions) MUST assume the home agent does not support these extensions and SHOULD continue operating per MIPv4 (RFC 3344).
All MLD and MLDv2 messages between the mobile node and home agent MUST be tunneled over an IPv4 tunnel between the mobile node's IPv4 home address and the home agent's IPv4 address, bypassing the foreign agent.
For each registered IPv6 prefix, the home agent MUST advertise its reachability as defined in NEMO (RFC 3963) Section 6.3.
Implementations MUST support the Static Tunnel MTU approach as defined in RFC 4213 Section 3.2. The Dynamic Tunnel MTU method is OPTIONAL.
IPv6-over-IPv4 tunnel endpoints MUST configure link-local IPv6 addresses per RFC 4213 Section 3.7, adhere to its neighbor discovery requirements (Section 3.8), and comply with its hop limit requirements (Section 3.3).
IPv6 prefix and tunneling mode extensions MUST be placed after the registration request header and before the mobile-home authentication extension, so they are included in the computation of any authentication extension.
The home agent MUST check that inner IPv6 packets received over the tunnel have a source address falling under the registered IPv6 prefix(es) for that mobile node. Packets with unregistered outer or inner source addresses SHOULD be dropped.
The home agent MUST check that registered IPv6 prefixes are not overlapping, ensuring all addresses under each prefix belong to a single mobile node at any time. These prefixes MUST NOT appear as on-link to any other node via Router Advertisements.
When IPv6 tunneling mode extension is absent, all IPv6 packets destined to registered prefixes MUST be tunneled by the home agent to the mobile node's registered IPv4 home address, requiring double encapsulation to keep IPv6 routing transparent to foreign agents.
When NAT traversal (RFC 3519) is used with a private CoA, the next header field of the Mobile Tunnel Data message MUST be set to the IPv6 value, and the encapsulation field of the UDP Tunnel Request Extension MUST be set to zero.
DSMIPv4 defines two modes of operation: implicit mode (no IPv6 prefix request extensions; HA determines prefixes out-of-band) and explicit mode (IPv6 bindings signaled explicitly via extensions). The specification primarily defines the explicit mode.
A new registry 'IPv6 Prefix Reply Extension Codes' was created: values 0 and 1 are accept codes (tunnel to HoA and CoA respectively), values 2-7 are reserved accept codes, values 8-9 are defined reject codes, and values 10-255 are reserved reject codes. Future allocations require Expert Review.
IANA registered extension type number 152 for DSMIPv4 Extensions in the Mobile IPv4 skippable extension space (128-255). A new subtype registry 'DSMIPv4 Extension subtypes' was created with values 1 (IPv6 Prefix Request), 2 (IPv6 Prefix Reply), 3 (IPv6 Tunneling Mode); remaining subtypes require Expert Review.
Home agents MUST perform reverse-tunnel checks for IPv6 packets analogous to RFC 3024 for IPv4: the outer source address must be a registered care-of address, and the inner header source address must be a registered IPv4 HoA or IPv6 prefix. Packets failing either check SHOULD be silently discarded and logged.
Security devices must account for IPv6 packets encapsulated over IPv4 either directly to the mobile node's CoA or via double encapsulation (first to IPv4 HoA, then to CoA). Interactions with IPsec are covered in RFC 5265 and RFC 5266.
IPv6 Prefix Reply Extension (Type 152, Subtype 2, Length 20): 1-byte Type, 1-byte Length, 1-byte Subtype, 1-byte Code, 1-byte Prefix Length, 1-byte Reserved, 16-byte Mobile IPv6 Network Prefix. Code 0 = tunneled to HoA, Code 1 = tunneled to CoA, Code 8 = rejected unspecified, Code 9 = rejected administratively prohibited.
IPv6 Prefix Request Extension (Type 152, Subtype 1, Length 18): 1-byte Type, 1-byte Length, 1-byte Subtype, 1-byte Prefix Length, 16-byte Mobile IPv6 Network Prefix. Insignificant low-order bits beyond Prefix Length MUST be zero.
IPv6 Tunneling Mode Extension (Type 152, Subtype 3, Length 2): 1-byte Type, 1-byte Length, 1-byte Subtype, 1-byte Reserved. Inclusion in a registration request signals that IPv6 traffic may be tunneled to the mobile node's CoA.