<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC6052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6052.xml">
<!ENTITY RFC6104 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6104.xml">
<!ENTITY RFC6105 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6105.xml">
<!ENTITY RFC6146 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6146.xml">
<!ENTITY RFC6147 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6147.xml">
<!ENTITY RFC6877 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6877.xml">
<!ENTITY RFC7050 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7050.xml">
<!ENTITY RFC7225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7225.xml">
<!ENTITY RFC7556 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7556.xml">
<!ENTITY RFC7858 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7858.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8305 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8305.xml">
<!ENTITY RFC8484 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8484.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions --> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" obsoletes=""
     category="std"
     docName="draft-ietf-6man-ra-pref64-09"> consensus="true" docName="draft-ietf-6man-ra-pref64-09"
     number="8781" updates="" submissionType="IETF" xml:lang="en"
     tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true"
     version="3">

  <!-- category values: std, bcp, info, exp, and historic xml2rfc v2v3 conversion 2.39.0 -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->

    <title>Discovering PREF64 in Router Advertisements</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <seriesInfo name="RFC" value="8781"/>

    <author fullname="Lorenzo Colitti" initials="L." surname="Colitti">
      <organization>Google</organization>
      <address>
        <postal>
          <street>Shibuya 3-21-3</street>
          <city>Shibuya</city>
          <region>Tokyo</region>
          <code>150-0002</code>
          <country>JP</country>
          <country>Japan</country>
        </postal>

        <phone></phone>
        <phone/>
        <email>lorenzo@google.com</email>
      </address>
    </author>
    <author fullname="Jen Linkova" initials="J." surname="Linkova">
      <organization>Google</organization>
      <address>
        <postal>
          <street>1 Darling Island Rd</street>
          <city>Pyrmont</city>
          <region>NSW</region>
          <code>2009</code>
          <country>AU</country>
          <country>Australia</country>
        </postal>

        <phone></phone>
        <phone/>
        <email>furry@google.com</email>
      </address>
    </author>

    <date/>

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

    <!-- Meta-data Declarations -->
    <date year="2020" month="April" />

    <area>Internet</area>
    <workgroup>IPv6 Maintenance</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>template</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document specifies a Neighbor Discovery option to be used in
      Router Advertisements (RAs) to communicate NAT64 prefixes of Network Address and Protocol
      Translation from IPv6 clients to IPv4 servers (NAT64) to hosts.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>NAT64 <xref target="RFC6146"/> target="RFC6146" format="default"/> with DNS64 DNS Extensions
      for Network Address Translation from IPv6 clients to IPv4 servers (DNS64) <xref target="RFC6147"/>
      target="RFC6147" format="default"/> is a widely-deployed widely deployed mechanism to
      provide IPv4 access on IPv6-only networks. In various scenarios, the
      host must be aware of the NAT64 prefix in use by the network. This
      document specifies a Neighbor Discovery <xref target="RFC4861"/> target="RFC4861"
      format="default"/> option to be used in Router Advertisements
      (RAs) to
      communicate NAT64 prefixes to hosts.</t>
      <section title="Requirements Language">
	        <t>The numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
                        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
                        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
                        BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
      <section title="Terminology">
	      <t>
		      PREF64 numbered="true" toc="default">
        <name>Terminology</name>
        <dl>
	  <dt>PREF64 (or NAT64 prefix): an prefix):</dt><dd>An IPv6 prefix used for IPv6 address
	  synthesis <xref target="RFC6146"/>;
	      </t>
	      <t>
		      NAT64: Network target="RFC6146" format="default"/>;
        </dd>
        <dt>NAT64:</dt><dd>Network Address and Protocol Translation from IPv6 Clients clients to
	  IPv4 Servers servers <xref target="RFC6146"/>;
	      </t>
	      <t>
		      RA:    Router Advertisement, a target="RFC6146" format="default"/>;
        </dd>
        <dt>Router Advertisement (RA):</dt><dd>A message used by IPv6 routers to
	  advertise their presence together
	  with various link and Internet parameters <xref target="RFC4861"/>;
	      </t> target="RFC4861" format="default"/>;
        </dd></dl>
        <t>
	  DNS64: a mechanism for synthesizing AAAA records from A records
	  <xref target="RFC6147"/>; target="RFC6147" format="default"/>;
        </t>
      </section>
    </section>
    <section title="Use cases numbered="true" toc="default">
      <name>Use Cases for communicating Communicating the NAT64 prefix Prefix to hosts"> Hosts</name>
      <t>
		On networks employing NAT64, it is useful for hosts to know the NAT64 prefix for several reasons, including the following:
		<list style="symbols">
      </t>
      <ul spacing="normal">
        <li>
          <t>Enabling DNS64 functions on end hosts. In particular:
			<list style="symbols">
            <t>Local
          </t>
          <ul spacing="normal">

            <li>Local DNSSEC validation (DNS64 in stub-resolver mode). As
	    discussed in <xref target="RFC6147"/> section 2, target="RFC6147" sectionFormat="comma" section="2"/>,
	    the stub resolver in the host "will try to obtain (real)
	    AAAA RRs,
	    and in case they are not available, the DNS64 function will
	    synthesize AAAA RRs for internal usage." Therefore Therefore, to perform the
	    DNS64 function function, the stub resolver needs to know the NAT64
	    prefix. This is required in order to use DNSSEC on a NAT64 network.</t>
	    <t>Trusted
	    network.</li>
            <li>Trusted DNS server. AAAA synthesis is required for the host to
	    be able to use a DNS server not provided by the network (e.g., a
	    DNS-over-TLS <xref target="RFC7858"/> target="RFC7858" format="default"/> or
	    DNS-over-HTTPS <xref target="RFC8484"/> target="RFC8484" format="default"/> server
	    with which the host has an existing trust relationship).</t>
	    <t>Networks relationship).</li>
            <li>Networks with no DNS64 server. Hosts that support AAAA
	    synthesis and that are aware of the NAT64 prefix in use do not need the
	    network to perform the DNS64 function at all.</t>
    </list></t> all.</li>
          </ul>
        </li>
        <li>
          <t> Enabling NAT64 address translation address-translation functions on end hosts. For example:
	    <list style="symbols">
            <t>IPv4
          </t>
          <ul spacing="normal">
            <li>IPv4 address literals on an IPv6-only host. As described in
	    <xref target="RFC8305"/> section 7.1, target="RFC8305" sectionFormat="comma" section="7.1"/>, IPv6-only
	    hosts connecting to IPv4 address literals can translate the IPv4
	    literal to an IPv6 literal.</t>
            <t>464XLAT literal.</li>
            <li>464XLAT <xref target="RFC6877"/>. target="RFC6877" format="default"/>. 464XLAT
	    requires the host be aware of the NAT64 prefix.</t>
            </list>
    </t>
            </list>
        </t> prefix.</li>
          </ul>
        </li>
      </ul>
    </section>
    <section title="Why include numbered="true" toc="default">

      <name>Why Include the NAT64 prefix Prefix in Router Advertisements">
	    <t>Fate sharing: NAT64 Advertisements?</name>
      <dl><dt>Fate sharing:</dt><dd>NAT64 requires routing to be configured. IPv6 routing
      configuration requires receiving an IPv6 Router Advertisement RA <xref target="RFC4861"/>. Therefore
      target="RFC4861" format="default"/>. Therefore, using Router Advertisements RAs to provide hosts with the NAT64 prefix ensures that NAT64
      reachability information shares the fate with of the rest of the network
      configuration on the host.</t>
	    <t>Atomic configuration: including host.</dd>
      <dt>Atomic configuration:</dt><dd>Including the NAT64 prefix in the Router Advertisement RA minimizes the number of packets required to configure a
      host. Only one packet (a Router Advertisement) (an RA) is required to complete
      the network configuration. This speeds up the process of connecting to a
      network that supports NAT64/DNS64, and NAT64/DNS64. It also simplifies host implementation by
      removing the possibility that the host can have an incomplete layer
      Layer 3
      configuration (e.g., IPv6 addresses and prefixes, but no NAT64 prefix).</t>
      <t>Updatability: it
      prefix).</dd>
      <dt>Updatability:</dt><dd>It is possible to change the NAT64 prefix at any time,
      because when it changes, it is possible to notify hosts by sending a new Router Advertisement.</t>
      <t>Deployability: all
      RA.</dd>
      <dt>Deployability:</dt><dd>All IPv6 hosts and networks are required to support
      Neighbor Discovery <xref target="RFC4861"/> target="RFC4861" format="default"/> so just a
      minor extension to the existing implementation is required. Other options
      options, such as <xref target="RFC7225"/> target="RFC7225" format="default"/>, require
      implementing other protocols (e.g. PCP (e.g., Port Control Protocol (PCP) <xref target="RFC7225"/>) target="RFC7225"
      format="default"/>), which could be considered an obstacle for deployment.</t>
      deployment.</dd></dl>
    </section>
    <section anchor="Format" title="Option format"> numbered="true" toc="default">
      <name>Option Format</name>
      <figure align="center" anchor="fig_Option"
                             title="NAT64 anchor="fig_Option">
        <name>NAT64 Prefix Option Format"> Format</name>

        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Scaled Lifetime     | PLC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|              Highest 96 bits of the Prefix                    |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

				      ]]></artwork>
      </figure>
      <t>Fields:</t>
		      <texttable style="none">
			      <ttcol></ttcol>
			      <ttcol></ttcol>

			      <c>Type</c> <c>8-bit

      <table align="center">
	<name>NAT64 Prefix Option Format Fields</name>
        <tbody>
          <tr>
            <td align="left">Type</td>
            <td align="left">8-bit identifier of the PREF64 option
	    type as assigned by IANA: TBD</c>

				      <c>Length</c> <c> 8-bit (38)</td>
          </tr>

          <tr>
            <td align="left">Length</td>
            <td align="left">8-bit unsigned integer.  The length of the
	    option (including the Type and Length fields) is in units of 8
	    octets. The sender MUST <bcp14>MUST</bcp14> set the length to 2.  The
	    receiver MUST <bcp14>MUST</bcp14> ignore the PREF64 option if the length
	    Length field value is not 2.</c>
				      <c></c><c></c>
				      <c>Scaled Lifetime</c>  <c>13-bit 2.</td>
          </tr>

          <tr>
            <td align="left">Scaled Lifetime</td>
            <td align="left">13-bit unsigned integer. The maximum time in
	    units of 8 seconds over which this NAT64 prefix MAY <bcp14>MAY</bcp14>
	    be used. See <xref target="lifetime"/> target="lifetime" format="default"/> for the
	    Scaled Lifetime field processing rules.
				      </c>
       <c></c><c></c>
       <c>PLC rules.</td>
          </tr>

          <tr>
            <td align="left">PLC (Prefix Length Code)</c><c>3-bit Code)</td>
            <td align="left">3-bit unsigned integer. This field encodes the
	    NAT64 Prefix Length defined in <xref target="RFC6052"/>. target="RFC6052"
	    format="default"/>. The PLC field values 0, 1, 2, 3, 4 4, and 5
	    indicate the NAT64 prefix length of 96, 64, 56, 48, 40 40, and 32 bits bits,
	    respectively. The receiver MUST <bcp14>MUST</bcp14> ignore the PREF64
	    option if the prefix length code Prefix Length Code field is not set to one of those values. </c>
				      <c></c><c></c>
       <c>Highest
	    values.</td>
          </tr>

          <tr>
            <td align="left">Highest 96 bits of the prefix</c>   <c>96-bit Prefix</td>
            <td align="left">96-bit unsigned integer. Contains bits 0 - 95 of the NAT64 prefix.</c>
       </texttable> prefix.</td>
          </tr>
        </tbody>
      </table>
      <section anchor="lifetime" title="Scaled numbered="true" toc="default">
        <name>Scaled Lifetime Processing"> Processing</name>
        <t>
	  It would be highly undesirable for the NAT64 prefix to
	  have a lifetime shorter than the Router Lifetime, which
	  is defined in the Section 4.2 of <xref target="RFC4861"/> target="RFC4861"
	  sectionFormat="of" section="4.2"/> as a 16-bit unsigned integer.
	  If the NAT64 prefix lifetime is not at least equal to
	  the default router lifetime Router Lifetime, it might lead to scenarios when
	  in which the NAT64 prefix lifetime expires before the
	  arrival of the next unsolicited RA.
		       Therefore Therefore, the
	  Scaled Lifetime encodes the NAT64 prefix lifetime in
	  units of 8 seconds. The receiver MUST <bcp14>MUST</bcp14>
	  multiply the Scaled Lifetime value by 8 (for example,
	  by a logical left shift) to calculate the maximum time in
	  seconds the prefix MAY <bcp14>MAY</bcp14> be used.
	  The maximum lifetime of the NAT64 prefix is thus 65528
	  seconds.

	  To ensure that the NAT64 prefix does not expire before the default
	  router, when using this option it is NOT RECOMMENDED <bcp14>NOT RECOMMENDED</bcp14>
	  to configure default router lifetimes Router Lifetimes greater than 65528 seconds.
		       Lifetime
	  seconds when using this option.
	  A lifetime of 0 indicates that the prefix SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used anymore.
        </t>
        <t>
		       The
	  By default, the value of the Scaled Lifetime field SHOULD by default <bcp14>SHOULD</bcp14> be set
	  to the lesser of 3 x MaxRtrAdvInterval (<xref target="RFC4861"/>) <xref
	  target="RFC4861" format="default"/> divided by 8, or 8191.
        </t>
        <t>
	  Router vendors SHOULD <bcp14>SHOULD</bcp14> allow administrators to specify non-zero
	  nonzero lifetime values which that are not divisible by 8.
	  In such cases cases, the router SHOULD <bcp14>SHOULD</bcp14> round the provided
	  value up to the nearest integer that is divisible by 8 and smaller
	  than 65536, then divide the result by 8 (or perform a logical right-shift
	  right shift by 3), 3) and set the Scaled Lifetime field to the
	  resulting value.
	  If such a non-zero nonzero lifetime value that is to be divided by 8 (to be (or
	  subjected to a logical right-shift right shift by 3) is less than 8 8, then the
	  Scaled Lifetime field SHOULD <bcp14>SHOULD</bcp14> be set to 1.
	  This last step ensures that lifetimes under 8 seconds are encoded as
	  a non-zero nonzero Scaled Lifetime.
        </t>
      </section>
    </section>
    <section title="Usage Guidelines"> numbered="true" toc="default">
      <name>Usage Guidelines</name>
      <t>This option specifies exactly one NAT64 prefix for all IPv4
      destinations. If the network operator desires wants to route different parts
      of the IPv4 address space to different NAT64 devices, this can be
      accomplished by routing more specific sub-prefixes subprefixes of the NAT64 prefix
      to those devices.
      For example, suppose an operator is using the <xref target="RFC1918"/> target="RFC1918"
      format="default"/> address space 10.0.0.0/8 internally.
      That operator might want to route 10.0.0.0/8 through NAT64 device A, and
      the rest of the IPv4 space through NAT64 device B.
      If the operator's NAT64 prefix is 2001:db8:a:b::/96, then the operator
      can route 2001:db8:a:b::a00:0/104 to NAT64 A and 2001:db8:a:b::/96 to
      NAT64 B.
      </t>
      <t>This option may appear more than once in a Router Advertisement (e.g. in case of graceful an RA
      (e.g., when gracefully renumbering the network from one NAT64 prefix
      to another). Host behaviour behavior with regards regard to synthesizing IPv6 addresses
      from IPv4 addresses SHOULD <bcp14>SHOULD</bcp14> follow the recommendations
      given in Section 3 of <xref target="RFC7050"/>, target="RFC7050" sectionFormat="of" section="3"/>, limited
      to the NAT64 prefixes that have non-zero a nonzero lifetime.</t>

      <t>In a network (or a provisioning domain) that provides both IPv4 and
      NAT64, it may be desirable for certain IPv4 addresses not to be
      translated. An example might be private address ranges that are local to
      the network/provisioning domain and that should not be reached through the
      NAT64. This type of configuration cannot be conveyed to hosts using this
      option, or through other NAT64 prefix provisioning mechanisms such as
      <xref target="RFC7050"/> target="RFC7050" format="default"/> or <xref target="RFC7225"/>. target="RFC7225"
      format="default"/>. This problem does not apply in IPv6-only networks, because in such networks,
      networks: the host in an IPv6-only network does not have an IPv4 address and
      cannot reach any IPv4 destinations without the NAT64.</t> NAT64.

</t>
      <section anchor="mult_src" title="Handling numbered="true" toc="default">
        <name>Handling Multiple NAT64 Prefixes"> Prefixes</name>
        <t>
	  In some cases cases, a host may receive multiple NAT64 prefixes from
	  different sources. Possible scenarios include (but are not limited
	  to):
        </t>
	    <t><list style="symbols">
			    <t>
        <ul spacing="normal">
          <li> the host is using multiple mechanisms to discover PREF64
	  prefixes (e.g. (e.g., by using PCP <xref target="RFC7225"/>) target="RFC7225"
	  format="default"/>) and/or by resolving an IPv4-only fully qualified
	  domain name <xref target="RFC7050"/> target="RFC7050" format="default"/> in addition to
	  receiving the PREF64 RA option);</t>
			    <t> option);</li>
          <li> the PREF64 option presents in a single RA more than once;</t>
			    <t> once;</li>
          <li> the host receives multiple RAs with different PREF64 prefixes
	  on a given interface.</t>
		    </list>
	    </t> interface.</li>
        </ul>
        <t>When multiple PREF64 were PREF64s are discovered via the RA PREF64 Option (the (either the
	Option presents more than once in a single RA or multiple RAs were are
	received), host behaviour behavior with regards regard to synthesizing IPv6 addresses
	from IPv4 addresses SHOULD <bcp14>SHOULD</bcp14> follow the recommendations
	given in Section 3 of <xref target="RFC7050"/>, target="RFC7050" section="3" sectionFormat="of"/>,
	limited to the NAT64 prefixes that have non-zero a nonzero lifetime.</t>
        <t>
	  When different PREF64 PREF64s are discovered by using multiple mechanisms,
	  hosts SHOULD <bcp14>SHOULD</bcp14> select one source of information
	  only. The RECOMMENDED <bcp14>RECOMMENDED</bcp14> order is:
    <list style="symbols">
		    <t>PCP-discovered
        </t>
        <ul spacing="normal">
          <li>PCP-discovered prefixes <xref target="RFC7225"/>, target="RFC7225" format="default"/>, if supported;</t>
		    <t>PREF64 supported;</li>
          <li>PREF64s discovered via the RA Option;</t>
		    <t>PREF64 Option;</li>
          <li>PREF64s resolving an  IPv4-only fully qualified domain name <xref target="RFC7050"/> </t>
	    </list>
    </t>
    <t>Note that if
	  target="RFC7050" format="default"/> </li>
        </ul>
        <t>Note: If the network provides PREF64 both PREF64s via both this RA option Option
	and <xref target="RFC7225"/>, target="RFC7225" format="default"/>, hosts that receive the
	PREF64 via the RA option Option may choose to use it immediately before (before waiting
	for the PCP to complete, and therefore complete); therefore, some traffic may not reflect any
	more detailed configuration provided by the PCP.</t>
        <t>
	    The host SHOULD <bcp14>SHOULD</bcp14> treat the PREF64 as being specific
	    to the network interface it was received on. Hosts that are aware
	    of Provisioning Domain (PvD, <xref target="RFC7556"/>) aware hosts MUST target="RFC7556" format="default"/>)
	    <bcp14>MUST</bcp14> treat the PREF64 as being scoped to the
	    implicit or explicit PvD.
        </t>
      </section>
      <section anchor="cons" title="PREF64 Consistency"> numbered="true" toc="default">
        <name>PREF64 Consistency</name>
        <t>
	    Section 6.2.7 of
	    <xref target="RFC4861"/> target="RFC4861" sectionFormat="of" section="6.2.7"/>
	    recommends that routers inspect RAs sent by other routers to
	    ensure that all routers onlink advertise consistent
	    information. Routers SHOULD <bcp14>SHOULD</bcp14> inspect valid PREF64
	    options received on a given link and verify the
	    consistency. Detected inconsistencies indicate that one or more
	    routers might be misconfigured. Routers SHOULD <bcp14>SHOULD</bcp14> log
	    such cases to system or network management. Routers SHOULD
	    <bcp14>SHOULD</bcp14> check and compare the following information:
    <list style="symbols">
	    <t>set
        </t>
        <ul spacing="normal">
          <li>set of PREF64 PREF64s with non-zero lifetime;</t>
	    <t>set a nonzero lifetime;</li>
          <li>set of PREF64 PREF64s with a zero lifetime.</t>
