IPv6 Terminology Definitions

Given the diverse and heterogeneous systems that compose the Internet and the various types of users, distinct parts of a network, Internet Service Providers (ISPs), flows, etc., there is not a single and easy way to categorically express something such as "IPv6-Only". One of the goals of this document is to depict this situation and define a common language to be used in the IETF and other documents, to facilitate conveying the correct understanding of the IPv6 deployment related terms for authors and readers. For example, the term "IPv6-Only" is being used in many IETF documents, without a clear definition of the scope or exact characterization, such as , , and . All the references in this document are about the actual usage of IPv4/IPv6, not the support of those protocols by networks, nodes, and their components. For example, an access network may support both IPv4 and IPv6, however that network might be only "natively" forwarding IPv6 packets if the link(s) used for forwarding are only natively configured for IPv6. IPv4 may be used as well, but IPv4 packets are encapsulated (or translated to) over IPv6. From this perspective, a node connected to such a network is attached to "IPv6-Only" link(s). A network service is considered "IPv6-Only" if it forwards plain IPv6 packets, not IPv4 packets, even if IPv4 is still supported and enabled but not configured neither used in the nodes participating in the service. This document focuses on key terms that are used to denote main IPv4/IPv6 deployment models.

In many cases, the transition of a complete network from IPv4 to IPv6, can't be done overnight or in a single step. Consequently, it is often not possible to reason about a whole network having “single and uniform” state, regarding the IPv4/IPv6 support, at least not in the early IPv6 deployment stages of a network. Even if it might be technically feasible, it is not frequent to deploy new end-site "IPv6-Only" networks, which have no IPv4 connectivity at all, because at the current status of the universal IPv6 deployment, almost every end-site network still needs to be able to access to "IPv4-Only" sites and services. In other words, it might not be commercially viable, however, this will change over the time, and there will be less and less dependency on IPv4-Only end-sites/services. Some networks may have IPv6-Only support for specific purposes or services. For example, a DOCSIS ISP may decide that is worth the effort to get rid of IPv4 for the management network of the cable modems. Also, a network that provides connectivity only to IoT devices, may be IPv6-Only; this is very common in Matter/Thread stub-networks . However, the stub-networks, in general, need to continue supporting IPv4, as there are many devices and applications, in both corporate and end-user networks (smartTVs, IP cameras, etc.), that are IPv4-Only and it is not always feasible to update or upgrade them. Also, if customer devices in a Local Area Network (LAN) are IPv4-Only, they will not be able to access IPv6-Only services. Overall, IPv6-Only services can't be deployed unless it is done in such way that some transition mechanism solves that problem as well (e.g., an IPv6-Only Data Centre, requires Stateless IP/ICMP Translation for IPv6 Data Centre Environments, SIIT-DC ). In IPv6-Only access networks, IPv4 support may be provided by mechanisms that allow "IPv4-as-a-Service" (IPv4aaS), for example, by means of encapsulation and/or translation on top of IPv6. In should be noticed also that server segments are transitioning to IPv6-Only, in enterprise networks, both for servicing internal and external clients. In this case, to support IPv4-Only clients, multiple tools are available, such as stateless NAT64 with Explicit Address Mappings for Stateless IP/ICMP Translation (EAM, ) or SIIT-DC . Consequently, considering the context described above, in order to be precise and avoid confusing readers by omitting necessary details, terminology such as "IPv6-Only" cannot be used in a generic way. Instead, an explicit indication of scope (e.g., what part of the network or which layer of the network stack is being referred to), must be provided. Therefore, it is necessary to define and describe the specific scope of applicability. The word "scope" is used in this precise sense throughout this document.

"IPv4 Native" or "IPv6 Native" means that IP packets run directly over a layer 2 (logical link layer) interface, for example, IEEE 802.3 (Ethernet) link layer, without anything at layer 3 being encapsulated within an IP packet of another IP shim.

"IPv4-Only" in a given scope means that only IPv4 is native in that scope. IPv6 is neither configured or managed in that scope, even if it may be transported (or encapsulated) over IPv4.

"IPv6-Only" in a given scope means that only IPv6 is native in that scope. IPv4 is neither configured or managed in that scope, even if it may be transported (or encapsulated) over IPv6.

"Dual-Stack" in a given scope means that both, IPv4 and IPv6 are native in that scope.

In the case of IPv6-Only scopes, it is common that, to ensure that communications with legacy IPv4-Only scopes are possible, IPv4 packets may be transported over IPv6, typically by means of encapsulation or translation. This can be made explicit by adding IPv4-as-a-Service (IPv4aaS). For example, IPv6-Only with IPv4aaS access network (e.g., 464XLAT , DS-Lite , lw4o6 , MAP-E , MAP-T ).

