IPv6 transition mechanism

Last updated

An IPv6 transition mechanism is a technology that facilitates the transitioning of the Internet from the Internet Protocol version 4 (IPv4) infrastructure in use since 1983 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.

Contents

To meet its technical criteria, IPv6 must have a straightforward transition plan from the current IPv4. [1] The Internet Engineering Task Force (IETF) conducts working groups and discussions through the IETF Internet Drafts and Request for Comments processes to develop these transition technologies towards that goal. Some basic IPv6 transition mechanisms are defined in RFC 4213.

Stateless IP/ICMP Translation

Stateless IP/ICMP Translation (SIIT) translates between the packet header formats in IPv6 and IPv4. [2] The SIIT method defines a class of IPv6 addresses called IPv4-translated addresses. [3] 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. [4] 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 by E. Nordmark of Sun Microsystems. [5] It was revised in 2011, [6] and in 2016 its current revision was published. [4]

Tunnel broker

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) [7] or AYIYA. [8]

6rd

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 was used for an early large deployment of an IPv6 service with native addresses during 2007 (RFC 5569 [9] ). The standard-track specification of the protocol is in RFC 5969. [10]

Transport Relay Translation

RFC 3142 defines the Transport Relay Translation (TRT) method. TRT employs DNS translation between AAAA and A records known as DNS-ALG as defined in RFC 2694.

NAT64

NAT64 and DNS64. NAT64.svg
NAT64 and DNS64.

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. [3] The IPv6 client embeds the IPv4 address with which it wishes to communicate 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. [11]

DNS64

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. [12]

There are two noticeable issues with this transition mechanism:

# DNS resolver 2606:4700:4700:64 synthesizes AAAA records for# ipv6test.google.com to a NAT64 address: 64:ff9b::<original-ipv4>$ nslookup ipv6test.google.com 2606:4700:4700::64Non-authoritative answer:ipv6test.google.comcanonical name = ipv6test.l.google.com.Name: ipv6test.l.google.comAddress:64:ff9b::8efa:c3e4
Implementations


ISATAP

ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) is an IPv6 transition mechanism meant to transmit IPv6 packets between dual-stack nodes on top of an IPv4 network.

Unlike 6over4 (an older similar protocol using IPv4 multicast), ISATAP uses IPv4 as a virtual nonbroadcast multiple-access network (NBMA) data link layer, so that it does not require the underlying IPv4 network infrastructure to support multicast.

464XLAT

464XLAT (RFC 6877) allows clients on IPv6-only networks to access IPv4-only Internet services, such as Skype. [14] [15]

The client uses a SIIT translator to convert packets from IPv4 to IPv6. These are then sent to a NAT64 translator which translates them from IPv6 back into IPv4 and on to an IPv4-only server. The client translator may be implemented on the client itself or on an intermediate device and is known as the CLAT (Customer-side transLATor). The NAT64 translator, or PLAT (Provider-side transLATor), 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.

Implementations

Dual-Stack Lite (DS-Lite)

DS-Lite DSLite.svg
DS-Lite

Dual-Stack Lite technology does not involve allocating an IPv4 address to customer-premises equipment (CPE) for providing Internet access. [28] 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.

Lightweight 4over6 extends DS-Lite by moving the NAT functionality from the ISP side to the CPE, eliminating the need to implement carrier-grade NAT. [29] This is accomplished by allocating a port range for a shared IPv4 address to each CPE. Moving the NAT functionality to the CPE allows the ISP to reduce the amount of state tracked for each subscriber, which improves the scalability of the translation infrastructure.

V4-via-v6 routing

V4-via-v6 routing is a technique where IPv4 addresses are assigned to end hosts only while intermediate routers are only assigned IPv6 addresses. IPv4 routes are propagated as usual, and no packet translation or encapsulation is employed, but use an IPv6 next hop. V4-via-v6 reduces the amount of management required, since the core network only needs to be assigned IPv6 addresses, but still requires that the core network be able to forward IPv4 packets.

V4-via-v6 is defined for the Border Gateway Protocol (BGP) [30] and the Babel routing protocol. [31] It has been implemented the Bird Internet routing daemon [32] and in babeld. [33]

MAP

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. [34] MAP-T [35] and MAP-E [36] entered standards track in July 2015, and Sky Italia has deployed MAP-T in its internet services as early as year 2021. [37]

Draft proposals

The following mechanisms are still being discussed or have been abandoned by the IETF:

4rd

