How DS-Lite Works: Dual-Stack Lite for IPv6 Transition

Dual-Stack Lite (DS-Lite), defined in RFC 6333, is an IPv6 transition technology that allows ISPs to operate an IPv6-only access network while still providing subscribers with IPv4 connectivity. The key insight is that the ISP never assigns a public or private IPv4 address to the subscriber's WAN interface. Instead, the customer premises equipment (CPE) encapsulates IPv4 traffic inside IPv6 packets (IPv4-in-IPv6 tunneling) and sends it to a centralized device in the ISP's network that performs NAT44 on behalf of all subscribers. The subscriber gets native IPv6 for the vast majority of modern internet traffic, and the tunnel handles the shrinking portion of IPv4-only destinations -- all without the ISP spending a single public IPv4 address per customer.

DS-Lite exists because IPv4 addresses are exhausted, and the traditional approach of giving every subscriber a public IPv4 address (or even a private one behind CGNAT) becomes untenable as subscriber counts grow. With conventional CGNAT, the ISP still needs to provision IPv4 addressing throughout its access network -- assigning RFC 6598 shared address space (100.64.0.0/10) to every CPE, maintaining IPv4 routing infrastructure, and running dual-stack at every layer. DS-Lite eliminates this entirely. The ISP's access network carries only IPv6. IPv4 is handled exclusively at two points: the subscriber's LAN (where devices still use 192.168.x.x) and the ISP's centralized NAT device. Everything in between is pure IPv6.

Architecture: B4 and AFTR

DS-Lite introduces two functional elements with deliberately descriptive names:

The B4 element (Basic Bridging BroadBand) runs on the subscriber's CPE -- the home router, cable modem, or ONT. It acts as the tunnel ingress for IPv4 traffic. When a device on the subscriber's LAN sends an IPv4 packet (say, to an IPv4-only website), the B4 takes that packet whole -- IP header and payload intact -- and encapsulates it as the payload of an IPv6 packet. The outer IPv6 header uses the CPE's globally routed IPv6 address as the source and the AFTR's IPv6 address as the destination. The B4 does not perform NAT on the IPv4 packet. It does not translate addresses. It simply wraps the IPv4 packet in IPv6 and sends it down the tunnel. The subscriber's LAN continues to use RFC 1918 private addressing (typically 192.168.0.0/16 or 10.0.0.0/8) exactly as it would behind any home router.

The AFTR (Address Family Transition Router) sits in the ISP's network -- typically at a regional aggregation point or data center. It terminates the IPv4-in-IPv6 tunnels from potentially hundreds of thousands of B4 elements, decapsulates the IPv4 packets, performs NAT44 (translating the subscriber's private source address to a public IPv4 address from its pool), and forwards the resulting packet onto the IPv4 internet. Return traffic follows the reverse path: the AFTR receives the IPv4 response, looks up the NAT mapping to identify which subscriber's tunnel to send it down, encapsulates the IPv4 response in an IPv6 packet addressed to the B4's IPv6 address, and sends it across the IPv6-only access network. The B4 decapsulates the IPv6 wrapper, and the IPv4 response is delivered to the LAN device.

The critical distinction from traditional CGNAT is what happens on the subscriber's WAN interface. In a conventional CGNAT deployment, the CPE's WAN interface receives an IPv4 address from the ISP's shared address space (100.64.0.0/10), and IPv4 packets traverse the access network natively until they hit the CGNAT device. In DS-Lite, the CPE's WAN interface has only an IPv6 address. There is no IPv4 address on the WAN side at all -- not a public one, not a private one, not a shared one. The ISP's access network does not carry IPv4 packets. This means the ISP can decommission all IPv4 routing infrastructure in the access network: no IPv4 DHCP, no IPv4 ARP, no IPv4 routing tables, no IPv4 ACLs. The operational simplification is substantial.

The Softwire: IPv4-in-IPv6 Tunneling