"IPv6-Mostly" is similar to Dual-Stack, with two additional key elements that allow an endpoint to act as IPv6-Only (). Those elements are a stateful NAT64 () and infrastructure such as DHCPv4 () operating Option 108 (). Optionally, there may be also a DNS64 function (). In doing so, in a Dual-Stack network scope, a mix of IPv4-Only, Dual-Stack or IPv6-Only endpoints are supported, depending on the endpoint's capabilities or configuration. IPv6-Mostly can be seen as a solution to provide IPv4 support on demand. Refer to for more architectural details. Notes: There is no default interpretation regarding the DNS64 availability, so it is necessary to state "with" or "without DNS64" to explicitly qualify the case. When referring to an endpoint, it should also have an embedded CLAT (464XLAT, ) function. Stateful NAT64 prefix(es) should be learned by means of some mechanism, such as PREF64 Router Advertisement (RA) option , Heuristic Discovery / or Port Control Protocol (PCP) .

"IPv6-Only-Strict" in a given scope means that only IPv6 is native in that scope and IPv4 is neither configured or managed, but also not transported (neither encapsulated nor translated) over IPv6. In other words, it means that communication with other endpoints is only possible using IPv6.

The scope can be further qualified providing additional information. A couple of examples are provided in the following subsections.

In some cases, it may be relevant to indicate if referring to the data plane, control plane, management plane or a combination thereof.

APIs can also be IPv4-Only, IPv6-Only, Dual-Stack or Multi-Stack (also supporting non-IP protocols). At the time of writing, networking APIs in operation systems are typically Dual-Stack or Multi-Stack regardless of any usage of IPv6-Only in other scopes. As a result, applications usually operate correctly in any situation, unless if they specifically request a specific AF not exposed. A typical example of a Dual-Stack feature in API scope is the getaddrinfo() function .

The following example diagrams show only a few of the possibilities of different scope combinations. They have been chosen and ordered to follow the most natural approach, that in general, a "full" transition from IPv4 to IPv6 will follow. This doesn't mean that all these transition stages are needed in all the transition cases. All the diagrams use a common notation for the different elements (from top to bottom, so from the ISP network to the endpoints): ISP (Internet Service Provider). Access Link(s). CE (Customer Edge Router). DHCPv4 function, which may be embedded in the CE. It may provide option 108. DNS, which may be embedded in the CE. It represents a DNS resolver or DNS proxy function. It may also provide also the DNS64 function, where indicated. Network Segment(s) (abbreviated as Segment): Represent a link or set of them within the end-site LANs. CLAT function, which may be embedded in the CE and endpoints. PLAT/NAT64 function: A stateful NAT64.

shows a case, where all the scopes are IPv4-Only and IPv6 is not present. This may apply not just to residential and SOHO networks but also to enterprise networks. The access link(s), CE Router, network segment, the endpoint, are all IPv4-Only, so the end-site scope is also IPv4-Only. It is unknown if inside the ISP network there is IPv6, so that scope can't be characterized.

IPv4-Only End-Site

shows a case, where all the scopes are Dual-Stack: The ISP network, the access link(s), the CE Router, the network segment and the endpoint. Consequently both, the end-site scope and the network scope, are Dual-Stack. In this example it is known that the ISP network is Dual-Stack.

Dual-Stack End-Site and Network

shows a very common case, where the ISP deploys IPv6-Only in the access link scope, instead of Dual-Stack, while the subscriber network segments are Dual-Stack. For example, this is the 464XLAT case, which is also very frequent in mobile networks, where User Equipment (UE) and tethered devices remain Dual-Stack; here the UE will function as a router. The CE (or UE) will have a CLAT or equivalent function. The ISP provides the stateful NAT64 (PLAT) function. Endpoints may have a CLAT function, but they may not enable it, because the CE Router already provides that functionality and DHCPv4 option 108 is not enabled/available. So basically, the end-site scope is IPv6-Only with IPv4aaS, the internal segments and endpoints are Dual-Stack and the access link is IPv6-Only. In this example, the ISP network scope characterization is unknown, as there are several possible alternatives to provide an IPv6-Only access link and IPv4 service by means of PLAT/NAT64 and DNS64.

IPv6-Only with IPv4aaS End-Site

shows a case of IPv6-Mostly, which may be implemented in different ways. For example, when used in enterprises, the PLAT function (and optionally the DNS64 function) may be implemented in the enterprise network itself, in order to gain greater control of the configuration. It is important to note that, in this case, the DHCPv4 function needs to support option 108. As a result, a Dual-Stack segment will be able to support both, endpoints using IPv6-Only with a CLAT function (even if they are Dual-Stack), as well as IPv4-Only endpoints or Dual-Stack endpoint without the support of CLAT/option 108. In residential and SOHO networks, typically the PLAT function is located in the ISP network, as well as the DNS64 function. Using IPv6-Mostly in that case, restricts the communication between IPv4-Only hosts and those that are using IPv6-Only mode. This is resolved in enterprise networks by means of an internal PLAT with EAM , SIIT-DC , or other means. Residential, SOHO an enterprise networks could choose an IPv6-Only+IPv4aaS Access Link, so the case becomes a mix of them. As in the previous example, the characterization of the ISP network scope is unknown.

IPv6-Mostly End-Site with Dual-Stack Access Link

