IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6
Extracted elements (23)
IPsec-encrypted traffic cannot be selected for offload because there is no visibility into the application payload. This is an acknowledged limitation of the flow selector approach.
IPv6 traffic offload is intentionally out of scope to avoid creating a NAT66 requirement. There are better ways to address IPv6 offload, so this specification only handles IPv4 flows.
The LMA can accept or override a MAG-proposed offload policy, allowing a two-way negotiation: the MAG may propose specific selectors or request the LMA's policy, and the LMA has final authority based on its own policy configuration (e.g., from AAA or PCRF).
When the mobile node performs an inter-MAG handover, the new MAG may not support IPv4 traffic offload, so the offload policy may change at handover boundaries even though the LMA cannot change policy mid-session for the same MAG.
If the LMA is configured to support IPv4 traffic offload and the PBU includes the IPv4 Traffic Offload Selector option, the LMA MUST enable offload support for that session and the PBA MUST include the IPv4 Traffic Offload Selector option.
If the MAG is not configured for IPv4 traffic offload support but receives a PBA with the IPv4 Traffic Offload Selector option, the MAG MUST ignore the option and process the rest of the message per RFC 5213.
If the received PBU does not include the IPv4 Traffic Offload Selector option, the LMA MUST NOT enable IPv4 traffic offload support for that session, and the PBA MUST NOT contain the option.
If there is no IPv4 Traffic Offload Selector option in the PBA from the LMA, the MAG SHOULD NOT enable IPv4 traffic offload support for that mobility session.
The LMA MUST NOT make changes to the mobile node's offload policy during the middle of a mobility session as long as the MN remains attached to the same MAG. The Traffic Selector option delivered during initial signaling MUST be the same as the one delivered for lifetime extension from the same MAG.
The offload policy MUST be specific to a mobile node's application traffic and MUST NOT match any other mobile node's IP traffic. Control-plane traffic (DHCP, Neighbor Discovery, etc.) MUST NOT be subject to offload.
The Reserved field in the IPv4 Traffic Offload Selector option MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
When the MAG includes the IPv4 Traffic Offload Selector option in a PBU without the Traffic Selector sub-option (requesting LMA policy), the M flag MUST be set to 0.
When the MAG sends a PBU for Binding Lifetime Extension or De-Registration, it SHOULD copy the IPv4 Traffic Offload Selector option from the initial PBU, and considerations from RFC 5213 Sections 6.9.1.3 and 6.9.1.4 MUST be applied.
The EnableIPv4TrafficOffloadSupport configuration variable (default 0/disabled) controls whether IPv4 traffic offload is enabled on the MAG or LMA. When set to 1 on the MAG, it requests offload policy from the LMA for all mobility sessions; configured values must survive server reboots.
The IPv4 Traffic Offload Selector option (type 53) is a new PMIPv6 mobility option carried in Proxy Binding Update and Proxy Binding Acknowledgement messages. It contains an Offload Mode (M) flag and an optional Traffic Selector sub-option, with 4n alignment requirement.
The Offload Mode (M) flag in the IPv4 Traffic Offload Selector option controls offload direction: M=0 means flows matching the traffic selectors are offloaded (all others tunneled to LMA); M=1 means flows matching the selectors are tunneled to LMA (all others offloaded).
The Traffic Selector sub-option is optional when the IPv4 Traffic Offload Selector option is carried in a Proxy Binding Update, but is mandatory when carried in a Proxy Binding Acknowledgement. Its format is defined in RFC 6089 Section 4.2.1.4.
The Traffic Selector sub-option uses a TS Format field to identify the flow specification format. TS Format value 1 (IPv4 binary traffic selector per RFC 6088 Section 3.1) is mandatory for this specification; TS Format value 2 (IPv6 binary traffic selector) is not used.
IANA assigned mobility option type 53 for the IPv4 Traffic Offload Selector option, allocated from the same numbering space as other mobility options per RFC 6275.
The IPv4 Traffic Offload Selector option inherits security guidelines from RFC 5213 (Proxy Mobile IPv6) and does not require additional security considerations. Carrying offload selectors does not introduce new security vulnerabilities.
When IPv4 traffic offload is enabled, offloaded flows typically get NAT translated, introducing NAT-related vulnerabilities documented in RFC 2663. Additionally, offloaded traffic bypasses home network firewall protections, exposing the mobile node to access network security risks.
When IPv4 traffic offload is enabled, some flows go through the home network and others through the access network, introducing complexity for traffic diagnostics and monitoring. Diagnostic tools must be aware of the offload policy.
The IPv4 Traffic Offload Selector option has a Type field (8-bit, value 53), a Length field (8-bit, octets excluding type and length), a 1-bit Offload Mode (M) flag, a 31-bit Reserved field (must be zero), and a variable-length Traffic Selector sub-option.