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").
Conclusion
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.
Comments 9
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Ross Chandler •
Apple's support for IPv6-only in iOS is incomplete because it does not cater for the case of tethered IPv4-only devices where the iPhone's uplink is IPv6-only. With a pure IPv6-only wireless connection to the phone Apple only provide handset not tethering support for IPv4 literal addresses by bump-in-the-api synthesis of IPv6 addresses to go through the operator NAT64. To provide tethering support to IPv4-only devices with iOS it is still necessary for the iPhone to request IPv4 or IPv4v6 from the carrier network which is counter to the objective of a pure IPv6-only connection. Operators typically either have a combined handset and tethering APN or separate handset and tethering APNs. In the example on T-Mobile US they have separate APNs so their handset traffic is pure IPv6-only but the tethering APN is dual-stack IPv4v6. Operators with a combined APN are out of luck if they want to support iOS using an IPv6-only APN. Their only option is to support IPv4v6 which is not what Apple themselves recommend.
Jordi Palet Martinez •
I think you may be partially right in the sense that, if they really don't use the bump-in-the-api for the tethering as well, but it may be some time ago, not now, as they use bump-in-the-host in the most recent versions of the OSs, as part of the Happy Eyeball v2, which is becoming an RFC in a matter of days: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis Anyway, I think Apple folks confirmed to me (I will try to verify and come back here), that they do bump-in-the-host also for the tethering. What I don't agree is that you actually need multiple APNs. You can configure a *single* APN for multiple type of devices/configurations, with different PDP types. I've explained that in one of my slides (41) in the recent https://ripe75.ripe.net/presentations/44-ipv6-cellular_v6.pdf.
Jordi Palet Martinez •
I just confirmed my previous response on this with Apple. If the handset gets and IPv6-only access from the operator, and requires tethering for IPv4 devices, they have a profile for enforcing one additional PDP context for the IPv4 devices, which is typically a PDP type IPv4v6 (dual-stack). However, and this is the good news, they are working in including CLAT, so we will have support for 464XLAT as in Android, so the IPv6-only (type IPv6) PDP context will make it.
Ross Chandler •
Jordi, If Apple are now going supporting IPv4 tethering over an IPv6-only PDP/PDN connection this is good news as it will increase the number of operators that can deploy IPv6. Previously they provided no encouragement on v6ops that they were going to it. Regarding the distinction between dual APN and dual PDP/PDN connection into a single APN that is possible. I did not also state that alternative because a full list was not directly relevant to the absence of a CLAT in iOS. So I don't think it is a point were "disagreeing" on.
Ross Chandler •
Coming back on the separate tethering + handset APNs versus separate PDP/PDN connections into a common APN. One reason some operators separate it into two APNs is because they have or have had different policies for tethered and handset traffic. Others do it all in the one APN. Changing APN design can be difficult especially if charging and packet core teams are separate. Anything the handset vendors can do to make their devices accommodative of more situations will make deployment easier to a greater number of operators.
Abraham Y. Chen •
It may seem to be after the fact. However, with so many twists involved in rolling out IPv6 because it was not designed with the very basic engineering discipline of being backward compatible with IPv4, we really should look at the whole thing seriously one more time. Below is the result of a study that we accidentally ventured into. It utilizes nothing more than the original RFC791 and the long-reserved yet hardly-utilized 240/4 address block. We call it EzIP (phonetic for Easy IPv4) and submitted a draft to IETF: https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03 Basically, the EzIP approach will not only resolve IPv4 address shortage issues, but also largely mitigate the root cause to cyber security vulnerabilities, plus open up new possibilities for the Internet, all within the confines of the IPv4 domain. In fact, this scheme may be deployed "stealthily" at isolated sites where needed. These should relieve the urgency to deploy the IPv6 for an appreciable length of time. Any thought or comment would be much appreciated. Abe (2018-07-13 16:39)
Hide replies
Jordi Palet Martinez •
I really think is too late to consider other approaches. IPv6 is already there and artificially extending IPv4 life is a non-sense in my opinion. We just need to make sure that IPv6 continues being deployed and customers with IPv4 needs can also get that service, even if this is somehow limited.
Hide replies
Abraham Y. Chen •
Hi, Jordi: 0) There is still time. 1) Please have a look at the following discussion thread on the "state of IPv6", http://www.circleid.com/posts/20190529_digging_into_ipv6_traffic_to_google_is_28_percent_deployment_limit/ 2) Then, you may like to have a look at the feasibility demonstration report below about our proposal for expanding IPv4 address pool, etc.: https://www.avinta.com/phoenix-1/home/RegionalAreaNetworkArchitecture.pdf These should provide some material for furthering the dialog. Abe (2020-08-29 22:31 EDT)
Hide replies
Jordi Palet Martinez •
The Ericsson publicacion has a lot of wrong misconceptions as starting point and consequently, anything that starts from there, is broken. When and if IETF approves the use of 240/4, and all the vendors start having firmware updated to users to support it, then we can talk about this. Meanwhile, the only solution *BEING* deployed, is IPv6.