shows a case, more common in enterprise networks, when hosts in network segments are able to use IPv6-Only but still is required to have Dual-Stack access links because IPv4-Only endpoints in the Internet need to be reachable or other networks segments may need IPv4, for example if the enterprise network needs to expose some Dual-Stack services to Internet. In this case, DHCPv4 is not needed. Once more, in this example the characterization of the ISP network is unknown. It should expected be, as IPv6 deployment progress, that residential and SOHO networks, will use IPv6-Only Access Links, once incoming IPv4 connections aren't needed any longer.

IPv6-Only End-Site with Dual-Stack Access Link

shows a case, when all the scopes of a network are using IPv6-Only-Strict and IPv4 communications are not possible. This would be the ideal "full transition" stage, which however, is not feasible in most of the cases, as certain destinations in the Internet, that a network still needs to reach, may remain IPv4-Only for a long period of time. This is assuming that the example ISP network is also IPv6-Only-Strict.

IPv6-Only-Strict End-Site and Network

The starting point is understanding the concept of “Native”. For instance, “IPv6 Native” in a given link, for example in an Ethernet segment, means that the link is able to transport IPv6 packets without any encapsulation or translation. Applying the same for “IPv4 Native” in the same link, self-explains that “Dual-Stack” means that both, IPv4 and IPv6 are native in that link. Once that is understood, it is fairly easy to apply the rest of this document terminology in very basic scopes such as endpoint (node, host, instance), interface, link or network segment (for instance, a VLAN). For example, a container with two interfaces, one of them IPv4-Only, the other one IPv6-Only, each connected to different VLANs, which in turn are IPv4-Only or IPv6-Only as well. In this case, there is Dual-Stack at the container scope, however, one interface and VLAN scope is IPv4-Only, while the other is IPv6-Only. A more complex and actually typical example is an ISP network, which has different types of IPv4/IPv6 support in different parts of the network. Typically, it will be some form of Dual-Stack support in the core, upstream connections, and BGP, but offers to customer end-sites IPv6-Only access, possibly with IPv4aaS. It is not common, but there might be cases where it is "IPv6-Only access data plane" and "Dual-Stack access control plane" or "IPv4-only access out-of-band management". As of this writing, most end-user networks and endpoints need to support IPv4, due to many global resources being only available over IPv4. Transition technologies may allow islands to be connected to the broader Internet over an IPv6-Only access networks acting as an underlay for legacy IPv4 traffic. An organization aiming to switch to an IPv6-Only end-user network will need to ensure that: All host/routers are capable of IPv6-Only operation. All off-network resources are available over IPv6 (either as IPv6-Only or Dual-Stack). For this reason, IPv6-Mostly seems an adequate solution to easily, gradual move towards IPv6-Only (and IPv6-Only-Strict). In the case of data-centres, "IPv6-Only compute nodes" may be provided with IPv4 external communication, using SIIT-DC. In this case, there is an "IPv6-Only data-centre" when speaking about the internal LANs (anything behind a Border Relay), but "Dual-Stack data-centre upstreams". In the case of a mobile network, the UEs (User Equipment, e.g., mobile phones) have "IPv6-Only PDP Context or PDU session", those UEs may offer "Dual-Stack Tethering" and "Dual-Stack to the UE applications"(by means of CLAT), and this is possible thanks to the support of a stateful NAT64 in the ISP network. The stateful NAT64 is a "Dual-Stack service", which has an "IPv6-Only transport to the UEs". In the case of an enterprise network, there may be a mix of VLANs or network segments offering Dual-Stack, IPv6-Only and IPv6-Mostly. So in this case, it becomes clear by using "Dual-Stack VLAN x", "IPv6-Only VLAN y" and "IPv6-Mostly VLAN z". IPv6-Only servers, IPv6-Only data-centres and IPv6-Only cloud environments are entirely possible as of this writing, as long as: All host/routers are capable of IPv6-Only operation. All accessed resources (DNS resolvers, NTP servers, software update servers, network management services, and other external resources) are available over IPv6 (either IPv6-Only or Dual-Stack). All inbound communications are capable of IPv6, either due to all external endpoints supporting IPv6 or due to all legacy IPv4 traffic being relayed through a gateway (such as reverse proxy, SIIT-DC gateway, CDN, etc.). Data-centres and cloud environments may also support IPv6-Only subnets/interfaces and, at the same time, internal Dual-Stack in other subnets/interfaces, even if using non-globally reachable IPv4 addresses, such as those listed in Section 2.2.2 of , which maybe also using NAT44.

This document provides definitions of various terms that are meant to unambiguously characterize specific deployment cases and would help tweak operational guidance for specific scopes.

This document does not have any specific security considerations.

This document does not have any IANA considerations.

The author would like to acknowledge the inputs from Tim Chown, Noah Maina, Lee Howard, Azael Fernandez Alcantara, Marcos Sanz Grosson, Robert M. Hinden, Henri Alves, Brian E. Carpenter, Erik Nygren, Jeremy Duncan, David Farmer, Nick Buraglio, Stan Barber, Goetz Goerisch, Mark Andrews, Michael Richardson, XiPeng Xiao, Chenhao Ma, Philipp Tiesel, Wilton Arthur Poth, Tom Petch, Spiro Stathakis, Andrew Yourtchenko, Nico Schottelius, Michael Sweet and, Mohamed Boucadair.