IPv6 transition mechanisms are important technologies to facilitate the transitioning of the Internet from its initial IPv4 infrastructure to the next generation addressing system of IPv6. Specifically, they are methods that allow IPv6-connected hosts to access IPv4 Internet resources and hosts. Some IPv6 transition mechanisms were first defined in RFC 1933, which has been superseded by newer developments in RFC 4213.
The Internet Engineering Task Force (IETF) conducts working groups and discussions through the IETF Internet Drafts and Requests for Comments processes to development these methods.
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
- IPv6 in Practice, Benedikt Stockebrand (2006), ISBN 3-540-24524-3
- 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
External links
- TRT Howto from 2003
- IPv6 - Prospects and problems: a technical and management investigation into the deployment of IPv6
- A Comparison of Proposals to Replace NAT-PT
- draft-baker-behave-v4v6-framework
- draft-baker-behave-v4v6-translation
- NAT64
- DNS64
- IVI
- Dual Stack Lite
- pTRTd user-level NAT-PT
- naptd user-level NAT-PT
- IVI (second page)
- NAT64
- niit