<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?> encoding="UTF-8"?>

<!-- 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 draft submitted in XML processors, including most browsers xml v3 -->

<!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-dhcp-pd-per-device-08" number="9663" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" consensus="true" xml:lang="en"
  version="3"> version="3" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="Prefix per client using Client Using DHCPv6-PD">Using DHCPv6 PD">Using DHCPv6-PD Prefix
    Delegation (DHCPv6-PD) to Allocate Unique IPv6 Prefix Prefixes per Client in Large
    Broadcast Networks</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-v6ops-dhcp-pd-per-device"/> name="RFC" value="9663"/>
 <author initials="L." surname="Colitti" fullname="Lorenzo Colitti">
      <organization>Google, LLC</organization>
      <address>
        <postal>
          <street>Shibuya 3-21-3</street>
          <country>Japan</country>
        </postal>
        <email>lorenzo@google.com</email>
      </address>
    </author>
    <author fullname="Jen Linkova" initials="J" role="editor" 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>
          <region>New South Wales</region>
          <code>2009</code>
          <country>AU</country>
          <country>Australia</country>
        </postal>
        <email>furry13@gmail.com</email>
        <email>furry@google.com</email>
      </address>
    </author>
    <author fullname="Xiao Ma" initials="X" role="editor" surname="Ma">
      <organization>Google</organization>
      <address>
        <postal>
          <street>Shibuya 3-21-3</street>
          <country>Japan</country>
        </postal>
        <email>xiaom@google.com</email>
      </address>
    </author>
    <date month="September" year="2024"/>
    <area>OPS Area</area>
    <workgroup>v6ops Working Group</workgroup>
    <area>OPS</area>
    <workgroup>v6ops</workgroup>

    <keyword>IPv6</keyword>
    <keyword>SLAAC</keyword>
    <keyword>DHCPv6-PD</keyword>

    <abstract>
      <t>This document discusses an IPv6 deployment scenario when individual
      nodes connected to large broadcast networks (such as enterprise networks
      or public Wi-Fi networks) are allocated unique prefixes via DHCPv6
      Prefix Delegation (DHCPv6-PD, RFC8415).</t> (DHCPv6-PD), as specified in RFC 8415.</t>
    </abstract>
  </front>

  <middle>

    <section>
      <name>Introduction</name>
      <t>Often

      <t>Often, broadcast networks such as enterprise or public Wi-Fi
      deployments place many devices on a shared link with a single on-link
      prefix. This document describes an alternative deployment model where
      individual devices obtain prefixes from the network. This provides two
      important advantages.</t>

<!--[rfced] May we rework the text below for clarity and concision?

Original:

   On VXLAN [RFC7348] networks each address might be represented as a route so
   8 addresses instead of 1 requires the devices to support 8 times more
   routes, etc.

Perhaps:

   On Virtual eXtensible Local Area Network (VXLAN) networks [RFC7348], each
   address might be represented as a route; this means that eight addresses,
   instead of one, require the devices to support eight times more routes, etc.
-->

<t>First, it offers better scalability. Unlike IPv4, IPv6 allows hosts
      to have multiple addresses, and this is the case in most deployments
      (see <xref target="appendix"/> for more details). However, increasing
      the number of addresses introduces scalability issues on the network
      infrastructure.  Network devices need to maintain various types of
      tables/hashes (Neighbor Cache on first-hop routers, Neighbor Discovery
      Proxy caches on Layer 2 devices devices, etc.).  On VXLAN <xref target="RFC7348"/> Virtual eXtensible Local Area Network (VXLAN) networks <xref
      target="RFC7348"/>, each address might be represented as a route
      so 8 eight addresses instead of 1 one requires the devices to support 8 eight times more
      routes, etc.  If an infrastructure device device's resources are exhausted, the
      device might drop some IPv6 addresses from the corresponding tables,
      while the address owner might be still be using the address to send
      traffic. This leads to traffic blackholing and a degraded customer
      experience.  Providing every host with one prefix allows the network to
      maintain only one entry per device, while still providing the device the
      ability to use an arbitrary number of addresses.
      </t>

      <t>Second,

<!--[rfced] We have clarified what subject "it" refers to in the sentence
below (from the Introduction) as this sentence appears far from its
original subject. Please let us know if this change alters your intended
meaning.

Original:

   Second, it provides the ability to extend the network.

Current:

   Second, this deployment method provides the ability to extend the network.

-->

      <t>Second, this deployment model provides the ability to extend the network. In IPv4, a
      device that connects to the network can provide connectivity to
      subtended devices by using NAT. With DHCPv6 Prefix Delegation (DHCPv6-PD,
      (DHCPv6-PD) <xref target="RFC8415"/>), target="RFC8415"/>, such a device can similarly
      extend the network, but unlike IPv4 NAT, it can provide its subtended
      devices with full end-to-end connectivity.</t>

      <t>Another method of deploying unique prefixes per device is documented
      in <xref target="RFC8273"/>. Similarly, the standard deployment model in
      cellular IPv6 networks <xref target="RFC6459"/> provides a unique prefix
      to every device. However, providing a unique prefix per device is very
      uncommon in enterprise-style networks, where nodes are usually connected
      to broadcast segments/VLANs and each link has a single on-link prefix
      assigned. This document takes a similar approach to <xref
      target="RFC8273"/>, but allocates the prefix using DHCPv6-PD.
      </t> DHCPv6-PD.</t>

      <t>This document focuses on the behaviour behavior of the network. Host behaviour behavior
      is not defined in this document.
      </t> document.</t>
    </section>

   <section>
	<name>Requirements Language</name>
        <t>The
        <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>
<name>Terminology</name>
<t>

<!--[rfced] Currently, the terminology list in Section 3 is not
alphabetized. May we alphabetize the list items?

Original:

3.  Terminology

   Node: a device that implements IPv6, <xref target="RFC8200"/>.
	      </t>
	      <t> [RFC8200].

   Host: any node that is not a router, <xref target="RFC8200"/>.
	      </t>
<t> [RFC8200].

   Client: a node which connects to a network and acquires addresses.
   The node may wish to obtain addresses for its own use, or may be a
   router that wishes to extend the network to its physical or virtual
   subsystems, or both.  It may be either a host or a router as defined
   by <xref target="RFC8200"/>.
	</t>

	      <t> [RFC8200].

   ND: Neighbor Discovery, <xref target="RFC4861"/>.
	      </t>
<t> [RFC4861].

   NUD: Neighbor Unreachability Detection,  <xref target="RFC4861"/>.
</t>
<t> [RFC4861].

   PIO: Prefix Information Option, <xref target="RFC4862"/>.
</t>
	      <t> [RFC4862].

   SLAAC: IPv6 Stateless Address Autoconfiguration, <xref target="RFC4862"/>.
	      </t>
<t> [RFC4862].

   DHCPv6-PD: DHCPv6 (<xref target="RFC8415"/>) ([RFC8415]) mechanism to delegate IPv6 prefixes to
   clients.
</t>
-->

<dl>
  <dt>Node:</dt><dd>a device that implements IPv6 <xref target="RFC8200"/></dd>
  <dt>Host:</dt><dd>any node that is not a router <xref target="RFC8200"/></dd>
  <dt>Client:</dt><dd>a node that connects to a network and acquires addresses. The
  node may wish to obtain addresses for its own use, or it may be a router that
  wishes to extend the network to its physical or virtual subsystems, or
  both. It may be either a host or a router as defined by <xref
  target="RFC8200"/>.</dd>
  <dt>ND:</dt><dd>Neighbor Discovery <xref target="RFC4861"/></dd>
  <dt>NUD:</dt><dd>Neighbor Unreachability Detection <xref target="RFC4861"/></dd>
  <dt>PIO:</dt><dd>Prefix Information Option <xref target="RFC4862"/></dd>
  <dt>SLAAC:</dt><dd>IPv6 Stateless Address Autoconfiguration <xref target="RFC4862"/></dd>
  <dt>DHCPv6-PD:</dt><dd>DHCPv6 Prefix Delegation <xref target="RFC8415"/>; a
  mechanism to delegate IPv6 prefixes to clients.</dd>
</dl>
</section>

    <section>
	    <name>Design Principles</name>
	    <t>

<!--[rfced] As the text below is both the first sentence of Section 4 and the
lead-in sentence for the list that follows, would it be helpful add
additional context for the reader?

Original:

   Instead of all clients on a given link forming addresses from the
   same shared prefix assigned to that link:
	    </t>
	    <ul>
		    <li>

   *  A device acts as DHCPv6-PD client and requests a prefix via
      DHCPv6-PD by sending an IA_PD request.
		    </li>
		    <li>
			    The

