draft-ietf-v6ops-464xlaton.xml

<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>  <!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->


<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
     Use of an external entity file is not recommended. -->

<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="info"
  docName="draft-ietf-v6ops-claton-02"
  ipr="trust200902"
  obsoletes=""
  updates="8585"
  submissionType="IETF"
  xml:lang="en"
  version="3">
  <front>
<title abbrev="claton">464XLAT Customer-side Translator (CLAT): Node Recommendations</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-v6ops-claton-02"/>
    <author fullname="Jen Linkova" initials="J" surname="Linkova">
      <organization>Google</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <street>1 Darling Island Rd</street>
          <city>Pyrmont</city>
          <region>NSW</region>
          <code>2009</code>
          <country>AU</country>
        </postal>        
        <email>furry13@gmail.com</email>  
        <email>furry@google.com</email>  
      </address>
    </author>
<author initials="T." surname="Jensen" fullname="Tommy Jensen">
      <organization showOnFrontPage="true">Microsoft</organization>
      <address>
        <email>tojens@microsoft.com</email>
      </address>
    </author>
    <date year="2024"/>
<area>Ops</area>
    <workgroup>IPv6 operations</workgroup>
    <keyword>ipv6</keyword>
    <keyword>slaac</keyword>
    <keyword>464xlat</keyword>
    <keyword>clat</keyword>
    <keyword>nat64</keyword>
    <keyword>pref64</keyword>
    <keyword>ipv6-only</keyword>
    <keyword>ipv6-mostly</keyword>


    <abstract>
 <t>
464XLAT [RFC6877] defines an architecture 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 complements [RFC6877] and updates [RFC8585] by providing recommendations for the node developers on enabling and disabling CLAT functions.
</t>

    </abstract>
 
  </front>

  <middle>
    
    <section>
      <name>Introduction</name>
<t>
464XLAT is widely deployed in 3GPP networks (as described in Section 4.2 of <xref target="RFC6877"/>) where User Equipment (UE) devices (such as mobile phones and CE routers) perform the CLAT function, providing a private IPv4 address and default route for the applications and tethered devices.
Enabling 464XLAT allowed mobile operators to transition UE devices to IPv6-only mode, where those devices are only assigned IPv6 addresses on their WAN interfaces.
</t>
<t>
Until recently, IPv6-only hosts were rather uncommon outside of mobile networks and datacenters.
Even if the network provides PLAT in the form of NAT64 (<xref target="RFC6146"/>), hosts (desktops, laptops etc) still needed the network to provide IPv4 addresses, as otherwise IPv4-only applications fail.
However, as more and more operating systems outside of the 3GPP world support CLAT, it becomes possible to migrate those devices to IPv6-only mode, while still providing IPv4 as a service via 464XLAT.
Networks such as public Wi-Fi, enterprise networks or even home networks can deploy 464XLAT as described in Section 4.2 of <xref target="RFC6877"/>:
</t>
<ul>
<li>
<t>PLAT functions are performed by NAT64 network devices.</t>
</li>
<li>
<t>
CLAT is performed by the UA itself.
</t>
</li>
</ul>

<t>
Another 464XLAT deployment model is a Wireline one (section 4.1 of <xref target="RFC6877"/>), when a CPE router is connected to an IPv6-only network and provides CLAT functions for IPv4-enabled downstream devices. <xref target="RFC8585"/> specifies 464XLAT support requirements for such devices.
</t>

<t>
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 complements <xref target="RFC6877"/> and updates <xref target="RFC8585"/> by  providing recommendations for the node developers on enabling and disabling CLAT functions.
</t>

    </section>
      
      <section>
        <name>Requirements Language</name>
        <t>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 <xref target="RFC2119"/>
          <xref target="RFC8174"/> when, and only when, they appear in
          all capitals, as shown here.</t>
      </section>

