IPv6 transition mechanisms are used to allow IPv6-connected hosts to access IPv4-only Internet resources and hosts. Some IPv6 transition mechanisms were first defined in RFC 1933 but this RFC has been obsoleted by RFC 4213.
There exists an ongoing process for a IPv4/IPv6 translation framework as described in draft-baker-behave-v4v6-framework. It also explains the background of the problem and some expected uses. Another document describes the translation proposal draft-baker-behave-v4v6-translation. There are two concrete protocol proposals that have much in common: NAT64/DNS64 and IVI. Also Dual Stack Lite has been proposed.
There are also some implementations for proposed solutions:
- pTRTd user-level NAT-PT
- naptd user-level NAT-PT
- IVI (second page)
- NAT64
A good text comparing all proposals is draft-wing-nat-pt-replacement-comparison.
Stateless IP/ICMP Translation (SIIT)
RFC 2765 defines a mechanism known as Stateless IP/ICMP Translation, or SIIT. SIIT is a mechanism which translates between IPv6 packet headers and IPv4 packet headers. It was initially drafted in February 2000 by E. Nordmark of Sun Microsystems.
Basically SIIT describes a method by which a router interprets an IPv4 header and creates a parallel IPv6 header with equivalent information and the inverse equivalent operation of converting an IPv6 header into an IPv4 header. The actual means of converting between an IPv4 address and an IPv6 address may vary and the means by which the routing occurs is described as unspecified in the RFC.
Due to the method in which SIIT operates it is not a sufficient migration mechanism in that it is incapable of coordinating more than two unique addresses on either side. This means that every IPv6 host would be required to have a globally routable IPv4 address as well.
NAT-PT
Network Address Translation/Protocol Translation (or simply NAT-PT) is defined in RFC 2766 but due to numerous problems, it has been obsoleted by RFC 4966 and deprecated to historic status. It is typically used in conjunction with a DNS Application-level gateway (DNS-ALG) implementation.
NAPT-PT
While almost identical to NAT-PT, Network Address Port Translation + Protocol Translation which is also described in RFC 2766 adds translation of the ports as well as the address. This is done primarily to avoid two hosts on one side of the mechanism from using the same exposed port on the other side of the mechanism, which could cause application instability and/or security flaws. This mechanism has been deprecated by RFC 4966.
Transport Relay Translation (TRT)
RFC 3142 defines the Transport Relay Translation (TRT) method. This is the most common form of NAT-PT/NAPT-PT but relies on DNS translation between AAAA and A records known as DNS-ALG as defined in RFC 2694.
IPv4 NAT
Network Address Translation (NAT) using IPv4 can be used to provide IPv4 connectivity to IPv6-only networks. Depending on the details of network deployment, several scenarios can be envisioned for deployment. For example, a network would establish an IPv4-over-IPv6 tunnel to an IPv4 NAT router on the service providers network.
See also
- Comparison of IPv6 application support
- stone (software): port translator for Windows & Unix-based systems.
- faithd: BSD-based static TRT implementation
- pTRTd: user space TRT implementation
References
- ISBN 3-540-24524-3: IPv6 in Practice by Benedikt Stockebrand, 2006
- RFC 2767, Bump-in-the-Stack / Bump-in-the-API
- RFC 3089, Socks-based Gateway
- RFC 3142, TCP-UDP Relay
- RFC 4966, Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status