Dual Stack Lite (DS-Lite)

Dual Stack Lite (also known as DS-Lite) was specified in RFC 6333, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", August 2011. Technically DS-Lite involves more than just tunneling, but the IPv6 Forum includes it under the tunnel transition mechanism in their training curriculum, so here it is.

The basic idea is to provide native (not tunneled) IPv6 service from the ISP to the customer. This will require a replacement (or major firmware upgrade) of the customers' existing Customer Premises Equipement (CPE) - the "modem/router" box usually provided by the ISP, with a DS-Lite compliant CPE device. IPv4 is provided not in native form, parallel to the IPv6 native service, but tunneled over the IPv6 via 4in6. The IPv4 addresses for internal nodes are only private, being supplied by Carrier Grade NAT (CGN). Because the customer has native IPv6 for any protocols that have problems with NAT44, the use of CGN is not as onerous as when it is provided without any IPv6. Furthermore, DS-Lite tags each user's IPv4 addresses with their assigned IPv6 prefix (in its NAT state table), so there is only one layer of NAT44, which means the IPv4 side in DS-Lite is no worse than existing existing ISP service with one layer of NAT44..

From the RFC:

The common thinking for more than 10 years has been that the
transition to IPv6 will be based solely on the dual-stack model and
that most things would be converted this way before we ran out of
IPv4.  However, this has not happened.  The IANA free pool of IPv4
addresses has now been depleted, well before sufficient IPv6
deployment had taken place.  As a result, many IPv4 services have to
continue to be provided even under severely limited address space.
 
This document specifies the Dual-Stack Lite technology, which is
aimed at better aligning the costs and benefits in service provider
networks.  Dual-Stack Lite will enable both continued support for
IPv4 services and incentives for the deployment of IPv6.  It also
de-couples IPv6 deployment in the service provider network from the
rest of the Internet, making incremental deployment easier.
 
Dual-Stack Lite enables a broadband service provider to share IPv4
addresses among customers by combining two well-known technologies:
IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT).


Basically, the world waited too long to begin migrating to IPv6. Some of the transition mechanisms that might have been viable when there were still some public IPv4 addresses available, are no longer viable. You can't use most IPv6 over IPv4 tunnel mechanisms without at least one public IPv4 address at each customer (which is often no longer available). DS-Lite is a scheme that can work long term, even with "severely limited IPv4 address space" (which is what we have today in Asia/Pac and EU/ME, and soon worldwide). No public IPv4 address is required for each customer (which is about what is available now).

DS-Lite is the most likely way that ISPs will continue providing service for years to come, including simple access to the legacy IPv4 Internet via one layer of NAT44, while also providing quality native IPv6 for protocols that won't work (or don't work well) via NAT (especially CGN) and future development and growth.

No NAT64 or NAT46 is used in DS-Lite (these are very problematic, so that is a good thing). The 4in6 tunnel exists only between the ISP and the CPE. On the customer side of the CPE, the internal network is native dual stack, as with the other tunneling schemes we've covered that terminate at the border gateway. The CGN at the ISP requires only a small of IPv4 public addresses to handle a very large number of customers. This use of IPv4 addresses qualifies for allocation from an RIR (even the "one-time per customer" /22 blocks from APNIC and RIPE NCC, who have ended normal allocation of IPv4 public addresses).

Like any CGN scheme, large numbers of nodes will appear to be coming from the same IPv4 public address (maybe tens of thousands). Therefore, sites will no longer be able to block bad users by IPv4 address (which is referred to in the RFCs as a "penalty box"), and you will not be able to restrict access to secure sites based on IPv4 address (many people would be granted access, in addition to the one you are trying to permit).

Traditionally, only people from a single legal entity (a company or a family) shared a public address. Now thousands of legal entities will share a single IPv4 public address. This will complicate law enforcement. ISPs will have to maintain detailed records of every NAT444 mapping, including timestamp, for possibly 5 years or more. This will require massive amounts of storage. The ISP will probably pass the cost of this onto the customers. Since this isn't required for IPv6, we may soon find that IPv6-only service is cheaper than dual stack service.

 

Technical Details of DS-Lite ISP Service

                +----+                               +-------------+
  IPv6 host-----+    |            +------------------+IPv6 Internet|
                |    +---IPv6-----+                  +-------------+
dual-stack host-+ GW |
                |    |                        +---+  +-------------+
  IPv4 host-----+    +===v4-over-v6 tunnel====+CGN+--+IPv4 Internet|
                +----+                        +---+  +-------------+

<-----------private v4 (partially in tunnel)-->NAT<---public v4---->
<-----------------------------public v6---------------------------->

Diagram of how DS-Lite works.

On the left is the user network. Where it says "dual-stack host" you could in theory actually put a single computer (and this may be common with smartphones), but more typically that would be a switch with numerous computers connected to it. The "GW" box is the DS-Lite compliant gateway (CPE), which includes the B4 (Basic Bridging BroadBand) element. In theory, the B4 element could be software running on a dual-stack node, rather than firmware in a CPE. On the right is the ISP. The ISP has native access to both the IPv6 and IPv4 Internets. The ISP provides native IPv6 between the IPv6 Internet and the DS-Lite gateway at the customer site (this requires upgrading their "last mile" to IPv6). The ISP deploys a CGN/4in6 tunnel endpoint called AFTR (Address Family Transition Router), marked "CGN" in the diagram. This provides Carrier Grade NAT for IPv4 addresses and one endpoint of the 4in6 tunnel, which provides the customer with IPv4 service tunneled over the native IPv6. The gateway includes the other endpoint of the 4in6 tunnel (the B4 element).

 