<section anchor="term">
<name>
Terminology
</name>
<t>
This document reuses most of Terminology section from <xref target="RFC6877"/>.
</t>
<ul>
<li>
<t>
CLAT Node: a node (a host or a router) which performs CLAT functions by running one or multiple CLAT instances (e.g. one CLAT instance per interface).
</t>
</li>
<li>
<t>
IPv6-only network: A network that does not assign IPv4 addresses to hosts and facilitates connectivity to IPv4-only destinations using NAT64 (<xref target="RFC6146"/>). In this document, the term "IPv6-only network" specifically refers to networks that provide NAT64 as it's required by the 464XLAT architecture (<xref target="RFC6877"/>).
</t>
</li>
<li>
<t>
Native IPv4 (such as in 'native IPv4 connectivity' or 'native IPv4 default gateway'): IPv4 connectivity or default gateway provided by the network without using any form of IPv4-as-a-service or translation mechanisms (such as 464XLAT).
</t>
</li>
</ul>

<t>
Currently the only avalable form of PLAT for 464XLAT deployments is NAT64.
Therefore this document uses those terms interchangeably.
</t>
</section>
<section anchor="multihomed">
<name>Multiple Interfaces Considerations</name>
<t>
A node may have multiple IPv6-only interfaces (for example, a mobile phone can be connected to an IPv6-only Wi-Fi network and to an IPv6-only mobile network).
In that case the node SHOULD run an independent, dedicated CLAT instance on each interface connected to a network equipped with PLAT.
Consequently, each CLAT instance SHOULD install a separate default IPv4 route on each CLAT-enabled interface.
The metrics of IPv4 routes SHOULD be consistent with the metrics of IPv6 default routes.
</t>
</section>

    <section anchor="enable">
<name>Enabling CLAT</name>

<t>
For performance and security reasons CLAT MUST NOT be enabled if the node has IPv4 native connectivity over the given interface.
Therefore recommendations provided in this section are only applicable to an IPv6-only node (a node which does not have a native IPv4 default route configured).
</t>

<t>
To enable CLAT, an IPv6-only node needs to discover the PLAT-side translation IPv6 prefix, also known as the NAT64 prefix (see Section 6.3 of <xref target="RFC6877"/>).
The PREF64 Router Advertisement (RA) option (<xref target="RFC8781"/>) provides that information and can be used as a strong indication that the network supports PLAT (NAT64) functionality.
Therefore an IPv6-only node SHOULD enable CLAT as soon as an Router Advertisement containing PREF64 option is received.
</t>
<t>
If RAs received by the node do not contain a PREF64 option, the node MAY use other mechanisms to detect the PLAT presence and obtain the NAT64 prefix (such as <xref target="RFC7050"/>).
When discovering the NAT64 prefix using the mechanism defined in <xref target="RFC7050"/>, the node MUST follow recommendations provided in <xref target="RFC8880"/>.
Specifically, the node MUST send the query to the DNS servers for the specific network interface per Section 7.1 of <xref target="RFC8880"/>. 
In particular, queries for AAAA resource records of "ipv4only.arpa." MUST be sent to the recursive resolvers provided by the network, not to the resolvers configured manually, local recursive resolvers etc.
</t>
<t>
Any delay in enabling CLAT on an IPv6-only node would be impactful for IPv4-only applications, as such applications cannot benefit from 464XLAT until CLAT is operational. Therefore it's desirable that the node enables CLAT as soon as network support for PLAT is detected while IPv4 connectivity is not yet detected.

The node SHOULD enable CLAT after discovering the NAT64 prefix, unless by that time the node has already obtained a non-link-local IPv4 address.

The node SHOULD NOT wait for an explicit (DHCP Option 108) or an implicit (DHCP timeouts) indication that native IPv4 connectivity is not available.

However, to mitigate attacks described in Section 7 of <xref target="RFC7050"/>, the node MAY delay enabling CLAT if the NAT64 prefix was discovered via DNS (<xref target="RFC7050"/>) only. The delay is implementation specific.

If IPv4 connectivity becomes available later, the node MUST disable CLAT (unless explicitly configured to keep it running) as discussed in the following section.
</t>
<t>
If the node supports multiple IPv4 continuity solutions, the node MUST follow recommendations from Section 4 of <xref target="RFC7335"/> to avoid IPv4 address space conflicts.
</t>

</section>

