IPv4 Support for Proxy Mobile IPv6
Extracted elements (27)
IPv4 home address mobility support is defined to be independent of IPv6 home address mobility support: a mobile node can obtain IPv4-only service without any IPv6 address assignment, enabling the same PMIPv6 infrastructure to serve IPv4-only, IPv6-only, or dual-stack nodes.
Native IPv4 transport support is defined to avoid the 40-octet per-packet overhead that would result from wrapping PMIPv6 signaling and tunneled data inside an IPv6-over-IPv4 transition tunnel. By sending the Mobility Header directly in IPv4-UDP, no extra encapsulation layer is needed for data traffic.
In Proxy Mobile IPv6, IPsec SAs are specific to the MAG (not the mobile node), use Proxy-CoA/IPv4-Proxy-CoA as traffic selectors, and are not updated when the mobile node moves. This differs fundamentally from Mobile IPv6 and Dual-Stack Mobile IPv6 where SAs are per-mobile-node and use HoA/IPv4-HoA as selectors.
The Binding Update 'F' flag and the NAT Detection Option defined in RFC 5555 (DS-MIPv6) are reused in Proxy Binding Update and Proxy Binding Acknowledgement messages solely to force UDP encapsulation between MAG and LMA when middleboxes are present.
For selective de-registration of only the IPv4 home address, the Proxy Binding Update with lifetime=0 MUST include exactly one IPv4 Home Address Request option for the address being de-registered and MUST NOT include any Home Network Prefix options; the Binding Cache entry MUST NOT be deleted, only the IPv4 state removed.
If a Proxy Binding Update contains an IPv4 Home Address Request option but no Home Network Prefix option, the LMA MUST NOT reject the request solely for missing the Home Network Prefix option; at least one of these two options MUST be present.
If the IPv4 DHCP Support Mode option in the received PBA has the S flag set to 1, the MAG MUST function as a DHCP server for the mobile node. If S=0 or the option is absent, the MAG MUST function as a DHCP relay.
If the mobile node is not authorized for IPv4 service or IPv4 routing is not enabled in the home network, the LMA MUST reject the Proxy Binding Update and send a PBA with Status set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (170).
Mobility agents at tunnel entry and exit points MUST handle ECN as specified in RFC 5213 Section 5.6.3, and MUST apply IP fragmentation and tunnel error processing per Sections 7 and 8 of RFC 2473, for IPv4 payload packets.
The DHCPOFFER message sent to the mobile node MUST include the Subnet Mask option and Router option set to the mobile node's IPv4 home subnet mask and default router address, and MUST include the Interface MTU option reflecting the tunnel MTU between MAG and LMA.
The MAG MUST include exactly one IPv4 Home Address Request option in the initial Proxy Binding Update when IPv4 home address mobility support is needed. The option MAY request a specific address or MAY set the address field to ALL_ZERO for dynamic allocation.
Upon initial registration with an IPv4 Home Address Request option set to ALL_ZERO, the LMA MUST allocate an IPv4 home address, create a single Binding Cache entry managing both IPv4 and IPv6 bindings, establish a bidirectional tunnel, create an IPv4 host route, and reply with a PBA containing the IPv4 Home Address Reply option.
When a mobile node is capable of performing a handoff between interfaces, a DHCP Client-identifier value MUST be used that is not tied to any physical interface and MUST be generated per RFC 4361 to ensure it is stable and unique across the PMIPv6 domain.
When serving a mobile node, the LMA MUST advertise a connected route into the routing infrastructure for the mobile node's IPv4 home address or home subnet so that IPv4 routers treat the LMA as the last-hop router for that subnet.
When the Binding Cache entry lookup uses an IPv4 home address as the search key (when no non-zero Home Network Prefix option is present), the LMA MUST apply the same lookup rules from RFC 5213 Section 5.4.1.1, substituting the IPv4 home address for the IPv6 prefix set and assuming exactly one IPv4 address rather than a set of prefixes.
Five encapsulation modes are defined for tunneling: IPv4-or-IPv6-over-IPv6, IPv4-or-IPv6-over-IPv4, IPv4-or-IPv6-over-IPv4-UDP, IPv4-or-IPv6-over-IPv4-UDP-TLV, and IPv4-or-IPv6-over-IPv4-GRE. The mode used for IPv4 transport depends on whether NAT-like middleboxes are present.
For IPv4 transport, the Mobility Header is carried inside an IPv4 packet with a UDP header (IPv4-UDP-MH), using a dedicated UDP port number for PMIPv6 signaling over IPv4. This allows MAG and LMA to exchange PMIPv6 messages without IPv6 connectivity.
Two DHCP deployment configurations are supported for IPv4 address delivery: DHCP server co-located with the MAG and DHCP relay agent co-located with the MAG. The LMA signals which mode to use via the IPv4 DHCP Support Mode option in the PBA.
Two independent features are defined: (1) IPv4 home address mobility support enabling dual-stack or IPv4-only mobile nodes to obtain and retain an IPv4 home address across handoffs, and (2) IPv4 transport support allowing PMIPv6 signaling to be exchanged over an IPv4 network between LMA and MAG.
Four new mobility options are defined and allocated from the existing Mobility Options registry: IPv4 Home Address Request option (36), IPv4 Home Address Reply option (37), IPv4 Default-Router Address option (38), and IPv4 DHCP Support Mode option (39).
Four new Proxy Binding Acknowledgement status codes are defined, allocated from the Mobile IPv6 binding acknowledgement status space: NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (170), NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (171), NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (172), MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (173).
A deployment where the MAG uses an IPv4 private address with NAT translation devices in the path to the LMA is explicitly not supported. Private IPv4 addresses are permitted only if there is no NAT between LMA and MAG; UDP encapsulation MAY be used if other types of middleboxes are present.
When DHCP messages are relayed across administrative boundaries, operators MUST ensure those messages are secured. DHCP messages may be tunneled to the LMA if needed, or the MAG can relay directly if the PMIPv6 domain network is considered secure.
IPv4 Default-Router Address option (Type=38, Length=6): carries a 16-bit Reserved field and a 4-byte IPv4 default router address for the mobile node, sent by the LMA in the Proxy Binding Acknowledgement.
IPv4 DHCP Support Mode option (Type=39, Length=2): carries a 15-bit Reserved field and a 1-bit DHCP Support Mode flag (S). S=0 indicates the MAG should act as a DHCP relay; S=1 indicates it should act as a DHCP server.
IPv4 Home Address Reply option (Type=37, Length=6): carries an 8-bit Status field (0–127 success, 128–255 failure), a 6-bit Pref-len, 2-bit Reserved, and a 4-byte IPv4 home address. Defined status codes include 0 (Success), 128 (Failure unspecified), 129 (Administratively prohibited), 130 (Incorrect address), 131 (Invalid address), 132 (Dynamic assignment not available).
IPv4 Home Address Request option (Type=36, Length=6): carries a 6-bit Prefix-len, 10-bit Reserved, and a 4-byte IPv4 home address field. A value of 0.0.0.0 requests dynamic address allocation by the LMA.