Prefix Delegation Support for Proxy Mobile IPv6
Extracted elements (26)
The delegation of IPv4 subnets to mobile routers is explicitly out of scope. Although the DMNP option supports IPv4 signaling between MAG and LMA (via the V flag), the mechanism for actually delegating IPv4 subnets to the MR is not addressed by this specification.
The deployment model with the delegating router co-located with the MAG is described as the simplest option because it keeps a single protocol interface between the MAG and LMA and avoids requiring DHCPv6 relay forwarding through the PMIPv6 tunnel.
The LMA tracks a single mobile router session and associates DMNPs with that session rather than tracking individual IP nodes (LFNs) in the mobile network. This keeps the PMIPv6 control plane scalable, as the LMA only needs per-MR state regardless of the number of attached LFNs.
If a mobile router performs a handoff to a new MAG that does not support prefix delegation as specified in this document, forwarding of the previously delegated mobile network prefixes is no longer performed and the LFNs will lose connectivity.
When the delegating router is co-located with the LMA, the MAG's DHCPv6 relay agent function MUST queue the DHCPv6 Reply message during the PMIPv6 PBU/PBA signaling exchange before forwarding it to the requesting router. Implementations must account for interactions between PMIPv6 timing and DHCPv6 timeout/retry logic.
If any requested prefix is assigned to another mobility node or is not from an authorized pool, the LMA MUST reject the PBU by sending a PBA with status REQUESTED_DMNP_IN_USE.
If the PBA status is NOT_AUTHORIZED_FOR_DELEGATED_MNP, the MAG MUST NOT enable mobility support for any prefixes in the mobile network and prefix delegation support must be disabled.
If the PBA status is REQUESTED_DMNP_IN_USE, the MAG MUST NOT enable mobility support for the requested prefixes, but MAY send a new PBU requesting the LMA to perform the prefix assignment.
If the PBU does not include any DMNP option(s), the LMA MUST NOT enable Delegated Prefix support for the mobility session, and the PBA MUST NOT contain any DMNP option(s).
If the PBU includes DMNP option(s) and the LMA is configured for Delegated Prefix support, the LMA MUST enable the DMNP option for that session and the PBA MUST include the allocated DMNP option(s).
On receiving a packet from the bidirectional tunnel with the LMA, the MAG MUST decapsulate the packet (remove the outer header) and then use the destination address of the inner packet to forward it to the interface through which the mobile router is reachable.
On receiving a packet whose destination matches a mobile router's DMNP, the LMA MUST forward it through the bidirectional tunnel to the MAG where the mobile router is attached.
On receiving an IP packet from a mobile router, the MAG MUST ensure an established binding exists and that the source IP address is a DMNP delegated to that mobile router before tunneling; packets whose source address is not part of the DMNP MUST NOT be tunneled to the LMA.
On receiving an IP packet from the tunnel with the MAG, the LMA MUST decapsulate the packet and MUST ensure there is an established binding for the mobile router and that the source IP address is a DMNP delegated to a mobile router reachable over that tunnel.
The DHCPv6 relay agent on the MAG SHOULD include the relay agent remote-id option (RFC 4649) in Relay-forward messages with appropriate identity information, to enable correlation of mobile router identities used over DHCPv6 and PMIPv6.
The LMA MUST advertise a connected route into the routing infrastructure for all IP prefixes delegated to mobile routers it serves, so that the LMA serves as the routing anchor for those prefixes.
The MAG MUST include one or more DMNP options in the Proxy Binding Update message in order to request the LMA to allocate DMNP(s) for the mobile router, provided the mobile router's policy profile indicates Delegated Prefix support.
When the MAG requests the LMA to perform prefix assignment, it MUST include exactly one DMNP option with an ALL_ZERO value and V=0 to request IPv6 DMNP allocation, and exactly one DMNP option with ALL_ZERO and V=1 to request IPv4 DMNP allocation.
The DMNP option is used in Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between the MAG and LMA to convey the mobile router's IPv4 or IPv6 delegated mobile network prefixes. Multiple instances may appear in a single message.
The LMA's conceptual Binding Cache Entry (BCE) data structure is extended to include a DMNP list, where each entry represents a delegated mobile network prefix associated with the mobile router's session.
The MAG's conceptual Binding Update List Entry (BULE) data structure is extended to include a DMNP list, where each entry stores an IPv4/IPv6 mobile network prefix delegated to the mobile router.
A new Mobility Header option type value 55 for the Delegated Mobile Network Prefix option has been allocated from the IANA 'Mobility Options' registry.
Two new Proxy Binding Acknowledgement status codes are defined: NOT_AUTHORIZED_FOR_DELEGATED_MNP (177) meaning the MR is not authorized for DMNP, and REQUESTED_DMNP_IN_USE (178) meaning the requested DMNP is already allocated. Both are allocated from the same number space as RFC 6275.
DHCPv6 signaling between the MAG and LMA requires message integrity protection and source authentication. The IPsec security association protecting PMIPv6 signaling MUST also be used to protect DHCPv6 signaling between MAG and LMA, using ESP in transport mode as illustrated by the SPD/SAD example entries.
The DMNP option is carried as a standard mobility header option and inherits all security guidelines from PMIPv6 (RFC 5213), including the IPsec-based protection of Proxy Binding Update and Proxy Binding Acknowledgement messages. No additional security mechanisms are required for the option itself.
The Delegated Mobile Network Prefix (DMNP) option carries a mobile router's IPv4 (4-byte) or IPv6 (16-byte) prefix in a Mobility Header option with type 55. Fields are: Type (8-bit), Length (8-bit), V-flag (1-bit indicating IPv4 prefix), Reserved (7-bit, MUST be 0), Prefix Length (8-bit), and Prefix value. Alignment requirement is 8n+2.