Methods of servicing legacy IPv4-only nodes with an IPv6-only core
In the first part of this 3-part blog series, we discussed how IPv4 will soon become a legacy protocol. In a few years, IPv6 Internet traffic volumes will surpass IPv4 Internet traffic volumes. We also explored the motivation for service providers to build an IPv6-only core network yet still fulfill their obligations to connect customer IPv4-only devices to the Internet. We must remember that, even though we may be striving for a near-term dual-protocol transition strategy, the long-term strategy is to run an IPv6-only environment. This article is going to continue by exploring how this will be accomplished while also peering into what is going on behind the scenes (from the subscriber’s perspective) in the service provider network.
Providing IPv4 as a Service
These transition mechanisms for providing IPv4 as a Service (IPv4aaS) require some changes to the service provider’s network architecture. This can include some form of Carrier Grade NAT (CGN) or Large Scale NAT (LSN) NAT44 function at their Internet edge due to the shortage of public IPv4 addresses. The service provider is allowed to use the shared IPv4 prefix 100.64.0.0/10 (RFC 6598) for these transition purposes. Most of these IPv4aaS techniques require some form of encapsulation and tunneling of the subscriber’s legacy IPv4 packets across the service provider’s IPv6-only core network. These techniques must also consider how to perform Lawful Interception (LI) and session logging for local and national Law Enforcement Agencies (LEAs).
Some of these techniques require some changes to the software running on the device at the customer/subscriber edge. This could involve changes to the DSL Modem or the DOCSIS 3.1 cable modems and eRouters. However, today, most consumer home routers support IPv6 (RFC 7084), particularly if they are the higher-end routers that have 802.11ac wireless. Getting your home network connected with IPv6 isn’t as difficult as you might expect, but you would want to make sure that your legacy IPv4-only systems remain operational in the near-term.
There are also ISPs who are actively planning on establishing an IPv4aaS offering. Brian Field Ph.D., with Comcast gave a great presentation at last year’s NANOG64 on the “Motivation, Analysis, and Architecture for IPv4aaS” describing this concept from their perspective. He has also written a paper on the topic of “Approaches for IPv4 as a Service (2015)”. John Jason Brzozowski, Fellow and Chief Architect, IPv6 for Comcast Cable has published a presentation about their IPv6-only plans and given a presentation at RIPE72. Comcast’s plans include taking Software-Defined Networking (SDN) techniques like Fast Data Input Output (fd.io) and their Vector Packet Processor (VPP) combined with Segment Routing over an IPv6 core.
The protocol architects at the IETF have been considering this IPv4aaS concept for many years now and have been working on establishing several different techniques for tunneling IPv4 across an IPv6-only ISP infrastructure. The IETF has established the “Softwires” (softwire) working group that is chartered with developing ways to seamlessly carry IPv4 over IPv6 core networks. What follows are descriptions of the various methods of accomplishing an IPv4 as a Service network.
GRE over IPv6
Encapsulating one type of packet within another creates a tunnel-type experience for the inner packet. It is as if it went into an intergalactic wormhole and miraculously emerged in the next dimension over what seemed like a single hop, but in reality, the packet traversed many parsecs.
In the early days of IPv6, it was envisioned that IPv6 packets would be encapsulated in IPv4 (RFC 4213) on their way to their ultimate IPv6 destination. Early tunneling transition mechanisms like 6over4 (RFC 2529), 6to4 (RFC 3056), Teredo (RFC 4380), ISATAP (RFC 5214), and 6rd (RFC 5969) were developed. It has also been possible to use Generic Packet Tunneling in the IPv6 Specification (RFC 2473) to carry IPv6 packets within IPv4. This was a method that was created before Generic Routing Encapsulation (GRE) and was officially standardized in RFC 2784. The original 6bone IPv6 testbed used this technique to tie together early IPv6 researchers. Ironically, the IANA assigned IP protocol number for encapsulating IPv6 packets in IPv4 packets is 41, which precedes the protocol number for encapsulating IPv4 packets in IPv4 with GRE, IP protocol 47.
Now we have full “IPv6 Support for Generic Routing Encapsulation” (GRE) (RFC 7676) and an ISP would be able to use this technique to create an IPv4aaS offering. This is a simple technique that just reverses the original IPv6 transition mechanism: i.e., instead of joining islands of IPv6 across an ocean of IPv4 by putting the IPv6 packets in an IPv4 boat, we inverse the method. Now we are talking about joining solar systems of IPv4 across a galaxy of IPv6 by thrusting the IPv4 packets into the IPv6 wormhole for their voyage across the intergalactic Internet. GRE could be used within the subscriber CPE device and encapsulate all IPv4 packets within IPv6 packets, traverse those GRE packets across the service provider’s core, and then use a GRE tunnel termination system to decapsulate the IPv4 packets and send them to the Internet. This function could optionally be combined with a CGN/LSN NAT function.
Dual-Stack Lite (DS-Lite)
One of the first techniques conceived to transport IPv4 across an IPv6-only core is Dual-Stack Lite (DS-Lite). DS-Lite was defined by RFC 6333 as a method of leveraging IPv6 for the service provider core as IPv4 address exhaustion occurred. The way that DS-Lite works is the subscriber CPE will have a Basic Bridging BroadBand (B4) element that encapsulates IPv4 packets within IPv6 packets. IPv6 packets from the subscriber are handled natively across the ISP’s IPv6-only core. These encapsulated connections are handled with the per-session state maintained per subscriber to a central CGN gateway called the Address Family Transition Router (AFTR). Get it? B4 (before) and AFTR (after).
The AFTR terminates the 4in6 tunnels from the B4 elements and performs the CGN/LSN translation. To be able to scale to many subscribers, the AFTR requires significant compute and throughput resources. The B4 elements use a DHCPv6 Option for Dual-Stack Lite (RFC 6334) to help the B4 element learn its global IPv6 address. The IETF has documented “Deployment Considerations for Dual-Stack Lite” (RFC 6908) and there are “RADIUS Extensions for Dual-Stack Lite” (RFC 6519).
One advantage with DS-Lite is that subscribers can have overlapping IPv4 address space. IANA has set aside the IPv4 address block 192.0.0.0/29 and documented it as the “IPv4 Service Continuity Prefix” (RFC 7335) for this exact purpose. The overlapping IPv4 subnets are separated statefully by the fact that they are wrapped in globally-unique IPv6 addresses. However, the down side to DS-Lite is that it requires changes to the subscriber CPE. If an ISP is going to go through all the trouble and cost to replace CPE, they could just as easily replace it with dual-protocol CPE to help speed up IPv6 adoption.
Lightweight 4over6
The IETF is continuing to develop new IPv4 as a Service standards. The IETF has finalized an RFC for “Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture” (RFC 7596). As the name implies, it is a modification of DS-Lite whereby the NAT function occurs on the B4 element instead of on the AFTR element. This adjustment to the DS-Lite architecture alleviates the NAT44/NAPT per-client state maintenance from the AFTR element. Additionally, there is no centralized stateful CGN/LSN function performed. Moving the NAT function to the B4 CPE element decouples the binding between the IPv4 and IPv6 addresses. This Lw4o6 method still maintains per-subscriber state for the provisioning of the IPv6 tunnels carrying the subscriber’s legacy IPv4 packets inside. With the Lw4o6 method, the central system is referred to the lwAFTR and the CPE element is referred to as the lwB4.
The Lw4o6 method can leverage “DHCPv4-over-DHCPv6 (DHCP 4o6) Transport” (RFC 7341) or the alternative “Dynamic Allocation of Shared IPv4 Addresses” (RFC 7618) to facilitate providing the shared IPv4 address to the lwB4 element using an IPv6 core infrastructure. Early Lw4o6 research results were published at IETF 85 in 2012 and the IETF is continuing its work on this method by documenting “Deployment Considerations for Lightweight 4over6”.
Public 4over6
The IETF has also published an RFC titled “Public IPv4-over-IPv6 Access Network” (RFC 7040). This is an informational RFC related to work done at the China Next Generation Internet (CNGI) and China Education and Research Network 2 (CERNET2). This RFC emphasizes that this is a specific implementation of IPv4 over IPv6, but any new deployment of an IPv4aaS should use Lightweight 4over6 instead.
In this Public 4over6 method, the CPE is referred to as a 4over6 CE and the central tunnel concentrator is referred to as a 4over6 BR. This method uses public IPv4 addresses for the subscriber and completely avoids any NAT function. Therefore, there is no IPv4 address sharing but the tunnel concentrator still maintains per-subscriber binding state of the subscriber’s public IPv4 and global IPv6 addresses.
Part 3
In the next and final part of this three-part blog series we will continue to look at additional protocols and methods that service providers are using to establish an IPv4 as a Service.
