| Internet-Draft | claton | November 2023 |
| Linkova | Expires 9 May 2024 | [Page] |
464XLAT ([RFC6877]) 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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 9 May 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
464XLAT is widely deployed in 3GPP networks (as described in Section 4.2 of [RFC6877]). 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 [RFC6877]:¶
Another 464XLAT deployment model is a Wireline one (section 4.1 of [RFC6877]), 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
To be added¶
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 ([RFC8781]). 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 [RFC7050]).¶
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 ([RFC8925]).¶
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.¶
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.¶
If a malicious actor spoofs PLAT presence signals (such as an RA with PREF64 option) or DNS responses for DNS-based NAT64 prefix detection ([RFC7050]), 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.¶
This document does not introduce any privacy considerations.¶
This memo does not introduce any requests to IANA.¶
Thanks to Lorenzo Colitti, Tommy Jensen, Ted Lemon, for the discussions, the input and all contribution.¶