Perhaps:

   Instead of all clients on a given link forming addresses from the
   same shared prefix assigned to that link, this deployment model follows
   the design principles described below.

   *  A device acts as a DHCPv6-PD client and requests a prefix via
      DHCPv6-PD by sending an IA_PD request.
   ...
-->

    <section>
      <name>Design Principles</name>
      <t>Instead of all clients on a given link forming addresses from the
      same shared prefix assigned to that link:</t>
      <ul>
	<li>A device acts as a DHCPv6-PD client and requests a prefix via
	DHCPv6-PD by sending an IA_PD request.</li>
	<li>The server delegates a prefix to the client and the delegated
	prefix is installed into the routing table of the first-hop router as
	a route pointing to the client's link-local address. The first-hop
	router can act as a DHCPv6 relay and snoop DHCPv6 Reply messages from
	an off-link DHCPv6 server, or it can act as a DHCPv6 server itself. In
	both cases cases, it can install the route locally, and if the network is
	running a dynamic routing protocol, distribute the route or the entire
	prefix pool into the protocol.</li>
	<li>For the router and all other infrastructure devices, the delegated
	prefix is considered off-link, so traffic to that prefix does not
	trigger any ND packets, other than the minimum ND required to sustain
	Neighbor Unreachability Detection (NUD) for the client's link-local address.
		    </li>
		    <li>
                The
	address.</li>
	<li>The device can use the delegated prefix in various ways. For
	example, it can form addresses, as described in <xref target="RFC7084"/> requirement WAA-7. WAA-7 of
	<xref target="RFC7084"/>. It can also extend the network, as described
	in <xref target="RFC7084"/> or <xref target="RFC7278"/>.
		    </li> target="RFC7278"/>.</li>
    </ul>
<t>
An

    <t>An example scenario is shown in Figure 1. <xref target="fig1"/>. Note that the prefix lengths
    used in the example are /64 because that is the prefix length currently
    supported by SLAAC and is not otherwise required by the proposed
    deployment model.
</t> model.</t>

<figure anchor="fig1">
<name>
An
<name>An Example Topology with Two First-Hop Routers.
</name> Routers</name>

<!--[rfced] Please review the following questions about the ASCII and SVG
artwork in Figure 1:

a. There are some inconsistencies between the SVG and ASCII artwork (see a few
below). Please review and let us know how to update so these artworks match.

  i. Tethered device (ASCII) v. Tethered device1 and Tethered device2 (SVG)

  ii. Text appears to be cut off in the "virtual system" boxes and the "Legacy
  client" box (ASCII)

  iii. Router Advertisement containing PIO (ASCII) v. Router Advertisement PIO
  (SVG)

  iv. Legacy (no DHCPv6-PD) client B (ASCII) v. legacy client B no DHCPv6-PD
  support (SVG)

b. The ASCII art is too wide; it extends beyond the 72 character limit. How may we adjust?
-->

<artset>
<artwork type="svg">

