464 Customer-side Translator (CLAT): Node Recommendations
draft-link-v6ops-claton-00

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,
              <https://www.rfc-editor.org/info/rfc2119>.

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,
              <https://www.rfc-editor.org/info/rfc6877>.

   [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,
              <https://www.rfc-editor.org/info/rfc7050>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8781]  Colitti, L. and J. Linkova, "Discovering PREF64 in Router
              Advertisements", RFC 8781, DOI 10.17487/RFC8781, April
              2020, <https://www.rfc-editor.org/info/rfc8781>.

   [RFC8925]  Colitti, L., Linkova, J., Richardson, M., and T.
              Mrugalski, "IPv6-Only Preferred Option for DHCPv4",
              RFC 8925, DOI 10.17487/RFC8925, October 2020,
              <https://www.rfc-editor.org/info/rfc8925>.

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,
              <https://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

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]