<section anchor="disable">
<name>Disabling CLAT</name>
<t>
It is possible that after the CLAT instance has started, native IPv4 becomes available (e.g. an IPv4 address received via DHCP).
Unless explicitly configured otherwise, the node MUST disable CLAT immediately upon obtaining a native IPv4 default gateway.
</t>
<t>
While disabling CLAT is impactful for all applications and traffic flows already utilizing CLAT, it is recommended not only from performance perspective, but also from security point of view.
Because IPv4-only networks are inherently IPv6-ignorant, they might lack IPv6 layer2 security features, such as RA Guard, that would prevent spoofed RAs. 
An attacker can send an RA containing the PREF64 option, while the network doesn't provide any PLAT functionality.
If the node keeps CLAT enabled and uses it for IPv4-only destinations, that traffic could be dropped (availability attack) or routed through an attacker-controlled route (active attack on insecure traffic or hoarding secure traffic for "Harvest Now, Decrypt Later" attacks for non-PQC secure traffic, see Section 8 of <xref target="I-D.ietf-pquip-pqc-engineers"/>).

Rogue RAs can also disturb traffic to destinations that support both IPv4 and IPv6 by causing IPv6 through an attacker's PLAT to be used instead of the legitimate network owner's IPv4 path.
</t>
<t>
There are some corner cases when the administrator might prefer the node to use CLAT even if the native IPv4 connectivity is available (e.g. for performance reasons, if IPv4 as a Service performs better than native IPv4). However for the reasons described above such behaviour MUST be explicitly enabled by the administrator via a configuration knob and MUST NOT be a default behaviour, especially for unmanaged nodes.
</t>
</section>

<section anchor="addr">
<name>
CLAT Addresses Considerations
</name>