</list>

Provisioning Domain (PvD, <xref target="RFC7556"/>) lifetime.</li>
        </ul>
        <t>
Routers that are aware routers MUST of PvD (<xref target="RFC7556"
format="default"/>) <bcp14>MUST</bcp14> only compare information scoped to the
same
implicit or explicit PvD.
</t>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>The IANA is requested to assign anchor="IANA-con" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has assigned a new IPv6 Neighbor Discovery Option
      type for the PREF64 option defined in this document.</t>

<texttable anchor="option_table">
    <ttcol align="left">Option Name</ttcol>
    <ttcol align="left">Type</ttcol>
    <c>PREF64 option</c>
    <c>(TBD)</c>
</texttable>

      <t>The IANA document in the
      &quot;IPv6 Neighbor Discovery Option Formats&quot; registry for these options is:
        <list><t>
          <eref target="https://www.iana.org/assignments/icmpv6-parameters">
          https://www.iana.org/assignments/icmpv6-parameters</eref>
      </t></list></t> <xref target="IANA" />.</t>

      <table anchor="option_table" align="center">
	<name>New IANA Registry Assignment</name>
        <thead>
          <tr>
            <th align="left">Description</th>
            <th align="left">Type</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">PREF64 option</td>
            <td align="left">38</td>
          </tr>
        </tbody>
      </table>

    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Because Router Advertisements RAs are required in all IPv6 configuration
      scenarios, on IPv6-only networks, Router Advertisements RAs must already be secured,
      secured -- e.g., by deploying RA guard an RA-Guard <xref target="RFC6105"/>. target="RFC6105"
      format="default"/>. Providing all configuration in Router Advertisements RAs
      reduces the attack surface to be targeted by malicious attackers trying to
      provide hosts with invalid configuration configuration, as compared to distributing the
      configuration through multiple different mechanisms that need to be
      secured independently.</t>
      <t>