<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="928" width="856" viewBox="0 0 856 928" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
<path d="M 8,128 L 8,288" fill="none" stroke="black"/>
<path d="M 8,736 L 8,912" fill="none" stroke="black"/>
<path d="M 24,336 L 24,432" fill="none" stroke="black"/>
<path d="M 24,816 L 24,880" fill="none" stroke="black"/>
<path d="M 48,48 L 48,176" fill="none" stroke="black"/>
<path d="M 48,224 L 48,336" fill="none" stroke="black"/>
<path d="M 48,440 L 48,592" fill="none" stroke="black"/>
<path d="M 48,640 L 48,736" fill="none" stroke="black"/>
<path d="M 168,80 L 168,192" fill="none" stroke="black"/>
<path d="M 168,256 L 168,328" fill="none" stroke="black"/>
<path d="M 168,432 L 168,592" fill="none" stroke="black"/>
<path d="M 168,640 L 168,728" fill="none" stroke="black"/>
<path d="M 216,816 L 216,880" fill="none" stroke="black"/>
<path d="M 224,528 L 224,736" fill="none" stroke="black"/>
<path d="M 232,816 L 232,880" fill="none" stroke="black"/>
<path d="M 248,288 L 248,336" fill="none" stroke="black"/>
<path d="M 256,16 L 256,96" fill="none" stroke="black"/>
<path d="M 304,432 L 304,528" fill="none" stroke="black"/>
<path d="M 320,576 L 320,656" fill="none" stroke="black"/>
<path d="M 352,240 L 352,328" fill="none" stroke="black"/>
<path d="M 424,816 L 424,880" fill="none" stroke="black"/>
<path d="M 432,336 L 432,432" fill="none" stroke="black"/>
<path d="M 440,736 L 440,912" fill="none" stroke="black"/>
<path d="M 448,96 L 448,128" fill="none" stroke="black"/>
<path d="M 456,512 L 456,576" fill="none" stroke="black"/>
<path d="M 480,336 L 480,432" fill="none" stroke="black"/>
<path d="M 480,864 L 480,912" fill="none" stroke="black"/>
<path d="M 520,240 L 520,328" fill="none" stroke="black"/>
<path d="M 536,688 L 536,768" fill="none" stroke="black"/>
<path d="M 584,832 L 584,864" fill="none" stroke="black"/>
<path d="M 608,768 L 608,832" fill="none" stroke="black"/>
<path d="M 616,576 L 616,656" fill="none" stroke="black"/>
<path d="M 632,432 L 632,528" fill="none" stroke="black"/>
<path d="M 640,768 L 640,800" fill="none" stroke="black"/>
<path d="M 656,16 L 656,96" fill="none" stroke="black"/>
<path d="M 656,864 L 656,912" fill="none" stroke="black"/>
<path d="M 680,288 L 680,336" fill="none" stroke="black"/>
<path d="M 680,528 L 680,688" fill="none" stroke="black"/>
<path d="M 680,864 L 680,912" fill="none" stroke="black"/>
<path d="M 736,80 L 736,160" fill="none" stroke="black"/>
<path d="M 736,208 L 736,336" fill="none" stroke="black"/>
<path d="M 736,440 L 736,592" fill="none" stroke="black"/>
<path d="M 736,640 L 736,688" fill="none" stroke="black"/>
<path d="M 760,832 L 760,864" fill="none" stroke="black"/>
<path d="M 808,432 L 808,592" fill="none" stroke="black"/>
<path d="M 808,640 L 808,680" fill="none" stroke="black"/>
<path d="M 824,32 L 824,208" fill="none" stroke="black"/>
<path d="M 824,256 L 824,328" fill="none" stroke="black"/>
<path d="M 848,128 L 848,288" fill="none" stroke="black"/>
<path d="M 848,336 L 848,432" fill="none" stroke="black"/>
<path d="M 848,688 L 848,768" fill="none" stroke="black"/>
<path d="M 848,864 L 848,912" fill="none" stroke="black"/>
<path d="M 256,16 L 656,16" fill="none" stroke="black"/>
<path d="M 656,32 L 824,32" fill="none" stroke="black"/>
<path d="M 48,48 L 240,48" fill="none" stroke="black"/>
<path d="M 168,80 L 256,80" fill="none" stroke="black"/>
<path d="M 664,80 L 736,80" fill="none" stroke="black"/>
<path d="M 256,96 L 656,96" fill="none" stroke="black"/>
<path d="M 8,128 L 848,128" fill="none" stroke="black"/>
<path d="M 8,288 L 848,288" fill="none" stroke="black"/>
<path d="M 24,336 L 432,336" fill="none" stroke="black"/>
<path d="M 480,336 L 848,336" fill="none" stroke="black"/>
<path d="M 24,432 L 432,432" fill="none" stroke="black"/>
<path d="M 480,432 L 848,432" fill="none" stroke="black"/>
<path d="M 192,528 L 696,528" fill="none" stroke="black"/>
<path d="M 320,576 L 616,576" fill="none" stroke="black"/>
<path d="M 320,656 L 616,656" fill="none" stroke="black"/>
<path d="M 536,688 L 848,688" fill="none" stroke="black"/>
<path d="M 8,736 L 440,736" fill="none" stroke="black"/>
<path d="M 536,768 L 848,768" fill="none" stroke="black"/>
<path d="M 24,816 L 216,816" fill="none" stroke="black"/>
<path d="M 232,816 L 424,816" fill="none" stroke="black"/>
<path d="M 544,832 L 784,832" fill="none" stroke="black"/>
<path d="M 480,864 L 656,864" fill="none" stroke="black"/>
<path d="M 680,864 L 848,864" fill="none" stroke="black"/>
<path d="M 24,880 L 216,880" fill="none" stroke="black"/>
<path d="M 232,880 L 424,880" fill="none" stroke="black"/>
<path d="M 8,912 L 440,912" fill="none" stroke="black"/>
<path d="M 480,912 L 656,912" fill="none" stroke="black"/>
<path d="M 680,912 L 848,912" fill="none" stroke="black"/>
<polygon class="arrowhead" points="832,328 820,322.4 820,333.6" fill="black" transform="rotate(90,824,328)"/>
<polygon class="arrowhead" points="832,208 820,202.4 820,213.6" fill="black" transform="rotate(90,824,208)"/>
<polygon class="arrowhead" points="816,680 804,674.4 804,685.6" fill="black" transform="rotate(90,808,680)"/>
<polygon class="arrowhead" points="816,592 804,586.4 804,597.6" fill="black" transform="rotate(90,808,592)"/>
<polygon class="arrowhead" points="744,640 732,634.4 732,645.6" fill="black" transform="rotate(270,736,640)"/>
<polygon class="arrowhead" points="744,440 732,434.4 732,445.6" fill="black" transform="rotate(270,736,440)"/>
<polygon class="arrowhead" points="744,208 732,202.4 732,213.6" fill="black" transform="rotate(270,736,208)"/>
<polygon class="arrowhead" points="672,80 660,74.4 660,85.6" fill="black" transform="rotate(180,664,80)"/>
<polygon class="arrowhead" points="648,800 636,794.4 636,805.6" fill="black" transform="rotate(90,640,800)"/>
<polygon class="arrowhead" points="528,328 516,322.4 516,333.6" fill="black" transform="rotate(90,520,328)"/>
<polygon class="arrowhead" points="360,328 348,322.4 348,333.6" fill="black" transform="rotate(90,352,328)"/>
<polygon class="arrowhead" points="248,48 236,42.4 236,53.6" fill="black" transform="rotate(0,240,48)"/>
<polygon class="arrowhead" points="176,728 164,722.4 164,733.6" fill="black" transform="rotate(90,168,728)"/>
<polygon class="arrowhead" points="176,592 164,586.4 164,597.6" fill="black" transform="rotate(90,168,592)"/>
<polygon class="arrowhead" points="176,328 164,322.4 164,333.6" fill="black" transform="rotate(90,168,328)"/>
<polygon class="arrowhead" points="176,192 164,186.4 164,197.6" fill="black" transform="rotate(90,168,192)"/>
<polygon class="arrowhead" points="56,640 44,634.4 44,645.6" fill="black" transform="rotate(270,48,640)"/>
<polygon class="arrowhead" points="56,440 44,434.4 44,445.6" fill="black" transform="rotate(270,48,440)"/>
<polygon class="arrowhead" points="56,224 44,218.4 44,229.6" fill="black" transform="rotate(270,48,224)"/>
<g class="text">
<text x="452" y="36">DHCPv6 Servers</text>
<text x="448" y="68">Pool 2001:db8:ddd0::/48 for clients</text>
<text x="452" y="84">on 2001:db8:c001::/64 link</text>
<text x="452" y="164">IPv6 Network</text>
<text x="724" y="180">DHCPv6</text>
<text x="76" y="196">DHCPv6</text>
<text x="720" y="196">Relay-Forward</text>
<text x="72" y="212">Relay-Forward</text>
<text x="180" y="228">DHCPv6</text>
<text x="444" y="228">Route for 2001:db8:ddd0::/48</text>
<text x="796" y="228">DHCPv6</text>
<text x="184" y="244">Relay-Reply</text>
<text x="800" y="244">Relay-Reply</text>
<text x="272" y="356">First-hop router/DHCPv6 relay</text>
<text x="648" y="356">First-hop Router/DHCPv6 relay</text>
<text x="220" y="388">Route 2001:db8:ddd0:1::/64 -&gt; fe80::aaaa</text>
<text x="596" y="388">Route 2001:db8:ddd0:1::/64</text>
<text x="768" y="388">-&gt; fe80::aaaa</text>
<text x="220" y="420">Route 2001:db8:ddd0:2::/64 -&gt; fe80::cccc</text>
<text x="596" y="420">Route 2001:db8:ddd0:2::/64</text>
<text x="768" y="420">-&gt; fe80::cccc</text>
<text x="388" y="516">Shared IPv6 link</text>
<text x="540" y="516">2001:db8:c001::/64</text>
<text x="456" y="596">legacy client B</text>
<text x="52" y="612">DHCPv6</text>
<text x="164" y="612">DHCPv6</text>
<text x="452" y="612">no DHCPv6-PD support</text>
<text x="740" y="612">DHCPv6</text>
<text x="812" y="612">DHCPv6</text>
<text x="56" y="628">Request</text>
<text x="160" y="628">Reply</text>
<text x="464" y="628">link-local address fe80::bbbb</text>
<text x="744" y="628">Request</text>
<text x="808" y="628">Reply</text>
<text x="468" y="644">global address 2001:db8:c001::bbbb</text>
<text x="628" y="708">Client C</text>
<text x="664" y="724">link-local address fe80::cccc</text>
<text x="696" y="740">delegated prefix 2001:db8:ddd0:2::/64</text>
<text x="220" y="756">Client A</text>
<text x="212" y="772">link-local address: fe80::aaaa</text>
<text x="228" y="788">delegated prefix: 2001:db8:ddd0:1::/64</text>
<text x="732" y="788">Router Advertisement</text>
<text x="748" y="804">PIO 2001:db8:ddd0:2::/64</text>
<text x="108" y="836">virtual system</text>
<text x="316" y="836">virtual system</text>
<text x="116" y="852">2001:db8:ddd0:1::f00</text>
<text x="320" y="852">2001:db8:ddd0:1::2345</text>
<text x="120" y="868">2001:db8:ddd0:1::cafe</text>
<text x="316" y="868">2001:db8:ddd0:1::abc</text>
<text x="572" y="884">Tethered device1</text>
<text x="756" y="884">Tethered device2</text>
<text x="568" y="900">2001:db8:ddd0:2::5555</text>
<text x="764" y="900">2001:db8:ddd0:2::6666</text>
</g>
</svg>
</artwork>

