1
0
mirror of https://github.com/becarpenter/book6.git synced 2024-05-07 02:54:53 +00:00
becarpenter-book6/3. Coexistence with Legacy IPv4/3. Coexistence with Legacy IPv4.md
Brian E Carpenter ac61e7ac46 Small additions
Added IPv6 literals in URLs to Addresses

Started section on obsolete coexistence techniques

Mention backwards incompatibility in Coexistence intro
2022-09-29 15:38:26 +13:00

3.6 KiB

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 capitol 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. Regardless, the reasonings are less important than the details necessary to support a dual-stacked environment.

As networks migrate away from IPv6 and into an IPv6-only environment, they will undoubetedly 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 posess 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. With that acknowledgment, it should be expected that there will exist one or more enclaves that differ in their network addressing schema.

  • IPv4 only enclaves Areas where IPv6 simply is not possible or desirable for compliance, technological, policy, budgetary, or other strategic reason 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.

  • IPv4-IPv6 dual stack

    • Supporting ships in the night protocols
      • Consistent policy
      • Monitoring and measurement
      • Multi-topology within the internet

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. 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 means that hosts and routers are able to handle both IPv4 and IPv6 at the same time. 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 box.

Dual stacks

Tunnels

Translation

Obsolete techniques

Back to main Contents