<section anchor="v4addr">
<name>
CLAT IPv4 Addresses
</name>
<t>
There are two different models in 464XLAT deployments:
</t>
<ul>
<li>
<t>
A dedicated prefix model, which Section 4.1 of <xref target="RFC6877"/> calls "wireline network architecture".
In that case, the node performing CLAT functions also extends the network downstream and provides network connectivity services to other connected systems.
Those systems can be physical (e.g. various clients connected to a CPE router), or logical (e.g. virtual systems running on a node, while the host system acts as a router and performs CLAT). 
In all those cases, systems behind the CLAT node usually use <xref target="RFC1918"/> addresses.
Despite the word "wireline", this architecure is applicable for wireless or 3GPP routers: such router can provide IPv4 connectivity to connected devices, performing CLAT functions for traffic sent/received via the IPv6-only uplink interface.
</t>
</li>
<li>
<t>
A single-address model, which section 4.2 of <xref target="RFC6877"/> calls "wireless network architecture".
In that case, the CLAT instance provides an IPv4 address and the default route to the local node's network stack only.
It should be noted that <xref target="RFC6877"/> implies that the second deployment scenario is limited to 3GPP cases, while currently it is also deployed in other types of networks, such as enterprise networks and Wi-Fi hotspots, where hosts (as mobile phones, laptops and desktops) use CLAT to provide connectivity to IPv4-only local applications.
Despite the word "wireless" in the name, this architecure is applicable for wired networks as well (e.g. desktops or servers using wired connections).
</t>
</li>
</ul>
<t>
In the single-address model, the CLAT instance needs a single IPv4 CLAT address and a single CLAT-only IPv6 address (which is distinct from the one or more IPv6 addresses used by the node running CLAT for its own native IPv6 connectivity, see <xref target="v6addr"/>).
The node providing CLAT functions to local applications SHOULD use IPv4 addresses from the dedicated 192.0.0.0/29 range (<xref target="RFC7335"/>), reserved for IPv4 continuity solutions including but not limited to 464XLAT.
If the node runs multiple CLAT instances (see <xref target="multihomed"/>), the node SHOULD use different local IPv4 addresses for each CLAT instance.
This approach limits the number of CLAT instances per node to 8, which seems to be more that sufficient at the time of writing. 
If in the future some deployment scenarios require more that 8 CLAT instances per node, a new larger IPv4 range will be requested from IANA.
</t>
<t>
The node MUST NOT send packets on wire from the local CLAT address.
</t>
<t>
The host SHOULD use 255.255.255.255 as a netmask for the CLAT address.
That allows all 8 addresses from 192.0.0.0/29 to be used, if needed.
</t>
<t>
It should be noted that 192.0.0.0/29 is shared between multiple IPv4 continuity solutions such as 464XLAT and DS-Lite (see <xref target="RFC7335"/>.
For example, Section 10 of <xref target="RFC6333"/> reserves 192.0.0.1 for the Dual-Stack Lite default router.
However, as per Section 4 of <xref target="RFC7335"/>, the host MUST NOT enable two active IPv4 continuity solutions simultaneously in a way that would cause a node to have overlapping 192.0.0.0/29 address space.
Therefore, as long as the host is not using DS-Lite, it MAY use 192.0.0.1 as a CLAT address.
</t>

</section>

<section anchor="v6addr">
<name>
CLAT IPv6 Addresses
</name>
<t>
Section 6.3 of <xref target="RFC6877"/> recommends that the CLAT instance acquires a dedicated /64 for translating between IPv4 and IPv6, and only uses a single interface IPv6 address if a dedicated prefix is not available via DHCPv6-PD.
However, deployments where each node can obtain a dedicated /64 just for CLAT are rather uncommon, especially in environments like enterprise networks, Wi-Fi hotspots, etc. 
Quite often the CLAT instance uses a single IPv6 address as a source for all IPv4 traffic translated by CLAT. 
In particular, in a single address model (see <xref target="v4addr"/>) the CLAT instance only need a single CLAT IPv6 address.
Even in a dedicated prefix model, the CLAT instance can first perform stateful NAT44 to translate all IPv4 addresses from the dedicated prefix to a single IPv4 address, and then perform stateless CLAT. 
</t>
<t>
The CLAT instance SHOULD obtain a dedicated IPv6 address used exclusively for CLAT functions. 
This is required as when the node receives a packet from a NAT64 source, the node needs to differentiate between native IPv6 traffic and traffic which needs to be passed to the CLAT instance.
For example, an ICMPv6 Echo Reply packet from 64:ff9b::203.0.113.1 can be a response to either an IPv6 ping to 64:ff9b::203.0.113.1, or an IPv4 ping to 203.0.113.1, translated by CLAT.
Using a dedicated IPv6 source address for CLAT traffic allows the node to make that distinction without keeping state and operate in the stateless mode (see Section 1.3 of <xref target="RFC6145"/>.
</t>
<t>
In a dedicated prefix model, the instance MAY obtain a dedicated IPv6 address for each CLAT IPv4 address.
</t>
<t>
In accordance with Section 5.4 of <xref target="RFC4862"/>, the node MUST perform Duplicate Address Detection for each dedicated CLAT address.
</t>
<t>
If the dedicated CLAT address is obtained via Stateless Address Autoconfiguration (SLAAC, <xref target="RFC4862"/>), the CLAT instance SHOULD ensure that the address is checksum-neutral for the given local IPv4 CLAT address and the NAT64 prefix (this means that the local IPv4 address needs to be assigned/known before the IPv6 address is configured).
Using a checksum-neutral CLAT address provides the following benefits:
</t>
<ul>
<li>
<t>Better performance as CLAT doesn't need to recalculate the checksum.</t>
</li>
<li>
<t>
If a protocol uses the standard IP checksum, CLAT doesn't need to recalculate the checksum.
That improves the chances of the protocol working via CLAT even if CLAT is not aware of the protocol's semantics.
</t>
</li>
</ul>

<t>
The node SHOULD treat SLAAC-generated CLAT addresses as temporary addresses (<xref target="RFC8981"/>). In particular:
</t>
<ul>
<li>
<t>
The node SHOULD generate new CLAT addresses over time, as described in Sections 3.4 and 3.6 of <xref target="RFC8981"/>.
</t>
</li>
<li>
<t>
The node SHOULD generate a different interface id for the CLAT address when connecting to different networks, even if the NAT64 prefix and the local IPv4 CLAT address do not change. 
To achieve that, the node SHOULD generate a random checksum-neutral CLAT address every time the network attachement changes to another network.
</t>
</li>
</ul>

<section anchor="mhoming">
<name>CLAT and Multiple Prefixes per Interface</name>
<t>
The CLAT instance SHOULD obtain a dedicated IPv6 address (or addresses, if a dedicated prefix model is used) from each global prefix used to configure IPv6 addresses on the given interface. When selecting an address to be used as a source address for the translated packet, the following rules are applied:
</t>
<ul>
<li>
<t>
All packets with the same IPv4 5-tuple MUST be translated to the same IPv6 address, as long as that address is valid (<xref target="RFC4862"/>) and assigned to the interface. 
</t>
</li>
<li>
<t>
When translation for a new IPv4 5-tuple is performed by the CLAT instance, the instance SHOULD comply with requirements defined in Section 3 of <xref target="RFC8028"/>, in particular Sections 3.2 and 3.3 of <xref target="RFC8028"/>. This is needed to ensure that the CLAT is operational and selects the source IPv6 correctly in multihomed environments or if the link subnet has been changed (renumbered).
</t>
</li>
</ul>

</section>

</section>
</section>

<section>
<name>
MTU Considerations
</name>
<t>
The IPv4 header is 20 bytes long (or longer if IP options are present), while the IPv6 header is 40 bytes.
This means that when CLAT translates an IPv4 packet to IPv6, it usually adds 20 bytes to the packet size.
To minimize undesirable IP fragmentation (<xref target="RFC8900"/>), the CLAT instance in a single-address mode SHOULD present IPv4-only applications with an IPv4 MTU which is 20 bytes smaller than the IPv6 MTU of the interface the instance is running on.
</t>
</section>

<section anchor="update">
<name>
Updates to RFC8585
</name>
<t>
This document makes the following changes to Section 3.2.1 of <xref target="RFC8585"/>:
</t>
<t>
OLD TEXT:
</t>
<t>
===
</t>
<t>
464XLAT requirements:
</t>
<t>
===
</t>
<t>
NEW TEXT:
</t>
<t>
===
</t>
<t>
464XLAT requirements:
</t>
<t>
464XLAT-0:  The IPv6 Transition CE Router SHOULD follow recommendations provided in draft-link-v6ops-claton.
</t>
<t>
===
</t>
<t>
OLD TEXT:
</t>
<t>
===
</t>
<t>464XLAT-4: The IPv6 Transition CE Router MUST implement <xref target="RFC7050"/>
               ("Discovery of the IPv6 Prefix Used for IPv6 Address
               Synthesis") in order to discover the provider-side
               translator (PLAT) translation IPv4 and IPv6
               prefix(es)/suffix(es). </t>
<t>
===
</t>
<t>
NEW TEXT:
</t>
<t>
===
</t>
<t>464XLAT-4: The IPv6 Transition CE Router MUST implement <xref target="RFC8781"/> ("Discovering PREF64 in Router Advertisements") and SHOULD implement <xref target="RFC7050"/>
               ("Discovery of the IPv6 Prefix Used for IPv6 Address
               Synthesis") in order to discover the provider-side
               translator (PLAT) translation IPv4 and IPv6
               prefix(es)/suffix(es). </t>
<t>
===
</t>

<t>
OLD TEXT:
</t>
<t>
===
</t>

<t>464XLAT-6:  If the network provides several choices for the
               discovery/learning of the NAT64 prefix, the priority to
               use one or the other MUST follow this order: 1) <xref target="RFC7225"/>
               and 2) <xref target="RFC7050"/>.</t>
<t>
   The NAT64 prefix could be discovered by means of the method defined
   in <xref target="RFC7050"/> only if the service provider uses DNS64 <xref target="RFC6147"/>.  It
   may be the case that the service provider does not use or does not
   trust DNS64 <xref target="RFC6147"/> because the DNS configuration at the CE (or
   hosts behind the CE) can be modified by the customer.  In that case,
   the service provider may opt to configure the NAT64 prefix by means
   of the option defined in <xref target="RFC7225"/>.  This can also be used if the
   service provider uses DNS64 <xref target="RFC6147"/>.
</t>
<t>
===
</t>
<t>
NEW TEXT
</t>
<t>
===
</t>

<t>464XLAT-6:  If the network provides several choices for the
               discovery/learning of the NAT64 prefix, the priority to
               use one or the other MUST follow this order: 1)<xref target="RFC7225"/> 2)<xref target="RFC8781"/>
               and 3) <xref target="RFC7050"/>.</t>