IPv4 Residual Deployment (4rd) is an experimental mechanism [38] 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 addressing based on transport-layer ports. This is a stateless variant of the A+P model.

Deprecated mechanisms

These mechanisms have been deprecated by the IETF:

NAT-PT

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.

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 security flaws. This mechanism has been deprecated by RFC 4966.

Implementations

See also

Related Research Articles

The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) networks for automatically assigning IP addresses and other communication parameters to devices connected to the network using a client–server architecture.

<span class="mw-page-title-main">Internet Protocol version 4</span> Fourth version of the Internet Protocol

Internet Protocol version 4 (IPv4) is the fourth version of the Internet Protocol (IP). It is one of the core protocols of standards-based internetworking methods in the Internet and other packet-switched networks. IPv4 was the first version deployed for production on SATNET in 1982 and on the ARPANET in January 1983. It is still used to route most Internet traffic today, even with the ongoing deployment of Internet Protocol version 6 (IPv6), its successor.

<span class="mw-page-title-main">IPv6</span> Version 6 of the Internet Protocol

Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol (IP), the communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet. IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with the long-anticipated problem of IPv4 address exhaustion, and was intended to replace IPv4. In December 1998, IPv6 became a Draft Standard for the IETF, which subsequently ratified it as an Internet Standard on 14 July 2017.

<span class="mw-page-title-main">Subnet</span> Logical subdivision of an IP network

A subnetwork, or subnet, is a logical subdivision of an IP network. The practice of dividing a network into two or more networks is called subnetting.

Zero-configuration networking (zeroconf) is a set of technologies that automatically creates a usable computer network based on the Internet Protocol Suite (TCP/IP) when computers or network peripherals are interconnected. It does not require manual operator intervention or special configuration servers. Without zeroconf, a network administrator must set up network services, such as Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS), or configure each computer's network settings manually.

In computer networking, localhost is a hostname that refers to the current computer used to access it. The name localhost is reserved for loopback purposes. It is used to access the network services that are running on the host via the loopback network interface. Using the loopback interface bypasses any local network interface hardware.

In Internet networking, a private network is a computer network that uses a private address space of IP addresses. These addresses are commonly used for local area networks (LANs) in residential, office, and enterprise environments. Both the IPv4 and the IPv6 specifications define private IP address ranges.

The Neighbor Discovery Protocol (NDP), or simply Neighbor Discovery (ND), is a protocol of the Internet protocol suite used with Internet Protocol Version 6 (IPv6). It operates at the internet layer of the Internet model, and is responsible for gathering various information required for network communication, including the configuration of local connections and the domain name servers and gateways.

The Dynamic Host Configuration Protocol version 6 (DHCPv6) is a network protocol for configuring Internet Protocol version 6 (IPv6) hosts with IP addresses, IP prefixes, default route, local segment MTU, and other configuration data required to operate in an IPv6 network. It is not just the IPv6 equivalent of the Dynamic Host Configuration Protocol for IPv4.

In the Internet addressing architecture, the Internet Engineering Task Force (IETF) and the Internet Assigned Numbers Authority (IANA) have reserved various Internet Protocol (IP) addresses for special purposes.

In computer networking, a link-local address is a network address that is valid only for communications on a local link, i.e. within a subnetwork that a host is connected to. Link-local addresses are most often unicast network addresses assigned automatically through a process known as stateless address autoconfiguration (SLAAC) or link-local address autoconfiguration, also known as automatic private IP addressing (APIPA) or auto-IP. Link-local addresses are not all unicast; e.g. IPv6 addresses beginning with ff02:, and IPv4 addresses beginning with 224.0.0. are multicast addresses that are link-local.

In computer networking, the Tunnel Setup Protocol (TSP) is an experimental networking control protocol used to negotiate IP tunnel setup parameters between a tunnel client host and a tunnel broker server, the tunnel end-points. A major use of TSP is in IPv6 transition mechanisms.

A Request for Comments (RFC), in the context of Internet governance, is a type of publication from the Internet Engineering Task Force (IETF) and the Internet Society (ISOC), usually describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems.

<span class="mw-page-title-main">IPv6 address</span> Label to identify a network interface of a computer or other network node

An Internet Protocol version 6 address is a numeric label that is used to identify and locate a network interface of a computer or a network node participating in a computer network using IPv6. IP addresses are included in the packet header to indicate the source and the destination of each packet. The IP address of the destination is used to make decisions about routing IP packets to other networks.

