]> Energy Sciences Network

buraglio@forwardingplane.net

Energy Sciences Network

reardenrt@gmail.com

Operations and Management IPv6 Operations IPv6 DNS64 PREF64 NAT64 CLAT This document reports findings in the availability and operational performance of the client side translator (CLAT) feature within 464XLAT as defined in . It also identifies remaining issues in providing ubiquitous and efficient CLAT support on a global scale. Since publication in April 2013, 464XLAT has made a significant impact on mobile networks wishing to implement endpoints purely with IPv6. This has allowed the IPv6 Internet to expand dramatically as well as increase IPv6 deployments across wireline and enterprise-style networks. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the IPv6 Operations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The increase of IPv6-only deployments since around 2021 has highlighted the importance of the 464XLAT technology, and specifically customer-side address translator 9CLAT) component, in enabling access to legacy IPv4-only resources. Inclusion of CLAT technology, as either a default addition or a user-installable feature, has been a notable enabler of a more seamless migration off of legacy IP. The availability of client side translation has proliferated over the last several years, and many options and implementations exist. This document details the findings of an availability study of major non-mobile operating systems and their status as a feature availability. Additionally, basic functionality and performance is tested between varying systems using common performance testing tools.

Terminology 464XLAT: A set of technologies that enable IPv6-only networks to access IPv4 services by combining stateful and stateless translation mechanisms as defined by . PLAT: As defined in , PLAT is provider-side translator (XLAT) that complies with . It translates N:1 global IPv6 addresses to global IPv4 addresses, and vice versa. CLAT: As defined in , CLAT is customer-side translator (XLAT) that complies with . It algorithmically translates 1:1 private IPv4 addresses to global IPv6 addresses, and vice versa. The CLAT function is applicable to a router or an end-node such as a mobile phone. The CLAT should perform IP routing and forwarding to facilitate packets forwarding through the stateless translation even if it is an end-node. The CLAT as a common home router or wireless Third Generation Partnership Project (3GPP) router is expected to perform gateway functions such as being a DHCP server and DNS proxy for local clients. The CLAT uses different IPv6 prefixes for CLAT-side and PLAT-side IPv4 addresses and therefore does not comply with the sentence "Both IPv4-translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD use the same prefix." in Section 3.3 of . The CLAT does not facilitate communications between a local IPv4-only node and an IPv6- only node on the Internet.

Availability CLAT functionality has existed as a core, automatic function of the devices operating systems in mobile devices for many years and has been successfully deployed, supported, and expanded its footprint since its inception. However, the availability within traditional desktop, laptop and general use operating systems has a longer tail, with few commercial, off the shelf (COTS) operating environments possessing the same level of support for CLAT that exists in mobile deployments. Within the confines of general use operating systems, there are four major categories that perform 99% of daily-use user-facing functions. The following details the current support for CLAT in these four environments.

BSD BSD systems that support the ipfw toolkit have support for CLAT. This support must be manually enabled within the ipfw configuration and does not come on by default, allowing a more seamless user experience by supporting DHCP option 108 as defined by , pref64 as defined by , or DNS activation as defined by . Within the official Concurrent Version System ports repository, there is a CLAT configuration daemon named which checks for a NAT64 translator and configures the BSD packet filter to translate IPv4 packets into IPv6 packets.

Linux Linux has no official support. Linux systems may install 3rd party applications to support CLAT. This support must be manually installed and enabled within the configuration of the third party application. Third party support has varying levels of support with the most common relying on DNS activation as defined by . There is ongoing work on several options for CLAT in Linux, and an effort to include it in the base operating system but currently this effort is incomplete. An open source SIIT-DC, implementation for Linux.

Microsoft Windows There is currently no public support for CLAT in any Microsoft Windows version that is usable within a LAN environment. Implementations exist within multiple versions of Microsoft Windows but are limited to Mobile / Cellular interfaces.

Apple MacOS MacOS supports all manner of CLAT activation, and has a native, non-mobile-device implementation of the CLAT service as of MacOS 13.

Behavior and Performance Performance of CLAT implementations across major operating systems can and will have any number of factors affecting the overall performance of the internal operation. However, some simple baseline tests can be run to ascertain fundamental expectations. It should be noted, however, that on commodity desktop systems performance is not often a significant factor unless there are notable and significant amounts of packet loss which can be attributed specifically to the internal CLAT process. This is uncommon, however, as it is far more likely that upstream problems would be the root case of noticeable performance. In these tests, a common set of parameters were used to aid in consistent outcomes. Tools involved were the same across all platforms, and based on , a common bandwidth testing utility.

Linux to Linux ()

MacOS to MacOS (version 15.5)

Security Considerations None.

IANA Considerations This document has no IANA actions.

References Normative References This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. Informative References This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 2765. [STANDARDS-TRACK] This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server. This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK] This document specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate prefixes of Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) to hosts. This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. This document specifies a DHCPv4 option to indicate that a host supports an IPv6-only mode and is willing to forgo obtaining an IPv4 address if the network provides IPv6 connectivity. It also updates RFC 2563 to specify DHCPv4 server behavior when the server receives a DHCPDISCOVER not containing the Auto-Configure option but containing the new option defined in this document. n.d. n.d. n.d.

Acknowledgments TODO acknowledge.