<t>
464XLAT-7: If the IPv6 Transition CE Router performs CLAT functions it SHOULD
           also  include the PLAT prefix  in Router Advertisements (<xref target="RFC8781"/>) sent via the LAN interfaces. If the IPv6 Transition CE Router acts as a DHCP server it SHOULD enable DHCP Option 108 (<xref target="RFC8925"/>) processing. The router SHOULD have a configuration knob to disable DHCP Option 108 processing.  </t>
<t>

   <xref target="RFC8781"/> allows the service provider to signal NAT64 prefix independently from DNS64 presence.
   At the same time the NAT64 prefix could be discovered by means of the method defined
   in <xref target="RFC7050"/> only if the service provider uses DNS64 <xref target="RFC6147"/>.  It
   may be the case that the service provider does not use or does not
   trust DNS64 <xref target="RFC6147"/> because the DNS configuration at the CE (or
   hosts behind the CE) can be modified by the customer.  In that case,
   the service provider may opt to configure the NAT64 prefix by means
   of the option defined in <xref target="RFC7225"/>.  This can also be used if the
   service provider uses DNS64 <xref target="RFC6147"/>.
</t>
<t>
===
</t>

</section>
    <section anchor="Security">
      <!-- All drafts are required to have a security considerations section. See RFC 3552 for a guide. -->
      <name>Security Considerations</name>
