| Standards Track |
| Experimental |
| Informational |
| Drafts |
| Deprecated |
IPv6 transition mechanisms are technologies to facilitate the transitioning of the Internet from its IPv4 infrastructure to the next generation addressing system of IPv6. Specifically, they are methods that allow hosts only connected with either IPv4 or IPv6 to access resources only available using the other protocol.
The Internet Engineering Task Force (IETF) conducts working groups and discussions through the IETF Internet Drafts and Requests for Comments processes to develop these methods. Some basic IPv6 transition mechanisms are defined in RFC 4213.
Contents |
Stateless IP/ICMP Translation translates between the packet header formats in IPv6 and IPv4. The SIIT method defines a class of IPv6 addresses called IPv4-translated addresses. They have the prefix ::ffff:0:0:0/96 and may be written as ::ffff:0:a.b.c.d, in which the IPv4 formatted address a.b.c.d refers to an "IPv6-enabled" node. The prefix was chosen to yield a zero-valued checksum to avoid changes to the transport protocol header checksum.[1]
The algorithm can be used in a solution that allows IPv6 hosts, that do not have a permanently assigned IPv4 address, to communicate with IPv4-only hosts. Address assignment and routing details are not addressed by the specification.
The specification is a product of the NGTRANS IETF working group, and was initially drafted in February 2000 as RFC 2765 by E. Nordmark of Sun Microsystems. RFC 2765 was obsoleted by RFC 6145 in 2011.[2] The address format part of RFC 2765 is defined in RFC 6052. [3] The framework of IPv4/IPv6 translation is defined in RFC 6144. [4]
6rd is a mechanism to facilitate rapid deployment of the IPv6 service across IPv4 infrastructures of Internet service providers (ISPs). It uses stateless address mappings between IPv4 and IPv6 addresses, and transmits IPv6 packets across automatic tunnels that follow the same optimized routes between customer nodes as IPv4 packets.
It has been used for the first large deployment of an IPv6 service with native addresses at the end of 2007 (RFC 5569 [5]). The standard-track specification of the protocol is in RFC 5969.[6]
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.
NAT64 is a mechanism to allow IPv6 hosts to communicate with IPv4 servers. The NAT64 server is the endpoint for at least one IPv4 address and an IPv6 network segment of 32-bits (for instance 64:ff9b::/96, see RFC 6052, RFC 6146). The IPv6 client embeds the IPv4 address it wishes to communicate with using these bits, and sends its packets to the resulting address. The NAT64 server then creates a NAT-mapping between the IPv6 and the IPv4 address, allowing them to communicate.[7]
DNS64 describes a DNS server that when asked for a domain's AAAA records, but only finds A records, synthesizes the AAAA records from the A records. The first part of the synthesized IPv6 address points to a IPv6/IPv4 translator and the second part embeds the IPv4 address from the A record. The translator in question is usually a NAT64 server. The standard-track specification of DNS64 is in RFC 6147.[8]
There are two noticeable issues with the transition mechanism:
Because of IPv4 address exhaustion, Dual-Stack Lite was designed to let an Internet service provider omit the deployment of any IPv4 address to the customer's Customer-premises equipment (CPE). Instead, only global IPv6 addresses are provided. (Regular Dual-Stack deploys global addresses for both IPv4 and IPv6.)
The CPE distributes private IPv4 addresses for the LAN clients, the same as a NAT device. The subnet information is arbitrarily chosen by the customer, identically to the NAT model. However, instead of performing the NAT itself, the CPE encapsulates the IPv4 packet inside an IPv6 packet. The CPE uses its global IPv6 connection to deliver the packet to the ISP's Carrier Grade NAT (CGN), which has a global IPv4 address. The IPv6 packet is decapsulated, restoring the original IPv4 packet. NAT is performed upon the IPv4 packet and is routed to the public IPv4 Internet. The CGN uniquely identifies traffic flows by recording the CPE public IPv6 address, the private IPv4 address, and TCP or UDP port number as a session.[9]
These mechanisms are still being discussed or have been abandoned by the IETF.
4rd is a mechanism to facilitate residual deployment of the IPv4 service across IPv6 networks. Like 6rd, it uses stateless address mappings between IPv6 and IPv4. It supports an extension of IPv4 address based on transport-layer ports. This is similar to A+P, but with each customer having a port set of up to 4 port ranges, and with port sets algorithmically derived from customer IPv6 prefixes.
These mechanisms have been deprecated by the IETF.
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.
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.
|
||||||||||||||