The previous article examined a couple of basic Large Scale NAT (LSN) architectures – NAT444 and NAT464 – for creating dual stacked networks in the face of a depleted IPv4 address pool. The focus is primarily on broadband service providers, who must somehow continue to assign addresses to very large numbers of new customers when there are no new IPv4 addresses to use. Assigning IPv6 addresses alone is not practical for two reasons:
· Almost all services accessible on the public Internet are still IPv4 only
· Although quickly changing, many broadband customers are still running operating systems that either do not support IPv6 or have some shortcomings in their IPv6 support
LSN – the newer, more accurate name for what was previously called Carrier Grade NAT (CGN) – is simply a NAT that is located in a service provider network rather than in a customer network. It is almost always a service on a router rather than a standalone device; whether LSNs live up to “carrier grade” performance or scaling expectations is yet to be seen.
NAT444 is the simplest architecture for providing IPv4 addresses on the provider-to-customer links. The existing NATs at the customer network can be used, and the same basic NAT44 functionality is used at the provider’s LSN. But as explained in the previous article, there are concerns with using RFC1918 addresses on the customer links: Overlap between the customer’s RFC1918 addresses and the provider-assigned RFC1918 addresses, and problems with routing between customers behind the same LSN are the main issues here. The proposed solution is to reserve a block of the remaining IPv4 addresses to be used as “shared addresses” that do not overlap with RFC1918 addresses and will not encounter filtering problems when routing between customers behind the same LSN. However, this is only a proposed solution and no IPv4 address blocks have yet been reserved for shared address use.
An alternative to using IPv4 shared addresses between the provider and the customers is to use IPv6 addresses. This solves the same problems that are solved by shared addresses, and eases the administrative burden of the provider having to assign and manage both an IPv4 address and an IPv6 address on every link. It also gets a bit closer to where the provider ultimately wants to be: An IPv6-only infrastructure. The downside to this NAT464 architecture is that both the CPE NAT and the LSN must perform translation between IPv4 and IPv6 (NAT64), which is complex and introduces performance, scaling, and redundancy problems.
Dual-Stack Lite is a promising approach that takes the best of NAT464 while avoiding its problems: It uses IPv6-only links between the provider and the customer, but does not use NAT64 translation. When a device in the customer network sends an IPv4 packet to an external destination, the IPv4 packet is encapsulated in an IPv6 packet for transport into the provider network. At the LSN, the packet is decapsulated and NAT44 is performed (Figure 1). Tunneling IPv4 over IPv6 is far simpler than translation, so the performance and redundancy concerns are eliminated.
There is, however, an extra functional element that must be added to the NAT44 in the LSN for DS Lite to work.
If a simple mapping between inside IPv4 source address / port to outside IPv4 source address / port was performed on outgoing packets, as is done with regular NAT44, the LSN would have no way to differentiate between overlapping RFC1918 IPv4 addresses in different customer networks. Therefore an additional element is added to the address mapping: The source address of the encapsulating IPv6 packet (the address of the customer end of the IPv6 link) is added to the inside IPv4 source address and port. Because the IPv6 address is unique to each customer, the combination of IPv6 source address + IPv4 source address + port makes the mapping unambiguous. When a responding IPv4 packet is received from the outside, its IPv4 destination address and port can be correctly matched to a specific customer behind the NAT based on the IPv6 address in the mapping table; the packet’s IPv4 destination address and port can then be mapped to the inside IPv4 destination address and port, encapsulated in IPv6 using the mapped IPv6 address as the IPv6 destination address, and forwarded to the customer.
In other words, the mapped IPv6 address not only disambiguates the customer RFC1918 address, it provides the reference for the tunnel endpoint.
Assuming there are multiple end systems in the customer network, the DS Lite function occurs on a CPE device such as a home gateway as shown in Figure 2. If a device sends an IPv6 packet, the packet is routed normally to the IPv6 destination. If a device sends an IPv4 packet, the CPE gateway performs the IPv4-in-IPv6 encapsulation, setting the destination address of the IPv6 packet to the address of the DS Lite enabled LSN. This model allows use of dual stacked, IPv4-only, and IPv6-only devices behind the gateway.
A frequently cited drawback is that DS Lite functionality must be added to existing customers’ CPE either through a software upgrade or by replacing the unit. Broadband providers are generally reluctant to inconvenience customers and to incur the expense of replacing installed equipment, so DS Lite capable CPE is more likely to be deployed initially only for new customers. However, this should not really be a significant issue since it is only new customers that are creating demand for new IP addresses. Existing customers’ CPE can be upgraded or replaced on a more casual schedule as a part of normal end-of-life equipment changes.
Another DS Lite model, depicted in Figure 3, implements DS Lite on an individual end system rather than on a CPE device. The device is dual stacked, and so can send and receive both IPv4 and IPv6 packets. Not only is this model relevant to customers that connect a single PC, game system, or laptop to the Internet rather than a network behind a router, it has great potential for mobile broadband.
Mobile providers face the same problems of needing to address “smart phones” and 4G wireless technologies such as LTE with IPv6 but providing a means for those mobile users to reach IPv4 content. A recent article in The Economist suggests that by 2015 all mobile phones sold will have IP capabilities (thus obsolescing the term “smart phone”) and most laptops will be sold with some sort of 4G wireless capability. The rapid growth of the mobile broadband market will soon make IPv6 as essential there as it is now becoming in the DSL- and cable-based broadband markets.
Comcast is the driving force behind DS Lite, and through Cablelabs DS Lite CPE development is well underway. Rumor has it that on the LSN end, the “big two” router vendors are developing DS Lite support. It’s a smart, reasonably simple solution to the dual stack problem, and I think we can expect to begin seeing DS Lite deployments soon.