IPv6 transition mechanism
|IPv6 transition mechanisms|
An IPv6 transition mechanism is a technology that facilitates the transitioning of the Internet from the Internet Protocol version 4 (IPv4) infrastructure in uses since 1981 to the successor addressing and routing system of Internet Protocol Version 6 (IPv6). As IPv4 and IPv6 networks are not directly interoperable, transition technologies are designed to permit hosts on either network type to communicate with any other host.
To meet its technical criteria, IPv6 must have a straightforward transition plan from the current IPv4. The Internet Engineering Task Force (IETF) conducts working groups and discussions through the IETF Internet Drafts and Requests for Comments processes to develop these transition technologies towards that goal. Some basic IPv6 transition mechanisms are defined in RFC 4213.
- 1 Stateless IP/ICMP Translation
- 2 Tunnel broker
- 3 6rd
- 4 Transport Relay Translation
- 5 NAT64
- 6 DNS64
- 7 464XLAT
- 8 Dual-Stack Lite (DS-Lite)
- 9 Draft proposals
- 10 Deprecated methods
- 11 Market transfers
- 12 Implementations
- 13 See also
- 14 References
- 15 External links
Stateless IP/ICMP Translation
Stateless IP/ICMP Translation (SIIT) 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.
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. SIIT can be viewed as a special case of stateless network address translation.
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. The address format part of RFC 2765 is defined in RFC 6052. The framework of IPv4/IPv6 translation is defined in RFC 6144.
A tunnel broker provides IPv6 connectivity by encapsulating IPv6 traffic in IPv4 Internet transit links, typically using 6in4. This establishes IPv6 tunnels within the IPv4 Internet. The tunnels may be managed with the Tunnel Setup Protocol (TSP) or AYIYA. The first tunnel brokers were demonstrated in February 1999.
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.
Transport Relay Translation
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, e.g., 64:ff9b::/96 (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.
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 an 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.
There are two noticeable issues with this transition mechanism:
- It only works for cases where DNS is used to find the remote host address, if IPv4 literals are used the DNS64 server will never be involved.
- Because the DNS64 server needs to return records not specified by the domain owner, DNSSEC validation against the root will fail in cases where the DNS server doing the translation is not the domain owner's server.
The client uses a SIIT translator (see above) to convert IPv4 packets (e.g. Skype client software) into IPv6 to send (over an IPv6-only network) to a NAT64 translator (see above) which translates them back into IPv4 to send (over an IPv4-capable network) to an IPv4-only server (e.g. Skype server). The SIIT translator (CLAT) may be implemented on the client itself (as special software) or an intermediate IPv4-capable LAN (but if it had IPv4 Internet connectivity, 464XLAT would not be needed), and the NAT64 translator (PLAT) must be able to reach both the server and the client (through the CLAT). The use of NAT64 limits connections to a client-server model using UDP, TCP, and ICMP.
There is a CLAT implementation for Android, Android CLAT. T-Mobile USA provides NAT64 with T-Mobile's IPv6-only service.[unreliable source?]
Orange Poland starts IPv6 only (CLAT/NAT64/DNS) service in September 2013.
Android native CLAT implementation appeared in Jelly Bean 4.3.
Windows Phone native CLAT implementation in 2014 with WP 8.1.
iOS native CLAT implementation does not exists
Dual-Stack Lite (DS-Lite)
Dual-Stack Lite technology does not involve allocating an IPV4 address to customer premise equipment (CPE) for providing Internet access. It is described in RFC 6333. The CPE distributes private IPv4 addresses for the LAN clients, according to the networking requirement in the local area network. The CPE encapsulates IPv4 packets within IPv6 packets. 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 original IPv4 packet is recovered and 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.
These mechanisms are still being discussed or have been abandoned by the IETF.
IPv4 Residual Deployment (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.
Mapping of Address and Port (MAP) is a Cisco IPv6 transition proposal which combines A+P port address translation with tunneling of the IPv4 packets over an ISP provider's internal IPv6 network. As of September 2012[update]. MAP has standards-track Internet Draft status.
These mechanisms have been deprecated by the IETF.
Network Address Translation/Protocol Translation (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.
Allocated-but-unused numbers and the creation of a true market are crucial to the stability of the Internet. Market-based solutions are beneficial and serve as a temporary solution to the transition difficulties. “There is a thriving and growing market for IPv4 number blocks. The market is improving the efficiency of IPv4 address allocation by moving numbers from unused or under-utilized holders to organizations that need them more. Buyers willingly pay for number blocks they could get for free in order to benefit from more liberal needs assessments and stronger property rights.” While there is no clear plan of how to proceed with IPv6 transition mechanisms, market transfers is a temporarily solution that extends the life of IPv4.
- stone (software), port translator for Windows & Unix-based systems.
- faithd, BSD-based static TRT implementation by the KAME project
- TAYGA, a stateless NAT64 implementation for Linux
- Jool, a stateful NAT64 implementation for Linux
- naptd, user-level NAT-PT
- Ecdysis, a NAT64 gateway, includes DNS64
- Address Family Transition Router (AFTR), a DS-Lite implementation
- niit Linux Kernel device that allow transmission of IPv4 unicast traffic through an IPv6 network
- IVI IPv4/IPv6 packet translation implementation as a Linux kernel patch
- Microsoft Forefront Unified Access Gateway, a reverse proxy and VPN solution that implements DNS64 and NAT64
- BIND, Berkeley Internet Name Domain DNS server, implements DNS64 since version 9.8
- PF (firewall), the OpenBSD packet filter supports IP version translation since version 5.1, includes NAT64
- Comparison of IPv6 application support
- Comparison of IPv6 support in operating systems
- Softwire (protocol)
- RFC 1726 - IPng Technical Criteria
- RFC 2765 - Stateless IP/ICMP Translation Algorithm (SIIT), E. Normark (February 2000)
- RFC 6145 IP/ICMP Translation Algorithm
- RFC 6052 - IPv6 Addressing of IPv4/IPv6 Translators
- RFC 6144 - Framework for IPv4/IPv6 Translation
- RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
- RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification
- RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
- RFC 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
- "Video: 464XLAT Live Demo at World IPv6 Congress in Paris". Internet Society. 3 April 2013.
- "464XLAT -- A Solution for Providing IPv4 Services Over and IPv6-only Network". T-Mobile USA. Retrieved 5 August 2013.
- "T-Mobile IPv6 is Here and Now". T-Mobile USA. Retrieved 5 August 2013.
- "Windows Phone Hardware Development".
- RFC 6333 - Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
- Mark Townsley (September 24, 2012). "Mapping Address + Port" (PDF). Cisco. Retrieved 2012-09-25.
- Mueller, M; Kuerbis, B; Asghari, H (1 September 2012). "Dimensioning the Elephant: An Empirical Analysis of the IPv4 Number Market." (PDF). Internet Governance Project. doi:10.1108/info-07-2013-0039.
- IPv6 in Practice, Benedikt Stockebrand (2006), ISBN 3-540-24524-3
- RFC 2767, Bump-in-the-Stack
- RFC 3338, Bump-in-the-API
- RFC 3089, Socks-based Gateway
- RFC 6219, The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition
- D. J. Bernstein - The IPv6 mess
- TRT Howto from 2003
- IPv6 - Prospects and problems: a technical and management investigation into the deployment of IPv6
- Network World: Understanding Dual-Stack Lite
- IETF Draft: Framework for IPv4/IPv6 Translation
- IPv4 and IPv6 Transition and Coexistence, 6DEPLOY project, 2011
- Assuring Interoperability Between Heterogeneous (IPv4/IPv6) Networks Without using Protocol Translation, IETE Technical Review, 2012
- Configuring Hosts to Auto-detect (IPv6, IPv6-in-IPv4, or IPv4) Network Connectivity, KSII TRANSACTIONS ON INTERNET AND INFORMATION SYSTEMS, 2011
- IPv6: NAT-PT versus NAT64 Gianrico Fichera, 2012