]> Google

1 Darling Island Rd Pyrmont NSW 2009 AU furry13@gmail.com furry@google.com

Ops IPv6 operations ipv6 slaac 464xlat clat nat64 pref64 ipv6-only ipv6-mostly 464XLAT () defines an arcitecture for providing IPv4 connectivity across an IPv6-only network. The solution contains two key elements: provider-side translator (PLAT) and customer-side translator (CLAT). This document provides recommendations on when a node shall enable or disable CLAT.

Introduction 464XLAT is widely deployed in 3GPP networks (as described in Section 4.2 of ). In that scenario a mobile phone performs the CLAT function, providing a private IPv4 address and IPv4 default route for the applications and tethered devices. Enabling 464XLAT allowed mobile operators to migrate User Equipment (UE) devices (also known as mobile phones) to IPv6-only mode, where those devices are only assigned IPv6 addresses. Until recently, IPv6-only hosts were rather uncommon outside of mobile networks and datacenters. Even if the network provide PLAT in the form of NAT64, hosts like desktops and laptops still the network to provide IPv4 addresses, as otherwise IPv4-only applications fail. However as more and more operating systems outside of 3GPP world support CLAT, it becomes possible to migrate those devices to IPv6-only mode. So networks like public WiFi, entterprise networks or even home networks can deploy 464XLAN as described in Section 4.2 of :

• PLAT functions are performed by NAT64 network devices.
• CLAT is performed by the host itself.

Another 464XLAT deployment model is a Wireline one (section 4.1 of ), when a CPE router is connected to an IPv6-only network and provides CLAT functions for IPv4-enabled downstream devices. For both scenarios to work, the node performing CLAT (such as a host or a CPE router) need to enable the CLAT when connecting to an IPv6-only network. This document provides recommendations for the nodes on when to enable CLAT and what conditions might lead to disabling CLAT functions.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology To be added

Enabling CLAT As 464XLAT requires both PLAT and CLAT elements, enabling CLAT in the absence of the corresponding PLAT system would cause an outage for the CLAT traffic. At the same time, when PLAT is present, the node performing CLAT needs to obtain the information about NAT64 prefix used by PLAT. Therefore the node SHOULD enable CLAT if it receives an Router Advertisement containing PREF64 option (). PREF64 option indicates that the network supports NAT64 and provides the node with all information required for CLAT at the same time. If RAs received by the node do not contain PREF64 option, the node MAY use other mechanisms to detect the PLAT presence and obtain NAT64 prefix (such as ). Some networks might provide PLAT functions while still providing devices with IPv4 addresses. From performance perspective native IPv4 connectivity might be preferrable over 464XLAT, therefore the node MAY delay enabling CLAT until one of the following happens:

• A DHCPOFFER message from the server contains a valid IPv6-Only Preferred option ().
• The node fails to obtain an IPv4 address via DHCPv4. The exact timeout period is implementation-specific.

However enabling CLAT only in the absence of IPv4 addresses is impactful for IPv4-only applications, as such applications can not benefit from 464XLAT until CLAT is operational. The delay (and impact for applications) is more significant if the node waits for DHCPv4 to time out. Therefore the timeout period shall be short enough.

Disabling CLAT The node MAY chose to turn CLAT off if an IPv4 address becomes available after CLAT has started. However turning it off would affect all applications and traffic flows utilizing CLAT.

Security Considerations If a malicious actor spoofs PLAT presence signals (such as an RA with PREF64 option) or DNS responses for DNS-based NAT64 prefix detection (), traffic of IPv4-only applications using CLAT can be affected:

• if there is no PLAT (NAT64) devices, traffic to NAT64 destinations would be dropped.
• If the attacker intercepts traffic for the NAT64 prefix (e.g. by providing the victim with a bogus NAT64 prefix and steering traffic for those destinations towards themselves), the attacker might be able to perform man-in-the-middle attack.

Using PREF64 RA option to detect PLAT presence and the NAT64 prefix is less prone to such attacks, as the attacker needs to be on-link.

Privacy Considerations This document does not introduce any privacy considerations.

IANA Considerations This memo does not introduce any requests to IANA.

References Normative References Informative References

Acknowledgements Thanks to Lorenzo Colitti, Tommy Jensen, Ted Lemon, for the discussions, the input and all contribution.