NAT64 is an IPv6 transition mechanism that facilitates communication between IPv6 and IPv4 hosts by using a form of network address translation (NAT). The NAT64 gateway is a translator between IPv4 and IPv6 protocols, for which function it needs at least one IPv4 address and an IPv6 network segment comprising a 32-bit address space. The "well-known prefix" reserved for this service is 64:ff9b::/96.

IPv4 Residual Deployment (4rd) is an IPv6 transition mechanism for Internet service providers for deployment of Internet Protocol version 6 (IPv6), while maintaining IPv4 service to customers. The protocol and sample applications are specified in RFC 7600.

<span class="mw-page-title-main">Rémi Després</span>

Rémi Després is a French engineer and entrepreneur known for his contributions on data networking.

<span class="mw-page-title-main">Address plus Port</span>

The Address plus Port (A+P) within the network layer communications protocol for Internet networking is an experimental approach to the IPv4 address shortage. It is a technique for sharing single IPv4 addresses among several users without using stateful network address translation in the carrier network.

Port Control Protocol (PCP) is a computer networking protocol that allows hosts on IPv4 or IPv6 networks to control how the incoming IPv4 or IPv6 packets are translated and forwarded by an upstream router that performs network address translation (NAT) or packet filtering. By allowing hosts to create explicit port forwarding rules, handling of the network traffic can be easily configured to make hosts placed behind NATs or firewalls reachable from the rest of the Internet, which is a requirement for many applications.

In order to ensure proper working of carrier-grade NAT (CGN), and, by doing so, alleviating the demand for the last remaining IPv4 addresses, a /10 size IPv4 address block was assigned by Internet Assigned Numbers Authority (IANA) to be used as shared address space. This block of addresses is specifically meant to be used by Internet service providers that implement carrier-grade NAT, to connect their customer-premises equipment (CPE) to their core routers.