<t>
If a malicious actor spoofs PLAT presence signals (such as an RA with PREF64 option) or DNS responses for DNS-based NAT64 prefix detection (<xref target="RFC7050"/>), traffic of IPv4-only applications using CLAT can be affected:
</t>
<ul>
<li>
<t>if there is no PLAT (NAT64) devices, traffic to NAT64 destinations would be dropped.</t>
</li>
<li>
<t>
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 attacks.
</t>
</li>
</ul>
<t>
Using the PREF64 RA option to detect PLAT presence and the NAT64 prefix is less prone to such attacks than DNS-based detection (<xref target="RFC7050"/>), as the attacker needs to be on-link and be able to bypass layer-2 security features such as RA Guard.
Therefore <xref target="enable"/> recommends the PREF64 RA option as a preferred way to detect PLAT presence.
</t>
<t>
In networks lacking explicit IPv6 deployment and consequently IPv6 security features, administrators may inadvertently expose link-local IPv6 connectivity when endpoints have IPv6 enabled.
This unintended exposure can facilitate PLAT presence signal falsification, enabling malicious actors to conduct Man-in-the-Middle (MitM) or Denial-of-Service (DoS) attacks.
This document mitigates this risk by requiring endpoints to disable CLAT when the network provides non-link-local IPv4 connectivity, as outlined in <xref target="disable"/>.
</t>
    </section>

    <section anchor="privacy">
      <name>Privacy Considerations</name>
      <t>
If the instance utilizes the same CLAT address for an extensive period of time or, much worse, uses the same CLAT address when connecting to different networks, eavesdroppers and information collectors can correlate various network activity to the same node. To mitigate that risk and make address-based network-activity correlation more difficult, each CLAT instance's source IPv6 address SHOULD be rotated the same way as temporary IPv6 addresses (see <xref target="v6addr"/>).
</t>
<t>
It should be noted that the node's CLAT IPv6 address is only used (and visible to observers) when the traffic is carried from the CLAT node to the PLAT device.
In the vast majority of the cases it means that address is never visible outside of the network Internet edge, so to perform address-based network-activity correlation the observer needs to be located in the same network as the CLAT node.
      </t>
<t>
To summarize, this document does not introduce any new privacy considerations.
</t>
    </section>
    
    <section anchor="IANA">
    <!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.-->
      <name>IANA Considerations</name>
      <t>This memo does not introduce any requests to IANA.</t>
    </section>
    
    <!-- NOTE: The Acknowledgements and Contributors sections are at the end of this template -->
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3927.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6146.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6147.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6333.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6877.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7050.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7335.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8880.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8028.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8781.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8585.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8925.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8981.xml"/>
        <!-- The recommended and simplest way to include a well known reference -->
        
      </references>
 
      <references>
	      <name>Informative References</name>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.1918.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4862.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6145.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7225.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8900.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pquip-pqc-engineers.xml"/>

      </references>
    </references>

<section anchor="app">
<name>Enabling and Disabling CLAT: Flowchart</name>

<figure>
  <name>Enabling and Disabling CLAT Instance</name>
  <artset>
    <artwork type="svg" name="clat.svg">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="576" width="616" viewBox="0 0 616 576" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