<artwork type="ascii-art">
<![CDATA[
+-----------------------------------------------------------------------------+
|                                  DHCPv6 Servers                             |
|         Pool 2001:db8:ddd0::/48 for clients on 2001:db8:c001::/64 link      |
+---------------+-------------------------+-----------------------------+-----+
         ^      |                         |                      ^      |
         |      |                         |                      |      |
 +-------+------+-------------------------+----------------------+------+-----+
 |DHCPv6 |      |                    IPv6 Network         DHCPv6 |      |     |
 |Relay-Forward |                                         Relay-Forward |     |
 |     ^        v           Route for 2001:db8:ddd0::/48        ^       v     |
 |     |     DHCPv6          |                    |             |    DHCPv6   |
 |     |   Relay-Reply       |                    |             |  Relay-Reply|
 |     |       |             |                    |             |       |     |
 +-----+-------+-------+-----+--------------------+-----+-------+-------+-----+
       |       |       |     |                    |     |       |       |
       |       v       |     v                    v     |       |       v
  +----+---------------+--------------+  +--------------+-------+-------------+
  |     First-hop router/DHCPv6 relay |  |    First-hop Router/DHCPv6 relay   |
  | 2001:db8:ddd0:1::/64 -> fe80::aaaa|  | 2001:db8:ddd0:1::/64 -> fe80::aaaa |
  | 2001:db8:ddd0:2::/64 -> fe80::cccc|  | 2001:db8:ddd0:2::/64 -> fe80::ccc  |
  +-----------+------------+----------+  +---------+--------------------+-----+
       ^      |            |   Shared IPv6 link,   |            ^       |
       |      |            |   2001:db8:c001::/64  |            |       |
       |      |  --+-------+-----------+-----------+------+---  |       |
       |      |    |                   |                  |     |       |
       |      |    |  +----------------+--------------+   |  DHCPv6     |
    DHCPv6    |    |  |Legacy (no DHCPv6-PD) client B |   |  Request    v
    Request   |    |  |link-local address fe80::bbbb  |   |     ^     DHCPv6
      ^       |    |  |global address 2001:db8:c001::b|   |     |     Reply
      |       |    |  +-------------------------------+   |     |       |
      |       v    |                                      |     |       v
      |    DHCPv6  |                  +-------------------+-----+------------+
      |    Reply   |                  |       Client C                       |
      |       |    |                  | link-local address fe80::cccc        |
      |       |    |                  | delegated prefix 2001:db8:ddd0:2::/64|
      |       |    |                  +--------------+-+---------------------+
      |       |    |                                 | |
 +----+-------+----+-----------------------------+   | | Router Advertisement
 |                    Client A                   |   | | containing PIO
 |        link-local address: fe80::aaaa         |   | v 2001:db8:ddd0:2::/64
 |      delegated prefix: 2001:db8:ddd0:1::/64   |   |
 | +---------------------+  +------------------+ |  -+-----------+---------
 | |   virtual system    |  |   virtual system | |               |
 | | 2001:db8:ddd0:1::f00|  |2001:db8:ddd0:1::2| |     +---------+-----------+
 | | 2001:db8:ddd0:1::caf|  |2001:db8:ddd0:1::a| |     |   Tethered device   |
 | +---------------------+  +------------------+ |     |2001:db8:ddd0:2::6666|
 |                                               |     +---------------------+
 +-----------------------------------------------+
]]>
</artwork>
</artset>
</figure>

    </section>

    <section>
    <name>Applicability and Limitations</name>
	    <t>
		    Delegating

    <t>Delegating a unique prefix per client provides all the benefits of both
    SLAAC and DHCPv6 address allocation, but at the cost of greater address space address-space usage.  This design would substantially benefit some networks (see
    <xref target="benefits"/>), target="benefits"/>) in which the additional cost of an additional
    service (DHCPv6 prefix delegation) (such as DHCPv6 Prefix Delegation) and allocating allocation of a larger amount of
    address space can easily be justified.  Examples of such networks include
    but are not limited to:
	    </t> to:</t>

	    <ul>
		    <li>
			    Large-scale
	      <li>Large-scale networks where even 3-5 three to five addresses per client
	      might introduce scalability issues.
		    </li>
		    <li>
			    Networks issues.</li>
	      <li>Networks with a high number of virtual hosts, so physical
	      devices require multiple addresses.
		    </li>
		    <li>
			    Managed addresses.</li>
	      <li>Managed networks where extensive troubleshooting, device
	      traffic logging, or forensics might be required.
		    </li> required.</li>
	    </ul>
	    <t>
		    In
	    <t>In smaller networks, such as home networks or small enterprises,
	    enterprises with smaller address space and a lower number of
	    clients, SLAAC is a simpler and often preferred option.
	    </t> option.</t>

    </section>

    <section>
    <name>Routing and Addressing Considerations</name>
      <section>
      <name>Prefix Pool Allocation</name>
        <t>One simple deployment model is to assign a dedicated prefix pool to
        each link. The prefixes from each link's pool are only issued to
        requesting clients on the link, and link; if clients move to another link link,
        they will obtain a prefix from the pool associated with the new link
        (see <xref target="mobility"/>).</t>

	<t>This is very similar to how address pools are allocated when using
	DHCP to assign individual addresses (e.g., DHCPv4 or DHCPv6 IA_NA),
	where each link has a dedicated pool of addresses, and clients on the
	link obtain addresses from the pool. In this model, the network can
	route the entire pool to the link's first-hop routers, and the routers
	do not need to advertise individual delegated prefixes into the
	network's dynamic routing protocol.</t>

        <t>Other deployment models, such as prefix pools shared over multiple
        links or routers, are possible, possible but are not described in this
        document.</t>
      </section>

    <section>
	    <name>
			   First-Hop
      <name>First-Hop Router Requirements
	    </name>
	    <t>
		    In Requirements</name>
    <t>In large networks, DHCPv6 servers are usually centralized, centralized and reached
    via DHCPv6 relays co-located with the first-hop routers.  To delegate IPv6
    prefixes to clients, the first hop routers need to implement DHCPv6 relay
    functions and meet the requirements defined in <xref target="RFC8987"/>.
    In particular, per <xref target="RFC8987" sectionFormat="of" section="4.2"/>, the first-hop
    router must maintain a local routing table that contains all prefixes
    delegated to clients.</t>

    <t>With the first-hop routers performing DHCPv6 relay functions, the
    proposed design neither requires any subsequent relays in the path nor
    introduces any requirements (e.g., snooping) to for such subsequent relays, if
    they are deployed.  </t>

<t>
To deployed.</t>

    <t>To ensure that routes to the delegated prefixes are preserved even if a
    relay is rebooted or replaced, the operator MUST <bcp14>MUST</bcp14> ensure
    that all relays in the network infrastructure support DHCPv6 Bulk
    Leasequery as defined in <xref target="RFC5460"/>. While Section 4.3 of <xref target="RFC8987"/>
    target="RFC8987" section="4.3" sectionFormat="of"/> lists keeping active
    prefix delegations in persistent storage as an alternative to DHCPv6 Bulk
    Leasequery, relying on persistent storage has the following drawbacks:
    </t>
<ul>
<li>

<!--[rfced] For ease of the reader, how may we add additional context and/or
verbs to clarify the items in parentheses below?

Original:

   *  In a network with multiple relays, network state can change
      significantly while the relay is rebooting (new prefixes
      delegated, some prefixes expiring etc).
</li>
<li>
Persistent

Perhaps:

   *  In a network with multiple relays, network state can change
      significantly while the relay is rebooting (new prefixes might
      be delegated or some prefixes might be expiring, etc).

-->

<ul>
      <li>In a network with multiple relays, network state can change
      significantly while the relay is rebooting (new prefixes delegated, some
      prefixes expiring, etc.).</li>
      <li>Persistent storage might not be preserved if the router is
      physically replaced.
</li> replaced.</li>
    </ul>
    <t>Another mechanism for first-hop routers to obtain information about
    delegated prefixes is by using Active Leasequery <xref target="RFC7653"/>,
    though this is not yet widely supported.</t>
    </section>

    <section anchor="mult_relays">
	    <name>
			    Topologies
    <name>Topologies with Multiple First-Hop Routers
	    </name>
	    <t>
		    In Routers</name>

    <t>In a topology with redundant first-hop routers, all the routers need to
    relay DHCPv6 traffic, install the delegated prefixes into their routing
    tables and, if needed, advertise those prefixes to the network.</t>

    <t>If the first-hop routers obtain information about delegated prefixes by
    snooping DHCPv6 Reply messages sent by the server, then all the first-hop
    routers must be able to snoop these messages. This is possible if the
    client multicasts the DHCPv6 messages it sends to the server. The server
    will receive one copy of the client message through each first-hop relay,
    and will reply unicast to each of them via the relay (or chain of relays)
    from which it received the message. Thus, all first-hop relays will be
    able to snoop the replies. Per <xref target="RFC8415" sectionFormat="of" section="14"/>,
    clients always use multicast unless the server uses the Server Unicast
    option to explicitly allow unicast communication (<xref target="RFC8415"
    section="21.12" sectionFormat="comma"/>). Therefore, in topologies with
    multiple first-hop routers, the DHCPv6 servers MUST <bcp14>MUST</bcp14> be
    configured not to use the Server Unicast option. It should be noted that
    <xref target="I-D.ietf-dhc-rfc8415bis"/> deprecates the Server Unicast
    option precisely because it is not compatible with topologies with
    multiple first-hop relays.
	    </t> relays.</t>

    <t>To recover from crashes or reboots, relays can use Bulk Leasequery or
    Active Leasequery to issue a QUERY_BY_RELAY_ID with the ID(s) of the other
    relay(s), as configured by the operator. Additionally, some vendors
    provide vendor-specific mechanisms to synchronize state between DHCP
    relays.</t>
    </section>

    <section>
<name>On-link
      <name>On-Link Communication </name>
<t>
For
      <t>For security reasons, some networks block on-link device-to-device
      traffic at layer Layer 2 to prevent communication between clients on the same
      link.  In this case, delegating a prefix to each client doesn't affect
      traffic flows, as all traffic is sent to the first-hop router anyway.
      Depending on the network security policy, the router may allow or drop
      the traffic.
</t>
<t>
If traffic.</t>

      <t>If the network does allow peer-to-peer communication, the PIO for the
      on-link prefix is usually advertised with the L-bit set to 1 <xref
      target="RFC4861"/>.  As a result, all addresses from that prefix are
      considered on-link, and traffic to those destinations is sent directly
      (not via routers).  If such a network delegates prefixes to clients (as
      described in this document), then each client will consider other
      client's destination addresses to be off-link, because those addresses
      are from the delegated prefixes and are no longer within the on-link
      prefix.  When a client sends traffic to another client, packets will
      initially be sent to the default router.  The router will respond with
      an ICMPv6 redirect message (Section 4.5 of <xref (<xref target="RFC4861" />). section="4.5"
      sectionFormat="of"/>). If the client receives and accepts the redirect,
      then traffic can flow directly from device to device.
Therefore  Therefore, the
      administrator deploying the solution described in this document SHOULD
      <bcp14>SHOULD</bcp14> ensure that the first-hop routers can send ICMPv6
      redirects (the routers are configured to do so and the security policies
      permit those messages).
</t> messages).</t>
    </section>
    </section>

    <section>
    <name>DHCPv6-PD Server Considerations</name>
	    <t>
