In the first part of this blog series we covered the rationale behind why organizations may prefer to run a single-protocol IPv6-only core. However, service providers must continue to provide service to subscribers who have legacy IPv4-only devices. The second part of the blog delved into several ways ISPs can create an IPv4 as a Service offering without subscribers even realizing. In part 2 we covered GRE, DS-Lite, Lightweight 4over6 (an adaptation of DS-Lite), and the obscure Public 4over6 method. In this third and final blog in this three-part-series, we will cover the remaining techniques that service providers are actively deploying for their IPv4 as a Service.
NAT64/DNS64
When organizations consider their options for using an IPv6-only core network to facilitate legacy IPv4 applications, they frequently turn to NAT64 and DNS64. These are two different functions that cooperate to enable an IPv6-only node to reach IPv4-only services. The IETF has standardized these two methods in “Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers” (RFC 6146) and “DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers” (RFC 6147). The IETF has also published “NAT64 Deployment Options and Experience” (RFC 7269).
The way this works is that an IPv6-only node sends a DNS query for the IPv4-only service it wishes to reach. Next, the NAT64 proxy function performs the IPv4 DNS resolution and returns an IPv6 address with the IPv4 destination embedded within. This typically uses the IPv6 prefix 64:ff9b::/96 (RFC 6052) where, for example, a query for b.resolvers.Level3.net results in 4.2.2.2 which then becomes 64:ff9b::0402:0202. The IPv6 node then initiates an IPv6 connection to the 64:ff9b::0402:0202 address. Next, the NAT64 service intercepts this and changes the connection to an IPv4 connection to the embedded 4.2.2.2 destination. The NAT64 function then brokers a stateful connection from that IPv6-only node to that IPv4-only service. Furthermore, native IPv6 connections completely bypass these NAT64 and DNS64 functions and are directly forwarded to the Internet natively.
The DNS64 function and NAT64 function can be provided by separate systems. An Infoblox NIOS appliance can perform the DNS64 function and forming the IPv6 DNS response. Large-scale routers and translation systems, such as those from A10 Networks, can operate as the NAT64 router. Because the NAT64 function is stateless, the router does not need to maintain a state table of all current client connections. The IPv6 address of the source client uniquely identifies that client. The IPv4 address embedded within the IPv6 address offers enough breadcrumbs to help it find the IPv4-only target server. An enterprise could establish a NAT64/DNS64 service at a much smaller scale than a service provider would construct.
This sounds great, but there are some disadvantages. For example, NAT64 only works for applications that begin with a DNS lookup and it breaks applications using IPv4 addresses in the URL (embedded literals) (e.g. http://192.168.1.1/index.html) or when applications make direct IPv4 socket connections. NAT64 also doesn’t work for domain names that have IPv4-only DNSSEC signed domains. Furthermore, approximately 15% of applications break with IPv6 native or break with NAT64: e.g., applications such as Spotify, WhatsApp, Skype, SIP, RTSP, H.323, XMPP peer to peer, (among other NAT64-breakage occurrences). NAT64 and DNS64 are also not suitable to the IPv4-only systems that might exist in broadband subscribers’ homes. These IPv4-only devices can only perform DNS lookups exclusively over IPv4 and would not be able to interact with a DNS64 service, which is the linchpin to the whole system’s functionality.
464XLAT
It is evident that many of these IPv4aaS methods use some form of translation (XLAT for short). The IETF produced an architecture for carrying IPv4 packets across an IPv6-only network and called it “464XLAT: Combination of Stateful and Stateless Translation” (RFC 6877). 464XLAT leverages RFC 6146 (see the above section on NAT64) and RFC 6145 (now RFC 7915) to create an IPv4 as a Service. 464XLAT may optionally use DNS64, but it is also designed to work without that function.
464XLAT uses a customer-side translator (CLAT) and a provider-side translator (PLAT). As a result, IPv4 packets are double-translated along their journey to the Internet. 464XLAT uses the same RFC 6052 64:ff9b::/96 IPv6 prefix as DNS64/NAT64. Like NAT64/DNS64, 464XLAN is an IPv4 service extension method that works for client-server connections and is not suited to IPv6 peer-to-peer communication.
464XLAT has had some traction from carriers and mobile providers like T-Mobile and is available on Android and Windows mobile devices.
Mapping of Address and Port (MAP)
Another IPv4aaS mechanism is Mapping of Address and Port (MAP). The MAP architecture has a MAP Customer Edge (CE) device at the subscriber’s location and a MAP Border Relay (BR) within the ISP network. MAP domains are groupings of CEs and BRs that have a common policy, address prefixes, and mapping rules configuration. MAP provides a stateless algorithmic mapping of an IPv6 prefix to an IPv4 address plus port range. This method leverages the “The Address plus Port (A+P) Approach to the IPv4 Address Shortage” (RFC 6346) method of combining the 32-bit IPv4 address with the 16-bit TCP/UDP port space resulting in a 48-bit address space. One of the key benefits of MAP is that it doesn’t require a stateful central CGN/LAN translation system, which greatly increases its scalability.
MAP comes in two forms: “Mapping of Address and Port with Encapsulation (MAP-E)” (RFC 7597), and “Mapping of Address and Port using Translation (MAP-T)” (RFC 7599). The MAP-E method encapsulates the IPv4 packets in IPv6 packets using the technique found in the RFC Generic Packet Tunneling in IPv6 (RFC 2473). MAP-E may be preferred by a service provider that does not control the customer CPE hardware or its software. MAP-T method translates the IPv4 header fields into the IPv6 header fields using Stateless IP/ICMP Translation (SIIT) (RFC 7915). MAP-T may be preferred by a service provider that offers a managed modem/router service and can customize the CPE so that it maintains the client connection state. At the North American IPv6 Summit 2015, Jordan Gottlieb of Charter Communications gave an excellent presentation titled “Mapping of Address and Port (MAP) an ISPs Perspective” that covers how MAP-E and MAP-T work.
MAP is gaining traction in the industry and has significant adoption momentum. The IETF is continuing its work on MAP and has documented MAP Deployment Considerations. Vendors like Cisco and A10 Networks have deployed MAP into their service-provider class products. Service providers are experimenting and deploying MAP in their environments. For example, China Education and Research Network (CERNET) is also working on an IPv4aaS design that uses IVI/MAP-T.
4rd
Another recent addition to these IPv4aaS mechanisms has been documented in the IETF RFC titled “IPv4 Residual Deployment via IPv6 – A Stateless Solution (4rd)” (RFC 7600). This technique is a reversal of the old IPv6 deployment method defined in the IETF RFC titled “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) Protocol Specification” (RFC 5969). The idea here is that TCP and UDP payloads can be carried in IPv4 or IPv6 packets. Legacy IPv4 packets could just have their payload stripped out and then carried in an IPv6 packet across an IPv6-only core network, reversing the process at the ISP’s Internet edge. This would provide a stateless method that also leverages the Address plus Port (A+P) approach detailed in RFC 6346. This method required a customized Customer Edge (CE) device with the 4rd functions in it and a Border Relay (BR) in the ISP network that performs the 4rd NAT64+ function.
Stateless IP/ICMP Translation for IPv6 Data Center Environments (SIIT-DC)
The above-mentioned techniques have been focused on providing IPv4 services to subscribers. However, these same techniques can be applied in a data center environment where there are legacy IPv4 servers or virtual machines connected to an IPv6-only data center core. To support this concept, the IETF has published “SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments” (RFC 7755). SIIT-DC leverages the IETF standard IPv6 Addressing of IPv4/IPv6 Translators (RFC 6052) to perform Explicit Address Mapping (EAM) of the server’s IPv4 address to its IPv6 address. An alternative address translation technique is documented in the IETF draft titled “Explicit Address Mappings for Stateless IP/ICMP Translation”. The breadcrumb of the embedded IPv4 address allow for the SIIT-DC Border Relay (BR) function to be stateless. Also, the Explicit Address Mapping (EAM) algorithm has been documented in RFC 7757 and the Stateless IP/ICMP Translation (SSIT) algorithm has been updated by RFC 7915.
A good explanation of this IPv4aaS method was presented at RIPE69 in 2014 by Tore Anderson “SIIT-DC: IPv4 Service Continuity for IPv6 Data Centres”.
There is a complementary standard titled “Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode” (RFC 7756). This standard defines a SIIT-DC Edge Relay (ER) that is close to the IPv4-only system and reverses the packet translation function of the SIIT-DC Border Relay (BR). This ER makes the application or server perceive the IPv4 communications as native.
Locator/ID Separation Protocol (LISP)
LISP (RFC 6830) is a network architecture and protocol that separates the namespaces used in IP addresses that represent the network’s location and that of the endpoint attached to that network. By separating the two namespaces (Routing Locators (RLOCs) and Endpoint Identifiers (EIDs)) this creates a level of abstraction that facilitates mobility, deals with address exhaustion, adds scalability of routing tables, and handles traffic engineering. LISP is a map and encapsulation (map and encap) protocol that uses a mapping and control function to provide abstraction by using UDP port 4342. It then encapsulates data packets using UDP port 4341. LISP works with both IP versions and can provide portability and coexistence, easing the transition to IPv6. The advantage of LISP is that it doesn’t require any changes to the end-user client. The disadvantages of LISP are the latency of the mapping and control plane function and the fact that it is a tunneling method. The IETF LISP working group is continuing to evolve this protocol.
The encapsulation mechanism in LISP could be used to carry the packets of one IP version in the same or different IP version. LISP could be used to carry IPv4 packets “Over the ToP (OTP)” of anan underlay IPv6-only service provider network . The mapping and control mechanisms in LISP could direct these packets to the closest Internet egress point to minimize the backhaul latency commonly seen in IPv4aaS methods. Presentations from Brian Field at Comcast indicate that they are considering using LISP and MAP with OpenStack and SDN to create their IPv4aaS solution.
DNS Forwarding and IPv4aaS
DNS is a critical component to making the Internet and network applications function properly and IPv4aaS services offer no exception to this rule. From the description of the IPv4aaS methods described above, NAT takes place either at the CPE or in the ISP infrastructure and this may pose a risk to proper DNS operations.
Our friends from Comcast John Jason Brzozowski and Paul Ebersman (an Infoblox alum) created this IETF draft titled “DNS Forwarding and IPv4aaS“ that describes these risks. For example, older Microsoft XP and Server 2003 systems are only capable of performing DNS queries over IPv4 transport. Translation of the DNS queries can cause problems for geolocation and may increase latency of connections due to slow query responses.
The draft also lists recommendations and best practices such as: using dual-protocol DNS servers, ensuring subscribers have dual-protocol connectivity, making sure hosts prefer DNS over IPv6 transport, and making sure DNS queries are not modified as a result of translation functions.
Summary:
Today, it may be nearly impossible to go IPv6-only in a home network. We all have embedded devices in our possession that are IPv4-only. However, every year IPv6-capable devices are replacing these old IPv4-only devices and more subscriber connections are becoming dual-protocol. Even enterprises would want to consider how they could benefit from constructing an IPv6-only infrastructure. At the scale of the large service provider’s networks, the advantages of running a single-protocol core are significant.
Most of these IPv4aaS techniques tunnel IPv4 packets within IPv6 packets and we have all observed time and again that tunneling techniques are not optimal: The downsides of any type of tunneling include issues with packet MTU, fragmentation, security, as well as operational troubleshooting burden. As more and more subscriber IPv4 packets are tunneled, the end-user-experience will deteriorate making native end-to-end IPv6 perform better and become the preferred transport protocol.
Most of these IPv4aaS techniques also perform translation of IPv4 addresses. Translation is also a sub-optimal transition mechanism and as the movie title reaffirms, something is always Lost in Translation. For instance, the IPv4 header and addressing format do not easily map to the IPv6 header and addressing format. The IPv4aaS methods that require translation could cause negative subscriber experiences.
The mechanisms that are taking place within an IPv4aaS offering disprove the adage that “what you don’t know, can’t hurt you”. The sum of these issues provide weight to the case that the only viable near-term and long-term strategy is to deploy IPv6 and move quickly to IPv6-only.