<path d="M 8,80 L 8,144" fill="none" stroke="black"/>
<path d="M 8,208 L 8,272" fill="none" stroke="black"/>
<path d="M 8,336 L 8,400" fill="none" stroke="black"/>
<path d="M 8,464 L 8,560" fill="none" stroke="black"/>
<path d="M 80,176 L 80,208" fill="none" stroke="black"/>
<path d="M 88,272 L 88,328" fill="none" stroke="black"/>
<path d="M 96,400 L 96,456" fill="none" stroke="black"/>
<path d="M 152,208 L 152,272" fill="none" stroke="black"/>
<path d="M 160,144 L 160,176" fill="none" stroke="black"/>
<path d="M 168,16 L 168,72" fill="none" stroke="black"/>
<path d="M 176,208 L 176,272" fill="none" stroke="black"/>
<path d="M 184,336 L 184,400" fill="none" stroke="black"/>
<path d="M 184,464 L 184,560" fill="none" stroke="black"/>
<path d="M 232,280 L 232,496" fill="none" stroke="black"/>
<path d="M 272,176 L 272,208" fill="none" stroke="black"/>
<path d="M 288,80 L 288,144" fill="none" stroke="black"/>
<path d="M 288,336 L 288,400" fill="none" stroke="black"/>
<path d="M 336,272 L 336,328" fill="none" stroke="black"/>
<path d="M 360,80 L 360,144" fill="none" stroke="black"/>
<path d="M 376,208 L 376,272" fill="none" stroke="black"/>
<path d="M 416,336 L 416,400" fill="none" stroke="black"/>
<path d="M 440,208 L 440,272" fill="none" stroke="black"/>
<path d="M 464,152 L 464,208" fill="none" stroke="black"/>
<path d="M 504,16 L 504,80" fill="none" stroke="black"/>
<path d="M 504,272 L 504,368" fill="none" stroke="black"/>
<path d="M 552,208 L 552,272" fill="none" stroke="black"/>
<path d="M 592,152 L 592,544" fill="none" stroke="black"/>
<path d="M 608,80 L 608,144" fill="none" stroke="black"/>
<path d="M 168,16 L 504,16" fill="none" stroke="black"/>
<path d="M 8,80 L 288,80" fill="none" stroke="black"/>
<path d="M 360,80 L 608,80" fill="none" stroke="black"/>
<path d="M 288,112 L 344,112" fill="none" stroke="black"/>
<path d="M 8,144 L 288,144" fill="none" stroke="black"/>
<path d="M 360,144 L 608,144" fill="none" stroke="black"/>
<path d="M 80,176 L 272,176" fill="none" stroke="black"/>
<path d="M 8,208 L 72,208" fill="none" stroke="black"/>
<path d="M 88,208 L 152,208" fill="none" stroke="black"/>
<path d="M 176,208 L 264,208" fill="none" stroke="black"/>
<path d="M 280,208 L 376,208" fill="none" stroke="black"/>
<path d="M 440,208 L 552,208" fill="none" stroke="black"/>
<path d="M 376,240 L 432,240" fill="none" stroke="black"/>
<path d="M 8,272 L 152,272" fill="none" stroke="black"/>
<path d="M 176,272 L 376,272" fill="none" stroke="black"/>
<path d="M 440,272 L 552,272" fill="none" stroke="black"/>
<path d="M 8,336 L 184,336" fill="none" stroke="black"/>
<path d="M 288,336 L 416,336" fill="none" stroke="black"/>
<path d="M 192,368 L 288,368" fill="none" stroke="black"/>
<path d="M 424,368 L 504,368" fill="none" stroke="black"/>
<path d="M 8,400 L 184,400" fill="none" stroke="black"/>
<path d="M 288,400 L 416,400" fill="none" stroke="black"/>
<path d="M 8,464 L 184,464" fill="none" stroke="black"/>
<path d="M 184,496 L 232,496" fill="none" stroke="black"/>
<path d="M 184,544 L 592,544" fill="none" stroke="black"/>
<path d="M 8,560 L 184,560" fill="none" stroke="black"/>
<polygon class="arrowhead" points="600,152 588,146.4 588,157.6" fill="black" transform="rotate(270,592,152)"/>
<polygon class="arrowhead" points="472,152 460,146.4 460,157.6" fill="black" transform="rotate(270,464,152)"/>
<polygon class="arrowhead" points="440,240 428,234.4 428,245.6" fill="black" transform="rotate(0,432,240)"/>
<polygon class="arrowhead" points="432,368 420,362.4 420,373.6" fill="black" transform="rotate(180,424,368)"/>
<polygon class="arrowhead" points="352,112 340,106.4 340,117.6" fill="black" transform="rotate(0,344,112)"/>
<polygon class="arrowhead" points="344,328 332,322.4 332,333.6" fill="black" transform="rotate(90,336,328)"/>
<polygon class="arrowhead" points="280,208 268,202.4 268,213.6" fill="black" transform="rotate(90,272,208)"/>
<polygon class="arrowhead" points="240,280 228,274.4 228,285.6" fill="black" transform="rotate(270,232,280)"/>
<polygon class="arrowhead" points="200,368 188,362.4 188,373.6" fill="black" transform="rotate(180,192,368)"/>
<polygon class="arrowhead" points="176,72 164,66.4 164,77.6" fill="black" transform="rotate(90,168,72)"/>
<polygon class="arrowhead" points="104,456 92,450.4 92,461.6" fill="black" transform="rotate(90,96,456)"/>
<polygon class="arrowhead" points="96,328 84,322.4 84,333.6" fill="black" transform="rotate(90,88,328)"/>
<polygon class="arrowhead" points="88,208 76,202.4 76,213.6" fill="black" transform="rotate(90,80,208)"/>
<g class="text">
<text x="312" y="100">YES</text>
<text x="148" y="116">Has native IPv4 default route?</text>
<text x="480" y="116">CLAT Disabled</text>
<text x="188" y="164">NO</text>
<text x="484" y="180">NO</text>
<text x="404" y="228">NO</text>
<text x="496" y="228">PLAT prefix</text>
<text x="76" y="244">Start DHCP</text>
<text x="276" y="244">Received PREF64 in RA?</text>
<text x="492" y="244">discovered</text>
<text x="500" y="260">via RFC7050?</text>
<text x="360" y="308">YES</text>
<text x="528" y="324">YES</text>
<text x="96" y="372">Wait for DHCP Offer</text>
<text x="344" y="372">Enable CLAT</text>
<text x="256" y="452">YES</text>
<text x="96" y="516">Option 108 Present?</text>
<text x="428" y="532">NO</text>
</g>
</svg>
    </artwork>
    <artwork type="ascii-art" name="clat-flowchat-ascii.txt">
      <![CDATA[
                    +-----------------------------------------+             
                    |                                         |             
                    |                                         |             
                    v                                         |             
+----------------------------------+        +-----------------+------------+
|                                  | YES    |                              |
| Has native IPv4 default route?   +------> |        CLAT Disabled         |
|                                  |        |                              |
+------------------+---------------+        +------------------------------+
                   |  NO                                 ^               ^  
         +---------+-------------+                       | NO            |  
         |                       |                       |               |  
+--------v--------+  +-----------v------------+       +--+----------+    |  
|                 |  |                        |  NO   | PLAT prefix |    |  
|   Start DHCP    |  | Received PREF64 in RA? +------>| discovered  |    |  
|                 |  |                        |       | via RFC7050?|    |  
+---------+-------+  +-------------------+----+       +-------+-----+    |  
          |                 ^            |                    |          |  
          |                 |            | YES                |          |  
          v                 |            v                    | YES      |  
+---------------------+     |      +---------------+          |          |  
|                     |     |      |               |          |          |  
| Wait for DHCP Offer |<----+------+ Enable CLAT   |<---------+          |  
|                     |     |      |               |                     |  
+----------+----------+     |      +---------------+                     |  
           |                |                                            |  
           |                |                                            |  
           v                | YES                                        |  
+---------------------+     |                                            |  
|                     |     |                                            |  
|                     +-----+                                            |  
| Option 108 Present? |                                                  |  
|                     |                             NO                   |  
|                     +--------------------------------------------------+  
+---------------------+                                                     

      ]]>
    </artwork>
  </artset>
</figure>

</section>
    
    <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
<t>
Thanks to Ondrej Caletka, Stuart Cheshire, Lorenzo Colitti, Jeremy Duncan, Jason Healy, Ed Horley, KAWASHIMA Masanobu, Ted Lemon, George Michaelson, Jordi Palet, Dieter Siegmund for the discussions, the input, and all contribution.
</t>
    </section>
    
 </back>
</rfc>