IPv4 Side

For IPv4, the AFTR at the ISP has a pool of public IPv4 addresses used for CGN. The AFTR does NAT44 between its public IPv4 addresses and a separate RFC 1918 private address block (e.g. 192.168/16, or 10/8) for each customer (presumably the customer can choose the private address block used - this is not discussed in the RFC). Each internal node in the customer site gets one of these IPv4 private addresses as its node address. The GW device (e.g. CPE) does not do a second layer of NAT. The private addresses for nodes behind the GW are tagged by the customer's IPv6 address in the CGN NAT44, to keep this user's private addresses separate from any other users' private addresses (this is different from IPv4 only CGN implementations, and solves some otherwise difficult problems). Unlike most CGN implementations, internal nodes are behind only one layer of NAT44, but that NAT is done at the CGN in the ISP, not in the CPE. The CPE routes all IPv4 private addresses from the AFTR into the customer's network. There should be no NAT44 gateway between the CPE and internal nodes. 

You can configure internal nodes to use external DNS servers, but each IPv4 DNS request to such a server will request a binding in the AFTR (hence use some of the scarce NAT table space there). Of course this would also apply to internal DNS servers doing forwarding to external DNS servers over IPv4. The binding lasts only until the reply is returned, but could still have a large impact. DNS queries (or forwarding) over IPv6 goes directly over native IPv6, with no impact on the AFTR. It will be far better for internal nodes to do DNS queries over IPv6 (note that Windows XP is not capable of doing this directly, but an internal dual stack DNS server could take IPv4 DNS queries from Windows XP and forward them over IPv6 (in effect translating the DNS queries to IPv6).

Note that the IPv4 external address for a given internal node (that you would see at whatismyipaddress.com) is one of the addresses in the public IPv4 pool on the AFTR. While in theory the AFTR could link a specific public IPv4 address to your assigned IPv6 prefix, there is no guarantee in the RFC that you will get the same public IPv4 address each time you make an outgoing connection over IPv4.

 

IPv6 Side

For IPv6, native IPv6 comes direct from the ISP (which should have native connectivity to the IPv6 Internet). Each customer should be allocated one or more /64 blocks (e.g. a /60, /56 or even a /48 block) of unicast global IPv6 addresses. If the customer is a smartphone or tablet via a wireless connection, a single /64 is usually sufficient (unless the device is relaying ISP service via WiFi using routing). The GW device should learn the routed IPv6 block via DHCPv6 prefix delegation. The GW should include a source of Router Advertisements that advertise the routed global unicast prefix to internal nodes. It should also include a DHCPv6 server or relay agent, to advertise the IPv6 addresses of DNS to internal nodes. Eventually, once all internal nodes support RFC 6106, those nodes will be able to obtain IPv6 addresses of DNS via SLAAC, and no DHCPv6 server or relay agent will be needed.

IPv6-capable (dual stack, or IPv6-only) internal nodes and devices should be able to use IPv6 service normally over the native IPv6 connection to the ISP and not involve the B4 element, the 4in6 tunnel or the AFTR in any way. If at some point you remove or disable all IPv4 interfaces in your network, DS-Lite basically becomes pure native IPv6 service (the IPv4 aspects of the GW and ISP are still there, but aren't being used).

 

Miscellaneous Details

If the CPE does not include firewall functionality, there is no problem with adding a separate firewall device between the CPE and the internal nodes, so long as it does not do NAT44. SolidGate is ideally suited to such placement, and can route both the global IPv6 and private IPv4 addresses into the customer's network with full control over incoming and outgoing IPv4 and IPv6 traffic. Most dual stack firewalls should be able to function in this manner, so long as you can disable the NAT44 function on IPv4. You will need more than one /64 block of IPv6 to deploy a firewall in this manner, since it is really a router. There would be one /64 subnet (e.g. 2001:470:3d:3000::/64) between the CPE and the firewall, and another /64 subnet (e.g. 2001:470:3d:3001::/64) on the customer side of the firewall. This is one example of why ISPs should provide customers with more than just a single /64 block.

The GW must implement a DNS relay to the ISP's DNS server. It must also implement a DHCPv4 server, which hands out private addresses (from the block NATTED by the CGN). It should advertise the internal NIC of the GW as the DNS server.

The B4 element needs to know the address of the AFTR. This is typically discovered from a DHCPv6 server at the ISP that supports RFC 6334, "Dynamic Host Configuration protocol for IPv6 (DHCPv6) Option for Dual Stack Lite", August 2011. This DHCPv6 option provides the FQDN of the AFTR. Once the node has the domain name of the AFTR, it can do a normal DNS query to obtain its IP address(es). With DS-Lite, all DNS references should be done over IPv6. Until the AFTR is discovered, DNS is available only over IPv6 DNS.

The DHCPv6 AFTR Name option has the following syntax:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|    OPTION_AFTR_NAME: 64       |          option-len           |
+-------------------------------+-------------------------------+
|                                                               |
|                  tunnel-endpoint-name (FQDN)                  |
|                                                               |
+---------------------------------------------------------------+

 

Sample DS-Lite Implementations

For Do-It-Yourselfers, here is an article on building your own DS-Lite compliant CPE device from a Linksys WRT-54GL wireless router. If you happen to have an ISP (or can simulate one), a free, open-source AFTR is available here from the Internet Software Consortium. These are suitable for a very advanced college level class project.