The tunnel between the B4 and AFTR is called a softwire, a term from RFC 4925 that refers to any tunnel established between two endpoints in a network using software-based configuration rather than physical infrastructure. In DS-Lite, the softwire uses IP-in-IP encapsulation as defined in RFC 2473 (Generic Packet Tunneling in IPv6). The outer protocol is IPv6, and the inner payload is a complete IPv4 packet including the IPv4 header.

The encapsulation format is straightforward: the B4 prepends a 40-byte IPv6 header to the IPv4 packet. The IPv6 header's Next Header field is set to 4 (IPv4), indicating that the payload is an IPv4 packet. There is no additional tunnel header, no GRE, no UDP encapsulation -- just a raw IPv6 header wrapping a raw IPv4 packet. This is the simplest possible tunneling mechanism, which keeps overhead to the minimum 40 bytes of the IPv6 header.

The B4 uses its own globally routable IPv6 address as the source of the outer IPv6 header, and the AFTR's well-known IPv6 address as the destination. The inner IPv4 packet is left completely untouched -- the B4 does not modify the IPv4 source address, destination address, ports, or any other field. This is important: the B4 is explicitly not a NAT. It is a tunnel endpoint. The NAT function is concentrated entirely at the AFTR.

Because the inner IPv4 source address is a private RFC 1918 address (e.g., 192.168.1.10), and because multiple subscribers behind different B4 elements can use identical private address ranges, the AFTR needs to distinguish between subscribers. It does this using the outer IPv6 source address. When the AFTR receives a tunneled packet from 2001:db8::1 containing an inner IPv4 packet from 192.168.1.10, and another tunneled packet from 2001:db8::2 also containing an inner IPv4 packet from 192.168.1.10, it knows these are two different subscribers because the IPv6 source addresses differ. The AFTR's NAT binding table is indexed by the tuple (subscriber IPv6 address, inner IPv4 source address, inner source port, protocol) rather than just (IPv4 source address, source port, protocol) as in traditional NAT.

AFTR: Centralized NAT44

The AFTR combines two functions: tunnel termination (decapsulating and re-encapsulating IPv4-in-IPv6 packets) and NAT44 (translating private IPv4 addresses to public ones). Both functions must operate at line rate for potentially millions of concurrent sessions across hundreds of thousands of subscribers.

The NAT44 at the AFTR is functionally identical to CGNAT -- it faces the same challenges of port allocation, session tracking, logging, and application compatibility. The difference is that the subscriber identification is richer: where CGNAT identifies a subscriber by their RFC 6598 shared address (100.64.x.x), the AFTR identifies a subscriber by their IPv6 address. This has practical implications for the binding table. The AFTR must store the outer IPv6 address (16 bytes) alongside each NAT mapping, rather than just an IPv4 address (4 bytes). This increases per-session memory consumption and can affect lookup performance if the data structures are not designed for 16-byte keys.

Port allocation at the AFTR follows the same strategies used in traditional CGNAT deployments:

• Dynamic port allocation assigns ports on demand as subscribers open connections. This maximizes utilization -- an idle subscriber consumes zero ports -- but requires per-allocation logging for law enforcement traceability. Ports are typically allocated in bulk (blocks of 64, 128, or 256) to amortize the overhead of allocation events and reduce log volume.
• Deterministic port allocation assigns a fixed port range to each subscriber based on their IPv6 address and a deterministic algorithm. Given a subscriber's IPv6 address, the AFTR can compute the assigned public IPv4 address and port range without consulting any state table. This eliminates per-flow logging entirely -- the ISP only needs to record the algorithm's configuration. The tradeoff is reduced efficiency: every subscriber gets the same port budget regardless of actual usage.
• Port Range Router (PRR) / A+P pre-allocates port ranges to subscribers and communicates them via DHCP or other provisioning mechanisms. The CPE is aware of its assigned port range and can perform local NAT within those bounds. This distributes NAT state across CPEs but adds provisioning complexity and is not part of the base DS-Lite specification.

