The notion of a utopian IPv6-only world is a noble goal. However, as with any tectonic change, it happens slowly, and differing elements exist simultaneously. As such, expectations should be set that in many cases coexistence with legacy IPv4 is the norm, and while it should be considered a transitional state, it may exist for extended or indefinite periods of time. Reasoning for coexistence will vary and is typically only locally relevant to a given environment. It may be due to the requirement for legacy hardware with no IPv6 support that requires capital expenditure beyond the budget of an organization, such as a specialized piece of operational technology, or it may be due to lagging compliance regulations that have not tracked current technology standards. It may simply be the conclusion from a cost/benefit analysis. Regardless, the reasonings are less important than the details necessary to support a dual-stacked environment.
Before describing the specific techniques for IPv6/IPv4 coexistence -- dual stacks, tunnels, and translators -- it is useful to answer a basic question that newcomers sometimes have: Why isn't IPv6 backwards compatible with IPv4? The answer is quite simple: this is a mathematical impossibility. IPv4 contains no provision for any address length other than 32 bits. Stretching the address length by only one bit, let alone by 32 or more bits, would completely break all existing IPv4 implementations. Therefore, backwards compatibility at the IP packet level was impossible, so was not a design goal.
Given that fundamental incompatibility, the designers of IPv6 decided to meet a number of requirements that IPv4 could never satisfy. As a result, the IP packet header was redesigned in the light of experience. This has no impact except on the low-level code that actually processes a raw packet.
Another basic decision was to develop a co-existence model from the start, since it was clear that a quick transition to a new version of IP was unthinkable. In short, a dual stack originally meant that hosts and routers were able to handle both IPv4 and IPv6 at the same time. Recently, this simple view of dual stacks has been complicated by the introduction of "IPv4 as a service", as discussed below. Tunnels means that IPv6 hosts can talk to each other over an IPv4 network, by encapsulating their packets, and vice versa. Translation means that, in a limited way, an IPv6 host can talk to an IPv4 host via a translation mechanism. The following sections discuss those three methods of co-existence in more detail. Later sections list some mechanisms that are no longer recommended, and the main differences between IPv4 and IPv6.
We first give two quite general references for this complex topic:
-
Although a few years old, RFC 6180 gives useful guidelines for deploying various IPv6 transition mechanisms.
-
A common tactic today for operators wishing to simplify their infrastructure is to provide IPv4 as a service over the top of an underlying IPv6 layer. Various ways to achieve this are described in RFC 9313.
As networks migrate away from IPv4 and into an IPv6-only environment, they will undoubtedly discover unexpected hurdles consisting of half-completed protocol stacks, lack of capabilities, and unexposed configuration knobs. These will almost certainly be discovered in the periphery of the network. Elements such as power controllers, optical multiplexing platforms, mechanical control systems, and other speciality hardware tend to possess a very long mean time to replacement, and a slow to modernize firmware offering. Operational technologies and SCADA systems are also very slow to update and may also live in the network for many years, if not decades. In domestic networks, old network appliances may persist for many years. With that acknowledgment, it should be expected that there will exist one or more enclaves that differ in their network addressing schema.
To summarize the coexistence scenarios, we have:
-
IPv4 only enclaves:
Areas where IPv6 simply is not possible or desirable for compliance, technological, policy, budgetary, or other strategic reasons may operate as an IPv4-only or Legacy IP enclave. This may be the result of migration happening around the enclave, or it may be an intentionally created segment for housing legacy services, devices, or application stacks. It is important to accept that there may be long-lived enclaves where legacy IPv4 is a hard requirement. This fact should inform policy, however, but in an ideal situation will not necessarily define it.
-
IPv4-IPv6 dual stack "on the wire"
- Supporting "ships in the night" protocols
- Consistent policy
- Monitoring and measurement
- Multi-topology within the Internet
- Widely deployed but requires dual management
- Supporting "ships in the night" protocols
-
IPv6 only infrastructure networks
- Native access to IPV6 resources
- Requiring access to IPv4-only resources via IPv4 as a service
- Reduced management complexity
- Still presents a dual stack to the upper layer API
In the long term, it is conceivable that all useful resources on the Internet will be accessible by IPv6, in which case IPv4 as a service could be discontinued, leaving IPv4-only enclaves to fend for themselves. However, there is no time scale for when this might occur.
This chapter is about IPv6/IPv4 coexistence, because IPv6-only enclaves can only be part of the whole Internet if they support at least one coexistence mechanism. Theoretically, such an enclave could be connected to the Internet by an application layer gateway, but we do not describe this further. An IPv6 network where there is no coexistence mechanism whatsoever is out of scope.