This

    <t>This document does not introduce any changes to the DHCPv6 protocol
    itself.  However, for the proposed solution to work correctly, the
    DHCPv6-PD server needs to be configured as follows:
	    </t> follows:</t>
    <ul>
		    <li>
			    The
      <li>The server MUST <bcp14>MUST</bcp14> follow recommendations from <xref
      target="RFC8168"/> recommendations on processing prefix-length hints.
</li>
<li>
The hints.</li>
      <li>The server MUST <bcp14>MUST</bcp14> provide a prefix short enough for the
      client to extend the network to at least one interface, interface and allow nodes
      on that interface to obtain addresses via SLAAC.  The server MAY
      <bcp14>MAY</bcp14> provide more address space to clients that ask for
      it, either by delegating multiple such prefixes, or by delegating a
      single prefix of a shorter length. It should be noted that <xref
      target="RFC8168"/> allows the server to provide a prefix shorter than
      the prefix-length hint value received from the client.
</li>
		    <li>
			    If client.</li>
      <li>If the server receives the same SOLICIT Solicit message from the same
      client multiple times through multiple relays, it MUST <bcp14>MUST</bcp14>
      reply to all of them with the same prefix(es).  This ensures that all
      the relays will correctly configure routes to the delegated prefixes.
		    </li>
		    <li>
			    The prefixes.</li>
      <li>The server MUST NOT <bcp14>MUST NOT</bcp14> send the Server Unicast option to
      the client unless the network topology guarantees that no client is
      connected to a link with multiple relays (see <xref target="mult_relays"/>).
		    </li>
		    <li>
			    In
      target="mult_relays"/>).</li>
      <li>In order to ensure uninterrupted connectivity when a first-hop
      router crashes or reboots, the server MUST <bcp14>MUST</bcp14> support Bulk
      Leasequery or Active Leasequery.
		    </li> Leasequery.</li>
    </ul>
<t>
As

    <t>As most operators have some experience with IPv4, they can use a
    similar approach for choosing the pool size and the timers (such as T1/T2
    timers).  In particular, the following factors shall be taken into account:</t>

<!--[rfced] FYI - We have slightly adjusted the list items below for
consistency. Please review and let us know if these changes alter your
intended meaning.

Original:
   In particular the following factors shall be taken
   into account:
</t>
<ul>
<li>

   *  the expected maximum number of clients;
</li>
<li>

   *  average duration of a client connection;
</li>
<li>

   *  how mobile the clients are (a network where all clients are
      connected to a single wired VLAN might choose longer timers than a
      network where clients can switch between multiple wireless SSIDs);
</li>
<li>

   *  expected level of recurring clients (for example, a corporate
      authenticated Wi-Fi network might be using longer timers than an
      open public Wi-Fi).

Current:
   In particular, the following factors shall be taken
   into account:

   *  the expected maximum number of clients;

   *  the average duration of a client connection;

   *  the mobility of the clients (for example, a network where all
      clients are connected to a single wired VLAN might choose longer
      timers than a network where clients can switch between multiple
      wireless SSIDs);

   *  the expected level of recurring clients (for example, a corporate
      authenticated Wi-Fi network might be using longer timers than an
      open public Wi-Fi).
</li>
-->

    <ul>
      <li>the expected maximum number of clients;</li>
      <li>the average duration of a client connection;</li>
      <li>the mobility of the clients (for example, a network where all clients are
      connected to a single wired VLAN might choose longer timers than a
      network where clients can switch between multiple wireless SSIDs);</li>
      <li>the expected level of recurring clients (for example, a corporate
      authenticated Wi-Fi network might be using longer timers than an open
      public Wi-Fi).</li>
    </ul>

<t>

<!-- [rfced] RFC 8501 does not have a section 2.5.2.  Perhaps the text should refer to section 2.3.2 (see https://www.rfc-editor.org/rfc/rfc8501#section-2.3.2)?

Original:
   DHCPv6 servers that delegate prefixes can interface with Dynamic DNS
   infrastructure to automatically populate reverse DNS, similarly to
   what is described in section 2.5.2 of RFC [RFC8501].
-->

    <t>DHCPv6 servers that delegate prefixes can interface with Dynamic DNS
    infrastructure to automatically populate reverse DNS, similarly to what is
    described in <xref target="RFC8501"/>. target="RFC8501" sectionFormat="of"
    section="2.5.2"/>. Networks that also wish to populate forward DNS cannot
    do so automatically based only on DHCPv6 prefix delegation transactions,
    but they can do so in other ways, such as by supporting DHCPv6 address
    registration as described in <xref target="I-D.ietf-dhc-addr-notification"/>.
</t>
    target="I-D.ietf-dhc-addr-notification"/>.</t>

    <t>Some additional recommendations driven by security and privacy
    considerations are discussed in <xref target="Security"/> and <xref
    target="privacy"/>.</t>
    </section>

    <section>
    <name>Prefix Length Considerations</name>

    <t>Delegating a prefix of sufficient size to use SLAAC allows the client
    to extend the network, providing limitless addresses to IPv6 nodes
    connected to it (e.g., virtual machines, machines or tethered devices), because all
    IPv6 hosts are required to support SLAAC <xref
    target="RFC8504"/>. Additionally, even clients that support other forms of
    address assignment require SLAAC for some functions, such as forming
    dedicated addresses for the use of 464XLAT (see Section 6.3 of <xref target="RFC6877"/>).</t>
    target="RFC6877" section="6.3" sectionFormat="of"/>).</t>

   <t>At the time of writing writing, the only prefix size that will allow devices to
   use SLAAC is 64 bits. Also, as noted in <xref target="RFC7421"/>, using an IID interface identifier (IID) shorter than 64 bits and a subnet prefix longer than 64 bits is outside
   the current IPv6 specifications.  Choosing longer prefixes would require
   the client and any connected system to use other address assignment
   mechanisms.  This would limit the applicability of the proposed solution,
   as other mechanisms are not currently supported by many hosts.
</t> hosts.</t>

   <t>For the same reasons, a prefix length of /64 or shorter is required to
   extend the network using as described in <xref target="RFC7084"/> (see requirement L-2),
   and a prefix length of /64 is required to provide global connectivity for
   stub networks as per <xref target="I-D.ietf-snac-simple"/>.</t>

	    <t>
            Assigning

   <t>Assigning a prefix of sufficient size to support SLAAC is possible on
   large networks. In general, any network that numbers clients from an IPv4
   prefix of length X (e.g., X=/18, X=/24), X=/24) would require an IPv6 prefix of
   length X+32 (e.g., X=/40, X=/56) to provide a /64 prefix to every device.
   As an example, <xref target="RFC7934" section="9.2"/> suggests that even a
   very large network that assigns every single one of the 16 million IPv4
   addresses in 10.0.0.0/8 would only need an IPv6 /40. A /40 prefix is a
   small amount of address space: there are 32 times more /40s in the current
   IPv6 unicast range 2000::/3 than there are IPv4 addresses.  Existing sites
   that currently use a /48 prefix cannot support more than 64k clients in
   this model without renumbering, though many networks of such size have LIR Local Internet Registry (LIR) status and can justify bigger address blocks.
	    </t> blocks.</t>

   <t>Note that assigning a prefix of sufficient size to support SLAAC does
   not require that subtended nodes use SLAAC; they can use other address
   assignment mechanisms as well.</t>
   </section>

<section anchor="mobility">
<name>Client Mobility</name>
<t>
As

<t>As per Section 18.2.12 of <xref target="RFC8415"/>, target="RFC8415" section="18.2.12" sectionFormat="of"/>, when
the client moves to a new link, it MUST <bcp14>MUST</bcp14> initiate a Rebind/Reply
message exchange. Therefore Therefore, when the client moves between network attachment points
points, it would refresh its delegated prefix the same way it refreshes
addresses assigned (via SLAAC or DHCPv6 IA_NA) from a shared on-link prefix:
</t> prefix:</t>

<ul>

<li>
When
  <li>When a client moves from between different attachment points on the same
  link (e.g., roams between two APs while connected to the same SSID or moves
  between two switchports switch ports belonging to the same VLAN), the delegated prefix
  does not change, and the first-hop routers have a route for the prefix with
  the nexthop set to the client link-local address on that link. As per
  requirement S-2 (Section 4.3 of in <xref target="RFC8987"/>), target="RFC8987" section="4.3" sectionFormat="of"/>, the DHCPv6-relays
  (the first-hop routers) MUST <bcp14>MUST</bcp14> retain the route for the
  delegating prefix until the route is released or removed due to expiring
  DHCP timers. Therefore, if the client reconnects to the same link, the
  prefix doesn't change.
</li>