A typical AFTR serving 100,000 subscribers with an average of 300 concurrent connections per subscriber must handle 30 million simultaneous NAT bindings. At roughly 100-200 bytes per binding (including the IPv6 address, IPv4 source/destination, ports, protocol, and timestamps), this requires 3-6 GB of state memory. The binding table must support fast lookups in both directions: outbound (keyed by subscriber IPv6 address + inner IPv4 + inner port) and inbound (keyed by external public IPv4 + external port). Hash tables or balanced trees are typical data structures, and lookup speed directly impacts forwarding latency.

AFTR Discovery: DHCPv6 Option 64

The B4 needs to know the AFTR's IPv6 address to establish the softwire. RFC 6334 defines DHCPv6 Option 64 (OPTION_AFTR_NAME) for this purpose. When the CPE boots and obtains its IPv6 configuration via DHCPv6, the DHCP server includes Option 64 containing the AFTR's fully qualified domain name (FQDN). The B4 resolves this FQDN to an IPv6 address using DNS and uses the result as the tunnel destination.

Using a domain name rather than a literal IPv6 address provides operational flexibility. The ISP can change the AFTR's address (for maintenance, migration, or load balancing) by updating DNS without reconfiguring every subscriber's DHCP lease. The ISP can also use DNS-based load distribution to direct different subscribers to different AFTR instances, though in practice, most deployments use anycast or direct address assignment for more predictable traffic distribution.

The DHCPv6 option flow during CPE provisioning:

1. CPE sends DHCPv6 Solicit, requesting Option 64 (AFTR name) in addition to standard options (IA_NA, IA_PD for IPv6 address and prefix delegation).
2. DHCPv6 server responds with Advertise, including Option 64 containing the AFTR FQDN (e.g., aftr.isp.example.com).
3. CPE resolves the FQDN via DNS to obtain the AFTR's IPv6 address (e.g., 2001:db8:aftr::1).
4. CPE configures the B4 tunnel with the resolved AFTR address as the remote endpoint.
5. IPv4 traffic from the LAN is now encapsulated and sent to the AFTR.

Some CPE implementations also support static AFTR configuration via the router's admin interface, which is useful for troubleshooting or for deployments where DHCPv6 Option 64 is not available. However, static configuration loses the operational benefits of centralized AFTR address management.

DS-Lite vs. CGNAT: What Changes, What Stays

DS-Lite is not a replacement for CGNAT -- it is CGNAT with a different access network architecture. The NAT44 at the AFTR has exactly the same behavioral properties, scaling challenges, and application compatibility issues as any other CGNAT deployment. Subscribers behind DS-Lite experience the same double-NAT effects as subscribers behind traditional CGNAT: restricted inbound connectivity, NAT traversal challenges for gaming and VoIP, and port exhaustion under heavy usage.

What DS-Lite changes is the access network. The differences are operational, not subscriber-facing:

The operational benefit is real but subtle: by eliminating IPv4 from the access network, the ISP eliminates an entire protocol's worth of configuration, monitoring, and troubleshooting. No IPv4 DHCP pools to manage, no IPv4 ARP tables consuming switch memory, no IPv4 ACLs to maintain, no IPv4 routing protocol adjacencies to monitor. For a large ISP with millions of access ports, this simplification reduces operational cost and failure modes. The cost is the 40-byte-per-packet tunneling overhead and the complexity of the B4/AFTR tunnel management.

MTU and Fragmentation Challenges

The 40-byte IPv6 encapsulation header reduces the effective Maximum Transmission Unit (MTU) for IPv4 traffic. If the access network's IPv6 MTU is 1500 bytes (the standard Ethernet MTU), the maximum IPv4 packet that can be encapsulated without fragmentation is 1460 bytes. This is smaller than the standard 1500-byte IPv4 MTU that LAN devices expect, which creates a path MTU mismatch.

