becarpenter-book6/3. Coexistence with Legacy IPv4/3. Coexistence with Legacy IPv4.md

# 3. Coexistence with Legacy IPv4

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 not a design goal.__ The only solution was a new
version number, and in 1994, the next free number was 6. (IPv5 was a
failed experiment.)

Given that fundamental incompatibility, the designers of IPv6 decided to
meet a number of requirements that IPv4 could never satisfy, and to
develop a co-existence model from the start. 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:

1. Although a few years old,
   [RFC6180](https://www.rfc-editor.org/info/rfc6180) gives useful
   guidelines for deploying various IPv6 transition mechanisms.

1. 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
   [RFC9313](https://www.rfc-editor.org/info/rfc9313).

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

- 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 whatever
is out of scope.


<!-- Link lines generated automatically; do not delete -->

## [Dual stack scenarios](Dual%20stack%20scenarios.md)

## [Tunnels](Tunnels.md)

## [Translation](Translation.md)

## [Obsolete techniques](Obsolete%20techniques.md)

## [IPv6 primary differences from IPv4](IPv6%20primary%20differences%20from%20IPv4.md)

### [<ins>Back to main Contents</ins>](../Contents.md)