We are starting to hear “IPv6-only” more often. However, it doesn't seem to be clear what exactly this means. I will attempt to explain it in this article.
Due to the nature of the Internet and the different types of users, parts of a network, providers, traffic flows, etc., there is no single and easy way to categorically say "IPv6-only".
In most cases, the transition from IPv4 to IPv6 is not something that can be achieved overnight. Consequently, we are unable to talk about a whole network having a "single and uniform" status regarding IPv6, at least not in the early deployment stages of an operator network.
Some networks choose to implement a fully dual-stacked network, end-to-end. Others, however, must consider means to relieve pressure on their IPv4 inventory. In order to achieve that, they may opt to deploy IPv4 in fewer places. This leads towards the now-commonplace situation that networks have IPv6 and IPv4 assigned in different places for different uses.
In this article, we'll review some of these approaches.
Domain-specific IPv6-only Networks
It is possible to deploy an IPv6 network that doesn't have any IPv4 connectivity at all. However, this isn't done very often (yet), because at the current phase of the universal deployment of IPv6, almost every network still needs to provide some kind of "access" to IPv4 sites. It is not feasible for most of the operators to tell their customers "I can provide you with IPv6 services, but you will not be able to access all content and applications available on the Internet, because some of them don't support IPv6, so unfortunately you will miss all content that is available via IPv4 only".
So, what often happens now is that some networks have IPv6-only support for specific purposes. For example, a DOCSIS provider may have decided that it is worth the effort to get rid of IPv4 for the management network of their cable-modems, or a network that provides connectivity only to IoT devices may be IPv6-only.
Another type of network that is usefully IPv6-only with no IPv4 access is a test network for developers.
Providing access to IPv4-only devices
Despite the IETF and vendor efforts to reduce reliance on IPv4, there are many devices, typically in the “end-networks”, in both corporate and end-user environments (printers, smart TVs, IP cameras, security devices, etc), that are IPv4-only. Often IPv4 needs to be provided for these devices, for instance because there is no (easy) way to upgrade the firmware. The vendor wants to sell new models of the device or the vendor isn't even on the market anymore.
Assisting IPv4-only applications
Relatedly, there are situations in which devices are dual-stack, the access network is natively IPv6-only, but some of the applications running on those devices are IPv4-only. If those applications are using IPv4 literals or they don't make the best use of networking APIs, simple translation technologies to get access to the IPv6-only network may fail (as they aren't using DNS supporting translation to IPv6). As indicated in the previous section, it may be not be possible to upgrade these devices or apps.
Providing access to IPv4-only services
It is true that IPv4 support can be done using tools developed by the IETF as part of the transition mechanisms (see the recent Tutorial at RIPE 75). So, there can be situations in which most parts of the operators (or even enterprise) networks are IPv6-only. However, some kind of IPv4 support will still be required, which we are calling "IPv4-as-a-service". That means that IPv4 is transported “somehow” (for example, by means of encapsulation or translation or a mix of both), on top of the existing native IPv6-only infrastructure.
Here with "IPv4-as-a-service" I am referring to networks that do not run IPv4 natively (it is removed automatically if there is not IPv4 traffic). It doesn't mean "service" as in "paid service".
Consider cellular networks: because of the nature of the applications in those networks, it is easier to have more control on how the developers work, and for example, mandate IPv6 support in order to allow the apps to be installed on the smartphones. Apple is an important example here. What that means is that it is possible to have an IPv6-only access network for a complete cellular operator network. It may even be possible to make the core and other parts of the operator network IPv6-only if all the operation and management is done over IPv6. However, as soon as any application on the smartphone requires access to IPv4-only end sites (for example web servers), there must be some kind of IPv4 support in that network, for example PLAT (NAT64 and optionally DNS64) and consequently, some IPv4 addresses to be shared, which allow the IPv4-only traffic flows to end sites by means of the IPv4 upstream providers/peers.
Now, if those smartphones in an IPv6-only cellular network provide tethering (sharing of a smartphone Internet connection with other devices), they may also need to "transport" IPv4 (those devices may be IPv4-only) in a seamless way over the IPv6-only access network.
One way to do that is by embedding the 464XLAT client (CLAT) in the smartphone. 464XLAT is a technique that allows providing IPv4-as-a-service on IPv6-only access networks.
We can extrapolate the example above from smartphones to LTE routers or CEs (Customer Edge Routers) with any non-cellular technology (FTTH, xDSL, Cable, Wireless ISP, etc.). In the end, no matter what access technology is used, we can't talk in the customer LANs about IPv6-only because we often must still provide some sort of IPv4 support ("IPv4-as-a-service").
Consequently, if we want to be precise and avoid confusing others, we can’t use the terminology "IPv6-only" in a generic way. Instead, we need to define what part of the network we are referring to.
So we could say “IPv6-only access network”, for example, which is going to be the most common case in the next few years if the WAN connection is only forwarding native IPv6 (and consequently, is not forwarding native IPv4 traffic). As said, IPv4 can still be transported by the IPv6-only link “as-a-service”.
This article is based in my Internet Draft IPv6-only Terminology Definition. Your input to this draft will be very relevant for this IETF work.