RFC 6333 addresses this in two ways. The B4 should set the IPv4 MTU on its LAN interface to the access network's IPv6 MTU minus 40 (e.g., 1460 bytes) so that LAN devices know to send smaller packets. This works for TCP, where the MSS (Maximum Segment Size) is negotiated during the three-way handshake -- TCP endpoints will clamp their segment size to fit the reduced MTU. It is less effective for UDP, where applications may send packets up to 1500 bytes without checking the path MTU.

When an IPv4 packet arrives at the B4 that is too large to encapsulate without exceeding the IPv6 MTU, the B4 must either fragment or drop the packet. IPv4 allows intermediate routers to fragment packets (if the Don't Fragment bit is not set), but fragmentation is problematic: it increases CPU load on the B4 and AFTR, it can cause reassembly failures if fragments arrive out of order or are lost, and it interacts poorly with NAT (only the first fragment contains the TCP/UDP port numbers needed for NAT lookup). If the Don't Fragment bit is set, the B4 must send an ICMPv4 "Fragmentation Needed" message back to the source, triggering Path MTU Discovery (PMTUD). This usually works correctly but relies on ICMP not being filtered -- a common problem in misconfigured networks.

On the IPv6 side, fragmentation is handled differently. IPv6 does not allow intermediate routers to fragment packets -- only the source can fragment. If the encapsulated packet exceeds the path MTU between the B4 and AFTR, the B4 receives an ICMPv6 "Packet Too Big" message and must reduce its tunnel MTU accordingly. The B4 then either fragments the inner IPv4 packet before encapsulation (if the DF bit is clear) or sends back an ICMPv4 "Fragmentation Needed" to the original source (if the DF bit is set).

In practice, ISPs often configure their access networks with jumbo-frame support or an IPv6 MTU of at least 1540 bytes between B4 and AFTR, ensuring that a full 1500-byte IPv4 packet can be encapsulated without fragmentation. This eliminates the MTU problem entirely for standard Ethernet traffic. Access technologies like GPON fiber and DOCSIS 3.1 cable commonly support MTUs well above 1500 bytes on the provider-side link.

Logging and Law Enforcement: The Binding Table Problem

Like all forms of address sharing, DS-Lite creates a traceability problem. When a public IPv4 address is shared by dozens or hundreds of subscribers, the address alone is insufficient to identify which subscriber was responsible for a given connection. Law enforcement subpoenas, abuse reports, and copyright complaints require the ISP to identify the specific subscriber. This requires logging the NAT binding table state at the AFTR.

DS-Lite adds a unique wrinkle to the logging problem: the subscriber is identified by their IPv6 address, not an IPv4 address. The AFTR's log entries must record the subscriber's IPv6 address alongside the NAT mapping. A typical log entry contains:

• Timestamp (millisecond or microsecond precision)
• Subscriber IPv6 address (source of the outer IPv6 header)
• Inner IPv4 source address (the subscriber's RFC 1918 LAN address)
• External public IPv4 address assigned by the AFTR
• External port or port range
• Protocol (TCP, UDP, ICMP)
• Event type (binding created, binding destroyed)

The IPv6 address adds 12 bytes to each log entry compared to CGNAT logging (16 bytes for IPv6 vs. 4 bytes for IPv4 source address). For an ISP with millions of subscribers generating billions of log entries per day, this increases storage requirements by 15-25%. More importantly, the log query infrastructure must support IPv6 address indexing, which some legacy systems designed for IPv4-only CGNAT logging do not handle well.

Deterministic NAT at the AFTR reduces the logging burden significantly, as with traditional CGNAT. If the AFTR assigns port ranges deterministically based on the subscriber's IPv6 address, the ISP only needs to log the mapping algorithm and its parameters -- not individual binding events. Given an external IPv4 address, port, and timestamp, the ISP can compute which IPv6 address (and therefore which subscriber) held that mapping. This is the preferred approach for large-scale DS-Lite deployments.

Comparison with MAP-E, MAP-T, and 464XLAT

DS-Lite is one of several IPv4-over-IPv6 mechanisms. Understanding the alternatives clarifies why an ISP might choose DS-Lite over the others, or vice versa.

MAP-E (Mapping of Address and Port using Encapsulation, RFC 7597) takes a fundamentally different approach to the NAT problem. Instead of centralizing NAT at the AFTR, MAP-E distributes it to the CPE. Each subscriber's CPE is assigned a specific share of a public IPv4 address -- a particular IPv4 address plus a range of ports -- algorithmically derived from the subscriber's IPv6 prefix. The CPE performs NAT44 locally, restricted to its assigned port range. The Border Relay (BR) in the ISP's network is completely stateless: it only performs decapsulation/encapsulation, not NAT. Given an incoming IPv4 packet's destination address and port, the BR can compute the correct subscriber's IPv6 address using the MAP-E mapping rules, encapsulate the packet, and forward it. No per-subscriber state, no binding table, no logging of NAT events -- the mapping is fully deterministic.

MAP-E's stateless BR is its primary advantage over DS-Lite. The BR can be horizontally scaled trivially (any BR can handle any packet), and there is no single point of failure holding millions of NAT bindings. The tradeoff is CPE complexity: the CPE must understand the MAP-E mapping rules, perform restricted NAT44, handle the encapsulation, and correctly limit itself to its assigned port range. This requires more capable CPE hardware and software. MAP-E is heavily deployed by Japanese ISPs (NTT, JPNE/v6plus, BIGLOBE), where it has become the dominant IPv4-over-IPv6 mechanism.

MAP-T (Mapping of Address and Port using Translation, RFC 7599) is similar to MAP-E but uses IPv4/IPv6 header translation instead of encapsulation. This eliminates the 40-byte tunnel overhead entirely -- there is no inner IPv4 header, only a translated IPv6 header. The tradeoff is additional complexity at both the CPE and BR, which must perform stateless NAT46/NAT64 translation using the MAP-T rules. MAP-T is less widely deployed than MAP-E.

464XLAT (RFC 6877) is the dominant mechanism in mobile networks. It combines a client-side CLAT (which translates IPv4 to IPv6 on the device) with a provider-side PLAT (a NAT64 gateway). The CLAT is built into mobile operating systems (Android, iOS) and does not require CPE hardware at all. The PLAT is a stateful NAT64 device in the ISP's network. 464XLAT is natural for mobile carriers because the CLAT runs on the phone itself -- there is no separate CPE. For fixed-line ISPs, 464XLAT requires either running CLAT on every LAN device (impractical) or on the CPE (which then functions similarly to DS-Lite but with translation instead of tunneling).

ISP Deployments

DS-Lite has seen significant deployment, particularly among European and Asian ISPs:

• Free (Iliad Group, France) was one of the earliest large-scale DS-Lite deployers, using it for their FTTH subscribers from the Freebox Revolution onwards. The Freebox CPE acts as the B4, tunneling IPv4 traffic to Free's AFTR infrastructure. Free's network is natively IPv6, and DS-Lite provides backward compatibility for IPv4-only services.
• Sky Broadband (UK) deployed DS-Lite for a subset of subscribers, particularly those on newer FTTP connections where the access network is IPv6-native. Subscribers behind DS-Lite share public IPv4 addresses through Sky's AFTR.
• SoftBank (Japan) uses DS-Lite alongside MAP-E (via the v6plus service from JPNE). The choice between DS-Lite and MAP-E depends on the subscriber's plan and CPE capabilities.
• Comcast (US) trialed DS-Lite during its early IPv6 deployment but ultimately chose a dual-stack approach with CGNAT for IPv4 address sharing, rather than DS-Lite's IPv6-only access model.
• Various European cable and fiber operators in Germany (Unitymedia/Vodafone), Switzerland, and the Nordics have deployed DS-Lite as part of their IPv6 transition strategies, leveraging the operational simplicity of IPv6-only access networks.

The geographical distribution is not accidental. DS-Lite appeals most to ISPs that are building new IPv6-native access networks (common in European FTTH and cable upgrades) and want to minimize IPv4 infrastructure investment. Mobile carriers tend to prefer 464XLAT (because the CLAT runs on the phone). Japanese fixed-line ISPs prefer MAP-E (because the stateless BR scales better for their subscriber densities). North American ISPs have generally opted for dual-stack with CGNAT, partly because their access networks already carry IPv4 and the migration cost to IPv6-only access is high.

CPE Requirements

A CPE supporting DS-Lite must implement the B4 element, which requires several capabilities beyond a standard home router:

• IPv6-only WAN — The CPE must be able to operate with only an IPv6 address on its WAN interface. Many older home routers assume they will receive an IPv4 WAN address and display errors or malfunction when they do not get one. A DS-Lite-capable CPE must function correctly without any IPv4 WAN address.
• DHCPv6 Option 64 support — The CPE must request and process the AFTR name option from DHCPv6. This is not a standard DHCPv6 option in most consumer router firmware -- it requires explicit DS-Lite support.
• IPv4-in-IPv6 tunnel endpoint — The CPE must create and manage an IP-in-IP tunnel (IP protocol 4 over IPv6) to the AFTR. This is a kernel-level capability on Linux-based CPEs (using the ip4ip6 tunnel interface) and requires specific firmware support on other platforms.
• MTU handling — The CPE must set the IPv4 MTU on its LAN interface to account for the 40-byte IPv6 encapsulation overhead. It should also handle IPv4 fragmentation and ICMP "Fragmentation Needed" messages correctly.
• IPv4 DHCP server on LAN — The CPE must continue to serve IPv4 addresses to LAN clients via DHCP, even though it has no IPv4 WAN address. The LAN operates as a standard IPv4 network; only the WAN transport changes.

ISPs deploying DS-Lite typically provide specific CPE models that they have validated for B4 compatibility. Subscribers who use their own equipment (common in markets with modem freedom regulations) may need to verify DS-Lite support before purchasing. OpenWrt, a popular open-source router firmware, has included DS-Lite support since the Barrier Breaker release (2014) via the ds-lite package, which configures the B4 tunnel interface and handles AFTR discovery.

AFTR Scaling Challenges

The AFTR is the critical scaling bottleneck in DS-Lite deployments. Unlike MAP-E's stateless border relay, the AFTR maintains per-subscriber, per-session state. Every active NAT binding -- every TCP connection, every UDP flow, every ICMP echo -- consumes state in the AFTR's binding table. The AFTR must process every IPv4 packet from every subscriber in both directions: decapsulate, NAT lookup, translate, and forward (or encapsulate, NAT lookup, translate, and tunnel).

Scaling dimensions for the AFTR include:

• Session count: A typical residential subscriber maintains 200-500 concurrent NAT sessions. A gaming or torrent-heavy subscriber can exceed 5,000. An AFTR serving 100,000 subscribers must handle 20-50 million concurrent sessions, with peaks during evening hours potentially doubling the average.
• Packets per second (PPS): At 1 Gbps of aggregated subscriber traffic with an average packet size of 500 bytes, the AFTR processes roughly 250,000 packets per second. At 10 Gbps, it is 2.5 million PPS. Each packet requires a hash table lookup in the NAT binding table plus IPv6 decapsulation/encapsulation.
• New session rate: The rate at which new NAT bindings are created matters because each new binding involves allocating state, writing to the binding table, and potentially logging the event. During subscriber reconnection storms (after a network outage, for example), hundreds of thousands of subscribers simultaneously establish new connections, creating a spike in new session creation.
• High availability: Because the AFTR holds stateful NAT bindings, failover requires either session replication to a standby AFTR (expensive in bandwidth and complexity) or accepting that all active sessions are dropped during failover (disruptive to subscribers). Compare this with MAP-E's stateless BR, where failover is instantaneous because there is no state to replicate.

ISPs address AFTR scaling through several approaches: deploying multiple AFTR instances with subscribers distributed across them (typically by geographic region or access network segment), using purpose-built CGNAT hardware from vendors like A10 Networks, F5, and Cisco (which optimize NAT lookup in custom ASICs or optimized software), and implementing deterministic NAT to reduce per-session state and eliminate logging overhead.

Gaming, P2P, and Application Impact

DS-Lite has the same application compatibility characteristics as CGNAT, because the AFTR is performing CGNAT. Any application that is broken by CGNAT is equally broken by DS-Lite. The tunneling layer is transparent to applications -- they see a standard IPv4 LAN and have no awareness that their packets are being encapsulated in IPv6 on the WAN side.

The specific impacts mirror those of any shared-address NAT deployment:

• Gaming: Console and PC gaming platforms detect "double NAT" or "strict NAT" when behind DS-Lite. UPnP and NAT-PMP only configure the home router (the B4), not the AFTR. Peer-to-peer matchmaking is restricted. Hosting game servers is impossible without external relay infrastructure. Latency may increase marginally due to the encapsulation/decapsulation overhead at the B4 and AFTR, though the additional latency is typically sub-millisecond and dominated by the geographic distance to the AFTR.
• Peer-to-peer: TCP-based P2P protocols (BitTorrent) work but with reduced connectivity. The subscriber cannot accept inbound connections, so peer discovery relies on DHT, trackers, and NAT traversal. The available port count limits the number of simultaneous peer connections.
• VoIP/WebRTC: SIP-based VoIP has the same ALG (Application Layer Gateway) challenges as behind any NAT. WebRTC and modern VoIP applications use ICE/STUN/TURN for NAT traversal, which works through DS-Lite's AFTR the same way it works through CGNAT -- with a higher likelihood of requiring TURN relay due to the NAT's filtering behavior.
• Port forwarding: Traditional port forwarding (opening a port to receive inbound connections) is not possible with DS-Lite. The subscriber has no public IPv4 address and cannot configure the AFTR. Crucially, UPnP and NAT-PMP — the protocols that applications and consoles use to automatically open ports — only control the home router (B4), not the carrier-grade NAT at the AFTR. The correct solution is PCP (Port Control Protocol, RFC 6887), which was specifically designed to traverse multiple NAT layers and can signal all the way to the AFTR. Some ISPs offer PCP integration with their AFTR, but deployment remains inconsistent.
• IPv4 geolocation: Because many subscribers share the same public IPv4 address, geolocation databases may return inaccurate results. The public IPv4 address is associated with the AFTR's location (the ISP's data center), not the subscriber's home. This can affect content localization, fraud detection, and regional content licensing.

One mitigation that some ISPs offer is a "dual-stack upgrade" or "public IPv4 add-on" for subscribers who need full IPv4 connectivity. The subscriber pays extra for a dedicated public IPv4 address, which is assigned to their CPE's WAN interface directly (bypassing the DS-Lite tunnel for IPv4 traffic). The CPE then operates in dual-stack mode: native IPv6 for IPv6 destinations, native IPv4 with a public address for IPv4 destinations. This two-tier model lets the ISP reserve scarce IPv4 addresses for subscribers who actually need them while serving the majority through DS-Lite.

Troubleshooting DS-Lite Connections

Diagnosing problems on a DS-Lite connection requires understanding which layer is failing. Common issues and their diagnostics:

No IPv4 connectivity at all: This usually indicates a tunnel establishment failure. Check that the CPE received the AFTR address via DHCPv6 Option 64 (visible in the CPE's admin interface under WAN/IPv6 settings). Verify that the CPE can resolve the AFTR FQDN to an IPv6 address. Check that the CPE has a valid IPv6 WAN address. Verify that ICMPv6 is not being filtered between the CPE and AFTR (needed for PMTUD). On Linux-based CPEs, check that the ip4ip6 tunnel interface exists and is up (ip tunnel show).

IPv4 works but is slow: Likely an MTU/fragmentation issue. If the CPE's IPv4 LAN MTU is not reduced to account for the 40-byte tunnel overhead, large packets may be fragmented or dropped. Test by pinging an IPv4 host with different packet sizes and the Don't Fragment bit set: ping -M do -s 1460 8.8.8.8 should work, while ping -M do -s 1472 8.8.8.8 may fail if the MTU is correctly set to 1460. On Windows, use ping -f -l 1460 8.8.8.8. If packets larger than 1460 bytes succeed, the CPE's MTU is misconfigured or the access network supports jumbo frames (which is actually fine).

Some websites fail while others work: This is a classic PMTUD blackhole symptom. If ICMPv4 "Fragmentation Needed" messages from the B4 are filtered somewhere in the path, the source host never learns that it needs to reduce its packet size, and large packets are silently dropped. TCP connections complete the handshake (SYN/SYN-ACK are small packets) but stall when bulk data transfer begins (data packets exceed the MTU). The workaround is TCP MSS clamping: the B4 should rewrite the MSS option in TCP SYN packets to reflect the reduced MTU (typically clamping to 1420 bytes). Most DS-Lite CPE firmware does this automatically.

IPv4 works but specific services are blocked: If the AFTR implements restrictive endpoint-dependent filtering, some NAT traversal mechanisms may fail. Check the NAT type reported by game consoles or VoIP applications. If the NAT type is "symmetric" or "strict," the AFTR is using address-and-port-dependent mapping, which prevents most P2P hole-punching techniques.

Identifying whether you are behind DS-Lite: Check your CPE's WAN interface. If it has only an IPv6 address (no IPv4 WAN address at all), and IPv4 traffic still works, you are behind DS-Lite (or a similar IPv4-over-IPv6 mechanism). You can also visit the looking glass from your connection -- if the tool shows an IPv6 address for your connection but IPv4 websites still load, your IPv4 traffic is being tunneled. Running traceroute to an IPv4 destination should show the first hop as your home router, with subsequent hops reflecting the path from the AFTR to the destination (not from your CPE to the destination), since the IPv4 packet only enters the "real" IPv4 internet at the AFTR.

DS-Lite and the IPv6 Transition Endgame

DS-Lite is fundamentally a transitional technology. Its purpose is to allow ISPs to operate IPv6-only access networks today while maintaining backward compatibility with the IPv4-only services and applications that subscribers still need. As the internet's content and services complete their own transition to IPv6, the fraction of traffic traversing the DS-Lite tunnel shrinks. When a subscriber accesses an IPv6-enabled website (Google, Facebook, Netflix, Cloudflare, and most major services), that traffic flows natively over IPv6 without touching the AFTR at all. Only traffic to IPv4-only destinations uses the tunnel.

This creates a natural scaling dynamic: as IPv6 adoption increases, the AFTR handles less traffic, even as the subscriber base grows. An ISP that deployed an AFTR sized for 100 Gbps of IPv4 throughput in 2020 may find that the same subscriber base only generates 40 Gbps of IPv4 traffic in 2026, because 60% of their traffic has shifted to native IPv6. Eventually, the IPv4 traffic through the tunnel becomes a small enough fraction that the ISP can retire the AFTR infrastructure entirely -- at which point the access network is pure IPv6, and the transition is complete.

In this sense, DS-Lite's centralized AFTR -- which is its primary weakness from a scaling perspective -- is also a strength from a sunset perspective. The AFTR is a single piece of infrastructure that the ISP can scale down and eventually remove. MAP-E's distributed NAT on every CPE means that CPEs must continue to support IPv4 NAT even after the ISP has no further use for it. DS-Lite keeps the IPv4 complexity in one place: the ISP's data center, where it can be managed, monitored, and eventually decommissioned on a timeline the ISP controls.

For network engineers working with DS-Lite connections, the BGP Looking Glass can help diagnose routing issues by showing the BGP routes and AS paths for both the subscriber's IPv6 prefix (the access network) and the AFTR's public IPv4 addresses (the NAT pool). Comparing the two can reveal asymmetric routing or unexpected AS paths that explain latency or reachability problems through the DS-Lite tunnel.