References

  1. Partridge, C.; Kastenholz, F. (December 1994). Technical Criteria for Choosing IP The Next Generation (IPng). doi: 10.17487/RFC1726 . RFC 1726.
  2. F. Baker; X. Li; C. Bao; K. Yin (April 2011). Framework for IPv4/IPv6 Translation. Internet Engineering Task Force (IETF). doi: 10.17487/RFC6144 . ISSN   2070-1721. RFC 6144.Informational.
  3. 1 2 C. Bao; C. Huitema; M. Bagnulo; M. Boucadair; X. Li (October 2010). IPv6 Addressing of IPv4/IPv6 Translators. IETF. doi: 10.17487/RFC6052 . ISSN   2070-1721. RFC 6052.Proposed Standard. Updates RFC  4291.
  4. 1 2 C. Bao; X. Li; F. Baker; T. Anderson; F. Gont (June 2016). Stateless IP/ICMP Translation Algorithm. doi: 10.17487/RFC7915 . RFC 7915.
  5. E. Nordmark (February 2000). Stateless IP/ICMP Translation Algorithm (SIIT). Network Working Group. doi: 10.17487/RFC2765 . RFC 2765.Obsolete. Obsoleted by RFC  6145.
  6. X. Li; C. Bao; F. Baker (April 2011). IP/ICMP Translation Algorithm. Internet Engineering Task Force (IETF). doi: 10.17487/RFC6145 . ISSN   2070-1721. RFC 6145.Obsolete. Obsoleted by RFC   7915. Updated by RFC  6791 and 7757.
  7. M. Blanchet; F. Parent (February 2010). IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP). doi: 10.17487/RFC5572 . ISSN   2070-1721. RFC 5572.Experimental.
  8. A. Durand; P. Fasano; I. Guardini; D. Lento (January 2001). IPv6 Tunnel Broker. Network Working Group. doi: 10.17487/RFC3053 . RFC 3053.Informational.
  9. Despres, R. (January 2010). IPv6 Rapid Deployment on IPv4 Infrastructures (6rd). doi: 10.17487/RFC5569 . RFC 5569.
  10. Troan, O. (August 2010). IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification. doi: 10.17487/RFC5969 . RFC 5969.
  11. M. Bagnulo; P. Matthews; I. van Beijnum (April 2011). Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. Internet Engineering Task Force (IETF). doi: 10.17487/RFC6146 . ISSN   2070-1721. RFC 6146.Proposed Standard.
  12. Bagnulo, M.; Sullivan, A.; Matthews, P.; van Beijnum, I. (April 2011). DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers. doi: 10.17487/RFC6147 . RFC 6147.
  13. "README.DNS64". GitHub .{{cite web}}: CS1 maint: url-status (link)
  14. Žorž, Jan (3 April 2013). "Video: 464XLAT Live Demo at World IPv6 Congress in Paris". Internet Society .
  15. "464XLAT -- A Solution for Providing IPv4 Services Over and IPv6-only Network". T-Mobile USA . Retrieved 5 August 2013.
  16. "Case Study: T-Mobile US Goes IPv6-only Using 464XLAT". Internet Society . June 13, 2014. Archived from the original on February 4, 2024. Retrieved January 15, 2023.
  17. Twardowska, Marta (January 6, 2015). "Orange Polska Has Launched a World's First Innovative IPv6 Solution with SoftAtHome". Business Wire . Retrieved 2023-01-15.
  18. "Telstra IPv6 Wireless Enablement - IPv6 Single Stack". February 6, 2020.
  19. Drown, Dan. "What is Android CLAT?". Dan's Notes. Retrieved January 15, 2023.
  20. Havey, Daniel; Balasubramanian, Praveen (February 14, 2019). "Core Network Stack Features in the Creators Update for Windows 10". Microsoft Networking Blog. Retrieved January 15, 2023.
  21. "Windows 11 Plans to Expand CLAT Support". Microsoft Networking Blog. Retrieved March 7, 2024.
  22. "Twitter" . Retrieved 27 June 2022.
  23. "[v6ops] iOS12 IPv6-only" . Retrieved 5 November 2018.
  24. van Beijnum, Iljitsch (2015-06-16). "Apple to iOS devs: IPv6-only cell service is coming soon, get your apps ready". Ars Technica. Retrieved 2 July 2016.
  25. Anderson, Tore (May 20, 2019). "clatd". GitHub . Retrieved January 15, 2023.
  26. "OpenWrt Wiki package: 464xlat". OpenWrt. Retrieved 1 April 2024.
  27. Baoi, Danilo G. (June 19, 2021). "FreeBSD 12.1-RELEASE Release Notes". FreeBSD.
  28. A. Durand; R. Droms; J. Woodyatt; Y. Lee (August 2011). Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion. Internet Engineering Task Force (IETF). doi: 10.17487/RFC6333 . ISSN   2070-1721. RFC 6333.Proposed Standard.
  29. Y. Cui; Q. Sun; M. Boucadair; T. Tsou; Y. Lee; I. Farrer (July 2015). Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture. Internet Engineering Task Force. doi: 10.17487/RFC7596 . ISSN   2070-1721. RFC 7596.Proposed Standard.
  30. Le Faucheur, François; Rosen, Eric (May 2009). Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop. doi: 10.17487/RFC5549 . RFC 5549.
  31. Chroboczek, Juliusz (May 2022). Pv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol. doi: 10.17487/RFC9229 . RFC 9229.
  32. Rammhold, Andreas (December 15, 2020). "[RFC] Babel: Add v4viav6 Support". BIRD Internet Routing Daemon. Retrieved 2023-01-15.
  33. Chroboczek, Juliusz (May 5, 2022). "[Babel-users] ANNOUNCE: babeld-1.12". Debian Alioth Lists. Retrieved 2023-01-15.
  34. Mark Townsley (September 24, 2012). "Mapping Address + Port" (PDF). Cisco. Retrieved 2012-09-25.
  35. X. Li; C. Bao; O. Troan; S. Matsushima; T. Murakami (July 2015). W. Dec (ed.). Mapping of Address and Port using Translation (MAP-T). Internet Engineering Task Force (IETF). doi: 10.17487/RFC7599 . ISSN   2070-1721. RFC 7599.Proposed Standard.
  36. W. Dec; X. Li; C. Bao; S. Matsushima; T. Murakami (July 2015). O. Troan; T. Taylor (eds.). Mapping of Address and Port with Encapsulation (MAP-E). Internet Engineering Task Force (IETF). doi: 10.17487/RFC7597 . ISSN   2070-1721. RFC 7597.Proposed Standard.
  37. Patterson, Richard (May 2021). "IPv6-Only with MAP-T". RIPE NCC Open House. Retrieved 1 August 2023.
  38. R. Despres; R. Penno; Y. Lee; G. Chen; M. Chen (July 2015). S. Jiang (ed.). IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd). Internet Engineering Task Force (IETF). doi: 10.17487/RFC7600 . ISSN   2070-1721. RFC 7600.Experimental.