<li>
When change.</li>
  <li>When a client moves to a different link, the DHCPv6 server provides the
  client with a new prefix, so the behaviour behavior is consistent with SLAAC or
  DHCPv6-assigned addresses, which are also different on the new link.
</li> link.</li>
</ul>

<t>
In

<t>In theory, DHCPv6 servers can delegate the same prefix to the same client
even if the client changes the attachment points.  However, while allowing the
client to keep the same prefix while roaming between links might provide some
benefits for the client, it is not feasible without changing DHCPv6 relay behaviour:
behavior: after the client moves to a new link, the DHCPv6 relays would
retain the route pointing to the client's link-local address on the old link
for the duration of DHCPv6 timers (see requirement S-2, Section 4.3 of <xref target="RFC8987"/>). target="RFC8987"
section="4.3" sectionFormat="of"/>).  As a result, the first-hop routers would
have two routes for the same prefix pointing to different links, causing
connectivity issues for the client.
</t> client.</t>

<t>It should be noted that addressing clients from a shared on-link prefix
also does not allow clients to keep addresses while roaming between links, so
the proposed solution is not different in that regard. In addition to that, quite often
different links often have different security policies applied (for
example, corporate internal network vs networks versus guest network), networks), hence clients on
different links need to use different prefixes.
</t> prefixes.</t>
</section>

<!--[rfced] We were unable to find the phrase "unicast Reverse Path
Forwarding (uRPF)" in RFC 3704. However, other types of Reverse Path
Forwarding do appear (e.g., Loose RPF, Feasible RPF, Strict RPF). Are any
updates needed to the text or citation below?

Original:

   Enabling the unicast Reverse Path Forwarding (uRPF, [RFC3704]) on the
   first-hop router interfaces towards clients provides the first layer
   of defense against spoofing.

-->

<section anchor="savi">
   <name>Antispoofing and SAVI Interaction</name>
	    <t>
		    Enabling
<!-- [rfced] Please clarify "another client link-local address".  Should this be "another client's link-local address"?

Original:
   Therefore the malicious client can only spoof addresses
   already delegated to another client on the same link or another
   client link-local address.
-->

    <t>Enabling unicast Reverse Path Forwarding (uRPF, (uRPF) <xref target="RFC3704"/>)
    target="RFC3704"/> on the first-hop router interfaces towards clients
    provides the first layer of defense against spoofing.  A spoofed packet
    sent by a malicious client would be dropped by the router unless the
    spoofed address belongs to a prefix delegated to another client on the
    same interface.
		    Therefore  Therefore, the malicious client can only spoof addresses
    already delegated to another client on the same link or another client
    link-local address.
	    </t>
	    <t>
		    Source address.</t>

    <t>Source Address Validation Improvement (SAVI, (SAVI) <xref target="RFC7039"/>) target="RFC7039"/>
    provides more reliable protection against address spoofing.
    Administrators deploying the proposed solution on SAVI-enabled
    infrastructure SHOULD <bcp14>SHOULD</bcp14> ensure that SAVI perimeter devices
    support DHCPv6-PD snooping to create the correct binding for the delegated
    prefixes (see <xref target="RFC7513"/>).  Using FCFS SAVI (<xref target="RFC6620"/>) for protecting <xref
    target="RFC6620"/> to protect link-local addresses and creating create SAVI
    bindings for DHCPv6-PD assigned prefixes would prevent spoofing.
	    </t>

