rfc9663.original.xml   rfc9663.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="rfc7991bis.rnc"?> <!-- Required for schema validation and sch
ema-aware editing --> <!-- draft submitted in xml v3 -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML proc
essors, including most browsers -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!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 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
xmlns:xi="http://www.w3.org/2001/XInclude" etf-v6ops-dhcp-pd-per-device-08" number="9663" ipr="trust200902" obsoletes="" up
category="info" dates="" submissionType="IETF" consensus="true" xml:lang="en" version="3" sortRe
docName="draft-ietf-v6ops-dhcp-pd-per-device-08" fs="true" symRefs="true">
ipr="trust200902"
obsoletes=""
updates=""
submissionType="IETF"
xml:lang="en"
version="3">
<front> <front>
<title abbrev="Prefix per client using DHCPv6 PD">Using DHCPv6-PD to Al <title abbrev="Prefix per Client Using DHCPv6-PD">Using DHCPv6 Prefix
locate Unique IPv6 Prefix per Client in Large Broadcast Networks</title> Delegation (DHCPv6-PD) to Allocate Unique IPv6 Prefixes per Client in Large
Broadcast Networks</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-v6ops-dhcp-pd-per-d <seriesInfo name="RFC" value="9663"/>
evice"/>
<author initials="L." surname="Colitti" fullname="Lorenzo Colitti"> <author initials="L." surname="Colitti" fullname="Lorenzo Colitti">
<organization>Google, LLC</organization> <organization>Google, LLC</organization>
<address> <address>
<postal> <postal>
<street>Shibuya 3-21-3</street> <street>Shibuya 3-21-3</street>
<country>Japan</country> <country>Japan</country>
</postal> </postal>
<email>lorenzo@google.com</email> <email>lorenzo@google.com</email>
</address> </address>
</author> </author>
<author fullname="Jen Linkova" initials="J" role="editor" surname="Linkova"> <author fullname="Jen Linkova" initials="J" role="editor" surname="Linkova">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<postal> <postal>
<!-- Reorder these if your country does things differently -->
<street>1 Darling Island Rd</street> <street>1 Darling Island Rd</street>
<city>Pyrmont</city> <city>Pyrmont</city>
<region>NSW</region> <region>New South Wales</region>
<code>2009</code> <code>2009</code>
<country>AU</country> <country>Australia</country>
</postal> </postal>
<email>furry13@gmail.com</email> <email>furry13@gmail.com</email>
<email>furry@google.com</email> <email>furry@google.com</email>
</address> </address>
</author> </author>
<author fullname="Xiao Ma" initials="X" role="editor" surname="Ma"> <author fullname="Xiao Ma" initials="X" role="editor" surname="Ma">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<postal> <postal>
<street>Shibuya 3-21-3</street> <street>Shibuya 3-21-3</street>
<country>Japan</country> <country>Japan</country>
</postal> </postal>
<email>xiaom@google.com</email> <email>xiaom@google.com</email>
</address> </address>
</author> </author>
<date month="October" year="2024"/>
<area>OPS</area>
<workgroup>v6ops</workgroup>
<date year="2024"/>
<area>OPS Area</area>
<workgroup>v6ops Working Group</workgroup>
<keyword>IPv6</keyword> <keyword>IPv6</keyword>
<keyword>SLAAC</keyword> <keyword>SLAAC</keyword>
<keyword>DHCPv6-PD</keyword> <keyword>DHCPv6-PD</keyword>
<abstract> <abstract>
<t>This document discusses an IPv6 deployment scenario when individua <t>This document discusses an IPv6 deployment scenario when individual
l nodes connected to large broadcast networks (such as enterprise networks or pu nodes connected to large broadcast networks (such as enterprise networks
blic Wi-Fi networks) are allocated unique prefixes via DHCPv6 Prefix Delegation or public Wi-Fi networks) are allocated unique prefixes via DHCPv6
(DHCPv6-PD, RFC8415).</t> Prefix Delegation (DHCPv6-PD), as specified in RFC 8415.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section> <section>
<name>Introduction</name> <name>Introduction</name>
<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 prefi xes from the network. This provides two important advantages.</t>
<t>First, it offers better scalability. Unlike IPv4, IPv6 allows hosts to <t>Often, broadcast networks such as enterprise or public Wi-Fi
have multiple addresses, and this is the case in most deployments (see <xref tar deployments place many devices on a shared link with a single on-link
get="appendix"/> for more details). prefix. This document describes an alternative deployment model where
individual devices obtain prefixes from the network. This provides two
important advantages.</t>
However, increasing the number of addresses introduces scalability issues on the <t>First, it offers better scalability. Unlike IPv4, IPv6 allows hosts
network infrastructure. to have multiple addresses, and this is the case in most deployments
Network devices need to maintain various types of tables/hashes (Neighbor Cache (see <xref target="appendix"/> for more details). However, increasing
on first-hop routers, Neighbor Discovery Proxy caches on Layer 2 devices etc.). the number of addresses introduces scalability issues on the network
On VXLAN <xref target="RFC7348"/> networks each address mig infrastructure. Network devices need to maintain various types of tables
ht be represented as a route so 8 addresses instead of 1 requires the devices to and hashes
support 8 times more routes, etc. (Neighbor Cache on first-hop routers, Neighbor Discovery Proxy caches
If an infrastructure device resources are exhausted, the de on Layer 2 devices, etc.).
vice might drop some IPv6 addresses from the corresponding tables, while the add On Virtual eXtensible Local Area Network (VXLAN) networks <xref target="RFC7348"
ress owner might be still using the address to send traffic. This leads to traff />,
ic blackholing and degraded customer experience. each address might be represented as a route. This means, for example,
Providing every host with one prefix allows the network to maintain only one ent that if every client has 10 addresses instead of one, the network must
ry per device, while still providing the device the ability to use an arbitrary support 10 times more routes, etc.
number of addresses. If an infrastructure device's resources are exhausted, the
device might drop some IPv6 addresses from the corresponding tables,
while the address owner might still be using the address to send
traffic. This leads to traffic being discarded and a degraded customer exp
erience.
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>
<t>Second, it provides the ability to extend the network. In IPv4, a devic <t>Second, this deployment model provides the ability to extend the networ
e that connects to the network can provide connectivity to subtended devices by k. In IPv4, a
using NAT. With DHCPv6 Prefix Delegation (DHCPv6-PD, <xref target="RFC8415"/>), device that connects to the network can provide connectivity to
such a device can similarly extend the network, but unlike IPv4 NAT, it can prov subtended devices by using NAT. With DHCPv6 Prefix Delegation
ide its subtended devices with full end-to-end connectivity.</t> (DHCPv6-PD) <xref 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 <t>Another method of deploying unique prefixes per device is documented
<xref target="RFC8273"/>. Similarly, the standard deployment model in cellular in <xref target="RFC8273"/>. Similarly, the standard deployment model in
IPv6 networks <xref target="RFC6459"/> provides a unique prefix to every device. cellular IPv6 networks <xref target="RFC6459"/> provides a unique prefix
However, providing a unique prefix per device is very uncommon in enterprise-st to every device. However, providing a unique prefix per device is very unc
yle networks, where nodes are usually connected to broadcast segments/VLANs and ommon in
each link has a single on-link prefix assigned. This document takes a similar ap enterprise-style networks, where nodes are usually connected to
proach to <xref target="RFC8273"/>, but allocates the prefix using DHCPv6-PD. broadcast segments such as VLANs and each link has a single on-link
</t> prefix assigned. This document takes a similar approach to <xref
<t>This document focuses on the behaviour of the network. Host behaviour i target="RFC8273"/>, but allocates the prefix using DHCPv6-PD.</t>
s not defined in this document.
</t> <t>This document focuses on the behavior of the network. Host behavior
is not defined in this document.</t>
</section> </section>
<section> <section>
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", <t>
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
interpreted as described in BCP 14 <xref target="RFC2119"/> ",
<xref target="RFC8174"/> when, and only when, they appear in "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section> <section>
<name>Terminology</name> <name>Terminology</name>
<t>
Node: a device that implements IPv6, <xref target="
RFC8200"/>.
</t>
<t>
Host: any node that is not a router, <xref target="
RFC8200"/>.
</t>
<t>
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 exte
nd 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> <dl>
ND: Neighbor Discovery, <xref target="RFC4861"/>. <dt>Node:</dt><dd>a device that implements IPv6 <xref target="RFC8200"/></dd>
</t> <dt>Host:</dt><dd>any node that is not a router <xref target="RFC8200"/></dd>
<t> <dt>Client:</dt><dd>a node that connects to a network and acquires addresses.
NUD: Neighbor Unreachability Detection, <xref target="RFC4861"/>. The
</t> node may wish to obtain addresses for its own use, or it may be a router that
<t> wishes to extend the network to its physical or virtual subsystems, or
PIO: Prefix Information Option, <xref target="RFC4862"/>. both. It may be either a host or a router as defined by <xref
</t> target="RFC8200"/>.</dd>
<t> <dt>AP:</dt><dd>(wireless) Access Point</dd>
SLAAC: IPv6 Stateless Address Autoconfiguration, <xref targ <dt>DHCPv6 IA_NA:</dt><dd>Identity Association for Non-temporary Addresses
et="RFC4862"/>. (<xref target="RFC8415" sectionFormat="of" section="21.4"/>)</dd>
</t> <dt>DHCPv6 IA_PD:</dt><dd>Identity Association for Prefix Delegation (<xref ta
<t> rget="RFC8415" sectionFormat="of" section="21.21"/>)</dd>
DHCPv6-PD: DHCPv6 (<xref target="RFC8415"/>) mechanism to delegate IPv6 prefixe <dt>DHCPv6-PD:</dt><dd>DHCPv6 Prefix Delegation <xref target="RFC8415"/>; a
s to clients. mechanism to delegate IPv6 prefixes to clients.</dd>
</t> <dt>ND:</dt><dd>Neighbor Discovery <xref target="RFC4861"/></dd>
<dt>NUD:</dt><dd>Neighbor Unreachability Detection <xref target="RFC4861"/></d
d>
<dt>PIO:</dt><dd>Prefix Information Option <xref target="RFC4862"/></dd>
<dt>SLAAC:</dt><dd>IPv6 Stateless Address Autoconfiguration <xref target="RFC4
862"/></dd>
</dl>
</section> </section>
<section> <section>
<name>Design Principles</name> <name>Design Principles</name>
<t> <t>Instead of all clients on a given link forming addresses from the same
Instead of all clients on a given link forming addresses from shared prefix assigned to that link, this deployment model operates as
the same shared prefix assigned to that link: described below:
</t>
<ul>
<li>
A device acts as DHCPv6-PD client and requests a pref
ix via DHCPv6-PD by sending an IA_PD request.
</li>
<li>
The server delegates a prefix to the client and the d
elegated 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 serve
r, or it can act as a DHCPv6 server itself. In both cases it can install the rou
te 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 U
nreachability Detection (NUD) for the client's link-local address.
</li>
<li>
The device can use the delegated prefix in various ways. For exa
mple, it can form addresses, as described in <xref target="RFC7084"/> requiremen
t WAA-7. It can also extend the network, as described in <xref target="RFC7084"/
> or <xref target="RFC7278"/>.
</li>
</ul>
<t>
An example scenario is shown in Figure 1. Note that the prefix lengths used in t
he example are /64 because that is the prefix length currently supported by SLAA
C and is not otherwise required by the proposed deployment model.
</t> </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, 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 device can use the delegated prefix in various ways. For
example, it can form addresses, as described in requirement WAA-7 of
<xref target="RFC7084"/>. It can also extend the network, as described
in <xref target="RFC7084"/> or <xref target="RFC7278"/>.</li>
</ul>
<t>An example scenario is shown in <xref target="fig1"/>. Note that the pref
ix 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>
<figure anchor="fig1"> <figure anchor="fig1">
<name> <name>An Example Topology with Two First-Hop Routers</name>
An Example Topology with Two First-Hop Routers.
</name>
<artset> <artset>
<artwork type="svg"> <artwork type="svg">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="784" width="576" v
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="928" width="856" v iewBox="0 0 576 784" class="diagram" text-anchor="middle" font-family="monospace
iewBox="0 0 856 928" class="diagram" text-anchor="middle" font-family="monospace " font-size="13px">
" font-size="13px"> <path d="M 8,112 L 8,224" fill="none" stroke="black"/>
<path d="M 8,128 L 8,288" fill="none" stroke="black"/> <path d="M 24,16 L 24,64" fill="none" stroke="black"/>
<path d="M 8,736 L 8,912" fill="none" stroke="black"/> <path d="M 24,272 L 24,336" fill="none" stroke="black"/>
<path d="M 24,336 L 24,432" fill="none" stroke="black"/> <path d="M 24,608 L 24,768" fill="none" stroke="black"/>
<path d="M 24,816 L 24,880" fill="none" stroke="black"/> <path d="M 40,672 L 40,736" fill="none" stroke="black"/>
<path d="M 48,48 L 48,176" fill="none" stroke="black"/> <path d="M 56,344 L 56,416" fill="none" stroke="black"/>
<path d="M 48,224 L 48,336" fill="none" stroke="black"/> <path d="M 56,464 L 56,608" fill="none" stroke="black"/>
<path d="M 48,440 L 48,592" fill="none" stroke="black"/> <path d="M 64,160 L 64,272" fill="none" stroke="black"/>
<path d="M 48,640 L 48,736" fill="none" stroke="black"/> <path d="M 72,72 L 72,128" fill="none" stroke="black"/>
<path d="M 168,80 L 168,192" fill="none" stroke="black"/> <path d="M 128,64 L 128,160" fill="none" stroke="black"/>
<path d="M 168,256 L 168,328" fill="none" stroke="black"/> <path d="M 128,200 L 128,264" fill="none" stroke="black"/>
<path d="M 168,432 L 168,592" fill="none" stroke="black"/> <path d="M 128,336 L 128,496" fill="none" stroke="black"/>
<path d="M 168,640 L 168,728" fill="none" stroke="black"/> <path d="M 128,544 L 128,600" fill="none" stroke="black"/>
<path d="M 216,816 L 216,880" fill="none" stroke="black"/> <path d="M 152,224 L 152,272" fill="none" stroke="black"/>
<path d="M 224,528 L 224,736" fill="none" stroke="black"/> <path d="M 168,384 L 168,608" fill="none" stroke="black"/>
<path d="M 232,816 L 232,880" fill="none" stroke="black"/> <path d="M 176,672 L 176,736" fill="none" stroke="black"/>
<path d="M 248,288 L 248,336" fill="none" stroke="black"/> <path d="M 184,416 L 184,480" fill="none" stroke="black"/>
<path d="M 256,16 L 256,96" fill="none" stroke="black"/> <path d="M 192,672 L 192,736" fill="none" stroke="black"/>
<path d="M 304,432 L 304,528" fill="none" stroke="black"/> <path d="M 216,336 L 216,384" fill="none" stroke="black"/>
<path d="M 320,576 L 320,656" fill="none" stroke="black"/> <path d="M 240,176 L 240,264" fill="none" stroke="black"/>
<path d="M 352,240 L 352,328" fill="none" stroke="black"/> <path d="M 272,512 L 272,576" fill="none" stroke="black"/>
<path d="M 424,816 L 424,880" fill="none" stroke="black"/> <path d="M 280,272 L 280,336" fill="none" stroke="black"/>
<path d="M 432,336 L 432,432" fill="none" stroke="black"/> <path d="M 304,64 L 304,112" fill="none" stroke="black"/>
<path d="M 440,736 L 440,912" fill="none" stroke="black"/> <path d="M 312,384 L 312,416" fill="none" stroke="black"/>
<path d="M 448,96 L 448,128" fill="none" stroke="black"/> <path d="M 320,272 L 320,336" fill="none" stroke="black"/>
<path d="M 456,512 L 456,576" fill="none" stroke="black"/> <path d="M 328,672 L 328,736" fill="none" stroke="black"/>
<path d="M 480,336 L 480,432" fill="none" stroke="black"/> <path d="M 344,176 L 344,264" fill="none" stroke="black"/>
<path d="M 480,864 L 480,912" fill="none" stroke="black"/> <path d="M 352,608 L 352,768" fill="none" stroke="black"/>
<path d="M 520,240 L 520,328" fill="none" stroke="black"/> <path d="M 376,576 L 376,672" fill="none" stroke="black"/>
<path d="M 536,688 L 536,768" fill="none" stroke="black"/> <path d="M 392,336 L 392,384" fill="none" stroke="black"/>
<path d="M 584,832 L 584,864" fill="none" stroke="black"/> <path d="M 400,224 L 400,272" fill="none" stroke="black"/>
<path d="M 608,768 L 608,832" fill="none" stroke="black"/> <path d="M 400,704 L 400,752" fill="none" stroke="black"/>
<path d="M 616,576 L 616,656" fill="none" stroke="black"/> <path d="M 424,416 L 424,480" fill="none" stroke="black"/>
<path d="M 632,432 L 632,528" fill="none" stroke="black"/> <path d="M 440,384 L 440,512" fill="none" stroke="black"/>
<path d="M 640,768 L 640,800" fill="none" stroke="black"/> <path d="M 456,672 L 456,704" fill="none" stroke="black"/>
<path d="M 656,16 L 656,96" fill="none" stroke="black"/> <path d="M 464,160 L 464,272" fill="none" stroke="black"/>
<path d="M 656,864 L 656,912" fill="none" stroke="black"/> <path d="M 464,344 L 464,400" fill="none" stroke="black"/>
<path d="M 680,288 L 680,336" fill="none" stroke="black"/> <path d="M 464,448 L 464,512" fill="none" stroke="black"/>
<path d="M 680,528 L 680,688" fill="none" stroke="black"/> <path d="M 472,72 L 472,128" fill="none" stroke="black"/>
<path d="M 680,864 L 680,912" fill="none" stroke="black"/> <path d="M 528,336 L 528,432" fill="none" stroke="black"/>
<path d="M 736,80 L 736,160" fill="none" stroke="black"/> <path d="M 528,480 L 528,504" fill="none" stroke="black"/>
<path d="M 736,208 L 736,336" fill="none" stroke="black"/> <path d="M 536,64 L 536,160" fill="none" stroke="black"/>
<path d="M 736,440 L 736,592" fill="none" stroke="black"/> <path d="M 536,208 L 536,264" fill="none" stroke="black"/>
<path d="M 736,640 L 736,688" fill="none" stroke="black"/> <path d="M 536,576 L 536,640" fill="none" stroke="black"/>
<path d="M 760,832 L 760,864" fill="none" stroke="black"/> <path d="M 544,704 L 544,752" fill="none" stroke="black"/>
<path d="M 808,432 L 808,592" fill="none" stroke="black"/> <path d="M 552,512 L 552,576" fill="none" stroke="black"/>
<path d="M 808,640 L 808,680" fill="none" stroke="black"/> <path d="M 560,16 L 560,64" fill="none" stroke="black"/>
<path d="M 824,32 L 824,208" fill="none" stroke="black"/> <path d="M 568,112 L 568,224" fill="none" stroke="black"/>
<path d="M 824,256 L 824,328" fill="none" stroke="black"/> <path d="M 568,272 L 568,336" fill="none" stroke="black"/>
<path d="M 848,128 L 848,288" fill="none" stroke="black"/> <path d="M 24,16 L 560,16" fill="none" stroke="black"/>
<path d="M 848,336 L 848,432" fill="none" stroke="black"/> <path d="M 24,64 L 560,64" fill="none" stroke="black"/>
<path d="M 848,688 L 848,768" fill="none" stroke="black"/> <path d="M 8,112 L 568,112" fill="none" stroke="black"/>
<path d="M 848,864 L 848,912" fill="none" stroke="black"/> <path d="M 8,224 L 568,224" fill="none" stroke="black"/>
<path d="M 256,16 L 656,16" fill="none" stroke="black"/> <path d="M 24,272 L 280,272" fill="none" stroke="black"/>
<path d="M 656,32 L 824,32" fill="none" stroke="black"/> <path d="M 320,272 L 568,272" fill="none" stroke="black"/>
<path d="M 48,48 L 240,48" fill="none" stroke="black"/> <path d="M 24,336 L 280,336" fill="none" stroke="black"/>
<path d="M 168,80 L 256,80" fill="none" stroke="black"/> <path d="M 320,336 L 568,336" fill="none" stroke="black"/>
<path d="M 664,80 L 736,80" fill="none" stroke="black"/> <path d="M 160,384 L 448,384" fill="none" stroke="black"/>
<path d="M 256,96 L 656,96" fill="none" stroke="black"/> <path d="M 184,416 L 424,416" fill="none" stroke="black"/>
<path d="M 8,128 L 848,128" fill="none" stroke="black"/> <path d="M 184,480 L 424,480" fill="none" stroke="black"/>
<path d="M 8,288 L 848,288" fill="none" stroke="black"/> <path d="M 272,512 L 552,512" fill="none" stroke="black"/>
<path d="M 24,336 L 432,336" fill="none" stroke="black"/> <path d="M 272,576 L 552,576" fill="none" stroke="black"/>
<path d="M 480,336 L 848,336" fill="none" stroke="black"/> <path d="M 24,608 L 352,608" fill="none" stroke="black"/>
<path d="M 24,432 L 432,432" fill="none" stroke="black"/> <path d="M 40,672 L 176,672" fill="none" stroke="black"/>
<path d="M 480,432 L 848,432" fill="none" stroke="black"/> <path d="M 192,672 L 328,672" fill="none" stroke="black"/>
<path d="M 192,528 L 696,528" fill="none" stroke="black"/> <path d="M 368,672 L 544,672" fill="none" stroke="black"/>
<path d="M 320,576 L 616,576" fill="none" stroke="black"/> <path d="M 400,704 L 544,704" fill="none" stroke="black"/>
<path d="M 320,656 L 616,656" fill="none" stroke="black"/> <path d="M 40,736 L 176,736" fill="none" stroke="black"/>
<path d="M 536,688 L 848,688" fill="none" stroke="black"/> <path d="M 192,736 L 328,736" fill="none" stroke="black"/>
<path d="M 8,736 L 440,736" fill="none" stroke="black"/> <path d="M 400,752 L 544,752" fill="none" stroke="black"/>
<path d="M 536,768 L 848,768" fill="none" stroke="black"/> <path d="M 24,768 L 352,768" fill="none" stroke="black"/>
<path d="M 24,816 L 216,816" fill="none" stroke="black"/> <polygon class="arrowhead" points="544,640 532,634.4 532,645.6" fill="black" tra
<path d="M 232,816 L 424,816" fill="none" stroke="black"/> nsform="rotate(90,536,640)"/>
<path d="M 544,832 L 784,832" fill="none" stroke="black"/> <polygon class="arrowhead" points="544,264 532,258.4 532,269.6" fill="black" tra
<path d="M 480,864 L 656,864" fill="none" stroke="black"/> nsform="rotate(90,536,264)"/>
<path d="M 680,864 L 848,864" fill="none" stroke="black"/> <polygon class="arrowhead" points="544,160 532,154.4 532,165.6" fill="black" tra
<path d="M 24,880 L 216,880" fill="none" stroke="black"/> nsform="rotate(90,536,160)"/>
<path d="M 232,880 L 424,880" fill="none" stroke="black"/> <polygon class="arrowhead" points="536,504 524,498.4 524,509.6" fill="black" tra
<path d="M 8,912 L 440,912" fill="none" stroke="black"/> nsform="rotate(90,528,504)"/>
<path d="M 480,912 L 656,912" fill="none" stroke="black"/> <polygon class="arrowhead" points="536,432 524,426.4 524,437.6" fill="black" tra
<path d="M 680,912 L 848,912" fill="none" stroke="black"/> nsform="rotate(90,528,432)"/>
<polygon class="arrowhead" points="832,328 820,322.4 820,333.6" fill="black" tra <polygon class="arrowhead" points="480,72 468,66.4 468,77.6" fill="black" transf
nsform="rotate(90,824,328)"/> orm="rotate(270,472,72)"/>
<polygon class="arrowhead" points="832,208 820,202.4 820,213.6" fill="black" tra <polygon class="arrowhead" points="472,448 460,442.4 460,453.6" fill="black" tra
nsform="rotate(90,824,208)"/> nsform="rotate(270,464,448)"/>
<polygon class="arrowhead" points="816,680 804,674.4 804,685.6" fill="black" tra <polygon class="arrowhead" points="472,344 460,338.4 460,349.6" fill="black" tra
nsform="rotate(90,808,680)"/> nsform="rotate(270,464,344)"/>
<polygon class="arrowhead" points="816,592 804,586.4 804,597.6" fill="black" tra <polygon class="arrowhead" points="472,160 460,154.4 460,165.6" fill="black" tra
nsform="rotate(90,808,592)"/> nsform="rotate(270,464,160)"/>
<polygon class="arrowhead" points="744,640 732,634.4 732,645.6" fill="black" tra <polygon class="arrowhead" points="352,264 340,258.4 340,269.6" fill="black" tra
nsform="rotate(270,736,640)"/> nsform="rotate(90,344,264)"/>
<polygon class="arrowhead" points="744,440 732,434.4 732,445.6" fill="black" tra <polygon class="arrowhead" points="248,264 236,258.4 236,269.6" fill="black" tra
nsform="rotate(270,736,440)"/> nsform="rotate(90,240,264)"/>
<polygon class="arrowhead" points="744,208 732,202.4 732,213.6" fill="black" tra <polygon class="arrowhead" points="136,600 124,594.4 124,605.6" fill="black" tra
nsform="rotate(270,736,208)"/> nsform="rotate(90,128,600)"/>
<polygon class="arrowhead" points="672,80 660,74.4 660,85.6" fill="black" transf <polygon class="arrowhead" points="136,496 124,490.4 124,501.6" fill="black" tra
orm="rotate(180,664,80)"/> nsform="rotate(90,128,496)"/>
<polygon class="arrowhead" points="648,800 636,794.4 636,805.6" fill="black" tra <polygon class="arrowhead" points="136,264 124,258.4 124,269.6" fill="black" tra
nsform="rotate(90,640,800)"/> nsform="rotate(90,128,264)"/>
<polygon class="arrowhead" points="528,328 516,322.4 516,333.6" fill="black" tra <polygon class="arrowhead" points="136,160 124,154.4 124,165.6" fill="black" tra
nsform="rotate(90,520,328)"/> nsform="rotate(90,128,160)"/>
<polygon class="arrowhead" points="360,328 348,322.4 348,333.6" fill="black" tra <polygon class="arrowhead" points="80,72 68,66.4 68,77.6" fill="black" transform
nsform="rotate(90,352,328)"/> ="rotate(270,72,72)"/>
<polygon class="arrowhead" points="248,48 236,42.4 236,53.6" fill="black" transf <polygon class="arrowhead" points="72,160 60,154.4 60,165.6" fill="black" transf
orm="rotate(0,240,48)"/> orm="rotate(270,64,160)"/>
<polygon class="arrowhead" points="176,728 164,722.4 164,733.6" fill="black" tra <polygon class="arrowhead" points="64,464 52,458.4 52,469.6" fill="black" transf
nsform="rotate(90,168,728)"/> orm="rotate(270,56,464)"/>
<polygon class="arrowhead" points="176,592 164,586.4 164,597.6" fill="black" tra <polygon class="arrowhead" points="64,344 52,338.4 52,349.6" fill="black" transf
nsform="rotate(90,168,592)"/> orm="rotate(270,56,344)"/>
<polygon class="arrowhead" points="176,328 164,322.4 164,333.6" fill="black" tra
nsform="rotate(90,168,328)"/>
<polygon class="arrowhead" points="176,192 164,186.4 164,197.6" fill="black" tra
nsform="rotate(90,168,192)"/>
<polygon class="arrowhead" points="56,640 44,634.4 44,645.6" fill="black" transf
orm="rotate(270,48,640)"/>
<polygon class="arrowhead" points="56,440 44,434.4 44,445.6" fill="black" transf
orm="rotate(270,48,440)"/>
<polygon class="arrowhead" points="56,224 44,218.4 44,229.6" fill="black" transf
orm="rotate(270,48,224)"/>
<g class="text"> <g class="text">
<text x="452" y="36">DHCPv6 Servers</text> <text x="292" y="36">DHCPv6 Servers</text>
<text x="448" y="68">Pool 2001:db8:ddd0::/48 for clients</text> <text x="288" y="52">Pool 3fff:0:d::/48 for clients on 2001:db8:ff::/64 link</te
<text x="452" y="84">on 2001:db8:c001::/64 link</text> xt>
<text x="452" y="164">IPv6 Network</text> <text x="44" y="132">DHCPv6</text>
<text x="724" y="180">DHCPv6</text> <text x="308" y="132">IPv6 Network</text>
<text x="76" y="196">DHCPv6</text> <text x="436" y="132">DHCPv6</text>
<text x="720" y="196">Relay-Forward</text> <text x="64" y="148">Relay-Forward</text>
<text x="72" y="212">Relay-Forward</text> <text x="464" y="148">Relay-Forward</text>
<text x="180" y="228">DHCPv6</text> <text x="288" y="164">Route for 3fff:0:d::/48</text>
<text x="444" y="228">Route for 2001:db8:ddd0::/48</text> <text x="124" y="180">DHCPv6</text>
<text x="796" y="228">DHCPv6</text> <text x="532" y="180">DHCPv6</text>
<text x="184" y="244">Relay-Reply</text> <text x="128" y="196">Relay-Reply</text>
<text x="800" y="244">Relay-Reply</text> <text x="520" y="196">Relay-Reply</text>
<text x="272" y="356">First-hop router/DHCPv6 relay</text> <text x="152" y="292">First-hop router/DHCPv6 relay</text>
<text x="648" y="356">First-hop Router/DHCPv6 relay</text> <text x="448" y="292">First-hop Router/DHCPv6 relay</text>
<text x="220" y="388">Route 2001:db8:ddd0:1::/64 -&gt; fe80::aaaa</text> <text x="152" y="308">3fff:0:d:1::/64 -&gt; fe80::aa</text>
<text x="596" y="388">Route 2001:db8:ddd0:1::/64</text> <text x="440" y="308">3fff:0:d:1::/64 -&gt; fe80::aa</text>
<text x="768" y="388">-&gt; fe80::aaaa</text> <text x="152" y="324">3fff:0:d:2::/64 -&gt; fe80::cc</text>
<text x="220" y="420">Route 2001:db8:ddd0:2::/64 -&gt; fe80::cccc</text> <text x="440" y="324">3fff:0:d:2::/64 -&gt; fe80::cc</text>
<text x="596" y="420">Route 2001:db8:ddd0:2::/64</text> <text x="308" y="356">Shared IPv6 link</text>
<text x="768" y="420">-&gt; fe80::cccc</text> <text x="308" y="372">2001:db8:ff::/64</text>
<text x="388" y="516">Shared IPv6 link</text> <text x="476" y="420">DHCPv6</text>
<text x="540" y="516">2001:db8:c001::/64</text> <text x="52" y="436">DHCPv6</text>
<text x="456" y="596">legacy client B</text> <text x="288" y="436">Client B (no DHCPv6-PD)</text>
<text x="52" y="612">DHCPv6</text> <text x="480" y="436">Request</text>
<text x="164" y="612">DHCPv6</text> <text x="56" y="452">Request</text>
<text x="452" y="612">no DHCPv6-PD support</text> <text x="292" y="452">link-local address fe80::b</text>
<text x="740" y="612">DHCPv6</text> <text x="532" y="452">DHCPv6</text>
<text x="812" y="612">DHCPv6</text> <text x="304" y="468">global address 2001:db8:ff::b</text>
<text x="56" y="628">Request</text> <text x="528" y="468">Reply</text>
<text x="160" y="628">Reply</text> <text x="132" y="516">DHCPv6</text>
<text x="464" y="628">link-local address fe80::bbbb</text> <text x="128" y="532">Reply</text>
<text x="744" y="628">Request</text> <text x="372" y="532">Client C</text>
<text x="808" y="628">Reply</text> <text x="392" y="548">link-local address fe80::cc</text>
<text x="468" y="644">global address 2001:db8:c001::bbbb</text> <text x="412" y="564">delegated prefix 3fff:0:d:2::/64</text>
<text x="628" y="708">Client C</text> <text x="500" y="612">Router</text>
<text x="664" y="724">link-local address fe80::cccc</text> <text x="172" y="628">Client A</text>
<text x="696" y="740">delegated prefix 2001:db8:ddd0:2::/64</text> <text x="472" y="628">Advertisement</text>
<text x="220" y="756">Client A</text> <text x="172" y="644">link-local address: fe80::aa</text>
<text x="212" y="772">link-local address: fe80::aaaa</text> <text x="468" y="644">containing PIO</text>
<text x="228" y="788">delegated prefix: 2001:db8:ddd0:1::/64</text> <text x="184" y="660">delegated prefix: 3fff:0:d:1::/64</text>
<text x="732" y="788">Router Advertisement</text> <text x="472" y="660">3fff:0:d:2::/64</text>
<text x="748" y="804">PIO 2001:db8:ddd0:2::/64</text> <text x="108" y="692">virtual system</text>
<text x="108" y="836">virtual system</text> <text x="260" y="692">virtual system</text>
<text x="316" y="836">virtual system</text> <text x="108" y="708">3fff:0:d:1::de</text>
<text x="116" y="852">2001:db8:ddd0:1::f00</text> <text x="260" y="708">3fff:0:d:1::ad</text>
<text x="320" y="852">2001:db8:ddd0:1::2345</text> <text x="108" y="724">3fff:0:d:1::ca</text>
<text x="120" y="868">2001:db8:ddd0:1::cafe</text> <text x="260" y="724">3fff:0:d:1::fe</text>
<text x="316" y="868">2001:db8:ddd0:1::abc</text> <text x="472" y="724">Tethered device</text>
<text x="572" y="884">Tethered device1</text> <text x="468" y="740">3fff:0:d:2::66</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> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art">
<artwork type="ascii-art">
<![CDATA[ <![CDATA[
+-----------------------------------------------------------------------------+ +------------------------------------------------------------------+
| DHCPv6 Servers | | DHCPv6 Servers |
| Pool 2001:db8:ddd0::/48 for clients on 2001:db8:c001::/64 link | | Pool 3fff:0:d::/48 for clients on 2001:db8:ff::/64 link |
+---------------+-------------------------+-----------------------------+-----+ +------------+---------------------+----------------------------+--+
^ | | ^ | ^ | | ^ |
| | | | | | | | | |
+-------+------+-------------------------+----------------------+------+-----+ +-------+------+---------------------+--------------------+-------+---+
|DHCPv6 | | IPv6 Network DHCPv6 | | | | DHCPv6| | IPv6 Network DHCPv6 | | |
|Relay-Forward | Relay-Forward | | |Relay-Forward | Relay-Forward | |
| ^ v Route for 2001:db8:ddd0::/48 ^ v | | ^ v Route for 3fff:0:d::/48 ^ v |
| | DHCPv6 | | | DHCPv6 | | | DHCPv6 | | | DHCPv6 |
| | Relay-Reply | | | Relay-Reply| | | Relay-Reply | | | Relay-Reply|
| | | | | | | | | | | | | | | |
+-----+-------+-------+-----+--------------------+-----+-------+-------+-----+ +------+-------+--+----------+------------+------+-------+--------+---+
| | | | | | | | | | | | | | | |
| v | v v | | v | v | v v | | v
+----+---------------+--------------+ +--------------+-------+-------------+ +----+----------+---------------+ +---------+-------+------------+
| First-hop router/DHCPv6 relay | | First-hop Router/DHCPv6 relay | | First-hop router/DHCPv6 relay | | First-hop Router/DHCPv6 relay|
| 2001:db8:ddd0:1::/64 -> fe80::aaaa| | 2001:db8:ddd0:1::/64 -> fe80::aaaa | | 3fff:0:d:1::/64 -> fe80::aa | | 3fff:0:d:1::/64 -> fe80::aa |
| 2001:db8:ddd0:2::/64 -> fe80::cccc| | 2001:db8:ddd0:2::/64 -> fe80::ccc | | 3fff:0:d:2::/64 -> fe80::cc | | 3fff:0:d:2::/64 -> fe80::cc |
+-----------+------------+----------+ +---------+--------------------+-----+ +------------+----------+-------+ +--------+----------------+----+
^ | | Shared IPv6 link, | ^ | ^ | | Shared IPv6 link | ^ |
| | | 2001:db8:c001::/64 | | | | | | 2001:db8:ff::/64 | | |
| | --+-------+-----------+-----------+------+--- | | | | -+-----+-----------+---------+-----+- | |
| | | | | | | | | | | | | |
| | | +----------------+--------------+ | DHCPv6 | | | | +---------------+-------------+ | DHCPv6 |
DHCPv6 | | |Legacy (no DHCPv6-PD) client B | | Request v DHCPv6 | | | Client B (no DHCPv6-PD) | | Request v
Request | | |link-local address fe80::bbbb | | ^ DHCPv6 Request | | |link-local address fe80::b | | ^ DHCPv6
^ | | |global address 2001:db8:c001::b| | | Reply ^ | | |global address 2001:db8:ff::b| | | Reply
| | | +-------------------------------+ | | | | | | +-----------------------------+ | | |
| v | | | v | v | | | v
| DHCPv6 | +-------------------+-----+------------+ | DHCPv6 | +--------------------+--+----------+
| Reply | | Client C | | Reply | | Client C |
| | | | link-local address fe80::cccc | | | | | link-local address fe80::cc |
| | | | delegated prefix 2001:db8:ddd0:2::/64| | | | | delegated prefix 3fff:0:d:2::/64 |
| | | +--------------+-+---------------------+ | | | +------------+-------------------+-+
| | | | | | v | | |
+----+-------+----+-----------------------------+ | | Router Advertisement +---+-------------+----------------------+ | Router |
| Client A | | | containing PIO | Client A | | Advertisement |
| link-local address: fe80::aaaa | | v 2001:db8:ddd0:2::/64 | link-local address: fe80::aa | | containing PIO v
| delegated prefix: 2001:db8:ddd0:1::/64 | | | delegated prefix: 3fff:0:d:1::/64 | | 3fff:0:d:2::/64
| +---------------------+ +------------------+ | -+-----------+--------- | +----------------+ +----------------+ | -+---------+-----------
| | virtual system | | virtual system | | | | | virtual system | | virtual system | | |
| | 2001:db8:ddd0:1::f00| |2001:db8:ddd0:1::2| | +---------+-----------+ | | 3fff:0:d:1::de | | 3fff:0:d:1::ad | | +------+----------+
| | 2001:db8:ddd0:1::caf| |2001:db8:ddd0:1::a| | | Tethered device | | | 3fff:0:d:1::ca | | 3fff:0:d:1::fe | | | Tethered device |
| +---------------------+ +------------------+ | |2001:db8:ddd0:2::6666| | +----------------+ +----------------+ | | 3fff:0:d:2::66 |
| | +---------------------+ | | +-----------------+
+-----------------------------------------------+ +----------------------------------------+
]]> ]]>
</artwork> </artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section> <section>
<name>Applicability and Limitations</name> <name>Applicability and Limitations</name>
<t>
Delegating a unique prefix per client provides all the benefi <t>Delegating a unique prefix per client provides all the benefits of both
ts of both SLAAC and DHCPv6 address allocation, but at the cost of greater addre SLAAC and DHCPv6 address allocation, but at the cost of greater address-spac
ss space usage. e usage. This design would substantially benefit some networks (see
This design would substantially benefit some networks (see <x <xref target="benefits"/>) in which the additional cost of an additional
ref target="benefits"/>), in which the additional cost of an additional service service (such as DHCPv6 Prefix Delegation) and allocation of a larger amount
(DHCPv6 prefix delegation) and allocating a larger amount of address space can e of
asily be justified. address space can easily be justified. Examples of such networks include
Examples of such networks include but are not limited to: but are not limited to:</t>
</t>
<ul> <ul>
<li> <li>Large-scale networks where even three to five addresses per cli
Large-scale networks where even 3-5 addresses per cli ent
ent might introduce scalability issues. might introduce scalability issues.</li>
</li> <li>Networks with a high number of virtual hosts, so physical
<li> devices require multiple addresses.</li>
Networks with a high number of virtual hosts, so phys <li>Managed networks where extensive troubleshooting, device
ical devices require multiple addresses. traffic logging, or forensics might be required.</li>
</li>
<li>
Managed networks where extensive troubleshooting, dev
ice traffic logging, or forensics might be required.
</li>
</ul> </ul>
<t> <t>In smaller networks, such as home networks or small
In smaller networks, such as home networks or small enterpris enterprises with smaller address space and a lower number of
es, with smaller address space and lower number of clients, SLAAC is a simpler a clients, SLAAC is a simpler and often preferred option.</t>
nd often preferred option.
</t>
</section> </section>
<section> <section>
<name>Routing and Addressing Considerations</name> <name>Routing and Addressing Considerations</name>
<section> <section>
<name>Prefix Pool Allocation</name> <name>Prefix Pool Allocation</name>
<t>One simple deployment model is to assign a dedicated prefix pool <t>One simple deployment model is to assign a dedicated prefix pool to
to each link. The prefixes from each link's pool are only issued to requesting c each link. The prefixes from each link's pool are only issued to
lients on the link, and if clients move to another link they will obtain a prefi requesting clients on the link; if clients move to another link,
x from the pool associated with the new link (see <xref target="mobility"/>).</t 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 usin
g 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 addresse
s from the pool. In this model, the network can route the entire pool to the lin
k's first-hop routers, and the routers do not need to advertise individual deleg
ated prefixes into the network's dynamic routing protocol.</t>
<t>Other deployment models, such as prefix pools shared over multipl <t>This is very similar to how address pools are allocated when using
e links or routers, are possible, but not described in this document.</t> DHCP to assign individual addresses (e.g., DHCPv4 or DHCPv6 IA_NA),
</section> 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 but are not described in this
document.</t>
</section>
<section> <section>
<name> <name>First-Hop Router Requirements</name>
First-Hop Router Requirements <t>In large networks, DHCPv6 servers are usually centralized and reached
</name> via DHCPv6 relays co-located with the first-hop routers. To delegate IPv6
<t> prefixes to clients, the first hop routers need to implement DHCPv6 relay
In large networks, DHCPv6 servers are usually centralized, an functions and meet the requirements defined in <xref target="RFC8987"/>.
d reached via DHCPv6 relays co-located with the first-hop routers. In particular, per <xref target="RFC8987" sectionFormat="of" section="4.2"/>
To delegate IPv6 prefixes to clients, the first hop routers n , the first-hop
eed to implement DHCPv6 relay functions and meet the requirements defined in <xr router must maintain a local routing table that contains all prefixes
ef target="RFC8987"/>. delegated to clients.</t>
In particular, per <xref target="RFC8987" section="4.2"/>, th
e first-hop router must maintain a local routing table that contains all prefixe
s delegated to clients.</t>
<t>With the first-hop routers performing DHCPv6 relay functions, <t>With the first-hop routers performing DHCPv6 relay functions, the
the proposed design neither requires any subsequent relays in the path nor intro proposed design neither requires any subsequent relays in the path nor
duces any requirements (e.g., snooping) to such subsequent relays, if they are d introduces any requirements (e.g., snooping) for such subsequent relays, if
eployed. </t> they are deployed.</t>
<t> <t>To ensure that routes to the delegated prefixes are preserved even if a
To ensure that routes to the delegated prefixes are preserved even if a relay is relay is rebooted or replaced, the operator <bcp14>MUST</bcp14> ensure
rebooted or replaced, the operator MUST ensure that all relays in the network i that all relays in the network infrastructure support DHCPv6 Bulk
nfrastructure support DHCPv6 Bulk Leasequery as defined in <xref target="RFC5460 Leasequery as defined in <xref target="RFC5460"/>. While <xref
"/>. 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>
While Section 4.3 of <xref target="RFC8987"/> lists keeping active prefix delega
tions in persistent storage as an alternative to DHCPv6 Bulk Leasequery, relying
on persistent storage has the following drawbacks:
</t>
<ul> <ul>
<li> <li>In a network with multiple relays, network state can change
In a network with multiple relays, network state can change significantly while significantly while the relay is rebooting (new prefixes might
the relay is rebooting (new prefixes delegated, some prefixes expiring etc). be delegated or some prefixes might be expiring, etc).
</li>
<li>
Persistent storage might not be preserved if the router is physically replaced.
</li> </li>
</ul> <li>Persistent storage might not be preserved if the router is
<t>Another mechanism for first-hop routers to obtain information physically replaced.</li>
about delegated prefixes is by using Active Leasequery <xref target="RFC7653"/>, </ul>
though this is not yet widely supported.</t> <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>
<section anchor="mult_relays"> <section anchor="mult_relays">
<name> <name>Topologies with Multiple First-Hop Routers</name>
Topologies with Multiple First-Hop Routers
</name> <t>In a topology with redundant first-hop routers, all the routers need to
<t> relay DHCPv6 traffic, install the delegated prefixes into their routing
In a topology with redundant first-hop routers, all the route tables and, if needed, advertise those prefixes to the network.</t>
rs need to relay DHCPv6 traffic, install the delegated prefixes into their routi
ng tables and, if needed, advertise those prefixes to the network.</t> <t>If the first-hop routers obtain information about delegated prefixes by
<t>If the first-hop routers obtain information about delegated pr snooping DHCPv6 Reply messages sent by the server, then all the first-hop
efixes by snooping DHCPv6 Reply messages sent by the server, then all the first- routers must be able to snoop these messages. This is possible if the
hop routers must be able to snoop these messages. This is possible if the client client multicasts the DHCPv6 messages it sends to the server. The server
multicasts the DHCPv6 messages it sends to the server. The server will receive will receive one copy of the client message through each first-hop relay,
one copy of the client message through each first-hop relay, and will reply unic and will reply unicast to each of them via the relay (or chain of relays)
ast to each of them via the relay (or chain of relays) from which it received th from which it received the message. Thus, all first-hop relays will be
e message. Thus, all first-hop relays will be able to snoop the replies. Per <xr able to snoop the replies. Per <xref target="RFC8415" sectionFormat="of" sec
ef target="RFC8415" section="14"/>, clients always use multicast unless the serv tion="14"/>,
er uses the Server Unicast option to explicitly allow unicast communication (<xr clients always use multicast unless the server uses the Server Unicast
ef target="RFC8415" section="21.12" sectionFormat="comma"/>). Therefore, in topo option to explicitly allow unicast communication (<xref target="RFC8415"
logies with multiple first-hop routers, the DHCPv6 servers MUST be configured no section="21.12" sectionFormat="comma"/>). Therefore, in topologies with
t to use the Server Unicast option. It should be noted that <xref target="I-D.ie multiple first-hop routers, the DHCPv6 servers <bcp14>MUST</bcp14> be
tf-dhc-rfc8415bis"/> deprecates the Server Unicast option precisely because it i configured not to use the Server Unicast option. It should be noted that
s not compatible with topologies with multiple first-hop relays. <xref target="I-D.ietf-dhc-rfc8415bis"/> deprecates the Server Unicast
</t> option precisely because it is not compatible with topologies with
<t>To recover from crashes or reboots, relays can use Bulk Leasequery multiple first-hop relays.</t>
or Active Leasequery to issue a QUERY_BY_RELAY_ID with the ID(s) of the other r
elay(s), as configured by the operator. Additionally, some vendors provide vendo <t>To recover from crashes or reboots, relays can use Bulk Leasequery or
r-specific mechanisms to synchronize state between DHCP relays.</t> 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>
<section> <section>
<name>On-link Communication </name> <name>On-Link Communication </name>
<t> <t>For security reasons, some networks block on-link device-to-device
For security reasons, some networks block on-link device-to-device traffic at la traffic at Layer 2 to prevent communication between clients on the same
yer 2 to prevent communication between clients on the same link. link. In this case, delegating a prefix to each client doesn't affect
In this case, delegating a prefix to each client doesn't affect traffic flows, a traffic flows, as all traffic is sent to the first-hop router anyway.
s all traffic is sent to the first-hop router anyway. Depending on the network security policy, the router may allow or drop
Depending on the network security policy, the router may allow or drop the traff the traffic.</t>
ic.
</t>
<t>
If the network does allow peer-to-peer communication, the PIO for the on-link pr
efix 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-l
ink, because those addresses are from the delegated prefixes and are no longer w
ithin 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 ta
rget="RFC4861" />). If the client receives and accepts the redirect, then traffi
c can flow directly from device to device.
Therefore the administrator deploying the solution described in this document SH
OULD ensure that the first-hop routers can send ICMPv6 redirects (the routers ar
e configured to do so and the security policies permit those messages).
</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 (<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, the
administrator deploying the solution described in this document
<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>
</section> </section>
</section> </section>
<section> <section>
<name>DHCPv6-PD Server Considerations</name> <name>DHCPv6-PD Server Considerations</name>
<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>
<ul>
<li>
The server MUST follow <xref target="RFC8168"/> recom
mendations on processing prefix-length hints.
</li>
<li>
The server MUST provide a prefix short enough for the client to extend the netwo
rk to at least one interface, and allow nodes on that interface to obtain addres
ses via SLAAC.
The server MAY 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 p
rovide a prefix shorter than the prefix-length hint value received from the clie
nt.
</li>
<li>
If the server receives the same SOLICIT message from
the same client multiple times through multiple relays, it MUST reply to all of
them with the same prefix(es).
This ensures that all the relays will correctly confi
gure routes to the delegated prefixes.
</li>
<li>
The server MUST NOT send the Server Unicast option to
the client unless the network topology guarantees that no client is connected t
o a link with multiple relays (see <xref target="mult_relays"/>).
</li>
<li>
In order to ensure uninterrupted connectivity when a
first-hop router crashes or reboots, the server MUST support Bulk Leasequery or
Active Leasequery.
</li>
</ul>
<t>
As most operators have some experience with IPv4, they can use a similar approac
h for choosing the pool size and the timers (such as T1/T2 timers).
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 sing
le 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-F
i network might be using longer timers than an open public Wi-Fi).
</li>
</ul>
<t> <t>This document does not introduce any changes to the DHCPv6 protocol
DHCPv6 servers that delegate prefixes can interface with Dynamic DNS infrastruct itself. However, for the proposed solution to work correctly, the
ure to automatically populate reverse DNS, DHCPv6-PD server needs to be configured as follows:</t>
similarly to what is described in section 2.5.2 of RFC <xref target="RFC8501"/>. <ul>
Networks that also wish to populate forward DNS cannot do so <li>The server <bcp14>MUST</bcp14> follow recommendations from <xref
automatically based only on DHCPv6 prefix delegation transactions, but they can target="RFC8168"/> on processing prefix-length hints.</li>
do so in other ways, such as by supporting <li>The server <bcp14>MUST</bcp14> provide a prefix short enough for the
DHCPv6 address registration as described in <xref target="I-D.ietf-dhc-addr-noti client to extend the network to at least one interface and allow nodes
fication"/>. on that interface to obtain addresses via SLAAC. The server
</t> <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 the server receives the same Solicit message from the same
client multiple times through multiple relays, it <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 server <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 order to ensure uninterrupted connectivity when a first-hop
router crashes or reboots, the server <bcp14>MUST</bcp14> support Bulk
Leasequery or Active Leasequery.</li>
</ul>
<t>Some additional recommendations driven by security and privacy considerations <t>As most operators have some experience with IPv4, they can use a
are discussed in <xref target="Security"/> and <xref target="privacy"/>.</t> similar approach for choosing the pool size and the timers (such as T1
and T2 timers). In particular, the following factors should be taken into accoun
t:</t>
<ul>
<li>the expected maximum number of clients;</li>
<li>the average duration of client connections;</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 networks);</li>
<li>how often clients are expected to reconnect to the network (for
example, a corporate authenticated Wi-Fi network might be using longer
timers than an open public Wi-Fi).</li>
</ul>
<t>DHCPv6 servers that delegate prefixes can interface with Dynamic DNS
infrastructure to automatically populate reverse DNS using wildcard
records, similarly to what is described in <xref target="RFC8501" sectionFormat=
"of"
section="2.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>
<t>Some additional recommendations driven by security and privacy
considerations are discussed in <xref target="Security"/> and <xref
target="privacy"/>.</t>
</section> </section>
<section> <section>
<name>Prefix Length Considerations</name> <name>Prefix Length Considerations</name>
<t>Delegating a prefix of sufficient size to use SLAAC allows the cli
ent to extend the network, providing limitless addresses to IPv6 nodes connected
to it (e.g., virtual machines, tethered devices), because all IPv6 hosts are re
quired to support SLAAC <xref target="RFC8504"/>. Additionally, even clients tha
t support other forms of address assignment require SLAAC for some functions, su
ch as forming dedicated addresses for the use of 464XLAT (see Section 6.3 of <xr
ef target="RFC6877"/>).</t>
<t>At the time of writing the only prefix size that will allow device <t>Delegating a prefix of sufficient size to use SLAAC allows the client
s to use SLAAC is 64 bits. Also, as noted in <xref target="RFC7421"/>, using an to extend the network, providing limitless addresses to IPv6 nodes
IID shorter than 64 bits and a subnet prefix longer than 64 bits is outside the connected to it (e.g., virtual machines or tethered devices), because all
current IPv6 specifications. IPv6 hosts are required to support SLAAC <xref
Choosing longer prefixes would require the client and any connected system to us target="RFC8504"/>. Additionally, even clients that support other forms of
e other address assignment mechanisms. address assignment require SLAAC for some functions, such as forming
This would limit the applicability of the proposed solution, as other mechanisms dedicated addresses for the use of 464XLAT (see <xref
are not currently supported by many hosts. target="RFC6877" section="6.3" sectionFormat="of"/>).</t>
</t>
<t>For the same reasons, a prefix length of /64 or shorter is require <t>At the time of writing, the only prefix size that will allow devices to
d to extend the network using <xref target="RFC7084"/> (see requirement L-2), an use SLAAC is 64 bits. Also, as noted in <xref target="RFC7421"/>, using an in
d a prefix length of /64 is required to provide global connectivity for stub net terface identifier (IID) shorter than 64 bits and a subnet prefix longer than 64
works as per <xref target="I-D.ietf-snac-simple"/>.</t> 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>
<t> <t>For the same reasons, a prefix length of /64 or shorter is required to
Assigning a prefix of sufficient size to support SLAAC is possible o extend the network as described in <xref target="RFC7084"/> (see requirement
n large networks. In general, any network that numbers clients from an IPv4 pref L-2),
ix of length X (e.g., X=/18, X=/24), would require an IPv6 prefix of length X+32 and a prefix length of /64 is required to provide global connectivity for
(e.g., X=/40, X=/56) to provide a /64 prefix to every device. stub networks as per <xref target="I-D.ietf-snac-simple"/>.</t>
As an example, <xref target="RFC7934" section="9.2"/> suggests that e
ven a very large network that assigns every single one of the 16 million IPv4 ad
dresses in 10.0.0.0/8 would only need an IPv6 /40. A /40 prefix is a small amoun
t of address space: there are 32 times more /40s in the current IPv6 unicast ran
ge 2000::/3 than there are IPv4 addresses.
Existing sites that currently use a /48 prefix cannot support more th
an 64k clients in this model without renumbering, though many networks of such s
ize have LIR status and can justify bigger address blocks.
</t>
<t>Note that assigning a prefix of sufficient size to support SLAAC does <t>Assigning a prefix of sufficient size to support SLAAC is possible on
not require that subtended nodes use SLAAC; they can use other address assignme large networks. In general, any network that numbers clients from an IPv4
nt mechanisms as well.</t> prefix of length X (e.g., X=/18, X=/24) would require an IPv6 prefix of
</section> 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 Local
Internet Registry (LIR) status and can justify bigger address 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"> <section anchor="mobility">
<name>Client Mobility</name> <name>Client Mobility</name>
<t>
As per Section 18.2.12 of <xref target="RFC8415"/>, when the client moves to a n
ew link, it MUST initiate a Rebind/Reply message exchange. Therefore when the cl
ient moves between network attachment points it would refresh its delegated pref
ix the same way it refreshes addresses assigned (via SLAAC or DHCPv6 IA_NA) from
a shared on-link prefix:
</t>
<ul> <t>As per <xref target="RFC8415" section="18.2.12" sectionFormat="of"/>, when
the client moves to a new link, it <bcp14>MUST</bcp14> initiate a Rebind/Reply
<li> message exchange. Therefore, when the client moves between network attachment
When a client moves from between different attachment points on the same link (e points, it would refresh its delegated prefix the same way it refreshes
.g., roams between two APs while connected to the same SSID or moves between two addresses assigned (via SLAAC or DHCPv6 IA_NA) from a shared on-link prefix:</t>
switchports 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 th
e client link-local address on that link. As per requirement S-2 (Section 4.3 of
<xref target="RFC8987"/>), the DHCPv6-relays (the first-hop routers) MUST retai
n 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> <ul>
When a client moves to a different link, the DHCPv6 server provides the client w <li>
ith a new prefix, so the behaviour is consistent with SLAAC or DHCPv6-assigned a When a client moves from between different attachment points on the
ddresses, which are also different on the new link. same link (e.g., roams between two APs while
</li> connected to the same wireless network or moves between two
switchports 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 in <xref target="RFC8987" section="4.3" sectionFormat="of"/>,
the DHCPv6-relays
(the first-hop routers) <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 a client moves to a different link, the DHCPv6 server provides the
client with a new prefix, so the behavior is consistent with SLAAC or
DHCPv6-assigned addresses, which are also different on the new link.</li>
</ul> </ul>
<t> <t>In theory, DHCPv6 servers can delegate the same prefix to the same client
In theory, DHCPv6 servers can delegate the same prefix to the same client even i even if the client changes the attachment points. However, while allowing the
f the client changes the attachment points. client to keep the same prefix while roaming between links might provide some
However, while allowing the client to keep the same prefix while roaming between benefits for the client, it is not feasible without changing DHCPv6 relay
links might provide some benefits for the client, it is not feasible without ch behavior: after the client moves to a new link, the DHCPv6 relays would
anging DHCPv6 relay behaviour: after the client moves to a new link, the DHCPv6 retain the route pointing to the client's link-local address on the old link
relays would retain the route pointing to the client's link-local address on the for the duration of DHCPv6 timers (see requirement S-2, <xref target="RFC8987"
old link for the duration of DHCPv6 timers (see requirement S-2, Section 4.3 of section="4.3" sectionFormat="of"/>). As a result, the first-hop routers would
<xref target="RFC8987"/>). have two routes for the same prefix pointing to different links, causing
As a result, the first-hop routers would have two routes for the same prefix poi connectivity issues for the client.</t>
nting to different links, causing connectivity issues for the client.
</t> <t>It should be noted that addressing clients from a shared on-link prefix
<t>It should be noted that addressing clients from a shared on-link prefix also also does not allow clients to keep addresses while roaming between links, so
does not allow clients to keep addresses while roaming between links, so the pro the proposed solution is not different in that regard. In addition to that,
posed solution is not different in that regard. In addition to that, quite often different links often have different security policies applied (for
different links have different security policies applied (for example, corporat example, corporate internal networks versus guest networks), hence clients on
e internal network vs guest network), hence clients on different links need to u different links need to use different prefixes.</t>
se different prefixes.
</t>
</section> </section>
<section anchor="savi"> <section anchor="savi">
<name>Antispoofing and SAVI Interaction</name> <name>Antispoofing and SAVI Interaction</name>
<t>
Enabling the unicast Reverse Path Forwarding (uRPF, <xref tar <t>Enabling unicast Reverse Path Forwarding (uRPF) <xref
get="RFC3704"/>) on the first-hop router interfaces towards clients provides the target="RFC3704"/> on the first-hop router interfaces towards clients
first layer of defense against spoofing. provides the first layer of defense against spoofing. A spoofed packet
A spoofed packet sent by a malicious client would be dropped sent by a malicious client would be dropped by the router unless the
by the router unless the spoofed address belongs to a prefix delegated to anothe spoofed address belongs to a prefix delegated to another client on the
r client on the same interface. same interface. Therefore the malicious client can only spoof addresses alr
Therefore the malicious client can only spoof addresses alrea eady
dy delegated to another client on the same link or another client link-local add delegated to another client on the same link or another client's
ress. link-local address.</t>
</t>
<t> <t>Source Address Validation Improvement (SAVI) <xref target="RFC7039"/>
Source Address Validation Improvement (SAVI, <xref target="RF provides more reliable protection against address spoofing.
C7039"/>) provides more reliable protection against address spoofing. Administrators deploying the proposed solution on SAVI-enabled
Administrators deploying the proposed solution on SAVI-enable infrastructure <bcp14>SHOULD</bcp14> ensure that SAVI perimeter devices
d infrastructure SHOULD ensure that SAVI perimeter devices support DHCPv6-PD sno support DHCPv6-PD snooping to create the correct binding for the delegated
oping to create the correct binding for the delegated prefixes (see <xref target prefixes (see <xref target="RFC7513"/>). Using FCFS SAVI <xref
="RFC7513"/>). target="RFC6620"/> to protect link-local addresses and create SAVI
Using FCFS SAVI (<xref target="RFC6620"/>) for protecting lin bindings for DHCPv6-PD assigned prefixes would prevent spoofing.</t>
k-local addresses and creating SAVI bindings for DHCPv6-PD assigned prefixes wou
ld prevent spoofing. <t>Some infrastructure devices do not implement SAVI as defined in <xref
</t> target="RFC7039"/>; instead, they perform other forms of address tracking an
d
snooping for security or performance improvement purposes (e.g., ND
proxy). This is very common behavior for wireless devices (such as access p
oints
and controllers). Administrators <bcp14>SHOULD</bcp14> ensure that such
devices are able to snoop DHCPv6-PD packets so the traffic from the
delegated prefixes is not 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
Neighbor Advertisements. In DHCPv6-PD environments, however, the
attacker can only learn about other 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>
<t>
Some infrastructure devices do not implement SAVI as defined in <xref target="RF
C7039"/> but perform other forms of address tracking and snooping for security o
r performance improvement purposes (e.g., ND proxy).
This is very common behaviour for wireless devices (access points and controller
s).
Administrators SHOULD ensure that such devices are able to snoop DHCPv6-PD packe
ts, so the traffic from the delegated prefixes is not dropped.
</t>
<t>
It should be noted that using DHCPv6-PD makes it harder for an attacker to selec
t 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 S
olicitations and Neighbour Advertisements.
In DHCPv6-PD environments, however, the attacker can only learn about other clie
nts's 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>
</section> </section>
<section> <section>
<name>Migration Strategies and Co-existence with SLAAC Using Prefixes <name>Migration Strategies and Co-existence with SLAAC Using Prefixes from t
From PIO</name> he PIO</name>
<t>
It would be beneficial for the network to explicitly indicate <t>It would be beneficial for the network to explicitly indicate its
its support of DHCPv6-PD for connected clients. support of DHCPv6-PD for connected clients.</t>
</t> <ul>
<ul>
<li> <li>In small networks (e.g., home networks), where the number of clients
In small networks (e.g., home networks), where the number of is not too high, the number of available prefixes becomes a limiting
clients is not too high, the number of available prefixes becomes a limiting fac factor. If every phone or laptop in a home network were to request a uniq
tor. ue
If every phone or laptop in a home network were to re prefix suitable for SLAAC, the home network might run out of prefixes,
quest a unique prefix suitable for SLAAC, the home network might run out of pre if the prefix allocated to the Customer Premises Equipment (CPE) by
fixes, if the prefix allocated to the CPE by its ISP is too small (e.g., if an I its ISP is too long. For example, if an ISP delegates a /60, the CPE
SP delegates a /60, it would only be able to delegate 15 /64 prefixes to clients would only be able to delegate fifteen /64 prefixes to clients.
). So while the enterprise network administrator
So while the enterprise network administrator might w might want all phones in the network to request a prefix, it would be
ant all phones in the network to request a prefix, it would be highly undesirabl highly undesirable for the same phone to request a prefix when
e for the same phone to request a prefix when connecting to a home network. connecting to a home network.</li>
</li>
<li> <li>When the network supports both a unique prefix per client and a PIO
When the network supports both a unique prefix per cl with A=1 as address assignment methods, it's highly desirable for the
ient and a PIO with A=1 as address assignment methods, it's highly desirable for client NOT to use the PIO prefix to form global addresses and instead only
the client NOT to use the PIO prefix to form global addresses and only use the use
prefix delegated via DHCPv6-PD. the prefix delegated via DHCPv6-PD.
Starting both SLAAC using the PIO prefix and DHCPv6-P Starting both SLAAC using the PIO prefix and DHCPv6-PD, and then
D and deprecating that SLAAC addresses after receiving a delegated prefix would deprecating the SLAAC addresses after receiving a delegated prefix
be very disruptive for applications. would be very disruptive for applications.
If the client continues to use addresses formed from If the client continues to use addresses formed from the PIO prefix, it
the PIO prefix it would not only undermine the benefits of the proposed solution would not only undermine the benefits of the proposed solution (see
(see <xref target="benefits"/>), but would also introduce complexity and unpred <xref target="benefits"/>), but it would also introduce complexity and
ictability in the source address selection. unpredictability in the source address selection. Therefore, the client
Therefore, the client needs to know what address assi needs to know what address assignment method to use and whether or not to
gnment method to use and whether to use the prefix in PIO or not, if the network use
provides the PIO with A flag set. the prefix in the PIO, if the network provides the PIO with the 'A' flag
</li> set.</li>
</ul> </ul>
<t>
The deployment model described in this document does not require <t>The deployment model described in this document does not require the
the network to signal support of DHCPv6-PD: for example, devices acting as <xre network to signal support of DHCPv6-PD: for example, devices acting as
f target="RFC7084"/> compatible routers will be able to receive prefixes via DHC compatible routers <xref target="RFC7084"/> will be able to receive
Pv6-PD even without such signalling. Also, some clients may decide to start DHCP prefixes via DHCPv6-PD even without such signaling. Also, some clients
v6-PD, and acquire prefixes, if they detect that the network does not provide ad may decide to start DHCPv6-PD and acquire prefixes if they detect that
dresses via SLAAC. To fully achieve the benefits described in this section, <xre the network does not provide addresses via SLAAC. To fully achieve the
f target="I-D.collink-6man-pio-pflag"/> defines a new PIO flag to signal that DH benefits described in this section, <xref
CPv6-PD is the preferred method of obtaining prefixes. target="I-D.ietf-6man-pio-pflag"/> defines a new PIO flag to signal
</t> that DHCPv6-PD is the preferred method of obtaining prefixes.</t>
</section> </section>
<section anchor="benefits"> <section anchor="benefits">
<name>Benefits</name> <name>Benefits</name>
<t>
The proposed solution provides the following benefits: <t>The proposed solution provides the following benefits:</t>
</t>
<ul> <ul>
<li> <li>Network device resources (e.g., memory) need to scale to the
Network device resources (e.g., memory) need to scale number of devices, not the number of IPv6 addresses. The
to the number of devices, not the number of IPv6 addresses. first-hop routers have a single route per device pointing to the
The first-hop routers have a single route per device device's link-local address. This can potentially enable
pointing to the device's link-local address. This can potentially hardware cost savings; for example, if hardware such as wireless
enable hardware cost savings, for example if hardware LAN controllers is limited to supporting only a specific number
such as wireless LAN controllers is limited to supporting only of client addresses, or in VXLAN deployments where each client
a specific number of client addresses, or in VXLAN de address consumes one routing table entry.</li>
ployments where each client address consumes one routing table <li>The cost of having multiple addresses is offloaded to the
entry. clients. Hosts are free to create and use as many addresses as
</li> they need without imposing any additional costs onto the
<li> network.</li>
The cost of having multiple addresses is offloaded to <li>If all clients connected to the given link support this mode
the clients. of operation and can generate addresses from the delegated
Hosts are free to create and use as many addresses as prefixes, there is no reason to advertise a common prefix
they need without imposing any additional costs onto the network. assigned to that link in the PIO with the 'A' flag set. Therefore,
</li> it is
<li> possible to remove the global shared prefix from that link and
If all clients connected to the given link support th the router interface completely, so no global addresses are
is mode of operation and can generate addresses from the delegated prefixes, the on-link for the link. This would lead to reducing the attack
re is no reason to advertise a common prefix assigned to that link in PIO with ' surface for Neighbor Discovery attacks described in <xref
A' flag set. target="RFC6583"/>.</li>
Therefore it is possible to remove the global shared prefix from that link and t <li>DHCPv6-PD logs and routing tables obtained from first-hop route
he router interface completely, so no global addresses are on-link for the link. rs
This would lead to reducing the attack surface for Neighbor Discovery attacks d provide complete information on IPv6 to MAC mapping, which can be used
escribed in <xref target="RFC6583"/>. for forensics and troubleshooting. Such information is much
</li> less dynamic than the ND cache; therefore, it's much easier for an
<li> operator to collect and process it.</li>
DHCPv6-PD logs and first-hop routers routing tables p <li>A dedicated prefix per client allows the network
rovide complete information on IPv6 to MAC mapping, which can be used for forens administrator to create security policies per device (such as ACLs)
ics and troubleshooting. even
Such information is much less dynamic than ND cache a if the client is using temporary addresses. This mitigates one
nd therefore it's much easier for an operator to collect and process it. of the issues described in <xref target="I-D.ietf-opsec-ipv6-addres
</li> sing"/>.</li>
<li>
A dedicated prefix per client allows the network administrator to create per-dev <li>Fate sharing: all global addresses used by a given client are r
ice security policies (ACLs) even if the client is using temporary addresses. Th outed
is mitigates one of the issues described in <xref target="I-D.ietf-opsec-ipv6-ad as a single prefix. Either all of them work or none of them work,
dressing"/>. which makes failures easier to diagnose and mitigate.</li>
</li> <li>Lower level of multicast traffic: less Neighbor Discovery
<li> <xref target="RFC4861"/> multicast packets, as the routers need to
Fate sharing: all global addresses used by a given cl resolve only the clients' link-local addresses. Also, there is no Duplicate Ad
ient are routed as a single prefix. dress Detection (DAD) traffic
Either all of them work or not, which makes failures except for the clients' link-local addresses.</li>
easier to diagnose and mitigate. <li>Ability to extend the network transparently. If the network
</li> delegates to the client a prefix of sufficient size to support
<li> SLAAC, the client can provide connectivity to other hosts, as
Lower level of multicast traffic: less Neighbor Disco is possible in IPv4 with NAT (e.g., by acting as an IPv6 Customer E
very (<xref target="RFC4861"/>) multicast packets, as there are only clients lin dge (CE)
k-local addresses the routers need to resolve. Also, no DAD traffic except for c router as described in <xref target="RFC7084"/>).</li>
lients' link-local addresses.
</li>
<li>
Ability to extend the network transparently. If the network delegates to the cli
ent a prefix of sufficient size to support SLAAC, the client can to provide conn
ectivity to other hosts, as is possible in IPv4 with NAT (e.g., by acting as an
IPv6 CE router as described in <xref target="RFC7084"/>).
</li>
</ul> </ul>
</section> </section>
<section anchor="privacy"> <section anchor="privacy">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t> <t>If an eavesdropper or information collector is aware that a
If an eavesdropper or information collector is aware that a g given client is using the proposed mechanism, then they may be
iven client is using the able to track the client based on its prefix. The privacy
proposed mechanism, then they may be able to track the client implications of this are equivalent to the privacy implications of
based on its prefix. networks using stateful DHCPv6 address assignment: in both cases,
The privacy implications of this are equivalent to the privac the IPv6 addresses are determined by the server, either because
y implications of networks the server assigns a full 128-bit address in a shared prefix, or
using stateful DHCPv6 address assignment: in both cases, the because the server determines what prefix is delegated to the
IPv6 addresses are client. Administrators deploying the proposed mechanism can use
determined by the server, either because the server assigns a similar methods to mitigate the impact as the ones used today in
full 128-bit address in a networks that use stateful DHCPv6 address assignment.</t>
shared prefix, or because the server determines what prefix i
s delegated to the client. <t>Except for networks (such as datacenter networks) where hosts
Administrators deploying the proposed mechanism can use simil do not need temporary addresses <xref target="RFC8981"/>, the
ar methods to mitigate the network <bcp14>SHOULD</bcp14>:</t>
impact as the ones used today in networks that use stateful D
HCPv6 address assignment.</t>
<t>Except for networks (such as datacenter networks) where hosts do not
need temporary
addresses (<xref target="RFC8981"/>), the network SHOULD:</t>
<ul> <ul>
<li>Ensure that when a client requests a prefix, the prefix i <li>Ensure that when a client requests a prefix, the prefix is
s randomly assigned randomly assigned and not allocated deterministically.</li>
and not allocated deterministically.</li> <li>Use short prefix lifetimes (e.g., hours) to ensure that
<li>Use short prefix lifetimes (e.g., hours), to ensure that when a client disconnects and reconnects it gets a different
when a client prefix.</li>
disconnects and reconnects it gets a different prefix.</li> <li>Allow the client to have more than one prefix at the same
<li>Allow the client to have more than one prefix at the time. This allows the client to rotate prefixes using a
same time. This allows the client to rotate prefixes using a mecha mechanism similar to temporary addresses, but that operates on
nism similar to temporary prefixes instead of on individual addresses. In this case, the
addresses, but that operates on prefixes instead of on individual prefix's lifetime <bcp14>MUST</bcp14> be short enough to allow
addresses. the client to use a reasonable rotation interval without using
In this case the prefix's lifetime MUST be short enough to allow t too much address space. For example, if every 24 hours the
he client to use a client asks for a new prefix and stops renewing the old prefix,
reasonable rotation interval without using too much address space. and the Valid Lifetime of delegated prefixes is one hour, then
For example, if every 24 hours the the client asks for a new prefi the client will consume two prefixes for one hour out of 24
x and stops renewing the old hours, and thus will consume just under 1.05
prefix, and the Valid Lifetime of delegated prefixes is one hour, prefixes on average.</li>
then the client will consume </ul>
two prefixes for one hour out of 24 hours, and thus will on averag
e consume just under 1.05
prefixes.</li>
</ul>
</section> </section>
<section anchor="IANA"> <section anchor="IANA">
<!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.-->
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This memo includes no request to IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="Security"> <section anchor="Security">
<!-- All drafts are required to have a security considerations section. Se e RFC 3552 for a guide. -->
<name>Security Considerations</name> <name>Security Considerations</name>
<t> A malicious (or just misbehaving) client might attempt to exhaust the <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. To pr DHCPv6-PD pool by sending a large number of requests with differing
event a misbehaving client from denying service to other clients, the DHCPv6 ser DHCP Unique Identifiers (DUIDs). To prevent a misbehaving client from deny
ver or relay MUST support limiting the number of prefixes delegated to a given c ing service to other
lient at any given time.</t> clients, the DHCPv6 server or relay <bcp14>MUST</bcp14> support limiting
<t>Networks can protect against malicious clients by authenticating dev the number of prefixes delegated to a given client at any given
ices using tokens that cannot be spoofed (e.g., 802.1x authentication) and limit time.</t>
ing the number of link-local addresses or MAC addresses that each client is allo
wed to use. Note that is not a new issue, as the same attack might be implemente <t>Networks can protect against malicious clients by authenticating
d using DHCPv4 or DHCPv6 IA_NA requests; in particular, while it is unlikely for devices using tokens that cannot be spoofed (e.g., 802.1x
clients to be able to exhaust an IA_NA address pool, clients using IA_NA can ex authentication) and limiting the number of link-local addresses or MAC
haust other resources such as DHCPv6 and routing infrastructure resources such s addresses that each client is allowed to use. Note that this is not a new
erver RAM, ND cache entries, TCAM entries, SAVI entries, etc. issue, as the same attack might be implemented using DHCPv4 or DHCPv6
</t> IA_NA requests; in particular, while it is unlikely for clients to be
<t> able to exhaust an IA_NA address pool, clients using IA_NA can exhaust
A malicious client might request a prefix and then release it very other resources such as DHCPv6 and routing infrastructure resources such a
quickly, causing routing convergence events on the relays. s
The impact of this attack can be reduced if the network rate-limits server RAM, ND cache entries, Ternary Content-Addressable Memory (TCAM) en
the amount of broadcast and multicast messages from the client. tries, SAVI entries, etc.</t>
</t>
<t> <t>A malicious client might request a prefix and then release it very
Delegating the same prefix for the same client introduces privacy c quickly, causing routing convergence events on the relays. The impact
oncerns. of this attack can be reduced if the network rate-limits the amount of
The proposed mitigation is discussed in <xref target="privacy"/>. broadcast and multicast messages from the client.</t>
</t>
<t> <t>Delegating the same prefix for the same client introduces privacy
Spoofing scenarios and prevention mechanisms are discussed in <xref concerns. The proposed mitigation is discussed in <xref
target="savi"/>. target="privacy"/>.</t>
</t>
<t>Spoofing scenarios and prevention mechanisms are discussed in <xref tar
get="savi"/>.</t>
</section> </section>
<!-- NOTE: The Acknowledgements and Contributors sections are at the end of this template -->
</middle> </middle>
<back> <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-NOTIFICAT
ION"/>
<displayreference target="I-D.ietf-opsec-ipv6-addressing" to="IPv6-ADDRESS"/
>
<displayreference target="I-D.ietf-snac-simple" to="SNAC-SIMPLE"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2 119.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2 119.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 193.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 193.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 084.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 084.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 460.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 460.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 620.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 620.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 877.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 877.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 168.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 168.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 174.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 174.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 273.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 273.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 415.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 415.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 981.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 981.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 987.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 987.xml"/>
<!-- The recommended and simplest way to include a well known reference -->
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3 704.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3 704.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 861.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 861.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 862.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 862.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 459.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 459.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 583.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 583.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 039.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 039.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 278.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 278.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 348.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 348.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 421.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 421.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 513.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 513.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 653.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 653.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 934.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 934.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 200.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 200.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 501.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 501.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 504.xml"/> <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 504.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
collink-6man-pio-pflag.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.
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-rfc8415bis.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
etf-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.i
etf.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</organiza
tion>
</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"/> <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"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. ietf-snac-simple.xml"/>
</references> </references>
</references> </references>
<section anchor="appendix" title="Appendix: Multiple Addresses Consideration <section anchor="appendix">
s"> <name>Multiple Addresses Considerations</name>
<t>While a typical IPv4 host normally has only one IPv4 address per interf
ace, an IPv6 device almost always has multiple addresses assigned to its interfa
ce.
At the very least, a host can be expected to have one link-local address, one te
mporary address, and, in most cases, one stable global address.
On a network providing NAT64 service, an IPv6-only host running the 464XLAT cust
omer-side translator (CLAT, <xref target="RFC6877"/>) would use a dedicated 464X
LAT address, configured via SLAAC (see Section 6.3 of <xref target="RFC6877"/>),
which brings the total number of addresses to 4.
Other common scenarios where the number of addresses per host interface might in
crease significantly, include but are not limited to:
</t>
<ul>
<li> <t>While a typical IPv4 host normally has only one IPv4 address per
Devices running containers/namespaces: each container/namespace would have multi interface, an IPv6 device almost always has multiple addresses assigned
ple addresses as described above. As a result, a device running just a few conta to its interface. At the very least, a host can be expected to have one
iners in a bridge mode can easily have 20 or more IPv6 addresses on the given li link-local address, one temporary address, and, in most cases, one
nk. stable global address. On a network providing NAT64 service, an
</li> IPv6-only host running the 464XLAT customer-side translator (CLAT) <xref
target="RFC6877"/> would use a dedicated 464XLAT address, configured
via SLAAC (see <xref target="RFC6877" section="6.3" sectionFormat="of"/>),
which brings
the total number of addresses to four. Other common scenarios where the
number of addresses per host interface might increase significantly
include but are not limited to:</t>
<li> <ul>
Networks assigning multiple prefixes to a given link: multihomed networks, netwo <li>Devices running containers or namespaces: each container or namespace
rks using ULA <xref target="RFC4193"/> and non-ULA prefixes together, or network would have multiple addresses as described above. As a result, a
performing a graceful renumbering from one prefix to another. device running just a few containers in a bridge mode can easily have
</li> 20 or more IPv6 addresses on the given link.</li>
<li>Networks assigning multiple prefixes to a given link: multihomed
networks, networks using Unique Local IPv6 Unicast Addresses (ULA,
<xref target="RFC4193"/>) and non-ULA prefixes together, or networks performing
a
graceful renumbering from one prefix to another.</li>
</ul>
</ul> <t><xref target="RFC7934"/> discusses this aspect and explicitly states
that IPv6 deployments <bcp14>SHOULD NOT</bcp14> limit the number of IPv6
addresses a host can have. However, it has 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> <t>The most common scenario of network-imposed limitations is ND proxy. M
<xref target="RFC7934"/> discusses this aspect and explicitly state any enterprise-scale wireless solutions
s that IPv6 deployments SHOULD NOT limit the number of IPv6 addresses a host can implement ND proxy to reduce the amount of broadcast and multicast
have. downstream (AP to clients) traffic and provide SAVI functions. To
However, it has been been observed that networks often do limit the perform ND proxy, a device usually maintains a table containing IPv6
number of on-link addresses per device, likely in an attempt to protect network and MAC addresses of connected clients. At least some implementations
resources and prevent DoS attacks. have hardcoded limits on how many IPv6 addresses per single MAC such a
</t> table can contain. When the limit is exceeded, the behavior is
<t> implementation dependent. Some vendors just fail to install an N+1 address
The most common scenario of network-imposed limitations is Neighbor D to the table. Others delete the oldest entry for this MAC and replace
iscovery (ND) proxy. it with the new address. In any case, the affected addresses lose
Many enterprise-scale wireless solutions implement ND proxy to redu network connectivity without receiving any implicit signal, with traffic
ce the amount of broadcast and multicast downstream (AP to clients) traffic and being silently dropped.</t>
provide SAVI functions.
To perform ND proxy, a device usually maintains a table, containing
IPv6 and MAC addresses of connected clients.
At least some implementations have hardcoded limits on how many IPv
6 addresses per single MAC such a table can contain.
When the limit is exceeded the behaviour is implementation-dependen
t. Some vendors just fail to install 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 with
out receiving any implicit signal, with traffic being silently dropped.
</t>
</section> </section>
<section anchor="Acknowledgements" numbered="false"> <section anchor="Acknowledgements" numbered="false">
<!-- [REPLACE/DELETE] an Acknowledgements section is optional -->
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>Thanks to Harald Alvestrand, Nick Buraglio, Brian Carpenter, Tim Chown, <t>Thanks to <contact fullname="Harald Alvestrand"/>, <contact
Roman Danyliw, Gert Doering, David Farmer, Fernando Gont, Joel Halpern, Nick Hi fullname="Nick Buraglio"/>, <contact fullname="Brian Carpenter"/>,
lliard, Bob Hinden, Martin Hunek, Erik Kline, Warren Kumari, David Lamparter, An <contact fullname="Tim Chown"/>, <contact fullname="Roman Danyliw"/>,
drew McGregor, Tomek Mrugalski, Alexandre Petrescu, Jurgen Schonwalder, Pascal T <contact fullname="Gert Doering"/>, <contact fullname="David Farmer"/>,
hubert, Ole Troan, Eric Vyncke, Eduard Vasilenko, Timothy Winters, Chongfeng Xie <contact fullname="Fernando Gont"/>, <contact fullname="Joel Halpern"/>,
, Peter Yee for the discussions, their input, and all contributions.</t> <contact fullname="Nick Hilliard"/>, <contact fullname="Bob Hinden"/>,
</section> <contact fullname="Martin Hunek"/>, <contact fullname="Erik Kline"/>,
<contact fullname="Warren Kumari"/>, <contact fullname="David
<section anchor="Contributors" numbered="false"> Lamparter"/>, <contact fullname="Andrew McGregor"/>, <contact
<!-- [REPLACE/DELETE] a Contributors section is optional --> fullname="Tomek Mrugalski"/>, <contact fullname="Alexandre Petrescu"/>,
<name>Contributors</name> <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>
</back> </back>
</rfc> </rfc>
 End of changes. 88 change blocks. 
957 lines changed or deleted 927 lines changed or added

This html diff was produced by rfcdiff 1.48.