6.6 KiB
Translation
When an operator wants to reduce infrastructure costs by running a single protocol, IPv6, instead of a dual stack, the strategic approach is to minimize IPv4 presence in the network. Unfortunately, some resources are available only on IPv4 and some client applications may require IPv4. Hence, a pure IPv6-only environment is unrealistic for the foreseeable future. In some situations, tunneling (as described above) is sufficient, but in others translation between IPv6 and IPv4 is unavoidable. For example, when providing IPv4 as a Service (IPv4aaS), a typical scenario will:
- Let IPv6 native traffic flow directly between the client and the server.
- Translate the traffic of local IPv6 clients to remote IPv4-only servers, using a centralized NAT64 device.
- Encapsulate literal IPv4 address requests into IPv6 on the client then decapsulate and translate it on the centralized NAT to access the IPv4 server.
Terminology
-
SIIT (Stateless IP/ICMP Translation Algorithm). This is also known simply as "IP/ICMP Translation Algorithm" [RFC7915], [RFC6144]. It translates IPv4 packets to IPv6 format and the opposite. Note that translation is limited to basic functionality, and does not translate any IPv4 options or any IPv6 extension headers except the Fragment Header. Technically the mechanism is stateless (i.e., it relies on no stored information) but in practice it is used as part of stateful mechanisms.
-
NAT64 is SIIT with address translation between IPv6 clients and IPv4 servers.
-
464XLAT (Combination of Stateful and Stateless Translation) [RFC6877] is SIIT plus address translation from IPv4 clients to IPv6 transport and back to IPv4 servers.
- CLAT is the client side translator in 464XLAT.
- PLAT is the provider side translator in 464XLAT.
-
The final two items have nothing to do with IPv6/IPv4 co-existence but are included here for completeness:
-
NPTv6 (IPv6-to-IPv6 Network Prefix Translation) is an experimental technique [RFC6296] whose applicability is debated.
-
NAT66 is not defined by the IETF and, given the vast supply of IPv6 addresses, is not generally considered useful enough to overcome its disadvantages, which it shares with classical IPv4 NAT [RFC5902].
-
Further details
Point 2 listed above evidently needs stateful NAT64 [RFC 6146].
Additionally, the client could be triggered to start a cross-protocol connection. For this, the client should be told that the server is available on the IPv6 Internet. DNS64 [RFC 6147] can do this on the ISP side. It can synthesize an IPv6 address from an IPv4 address, by adding a particular static prefix. When the client asks for www.example.net (which only has an A record in the global DNS), DNS64 will synthesize and return an AAAA record. Deployment of DNS64 involves complications and is not necessary in the presence of IPv4-as-a-service.
Point 3 above may be implemented (in addition to points 1 and 2) by various technologies:
- 464XLAT (Combination of Stateful and Stateless Translation) [RFC 6877]
- DS-Lite (Dual-Stack Lite) [RFC 6333]
- lw4o6 (Lightweight 4over6) [RFC 7596]
- MAP E (Mapping of Address and Port with Encapsulation) [RFC 7597]
- MAP T (Mapping of Address and Port using Translation) [RFC 7599].
RFC 9313 has a good overview and comparison of these technologies.
The following figure illustrates such a scenario.
-
464XLAT is the widely preferred translation technology now because it has a natural synergy with NAT64 (which is highly desirable by itself) and because it is the only solution supported on mobile devices. The centralized NAT64 engine is called PLAT, and is the same [RFC 6146] as for ordinary NAT64. The client side is called CLAT, and is typically a stateless NAT46 translation [RFC 7915]. A good analysis of deployment considerations is in RFC8683, from which an operator might conclude not to implement DNS64, since IPv4 clients can simply use the normal DNS A records and the IPv4 service as if it was native.
-
DS-Lite was the most popular technology for a considerable period of time.
-
Lw6o4 has not gained significant market adoption.
-
Technically, MAP-E and MAP-T are stateless with significant related advantages: no need for logs, possible to implement on routers. But MAP needs a rather big IPv4 address space to be reserved for all clients (even when disconnected) and MAP is not available by default on the majority of Mobile OSes. As a result, MAP has a small market share.
Network Prefix Translation (NPTv6) [RFC 6296] is a special technology available only in IPv6. It exchanges prefixes between “inside” (private network) and “outside” (public network) of the translation engine and modifies the IID. The IID is changed so as preserve the transport layer checksum despite the prefix change. Hence, it is transparent for all transport layer protocols. In principle it would, for example, allow a site using ULA addresses [2. Addresses] to communicate with global IPv6 addresses, but with some of the disadvantages of classical IPv4 NAT. The principal difference between NPTv6 and classical NAT is that it permits connection initiation in both directions. However, it is not fully transparent for applications that embed IP addresses at high layers (so-called “referrals”). Hence, it cannot be considered end-to-end transparent.