<t>
Some spoofing.</t>

    <t>Some infrastructure devices do not implement SAVI as defined in <xref target="RFC7039"/> but
    target="RFC7039"/>; instead, they perform other forms of address tracking and
    snooping for security or performance improvement purposes (e.g., ND
    proxy).  This is very common behaviour behavior for wireless devices (access (such as access points
    and controllers).  Administrators SHOULD <bcp14>SHOULD</bcp14> ensure that such
    devices are able to snoop DHCPv6-PD packets, packets so the traffic from the
    delegated prefixes is not dropped.
</t>
<t>
It dropped.</t>

    <t>It should be noted that using DHCPv6-PD makes it harder for an attacker
    to select the spoofed source address.  When all clients are using the same
    shared link to form addresses, the attacker might learn addresses used by
    other clients by listening to multicast Neighbor Solicitations and Neighbour
    Neighbor Advertisements.  In DHCPv6-PD environments, however, the
    attacker can only learn about other clients's clients' global addresses by
    listening to multicast DHCPv6 messages, which are not transmitted so
    often, and may not be received by the client at all because they are sent
    to multicast groups that are specific to DHCPv6 servers and relays.
</t> relays.</t>

    </section>

    <section>
    <name>Migration Strategies and Co-existence with SLAAC Using Prefixes From from the PIO</name>
	    <t>
		    It

    <t>It would be beneficial for the network to explicitly indicate its
    support of DHCPv6-PD for connected clients.
	    </t> clients.</t>
    <ul>
		    <li>
		    In
<!-- [rfced] Is the closing parenthesis misplaced?  If the suggested text is incorrect, please clarify what happens when the prefix is too small.

Original:
      If every phone or laptop in a home network
      were to request a unique prefix suitable for SLAAC, the home
      network might run out of prefixes, if the prefix allocated to the
      CPE by its ISP is too small (e.g., if an ISP delegates a /60, it
      would only be able to delegate 15 /64 prefixes to clients).

Perhaps:
      If every phone or laptop in a home network
      were to request a unique prefix suitable for SLAAC, the home
      network might run out of prefixes.  If the prefix allocated to the
      Customer Premises Equipment (CPE) by its ISP is too small (e.g., if
      an ISP delegates a /60), it would only be able to delegate 15
      /64 prefixes to clients.
-->

      <li>In small networks (e.g., home networks), where the number of clients
      is not too high, the number of available prefixes becomes a limiting
      factor.  If every phone or laptop in a home network were to request a
      unique prefix suitable for SLAAC, the home network might run out of
      prefixes, if the prefix allocated to the CPE Customer Premises Equipment (CPE) by its ISP is too small
      (e.g., if an ISP delegates a /60, it would only be able to delegate 15
      /64 prefixes to clients).  So while the enterprise network administrator
      might want all phones in the network to request a prefix, it would be
      highly undesirable for the same phone to request a prefix when
      connecting to a home network.
		    </li>
		    <li>
			    When network.</li>

<!--[rfced] How may we update the text below for clarity? Specifically, what
two items does "both" refer to, and should "that SLAAC addresses" be plural or
singular?

Original:

      Starting both SLAAC using the PIO prefix and DHCPv6-PD and deprecating
      that SLAAC addresses after receiving a delegated prefix would be very
      disruptive for applications.

Perhaps:

      Starting both DHCPv6-PD and SLAAC using the PIO prefix and then
      deprecating that SLAAC address after receiving a delegated prefix
      would be very disruptive for applications.
-->

      <li>When the network supports both a unique prefix per client and a PIO
      with A=1 as address assignment methods, it's highly desirable for the
      client NOT to use the PIO prefix to form global addresses and instead only use
      the prefix delegated via DHCPv6-PD.  Starting both SLAAC using the PIO
      prefix and DHCPv6-PD and deprecating that SLAAC addresses after
      receiving a delegated prefix would be very disruptive for applications.
      If the client continues to use addresses formed from the PIO prefix prefix, it
      would not only undermine the benefits of the proposed solution (see
      <xref target="benefits"/>), but it would also introduce complexity and
      unpredictability in the source address selection.  Therefore, the client
      needs to know what address assignment method to use and whether or not to use
      the prefix in PIO or not, the PIO, if the network provides the PIO with A the 'A' flag set.
		    </li>
      set.</li>
    </ul>
	    <t>
                The

    <t>The deployment model described in this document does not require the
    network to signal support of DHCPv6-PD: for example, devices acting as <xref target="RFC7084"/>
    compatible routers <xref target="RFC7084"/> will be able to receive
    prefixes via DHCPv6-PD even without such signalling. signaling. Also, some clients
    may decide to start DHCPv6-PD, DHCPv6-PD and acquire prefixes, prefixes if they detect that
    the network does not provide addresses via SLAAC. To fully achieve the
    benefits described in this section, <xref target="I-D.collink-6man-pio-pflag"/>
    target="I-D.ietf-6man-pio-pflag"/> defines a new PIO flag to signal
    that DHCPv6-PD is the preferred method of obtaining prefixes.
	    </t> prefixes.</t>
    </section>

    <section anchor="benefits">
    <name>Benefits</name>
	    <t>
		    The

<!--[rfced] FYI - For ease of the reader, we have updated the text below as
follows. Please review and let us know if this change alters your
intended meaning.

Original:

  DHCPv6-PD logs and first-hop routers routing tables provide
  complete information...

Current:

  DHCPv6-PD logs and routing tables for first-hop routers provide
  complete information...

-->

<t>The proposed solution provides the following benefits:
	    </t> benefits:</t>
	    <ul>
		    <li>
			    Network
	      <li>Network device resources (e.g., memory) need to scale to the
	      number of devices, not the number of IPv6 addresses.  The
	      first-hop routers have a single route per device pointing to the
	      device's link-local address. This can potentially enable
	      hardware cost savings, savings; for example example, if hardware such as wireless
	      LAN controllers is limited to supporting only a specific number
	      of client addresses, or in VXLAN deployments where each client
	      address consumes one routing table
			    entry.
		    </li>
		    <li>
			    The entry.</li>
	      <li>The cost of having multiple addresses is offloaded to the
	      clients.  Hosts are free to create and use as many addresses as
	      they need without imposing any additional costs onto the network.
		    </li>
		    <li>
			    If
	      network.</li>
	      <li>If all clients connected to the given link support this mode
	      of operation and can generate addresses from the delegated
	      prefixes, there is no reason to advertise a common prefix
	      assigned to that link in the PIO with the 'A' flag set.
Therefore  Therefore, it is
	      possible to remove the global shared prefix from that link and
	      the router interface completely, so no global addresses are
	      on-link for the link.  This would lead to reducing the attack
	      surface for Neighbor Discovery attacks described in <xref target="RFC6583"/>.
		    </li>
		    <li>
			    DHCPv6-PD
	      target="RFC6583"/>.</li>
	      <li>DHCPv6-PD logs and first-hop routers routing tables for first-hop routers provide
	      complete information on IPv6 to MAC mapping, which can be used
	      for forensics and troubleshooting.  Such information is much
	      less dynamic than the ND cache and therefore cache; therefore, it's much easier for an
	      operator to collect and process it.
		    </li>
<li>
A it.</li>
	      <li>A dedicated prefix per client allows the network
	      administrator to create per-device security policies (ACLs) per device (such as ACLs) even
	      if the client is using temporary addresses. This mitigates one
	      of the issues described in <xref target="I-D.ietf-opsec-ipv6-addressing"/>.
</li>
		    <li> target="I-D.ietf-opsec-ipv6-addressing"/>.</li>
<!-- [rfced] Does "or not" mean "not all of them work", "none of them work", or otherwise?  Please clarify.

Original:
   *  Fate sharing: all global addresses used by a given client are
      routed as a single prefix.  Either all of them work or not, which
      makes failures easier to diagnose and mitigate.
		    </li>
                    <li>
                           Lower
-->

	      <li>Fate sharing: all global addresses used by a given client
	      are routed as a single prefix.  Either all of them work or not,
	      which makes failures easier to diagnose and mitigate.</li>
              <li>Lower level of multicast traffic: less Neighbor Discovery (<xref target="RFC4861"/>)
              <xref target="RFC4861"/> multicast packets, as there are only clients link-local addresses the routers need to resolve. resolve only the clients' link-local addresses.  Also, there is no DAD Duplicate Address Detection (DAD) traffic
   except for the clients' link-local addresses.
                    </li>
<li>
Ability addresses.</li>
	      <li>Ability to extend the network transparently. If the network
	      delegates to the client a prefix of sufficient size to support
	      SLAAC, the client can to provide connectivity to other hosts, as
	      is possible in IPv4 with NAT (e.g., by acting as an IPv6 CE Customer Edge (CE)
	      router as described in <xref target="RFC7084"/>).
</li> target="RFC7084"/>).</li>
	    </ul>
    </section>

    <section anchor="privacy">
	    <name>Privacy Considerations</name>
	    <t>
		    If
	    <t>If an eavesdropper or information collector is aware that a
	    given client is using the proposed mechanism, then they may be
	    able to track the client based on its prefix.  The privacy
	    implications of this are equivalent to the privacy implications of
	    networks using stateful DHCPv6 address assignment: in both cases,
	    the IPv6 addresses are determined by the server, either because
	    the server assigns a full 128-bit address in a shared prefix, or
	    because the server determines what prefix is delegated to the
	    client.  Administrators deploying the proposed mechanism can use
	    similar methods to mitigate the impact as the ones used today in
	    networks that use stateful DHCPv6 address assignment.</t>

            <t>Except for networks (such as datacenter networks) where hosts
            do not need temporary addresses (<xref target="RFC8981"/>), <xref target="RFC8981"/>, the
            network SHOULD:</t> <bcp14>SHOULD</bcp14>:</t>
	    <ul>
	      <li>Ensure that when a client requests a prefix, the prefix is
	      randomly assigned and not allocated deterministically.</li>
	      <li>Use short prefix lifetimes (e.g., hours), hours) to ensure that
	      when a client disconnects and reconnects it gets a different
	      prefix.</li>
	      <li>Allow the client to have more than one prefix at the same
	      time. This allows the client to rotate prefixes using a
	      mechanism similar to temporary addresses, but that operates on
	      prefixes instead of on individual addresses.  In this case case, the
	      prefix's lifetime MUST <bcp14>MUST</bcp14> be short enough to allow
	      the client to use a reasonable rotation interval without using
	      too much address space.  For example, if every 24 hours the the
	      client asks for a new prefix and stops renewing the old prefix,
	      and the Valid Lifetime of delegated prefixes is one hour, then
	      the client will consume two prefixes for one hour out of 24
	      hours, and thus will on average consume just under 1.05
	       prefixes.</li>
	      prefixes on average.</li>
           </ul>
    </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 includes document has no request to IANA.</t> IANA actions.</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> A
      <t>A malicious (or just misbehaving) client might attempt to exhaust the
      DHCPv6-PD pool by sending a large number of requests with differing DUIDs.
      DHCP Unique Identifiers (DUIDs). To prevent a misbehaving client from denying service to other
      clients, the DHCPv6 server or relay MUST <bcp14>MUST</bcp14> support limiting
      the number of prefixes delegated to a given client at any given
      time.</t>

      <t>Networks can protect against malicious clients by authenticating
      devices using tokens that cannot be spoofed (e.g., 802.1x
      authentication) and limiting the number of link-local addresses or MAC
      addresses that each client is allowed to use. Note that this is not a new
      issue, as the same attack might be implemented using DHCPv4 or DHCPv6
      IA_NA requests; in particular, while it is unlikely for clients to be
      able to exhaust an IA_NA address pool, clients using IA_NA can exhaust
      other resources such as DHCPv6 and routing infrastructure resources such as
      server RAM, ND cache entries, TCAM Ternary Content-Addressable Memory (TCAM) entries, SAVI entries, etc.
	      </t>
      <t>
	      A etc.</t>

      <t>A malicious client might request a prefix and then release it very
      quickly, causing routing convergence events on the relays.  The impact
      of this attack can be reduced if the network rate-limits the amount of
      broadcast and multicast messages from the client.
      </t>
      <t>
	      Delegating client.</t>

      <t>Delegating the same prefix for the same client introduces privacy
      concerns.  The proposed mitigation is discussed in <xref target="privacy"/>.
      </t>
      <t>
	      Spoofing
      target="privacy"/>.</t>

      <t>Spoofing scenarios and prevention mechanisms are discussed in <xref target="savi"/>.
      </t> target="savi"/>.</t>
    </section>

    <!-- NOTE: The Acknowledgements and Contributors sections are at the end of this template -->

  </middle>

  <back>
    <displayreference target="I-D.ietf-6man-pio-pflag" to="PIO-PFLAG"/>
    <displayreference target="I-D.ietf-dhc-rfc8415bis" to="RFC8415bis"/>
    <displayreference target="I-D.ietf-dhc-addr-notification" to="ADDR-NOTIFICATION"/>
    <displayreference target="I-D.ietf-opsec-ipv6-addressing" to="IPv6-ADDRESS"/>
    <displayreference target="I-D.ietf-snac-simple" to="SNAC-SIMPLE"/>

    <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.4193.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7084.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5460.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6620.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.8168.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.8273.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8415.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8981.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8987.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.3704.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4861.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.6459.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6583.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7039.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7278.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7348.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7421.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7513.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7653.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7934.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8501.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8504.xml"/>

<!-- [I-D.ietf-6man-pio-pflag] IESG state: I-D Exists as of 07/09/24 -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.collink-6man-pio-pflag.xml"/> href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-pio-pflag.xml"/>

<!-- [I-D.ietf-dhc-rfc8415bis] IESG state: I-D Exists as of 07/09/24 -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-rfc8415bis.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-addr-notification"/>

