Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
updated by
- rfc-7335 — IPv4 Service Continuity Prefix
Extracted elements (28)
AFTR reassembly of fragmented IPv6 packets is expensive because the AFTR must buffer partial fragments from many simultaneous tunnels, but the document notes this is only a fraction of AFTR workload in practice since most residential clients receive large packets (e.g., video) rather than sourcing them.
DS-Lite decouples IPv6 deployment in the service provider access network from IPv6 deployment in the global Internet and customer applications. Customers receive only IPv6 from the ISP, while IPv4 service is transparently provided through the tunnel and AFTR, allowing incremental IPv6 rollout without waiting for end-to-end IPv6 readiness.
DS-Lite uses IPv4-in-IPv6 tunnels rather than a cascade of NATs so that communications stay within a single address family — IPv6 sources talk to IPv6 destinations, IPv4 sources to IPv4 destinations — with no protocol-family translation. This greatly simplifies applications that embed literal IP addresses in their payloads.
The tunnel-based architecture allows AFTR endpoints to be placed anywhere in the service provider network, enabling horizontal scaling by adding more AFTRs and redistributing customer groups via DHCPv6 AFTR discovery, without requiring per-user static configuration on any AFTR.
DS-Lite currently only defines IPv4-in-IPv6 tunnels for the softwire between B4 and AFTR; the specification notes that other encapsulation types could be defined in future documents.
The AFTR performs NAT-44 and inherits NAT limitations regarding Application Level Gateways (ALGs). Some protocols (e.g., Active FTP) require ALGs to traverse NAT, but the AFTR is a shared device and cannot implement every current and future ALG.
The B4 element SHOULD NOT initialize if the host or CPE selects native dual-stack mode during interface initialization; the selection mechanism between DS-Lite and native dual-stack is out of scope and left to implementation. Running both simultaneously is discouraged.
A DS-Lite CPE SHOULD NOT operate a NAT function between its internal LAN interface and the B4 interface, to avoid creating an unintended double-NAT environment; NAT is performed exclusively by the AFTR in the service provider network.
A DS-Lite CPE SHOULD operate its own DHCPv4 server handing out RFC 1918 address space to home hosts, SHOULD advertise itself as the default IPv4 router and as a DNS server (DHCP Option 6), and SHOULD operate a DNS proxy to forward IPv4 DNS requests over IPv6 to service-provider DNS servers.
A Dual-Stack Lite AFTR MUST implement NAT behavior conforming to the best current practices documented in RFC 4787 (UDP NAT), RFC 5508 (ICMP NAT), and RFC 5382 (TCP NAT).
The AFTR MAY be provisioned with multiple NAT pools, but address ranges in those pools MUST NOT overlap. Operators may implement policies to assign different B4 clients to different pools.
The AFTR MUST perform fragmentation and reassembly if the underlying link MTU cannot accommodate the encapsulation overhead. Fragmentation MUST happen after IPv6 encapsulation; reassembly MUST happen before IPv6 header decapsulation, per RFC 2473 Section 7.2.
The AFTR SHOULD use the well-known IPv4 address 192.0.0.1 (reserved by IANA) to configure the IPv4-in-IPv6 tunnel endpoint, so that address appears in ICMP problem reports and traceroute outputs.
The B4 element MUST perform fragmentation and reassembly if the outgoing link MTU cannot accommodate the extra IPv6 encapsulation header. The inner IPv4 packet MUST NOT be fragmented; fragmentation MUST happen after IPv6 encapsulation, and reassembly MUST happen before IPv4 decapsulation, following RFC 2473 Section 7.2.
The B4 element SHOULD implement a DNS proxy following RFC 5625 recommendations, because it is provisioned only with IPv6 and cannot directly convey an IPv4 DNS server address to downstream IPv4-only nodes. The proxy must also be security-aware to support DNSSEC-validating resolvers behind the B4.
To guarantee interoperability, a B4 element SHOULD implement the DHCPv6 option defined in RFC 6334 for discovering the IPv6 address of the AFTR tunnel endpoint.
Tunneling MUST be done in accordance with RFC 2473 and RFC 4213. Traffic classes from IPv4 headers (RFC 2474) MUST be carried over to the corresponding IPv6 headers and vice versa.
When decapsulating packets, the AFTR MUST only forward packets sourced by RFC 1918 addresses, the IANA reserved range 192.0.0.0/29, or pre-authorized out-of-band addresses. The AFTR MUST drop all other packets, preventing rogue devices from launching DoS attacks using spoofed public IPv4 source addresses.
When the AFTR's reassembly resources fall below a pre-defined threshold, the AFTR SHOULD generate a notification to the administrator before resources are completely exhausted.
IANA allocated the well-known IPv4 prefix 192.0.0.0/29 for DS-Lite interfaces. Within that range, 192.0.0.0 is the reserved subnet address, 192.0.0.1 is reserved for the AFTR element, and 192.0.0.2 is reserved for the B4 element; the remaining addresses accommodate multi-homed nodes implementing multiple B4 elements.
The AFTR (Address Family Transition Router) element combines an IPv4-in-IPv6 tunnel endpoint with an IPv4-IPv4 NAT on the same node. It terminates softwire tunnels from B4 elements and performs carrier-grade NAT to share a pool of public IPv4 addresses among customers.
The AFTR's NAT binding table is extended to include the source IPv6 address (Softwire-Id) of incoming tunneled packets. The composite key {Softwire-Id, IPv4+Port} disambiguates overlapping private IPv4 address spaces across different customers and allows the AFTR to reconstruct the correct IPv6 encapsulation for return traffic without static per-tunnel configuration.
The B4 (Basic Bridging BroadBand) element is a function implemented on a dual-stack-capable node, either a directly connected device or a CPE, that creates a multipoint-to-point IPv4-in-IPv6 tunnel to an AFTR. It encapsulates outbound IPv4 traffic in IPv6 and decapsulates inbound IPv6-tunneled IPv4 traffic.
IANA allocated the IPv4 prefix 192.0.0.0/29 for DS-Lite interface numbering. The /29 reserves six usable addresses to accommodate multi-homed nodes with multiple B4 elements; 192.0.0.1 is the default AFTR address and 192.0.0.2 is the default B4 address.
AFTRs should implement IPv6 ingress filtering on their tunnel interfaces to accept only the IPv6 address range belonging to registered customers, limiting DS-Lite service to authorized users and reducing attack surface.
Because ports are a critical shared resource when IPv4 addresses are shared, the AFTR must implement port-usage limits per user — either by rate-limiting new connections or by capping the maximum number of ports — to protect the shared NAT pool from exhaustion by a single user.
With IPv4 addresses shared by multiple customers, IPv4 address plus timestamp is no longer sufficient to identify a specific broadband user. The AFTR should log the tunnel-id, protocol, ports/IP addresses, and NAT binding creation time to uniquely identify user sessions, in order to support abuse investigations and lawful intercept.
Each entry in the AFTR's extended NAT binding table has the form {Softwire-Id (IPv6 address of the B4), inner IPv4 source address, protocol, port} mapped to {public IPv4 address, protocol, port}. The Softwire-Id field disambiguates customers sharing overlapping RFC 1918 space and is used to reconstruct the IPv6 encapsulation for return traffic.