If a host is provided with an incorrect NAT64 prefix prefix, the IPv6-only host might
not be able to communicate with IPv4-only destinations.
Connectivity to destinations reachable over IPv6 would not be impacted just by
providing a host with an incorrect prefix (however prefix; however, if attackers are capable
of sending rogue RAs RAs, they can perform denial-of-service or man-in-the-middle
attacks, as described in <xref target="RFC6104"/>). target="RFC6104" format="default"/>.
      </t>
      <t>The security measures that must already be in place to ensure that Router Advertisements
      RAs are only received from legitimate sources
      eliminate the problem of NAT64 prefix validation described in section 3.1 of <xref target="RFC7050"/>.</t>
      target="RFC7050" sectionFormat="of" section="3.1"/>.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6052.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7050.xml"/>
        <xi:include
	    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

<reference anchor="IANA"
           target="https://www.iana.org/assignments/icmpv6-parameters">
  <front>
    <title>Internet Control Message Protocol version 6 (ICMPv6) Parameters</title>
    <author><organization>IANA</organization></author>
  </front>
</reference>

      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6104.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6105.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6877.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7225.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7556.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
      </references>
    </references>

    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
	Thanks to the following people (in alphabetical order) for their review and feedback:
		    Mikael Abrahamsson, Mark Andrews, Brian
	<contact fullname="Mikael Abrahamsson"/>, <contact fullname="Mark Andrews"/>, <contact fullname="Brian E Carpenter, David Farmer, Nick Heatley, Robert Hinden, Martin Hunek, Tatuya Jinmei, Benjamin Kaduk, Erik Kline, Suresh Krishnan, Warren Kumari, David Lamparter, Barry Leiba, Jordi Carpenter"/>, <contact fullname="David Farmer"/>,
	<contact fullname="Nick Heatley"/>, <contact fullname="Robert Hinden"/>, <contact fullname="Martin Hunek"/>, <contact fullname="Tatuya Jinmei"/>, <contact fullname="Benjamin
	Kaduk"/>, <contact fullname="Erik Kline"/>, <contact fullname="Suresh Krishnan"/>, <contact fullname="Warren Kumari"/>, <contact fullname="David Lamparter"/>,
	<contact fullname="Barry Leiba"/>, <contact fullname="Jordi Palet Martinez, Tommy Pauly, Alexandre Petrescu, Michael Richardson, David Schinazi, Ole Troan, Eric Vynke, Bernie Volz. Martinez"/>, <contact fullname="Tommy Pauly"/>, <contact fullname="Alexandre Petrescu"/>,
	<contact fullname="Michael Richardson"/>, <contact fullname="David Schinazi"/>, <contact fullname="Ole Troan"/>, <contact fullname="Eric Vynke"/>, <contact fullname="Bernie
	Volz"/>.
      </t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC4861;
      &RFC6052;
      &RFC7050;
      &RFC8174;
    </references>

    <references title="Informative References">
      &RFC1918;
      &RFC6104;
      &RFC6105;
      &RFC6146;
      &RFC6147;
      &RFC6877;
      &RFC7225;
      &RFC7556;
      &RFC7858;
      &RFC8305;
      &RFC8484;
    </references>

  </back>
</rfc>