<!-- [I-D.ietf-dhc-addr-notification] IESG state: In RFC Ed Queue as of 07/09/24 -->
<reference anchor="I-D.ietf-dhc-addr-notification" target="https://datatracker.ietf.org/doc/html/draft-ietf-dhc-addr-notification-13">
  <front>
    <title>Registering Self-generated IPv6 Addresses using DHCPv6</title>
    <author fullname="Warren Kumari" initials="W." surname="Kumari">
      <organization>Google, LLC</organization>
    </author>
    <author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
      <organization>Cisco Systems, Inc.</organization>
    </author>
    <author fullname="Rajiv Asati" initials="R." surname="Asati">
      <organization>Independent</organization>
    </author>
    <author fullname="Lorenzo Colitti" initials="L." surname="Colitti">
      <organization>Google, LLC</organization>
    </author>
    <author fullname="Jen Linkova" initials="J." surname="Linkova">
      <organization>Google, LLC</organization>
    </author>
    <author fullname="Sheng Jiang" initials="S." surname="Jiang">
      <organization>Beijing University of Posts and Telecommunications</organization>
    </author>
    <date day="16" month="May" year="2024"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-dhc-addr-notification-13"/>
</reference>

<!-- [I-D.ietf-opsec-ipv6-addressing] IESG state: Expired as of 04/08/24 -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-opsec-ipv6-addressing.xml"/>

<!-- [I-D.ietf-snac-simple] IESG state: I-D Exists as of 06/20/24 -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-snac-simple.xml"/>

      </references>
    </references>

    <section anchor="appendix" title="Appendix: Multiple anchor="appendix">
      <name>Multiple Addresses Considerations"> Considerations</name>

      <t>While a typical IPv4 host normally has only one IPv4 address per
      interface, an IPv6 device almost always has multiple addresses assigned
      to its interface.  At the very least, a host can be expected to have one
      link-local address, one temporary address, and, in most cases, one
      stable global address.  On a network providing NAT64 service, an
      IPv6-only host running the 464XLAT customer-side translator (CLAT, (CLAT) <xref target="RFC6877"/>)
      target="RFC6877"/> would use a dedicated 464XLAT address, configured
      via SLAAC (see Section 6.3 of <xref target="RFC6877"/>), target="RFC6877" section="6.3" sectionFormat="of"/>), which brings
      the total number of addresses to 4. four.  Other common scenarios where the
      number of addresses per host interface might increase significantly, significantly
      include but are not limited to:
</t> to:</t>

      <ul>

<li>
Devices
	<li>Devices running containers/namespaces: each container/namespace
	would have multiple addresses as described above. As a result, a
	device running just a few containers in a bridge mode can easily have
	20 or more IPv6 addresses on the given link.
</li>

<li>
Networks link.</li>
	<li>Networks assigning multiple prefixes to a given link: these include multihomed
	networks, networks using ULA <xref target="RFC4193"/> and non-ULA
	prefixes together, or network networks performing a graceful renumbering from
	one prefix to another.
</li> another.</li>
      </ul>

      <t>
	      <xref

      <t><xref target="RFC7934"/> discusses this aspect and explicitly states
      that IPv6 deployments SHOULD NOT <bcp14>SHOULD NOT</bcp14> limit the number of IPv6
      addresses a host can have.  However, it has been been observed that
      networks often do limit the number of on-link addresses per device,
      likely in an attempt to protect network resources and prevent DoS attacks.
</t>
<t>
	    The
      attacks.</t>

      <t>The most common scenario of network-imposed limitations is Neighbor Discovery (ND) ND proxy.  Many enterprise-scale wireless solutions
      implement ND proxy to reduce the amount of broadcast and multicast
      downstream (AP to clients) traffic and provide SAVI functions.  To
      perform ND proxy, a device usually maintains a table, table containing IPv6
      and MAC addresses of connected clients.  At least some implementations
      have hardcoded limits on how many IPv6 addresses per single MAC such a
      table can contain.  When the limit is exceeded exceeded, the behaviour behavior is implementation-dependent.
      implementation dependent. Some vendors just fail to install an N+1 address
      to the table.  Others delete the oldest entry for this MAC and replace
      it with the new address. In any case, the affected addresses lose
      network connectivity without receiving any implicit signal, with traffic
      being silently dropped.
	    </t> dropped.</t>
    </section>

    <section anchor="Acknowledgements" numbered="false">
      <!-- [REPLACE/DELETE] an Acknowledgements section is optional -->
      <name>Acknowledgements</name>
      <t>Thanks to Harald Alvestrand, Nick Buraglio, Brian Carpenter, Tim Chown, Roman Danyliw, Gert Doering, David Farmer, Fernando Gont, Joel Halpern, Nick Hilliard, Bob Hinden, Martin Hunek, Erik Kline, Warren Kumari, David Lamparter, Andrew McGregor, Tomek Mrugalski, Alexandre Petrescu, Jurgen Schonwalder, Pascal Thubert, Ole Troan, Eric Vyncke, Eduard Vasilenko, Timothy Winters, Chongfeng Xie, Peter Yee <contact fullname="Harald Alvestrand"/>, <contact
      fullname="Nick Buraglio"/>, <contact fullname="Brian Carpenter"/>,
      <contact fullname="Tim Chown"/>, <contact fullname="Roman Danyliw"/>,
      <contact fullname="Gert Doering"/>, <contact fullname="David Farmer"/>,
      <contact fullname="Fernando Gont"/>, <contact fullname="Joel Halpern"/>,
      <contact fullname="Nick Hilliard"/>, <contact fullname="Bob Hinden"/>,
      <contact fullname="Martin Hunek"/>, <contact fullname="Erik Kline"/>,
      <contact fullname="Warren Kumari"/>, <contact fullname="David
      Lamparter"/>, <contact fullname="Andrew McGregor"/>, <contact
      fullname="Tomek Mrugalski"/>, <contact fullname="Alexandre Petrescu"/>,
      <contact fullname="Jurgen Schonwalder"/>, <contact fullname="Pascal
      Thubert"/>, <contact fullname="Ole Troan"/>, <contact fullname="Eric
      Vyncke"/>, <contact fullname="Eduard Vasilenko"/>, <contact
      fullname="Timothy Winters"/>, <contact fullname="Chongfeng Xie"/>, and
      <contact fullname="Peter Yee"/> for the discussions, their input, and all contributions.</t>
    </section>

    <section anchor="Contributors" numbered="false">
      <!-- [REPLACE/DELETE] a

<!--[rfced] FYI - We have deleted the Contributors section of this document as
it was empty. Please review. -->

<!--[rfced] Please review the following questions and changes regarding the
terminology used in this document.

a. Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations must be
expanded upon first use. How may we expand AP, SSID, and ULA in the examples
below?

Originals:

   When a client moves from between different attachment points on
   the same link (e.g., roams between two APs while connected to the
   same SSID or moves between two switchports belonging to the same
   VLAN), the delegated prefix does not change

   Many enterprise-scale wireless solutions
   implement ND proxy to reduce the amount of broadcast and multicast
   downstream (AP to clients) traffic and provide SAVI functions.

   Networks assigning multiple prefixes to a given link: multihomed
   networks, networks using ULA [RFC4193] and non-ULA prefixes
   together, or network performing a graceful renumbering from one
   prefix to another.

b. Per RFC 8415, IA_PD and IA_NA represent "Identity Association for Prefix
Delegation" and "Identity Association for Non-temporary Addresses",
respectively. Should these two terms be expanded and/or introduced in this
document's terminology list?

c. FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

Local Internet Registry (LIR)
Customer Premises Equipment (CPE)
Virtual eXtensible Local Area Network (VXLAN)
DHCP Unique Identifiers (DUIDs)
Ternary Content-Addressable Memory (TCAM)
Duplicate Address Detection (DAD)
Customer Edge (CE)
interface identifier (IID) (per RFC 7421)
-->

<!--[rfced] Please review usage of the "/" character to separate terms in this
document (some instances included below). It may be unclear whether the
"/" stands for "or", "and", or "and/or". For clarity, please review and
let us know how/if these instances should be updated.

Originals:

   Network devices need to maintain various types of
   tables/hashes (Neighbor Cache on first-hop routers, Neighbor
   Discovery Proxy caches on Layer 2 devices etc.).

   However, providing a unique prefix per device is optional very uncommon in
   enterprise-style networks, where nodes are usually connected to
   broadcast segments/VLANs and each link has a single on-link prefix
   assigned.

   As most operators have some experience with IPv4, they can use a
   similar approach for choosing the pool size and the timers (such as
   T1/T2 timers).

   Devices running containers/namespaces: each container/namespace would have
   multiple addresses as described above.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Note that updates may result in more precise language that better convey the meaning to the readers.

For example, please consider whether "blackholing" should be updated in the
text below:

This leads to traffic blackholing and degraded customer experience.
-->
      <name>Contributors</name>
    </section>

 </back>
</rfc>