Separation of Control and User Plane for Proxy Mobile IPv6
Extracted elements (22)
Existing PMIPv6 specifications (RFC 6275, RFC 6463) allowed the MAG to separate control and user plane via the Alternate Care-of Address option, but provided no corresponding mechanism for the LMA to advertise a different address for its user plane. This document fills that gap by defining a new mobility option for the LMA.
Separation is motivated by deployment scenarios such as WLAN networks where the MAG control-plane resides on the Access Controller (WLC) while the user-plane resides on individual Access Points, and by the need to scale or geo-distribute LMA control and user planes independently.
The protocol interface between a physically separated LMA control-plane node and LMA user-plane node is intentionally left out of scope. Possible options include OpenFlow, ForCES, routing infrastructure, or vendor-specific approaches; no specific interface is mandated.
The LMA User-Plane Address mobility option is carried in PBU and PBA messages like any other mobility header option per RFC 5213 and inherits that specification's security guidelines. Encapsulation mode selection for the user-plane tunnel must follow considerations in RFC 5213 and RFC 5844.
The Domain-wide-LMA-UPA-Support configuration variable MUST survive server reboots and service restarts, and MUST be the same for every LMA and MAG in the PMIPv6 network domain.
The Reserved field in the LMA User-Plane Address mobility option MUST be set to zero by the sender and MUST be ignored by the receiver.
When Domain-wide-LMA-UPA-Support is one on the LMA, the LMA SHOULD include the option in the PBA even if the MAG did not include it in the PBU.
When Domain-wide-LMA-UPA-Support is zero on the LMA, the LMA MUST NOT include the LMA User-Plane Address option in a PBA unless the MAG first indicated support by including it in the PBU.
When the LMA control-plane and user-plane functions are on separate IP nodes, the user-plane anchor requirements from RFC 5213 Section 5.6.2 and RFC 5844 Section 3.1.3 MUST be met by the node hosting the LMA user-plane function; that node must be a topological anchor point for the mobile node's IP address/prefixes.
When the LMA includes the option in a PBA, the address field MUST be set to the LMA's actual IPv4 or IPv6 address carrying user-plane traffic.
When the MAG includes the option in a PBU using IPv4 transport, the address field MUST be either zero-length or a 4-octet ALL_ZERO value; for IPv6 transport it MUST be either zero-length or a 16-octet ALL_ZERO value.
The Binding Update List entry conceptual data structure maintained by both LMA and MAG is extended with two new fields: the IP address of the LMA carrying user-plane traffic and the IP address of the LMA handling control-plane traffic.
The Domain-wide-LMA-UPA-Support configuration variable indicates whether all mobility entities in the PMIPv6 domain support the LMA User-Plane Address option. Its default value is zero on both LMA and MAG, and it MUST survive server reboots and service restarts and MUST be consistent across all LMA and MAG entities in the domain.
The LMA User-Plane Address (LMA-UPA) is a new per-session IP address on the LMA used exclusively for sending and receiving user-plane traffic from the MAG, distinct from the LMA Control-Plane Address (LMA-CPA) used for PMIPv6 signaling.
The MAG User-Plane Address (MAG-UPA) is the IP address on the MAG used for user-plane traffic; it is also referred to as the Alternate Care-of Address.
The option may appear zero, one, or two times in a PBU or PBA message. When two instances are present, one must carry an IPv4 transport address and the other an IPv6 transport address.
IANA allocated Type value 59 for the LMA User-Plane Address mobility option in the 'Mobility Options' registry at iana.org/assignments/mobility-parameters.
If LMA user-plane and control-plane functions are hosted on separate entities, any control messages between them that contain the LMA User-Plane Address mobility option MUST be protected using end-to-end security associations offering integrity and data origin authentication.
IPsec is mandatory-to-implement for nodes hosting the user-plane functions of the MAG and LMA, but its use for protecting user-plane traffic is optional, consistent with the base PMIPv6 specification.
PMIPv6 signaling messages between MAG and LMA MUST be protected using end-to-end security associations offering integrity and data origin authentication, and IPsec is a mandatory-to-implement mechanism for nodes hosting the control-plane functions, even when CP and UP are on separate nodes.
The LMA-UPA address provided in the mobility option MUST be a valid address under the administrative control associated with the LMA functional block, preventing redirection attacks.
The LMA User-Plane Address mobility option (Type=59) carries an 8-bit Type, 8-bit Length, 16-bit Reserved field (must be zero), and a variable-length LMA User-Plane Address field holding either a 32-bit IPv4 address or a 128-bit IPv6 address. Alignment requirement is 8n+2.