IPv6 operations J. Linkova Internet-Draft Google Intended status: Informational 6 November 2023 Expires: 9 May 2024 464 Customer-side Translator (CLAT): Node Recommendations draft-link-v6ops-claton-00 Abstract 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. Status of This Memo 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 Notice 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. Linkova Expires 9 May 2024 [Page 1] Internet-Draft claton November 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Enabling CLAT . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Disabling CLAT . . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 9.2. Informative References . . . . . . . . . . . . . . . . . 5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction 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]: * 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 [RFC6877]), when a CPE router is connected to an IPv6-only network and provides CLAT functions for IPv4-enabled downstream devices. Linkova Expires 9 May 2024 [Page 2] Internet-Draft claton November 2023 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. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology To be added 4. 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 ([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. Linkova Expires 9 May 2024 [Page 3] Internet-Draft claton November 2023 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. 5. 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. 6. 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 ([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. 7. Privacy Considerations This document does not introduce any privacy considerations. 8. IANA Considerations This memo does not introduce any requests to IANA. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Linkova Expires 9 May 2024 [Page 4] Internet-Draft claton November 2023 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, . [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8781] Colitti, L. and J. Linkova, "Discovering PREF64 in Router Advertisements", RFC 8781, DOI 10.17487/RFC8781, April 2020, . [RFC8925] Colitti, L., Linkova, J., Richardson, M., and T. Mrugalski, "IPv6-Only Preferred Option for DHCPv4", RFC 8925, DOI 10.17487/RFC8925, October 2020, . 9.2. Informative References [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . Acknowledgements Thanks to Lorenzo Colitti, Tommy Jensen, Ted Lemon, for the discussions, the input and all contribution. Author's Address Jen Linkova Google 1 Darling Island Rd Pyrmont NSW 2009 Australia Email: furry13@gmail.com, furry@google.com Linkova Expires 9 May 2024 [Page 5]