Gateway-Initiated Dual-Stack Lite Deployment
Extracted elements (24)
GI-DS-Lite initiates the softwire at the access gateway rather than at the access device, extending existing access tunnels. This requires no changes to either the access device or the access architecture and omits additional tunneling overhead in the access network.
GI-DS-Lite supports M:N relationships between access gateways and AFTRs rather than requiring a 1:1 pairing. AFTRs can be dedicated to specific device groups, gateway groups, or geographic regions, and may optionally be co-located with an access gateway.
The CID mechanism allows multiple access devices behind the access gateway to share the same private RFC 1918 IPv4 address, because the CID uniquely identifies each flow's originating access device at the AFTR independently of the inner IP address.
The IPv6 Flow Label (20 bits) is offered as a CID alternative for IPv4-in-IPv6 deployments but is shorter than the recommended 32-bit CID. Implementers must ensure sufficient randomization to avoid interference with other Flow Label uses such as ECMP, and must account for scaling limits in large deployments.
GI-DS-Lite is applicable across multiple tunnel-based access architectures: the access gateway function is implemented by the Mobile IPv6 HA, PMIPv6 LMA, 3GPP PDN-GW or GGSN, WiMAX ASN-GW or home agent, PPP BRAS/BNG, or per-subscriber VLAN BNG, depending on deployment.
On receiving any packet from the softwire, the access gateway SHOULD obtain the CID from the packet and use it for making the forwarding decision toward the correct access device.
Softwire peers SHOULD use the correct path MTU value for the tunnel path between the access gateway and AFTR. This value MAY be statically configured at softwire creation time or dynamically discovered using standard path MTU discovery techniques.
The access gateway, on receiving any IPv4 packet from an access device, SHOULD look up the CID for that access device and embed it in the softwire encapsulation (e.g., in the GRE Key field) when tunneling toward the AFTR.
The NAT binding entry at the AFTR reflecting an active flow between an access device and an Internet node SHOULD be extended to include the CID and the SWID (e.g., when GRE encapsulation with GRE Key is used).
When creating an IPv4-to-IPv4 NAT binding for a packet received over the softwire, the AFTR SHOULD associate the CID with that NAT binding and SHOULD use the combination of CID and SWID as the unique identifier in the binding entry.
When encapsulating an IPv4 packet, the access gateway and AFTR SHOULD derive the DSCP (or MPLS Traffic-Class Field) of the softwire encapsulation from the inner packet's DSCP value.
When forwarding a packet to an access device, the AFTR SHOULD obtain the CID from the NAT binding associated with that flow and use it in the softwire encapsulation (e.g., add it to the GRE Key extension) before tunneling the packet to the access gateway.
GI-DS-Lite logically extends existing point-to-point access tunnels beyond the access gateway to an AFTR using softwires with an embedded Context Identifier (CID). The CID uniquely identifies the end-system to which tunneled packets belong. Local policies at the access gateway determine which portion of traffic is forwarded to the AFTR.
Multiple softwires MAY be established between the same access gateway and AFTR pair, for example to separate address domains or provide load-sharing. Softwire peers MAY also be provisioned to perform policy enforcement on protocol types or QoS settings.
The AFTR combines softwire termination and IPv4-IPv4 NAT. NAT bindings may be assigned autonomously from a local address pool, configured per-binding via a remote NAT control protocol, or derived from the CID (e.g., mapping a 32-bit CID 1:1 to a public IPv4 address).
The AFTR translation table maps entries keyed by (Softwire-ID, Context-ID, inner IPv4 address, port) to a public (IPv4 address, port) tuple. This allows access devices sharing the same private IPv4 address to be uniquely identified and NATted based on CID and SWID.
The Context Identifier (CID) is used to multiplex flows from individual access devices onto the softwire. It is typically 32 bits wide and assigned by the access gateway, retrieved from a local or remote (e.g., AAA) repository. The combination of CID and SWID must be unique between the access gateway and AFTR.
The softwire between the access gateway and AFTR MAY be created at system startup or dynamically established on-demand. OAM mechanisms such as ICMP, BFD (RFC 5880), or LSP ping (RFC 4379) MAY be employed for softwire health management and protection strategies.
The Softwire Identifier (SWID) identifies the softwire between the access gateway and AFTR. The SWID does not need to be globally unique; different SWIDs may identify the same softwire at each end. Its form depends on tunneling technology (e.g., GRE tunnel endpoints or a VPN-ID).
When GRE with GRE Key (RFC 2890) is used as the softwire, the SWID is the GRE tunnel identifier and the CID is the GRE Key associated with the access device. This allows the network between the access gateway and AFTR to be IPv4-only, IPv6-only, or dual-stack.
When IPv4-in-IPv6 with IPv6 Flow Label is used, the SWID is the outer IPv6 source address and the 20-bit Flow Label serves as the CID, enabling overlapping IPv4 addresses among access devices. The 20-bit width is shorter than the recommended 32-bit CID, requiring scaling consideration for large deployments.
When MPLS VPN (RFC 4364) is used as the softwire, the SWID is a generic VPN identifier and the AD's IPv4 address serves as the CID. For a given VPN, each AD's IPv4 address must be unique, so overlapping private addresses across ADs are not supported in this mode.
An on-path attacker between the access gateway and AFTR can modify the Context Identifier in the packet, causing it to be associated with an incorrect access device. This threat is analogous to an attacker modifying the source/destination IP address of a packet.
The CID modification threat can be mitigated by enabling IPsec with integrity protection between the access gateway and the AFTR, ensuring the correct binding of the Context Identifier and the inner packet. No security requirements beyond those in RFC 6333 (DS-Lite) and the underlying access architecture are introduced.