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 " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<!-- 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="September" 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 | <!--[rfced] May we rework the text below for clarity and concision? | |||
network infrastructure. | ||||
Network devices need to maintain various types of tables/hashes (Neighbor Cache | ||||
on first-hop routers, Neighbor Discovery Proxy caches on Layer 2 devices etc.). | ||||
On VXLAN <xref target="RFC7348"/> networks each address mig | ||||
ht be represented as a route so 8 addresses instead of 1 requires the devices to | ||||
support 8 times more routes, etc. | ||||
If an infrastructure device resources are exhausted, the de | ||||
vice might drop some IPv6 addresses from the corresponding tables, while the add | ||||
ress owner might be still using the address to send traffic. This leads to traff | ||||
ic blackholing and degraded customer experience. | ||||
Providing every host with one prefix allows the network to maintain only one ent | ||||
ry per device, while still providing the device the ability to use an arbitrary | ||||
number of addresses. | ||||
</t> | ||||
<t>Second, it provides the ability to extend the network. In IPv4, a devic e that connects to the network can provide connectivity to subtended devices by using NAT. With DHCPv6 Prefix Delegation (DHCPv6-PD, <xref target="RFC8415"/>), such a device can similarly extend the network, but unlike IPv4 NAT, it can prov ide its subtended devices with full end-to-end connectivity.</t> | Original: | |||
<t>Another method of deploying unique prefixes per device is documented in | On VXLAN [RFC7348] networks each address might be represented as a route so | |||
<xref target="RFC8273"/>. Similarly, the standard deployment model in cellular | 8 addresses instead of 1 requires the devices to support 8 times more | |||
IPv6 networks <xref target="RFC6459"/> provides a unique prefix to every device. | routes, etc. | |||
However, providing a unique prefix per device is very uncommon in enterprise-st | ||||
yle networks, where nodes are usually connected to broadcast segments/VLANs and | Perhaps: | |||
each link has a single on-link prefix assigned. This document takes a similar ap | ||||
proach to <xref target="RFC8273"/>, but allocates the prefix using DHCPv6-PD. | On Virtual eXtensible Local Area Network (VXLAN) networks [RFC7348], each | |||
</t> | address might be represented as a route; this means that eight addresses, | |||
<t>This document focuses on the behaviour of the network. Host behaviour i | instead of one, require the devices to support eight times more routes, etc. | |||
s not defined in this document. | --> | |||
<t>First, it offers better scalability. Unlike IPv4, IPv6 allows hosts | ||||
to have multiple addresses, and this is the case in most deployments | ||||
(see <xref target="appendix"/> for more details). However, increasing | ||||
the number of addresses introduces scalability issues on the network | ||||
infrastructure. Network devices need to maintain various types of | ||||
tables/hashes (Neighbor Cache on first-hop routers, Neighbor Discovery | ||||
Proxy caches on Layer 2 devices, etc.). On Virtual eXtensible Local Area | ||||
Network (VXLAN) networks <xref | ||||
target="RFC7348"/>, each address might be represented as a route | ||||
so eight addresses instead of one requires the devices to support eight ti | ||||
mes more | ||||
routes, etc. 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 blackholing and a degraded customer | ||||
experience. Providing every host with one prefix allows the network to | ||||
maintain only one entry per device, while still providing the device the | ||||
ability to use an arbitrary number of addresses. | ||||
</t> | </t> | |||
<!--[rfced] We have clarified what subject "it" refers to in the sentence | ||||
below (from the Introduction) as this sentence appears far from its | ||||
original subject. Please let us know if this change alters your intended | ||||
meaning. | ||||
Original: | ||||
Second, it provides the ability to extend the network. | ||||
Current: | ||||
Second, this deployment method provides the ability to extend the network. | ||||
--> | ||||
<t>Second, this deployment model provides the ability to extend the networ | ||||
k. In IPv4, a | ||||
device that connects to the network can provide connectivity to | ||||
subtended devices by using NAT. With DHCPv6 Prefix Delegation | ||||
(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 <xref target="RFC8273"/>. Similarly, the standard deployment model in | ||||
cellular IPv6 networks <xref target="RFC6459"/> provides a unique prefix | ||||
to every device. However, providing a unique prefix per device is very | ||||
uncommon in enterprise-style networks, where nodes are usually connected | ||||
to broadcast segments/VLANs and each link has a single on-link prefix | ||||
assigned. This document takes a similar approach to <xref | ||||
target="RFC8273"/>, but allocates the prefix using DHCPv6-PD.</t> | ||||
<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 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> | <!--[rfced] Currently, the terminology list in Section 3 is not | |||
ND: Neighbor Discovery, <xref target="RFC4861"/>. | alphabetized. May we alphabetize the list items? | |||
</t> | ||||
<t> | Original: | |||
NUD: Neighbor Unreachability Detection, <xref target="RFC4861"/>. | ||||
</t> | 3. Terminology | |||
<t> | ||||
PIO: Prefix Information Option, <xref target="RFC4862"/>. | Node: a device that implements IPv6, [RFC8200]. | |||
</t> | ||||
<t> | Host: any node that is not a router, [RFC8200]. | |||
SLAAC: IPv6 Stateless Address Autoconfiguration, <xref targ | ||||
et="RFC4862"/>. | Client: a node which connects to a network and acquires addresses. | |||
</t> | The node may wish to obtain addresses for its own use, or may be a | |||
<t> | router that wishes to extend the network to its physical or virtual | |||
DHCPv6-PD: DHCPv6 (<xref target="RFC8415"/>) mechanism to delegate IPv6 prefixe | subsystems, or both. It may be either a host or a router as defined | |||
s to clients. | by [RFC8200]. | |||
</t> | ||||
ND: Neighbor Discovery, [RFC4861]. | ||||
NUD: Neighbor Unreachability Detection, [RFC4861]. | ||||
PIO: Prefix Information Option, [RFC4862]. | ||||
SLAAC: IPv6 Stateless Address Autoconfiguration, [RFC4862]. | ||||
DHCPv6-PD: DHCPv6 ([RFC8415]) mechanism to delegate IPv6 prefixes to | ||||
clients. | ||||
--> | ||||
<dl> | ||||
<dt>Node:</dt><dd>a device that implements IPv6 <xref target="RFC8200"/></dd> | ||||
<dt>Host:</dt><dd>any node that is not a router <xref target="RFC8200"/></dd> | ||||
<dt>Client:</dt><dd>a node that connects to a network and acquires addresses. | ||||
The | ||||
node may wish to obtain addresses for its own use, or it may be a router that | ||||
wishes to extend the network to its physical or virtual subsystems, or | ||||
both. It may be either a host or a router as defined by <xref | ||||
target="RFC8200"/>.</dd> | ||||
<dt>ND:</dt><dd>Neighbor Discovery <xref target="RFC4861"/></dd> | ||||
<dt>NUD:</dt><dd>Neighbor Unreachability Detection <xref target="RFC4861"/></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> | ||||
<dt>DHCPv6-PD:</dt><dd>DHCPv6 Prefix Delegation <xref target="RFC8415"/>; a | ||||
mechanism to delegate IPv6 prefixes to clients.</dd> | ||||
</dl> | ||||
</section> | </section> | |||
<!--[rfced] As the text below is both the first sentence of Section 4 and the | ||||
lead-in sentence for the list that follows, would it be helpful add | ||||
additional context for the reader? | ||||
Original: | ||||
Instead of all clients on a given link forming addresses from the | ||||
same shared prefix assigned to that link: | ||||
* A device acts as DHCPv6-PD client and requests a prefix via | ||||
DHCPv6-PD by sending an IA_PD request. | ||||
Perhaps: | ||||
Instead of all clients on a given link forming addresses from the | ||||
same shared prefix assigned to that link, this deployment model follows | ||||
the design principles described below. | ||||
* A device acts as a DHCPv6-PD client and requests a prefix via | ||||
DHCPv6-PD by sending an IA_PD request. | ||||
... | ||||
--> | ||||
<section> | <section> | |||
<name>Design Principles</name> | <name>Design Principles</name> | |||
<t> | <t>Instead of all clients on a given link forming addresses from the | |||
Instead of all clients on a given link forming addresses from | same shared prefix assigned to that link:</t> | |||
the same shared prefix assigned to that link: | <ul> | |||
</t> | <li>A device acts as a DHCPv6-PD client and requests a prefix via | |||
<ul> | DHCPv6-PD by sending an IA_PD request.</li> | |||
<li> | <li>The server delegates a prefix to the client and the delegated | |||
A device acts as DHCPv6-PD client and requests a pref | prefix is installed into the routing table of the first-hop router as | |||
ix via DHCPv6-PD by sending an IA_PD request. | a route pointing to the client's link-local address. The first-hop | |||
</li> | router can act as a DHCPv6 relay and snoop DHCPv6 Reply messages from | |||
<li> | an off-link DHCPv6 server, or it can act as a DHCPv6 server itself. In | |||
The server delegates a prefix to the client and the d | both cases, it can install the route locally, and if the network is | |||
elegated prefix is installed into the routing table of the first-hop router as a | running a dynamic routing protocol, distribute the route or the entire | |||
route pointing to the client's link-local address. The first-hop router can act | prefix pool into the protocol.</li> | |||
as a DHCPv6 relay and snoop DHCPv6 Reply messages from an off-link DHCPv6 serve | <li>For the router and all other infrastructure devices, the delegated | |||
r, or it can act as a DHCPv6 server itself. In both cases it can install the rou | prefix is considered off-link, so traffic to that prefix does not | |||
te locally, and if the network is running a dynamic routing protocol, distribute | trigger any ND packets, other than the minimum ND required to sustain | |||
the route or the entire prefix pool into the protocol.</li> | Neighbor Unreachability Detection (NUD) for the client's link-local | |||
<li>For the router and all other infrastructure devices, | address.</li> | |||
the delegated prefix is considered off-link, so traffic to that prefix does not | <li>The device can use the delegated prefix in various ways. For | |||
trigger any ND packets, other than the minimum ND required to sustain Neighbor U | example, it can form addresses, as described in requirement WAA-7 of | |||
nreachability Detection (NUD) for the client's link-local address. | <xref target="RFC7084"/>. It can also extend the network, as described | |||
</li> | in <xref target="RFC7084"/> or <xref target="RFC7278"/>.</li> | |||
<li> | </ul> | |||
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>An example scenario is shown in <xref target="fig1"/>. Note that the pref | |||
t WAA-7. It can also extend the network, as described in <xref target="RFC7084"/ | ix lengths | |||
> or <xref target="RFC7278"/>. | used in the example are /64 because that is the prefix length currently | |||
</li> | supported by SLAAC and is not otherwise required by the proposed | |||
</ul> | deployment model.</t> | |||
<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> | ||||
<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> | <!--[rfced] Please review the following questions about the ASCII and SVG | |||
artwork in Figure 1: | ||||
a. There are some inconsistencies between the SVG and ASCII artwork (see a few | ||||
below). Please review and let us know how to update so these artworks match. | ||||
i. Tethered device (ASCII) v. Tethered device1 and Tethered device2 (SVG) | ||||
ii. Text appears to be cut off in the "virtual system" boxes and the "Legacy | ||||
client" box (ASCII) | ||||
iii. Router Advertisement containing PIO (ASCII) v. Router Advertisement PIO | ||||
(SVG) | ||||
iv. Legacy (no DHCPv6-PD) client B (ASCII) v. legacy client B no DHCPv6-PD | ||||
support (SVG) | ||||
b. The ASCII art is too wide; it extends beyond the 72 character limit. How may | ||||
we adjust? | ||||
--> | ||||
<artset> | <artset> | |||
<artwork type="svg"> | <artwork type="svg"> | |||
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="928" width="856" v iewBox="0 0 856 928" class="diagram" text-anchor="middle" font-family="monospace " font-size="13px"> | <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="928" width="856" v iewBox="0 0 856 928" class="diagram" text-anchor="middle" font-family="monospace " font-size="13px"> | |||
<path d="M 8,128 L 8,288" fill="none" stroke="black"/> | <path d="M 8,128 L 8,288" fill="none" stroke="black"/> | |||
<path d="M 8,736 L 8,912" fill="none" stroke="black"/> | <path d="M 8,736 L 8,912" fill="none" stroke="black"/> | |||
<path d="M 24,336 L 24,432" fill="none" stroke="black"/> | <path d="M 24,336 L 24,432" fill="none" stroke="black"/> | |||
<path d="M 24,816 L 24,880" fill="none" stroke="black"/> | <path d="M 24,816 L 24,880" fill="none" stroke="black"/> | |||
<path d="M 48,48 L 48,176" fill="none" stroke="black"/> | <path d="M 48,48 L 48,176" fill="none" stroke="black"/> | |||
<path d="M 48,224 L 48,336" fill="none" stroke="black"/> | <path d="M 48,224 L 48,336" fill="none" stroke="black"/> | |||
skipping to change at line 322 ¶ | skipping to change at line 446 ¶ | |||
<text x="116" y="852">2001:db8:ddd0:1::f00</text> | <text x="116" y="852">2001:db8:ddd0:1::f00</text> | |||
<text x="320" y="852">2001:db8:ddd0:1::2345</text> | <text x="320" y="852">2001:db8:ddd0:1::2345</text> | |||
<text x="120" y="868">2001:db8:ddd0:1::cafe</text> | <text x="120" y="868">2001:db8:ddd0:1::cafe</text> | |||
<text x="316" y="868">2001:db8:ddd0:1::abc</text> | <text x="316" y="868">2001:db8:ddd0:1::abc</text> | |||
<text x="572" y="884">Tethered device1</text> | <text x="572" y="884">Tethered device1</text> | |||
<text x="756" y="884">Tethered device2</text> | <text x="756" y="884">Tethered device2</text> | |||
<text x="568" y="900">2001:db8:ddd0:2::5555</text> | <text x="568" y="900">2001:db8:ddd0:2::5555</text> | |||
<text x="764" y="900">2001:db8:ddd0:2::6666</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 2001:db8:ddd0::/48 for clients on 2001:db8:c001::/64 link | | |||
+---------------+-------------------------+-----------------------------+-----+ | +---------------+-------------------------+-----------------------------+-----+ | |||
^ | | ^ | | ^ | | ^ | | |||
| | | | | | | | | | | | |||
+-------+------+-------------------------+----------------------+------+-----+ | +-------+------+-------------------------+----------------------+------+-----+ | |||
|DHCPv6 | | IPv6 Network DHCPv6 | | | | |DHCPv6 | | IPv6 Network DHCPv6 | | | | |||
|Relay-Forward | Relay-Forward | | | |Relay-Forward | Relay-Forward | | | |||
skipping to change at line 380 ¶ | skipping to change at line 504 ¶ | |||
| | 2001:db8:ddd0:1::caf| |2001:db8:ddd0:1::a| | | Tethered device | | | | 2001:db8:ddd0:1::caf| |2001:db8:ddd0:1::a| | | Tethered device | | |||
| +---------------------+ +------------------+ | |2001:db8:ddd0:2::6666| | | +---------------------+ +------------------+ | |2001:db8:ddd0:2::6666| | |||
| | +---------------------+ | | | +---------------------+ | |||
+-----------------------------------------------+ | +-----------------------------------------------+ | |||
]]> | ]]> | |||
</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 | <!--[rfced] For ease of the reader, how may we add additional context and/or | |||
tions in persistent storage as an alternative to DHCPv6 Bulk Leasequery, relying | verbs to clarify the items in parentheses below? | |||
on persistent storage has the following drawbacks: | ||||
</t> | Original: | |||
<ul> | ||||
<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 | |||
the relay is rebooting (new prefixes delegated, some prefixes expiring etc). | delegated, some prefixes expiring etc). | |||
</li> | ||||
<li> | Perhaps: | |||
Persistent storage might not be preserved if the router is physically replaced. | ||||
</li> | * In a network with multiple relays, network state can change | |||
</ul> | significantly while the relay is rebooting (new prefixes might | |||
<t>Another mechanism for first-hop routers to obtain information | be delegated or some prefixes might be expiring, etc). | |||
about delegated prefixes is by using Active Leasequery <xref target="RFC7653"/>, | ||||
though this is not yet widely supported.</t> | ||||
--> | ||||
<ul> | ||||
<li>In a network with multiple relays, network state can change | ||||
significantly while the relay is rebooting (new prefixes delegated, some | ||||
prefixes expiring, etc.).</li> | ||||
<li>Persistent storage might not be preserved if the router is | ||||
physically replaced.</li> | ||||
</ul> | ||||
<t>Another mechanism for first-hop routers to obtain information about | ||||
delegated prefixes is by using Active Leasequery <xref target="RFC7653"/>, | ||||
though this is not yet widely supported.</t> | ||||
</section> | </section> | |||
<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/T2 | |||
timers). In particular, the following factors shall be taken into account:< | ||||
/t> | ||||
<!--[rfced] FYI - We have slightly adjusted the list items below for | ||||
consistency. Please review and let us know if these changes alter your | ||||
intended meaning. | ||||
Original: | ||||
In particular the following factors shall be taken | ||||
into account: | ||||
* the expected maximum number of clients; | ||||
* average duration of a client connection; | ||||
* how mobile the clients are (a network where all clients are | ||||
connected to a single wired VLAN might choose longer timers than a | ||||
network where clients can switch between multiple wireless SSIDs); | ||||
* expected level of recurring clients (for example, a corporate | ||||
authenticated Wi-Fi network might be using longer timers than an | ||||
open public Wi-Fi). | ||||
Current: | ||||
In particular, the following factors shall be taken | ||||
into account: | ||||
* the expected maximum number of clients; | ||||
* the average duration of a client connection; | ||||
* the mobility of the clients (for example, a network where all | ||||
clients are connected to a single wired VLAN might choose longer | ||||
timers than a network where clients can switch between multiple | ||||
wireless SSIDs); | ||||
* the expected level of recurring clients (for example, a corporate | ||||
authenticated Wi-Fi network might be using longer timers than an | ||||
open public Wi-Fi). | ||||
--> | ||||
<ul> | ||||
<li>the expected maximum number of clients;</li> | ||||
<li>the average duration of a client connection;</li> | ||||
<li>the mobility of the clients (for example, a network where all clients | ||||
are | ||||
connected to a single wired VLAN might choose longer timers than a | ||||
network where clients can switch between multiple wireless SSIDs);</li> | ||||
<li>the expected level of recurring clients (for example, a corporate | ||||
authenticated Wi-Fi network might be using longer timers than an open | ||||
public Wi-Fi).</li> | ||||
</ul> | ||||
<!-- [rfced] RFC 8501 does not have a section 2.5.2. Perhaps the text should re | ||||
fer to section 2.3.2 (see https://www.rfc-editor.org/rfc/rfc8501#section-2.3.2)? | ||||
Original: | ||||
DHCPv6 servers that delegate prefixes can interface with Dynamic DNS | ||||
infrastructure to automatically populate reverse DNS, similarly to | ||||
what is described in section 2.5.2 of RFC [RFC8501]. | ||||
--> | ||||
<t>DHCPv6 servers that delegate prefixes can interface with Dynamic DNS | ||||
infrastructure to automatically populate reverse DNS, similarly to what is | ||||
described in <xref target="RFC8501" sectionFormat="of" | ||||
section="2.5.2"/>. Networks that also wish to populate forward DNS cannot | ||||
do so automatically based only on DHCPv6 prefix delegation transactions, | ||||
but they can do so in other ways, such as by supporting DHCPv6 address | ||||
registration as described in <xref | ||||
target="I-D.ietf-dhc-addr-notification"/>.</t> | ||||
<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> | ||||
<li> | <t>As per <xref target="RFC8415" section="18.2.12" sectionFormat="of"/>, when | |||
When a client moves from between different attachment points on the same link (e | the client moves to a new link, it <bcp14>MUST</bcp14> initiate a Rebind/Reply | |||
.g., roams between two APs while connected to the same SSID or moves between two | message exchange. Therefore, when the client moves between network attachment | |||
switchports belonging to the same VLAN), the delegated prefix does not change, | points, it would refresh its delegated prefix the same way it refreshes | |||
and the first-hop routers have a route for the prefix with the nexthop set to th | addresses assigned (via SLAAC or DHCPv6 IA_NA) from a shared on-link prefix:</t> | |||
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>When a client moves between different attachment points on the same | |||
ith a new prefix, so the behaviour is consistent with SLAAC or DHCPv6-assigned a | link (e.g., roams between two APs while connected to the same SSID or moves | |||
ddresses, which are also different on the new link. | between two switch ports belonging to the same VLAN), the delegated prefix | |||
</li> | 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"> | <!--[rfced] We were unable to find the phrase "unicast Reverse Path | |||
<name>Antispoofing and SAVI Interaction</name> | Forwarding (uRPF)" in RFC 3704. However, other types of Reverse Path | |||
<t> | Forwarding do appear (e.g., Loose RPF, Feasible RPF, Strict RPF). Are any | |||
Enabling the unicast Reverse Path Forwarding (uRPF, <xref tar | updates needed to the text or citation below? | |||
get="RFC3704"/>) on the first-hop router interfaces towards clients provides the | ||||
first layer of defense against spoofing. | Original: | |||
A spoofed packet sent by a malicious client would be dropped | ||||
by the router unless the spoofed address belongs to a prefix delegated to anothe | Enabling the unicast Reverse Path Forwarding (uRPF, [RFC3704]) on the | |||
r client on the same interface. | first-hop router interfaces towards clients provides the first layer | |||
Therefore the malicious client can only spoof addresses alrea | of defense against spoofing. | |||
dy delegated to another client on the same link or another client link-local add | ||||
ress. | --> | |||
</t> | ||||
<t> | <section anchor="savi"> | |||
Source Address Validation Improvement (SAVI, <xref target="RF | <name>Antispoofing and SAVI Interaction</name> | |||
C7039"/>) provides more reliable protection against address spoofing. | <!-- [rfced] Please clarify "another client link-local address". Should this be | |||
Administrators deploying the proposed solution on SAVI-enable | "another client's link-local address"? | |||
d infrastructure SHOULD ensure that SAVI perimeter devices support DHCPv6-PD sno | ||||
oping to create the correct binding for the delegated prefixes (see <xref target | Original: | |||
="RFC7513"/>). | Therefore the malicious client can only spoof addresses | |||
Using FCFS SAVI (<xref target="RFC6620"/>) for protecting lin | already delegated to another client on the same link or another | |||
k-local addresses and creating SAVI bindings for DHCPv6-PD assigned prefixes wou | client link-local address. | |||
ld prevent spoofing. | --> | |||
</t> | ||||
<t>Enabling unicast Reverse Path Forwarding (uRPF) <xref | ||||
target="RFC3704"/> on the first-hop router interfaces towards clients | ||||
provides the first layer of defense against spoofing. A spoofed packet | ||||
sent by a malicious client would be dropped by the router unless the | ||||
spoofed address belongs to a prefix delegated to another client on the | ||||
same interface. Therefore, the malicious client can only spoof addresses | ||||
already delegated to another client on the same link or another client | ||||
link-local address.</t> | ||||
<t>Source Address Validation Improvement (SAVI) <xref target="RFC7039"/> | ||||
provides more reliable protection against address spoofing. | ||||
Administrators deploying the proposed solution on SAVI-enabled | ||||
infrastructure <bcp14>SHOULD</bcp14> ensure that SAVI perimeter devices | ||||
support DHCPv6-PD snooping to create the correct binding for the delegated | ||||
prefixes (see <xref target="RFC7513"/>). Using FCFS SAVI <xref | ||||
target="RFC6620"/> to protect link-local addresses and create SAVI | ||||
bindings for DHCPv6-PD assigned prefixes would prevent spoofing.</t> | ||||
<t>Some infrastructure devices do not implement SAVI as defined in <xref | ||||
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> | <!-- [rfced] Is the closing parenthesis misplaced? If the suggested text is inc | |||
<li> | orrect, please clarify what happens when the prefix is too small. | |||
In small networks (e.g., home networks), where the number of | ||||
clients is not too high, the number of available prefixes becomes a limiting fac | Original: | |||
tor. | If every phone or laptop in a home network | |||
If every phone or laptop in a home network were to re | were to request a unique prefix suitable for SLAAC, the home | |||
quest a unique prefix suitable for SLAAC, the home network might run out of pre | network might run out of prefixes, if the prefix allocated to the | |||
fixes, if the prefix allocated to the CPE by its ISP is too small (e.g., if an I | CPE by its ISP is too small (e.g., if an ISP delegates a /60, it | |||
SP delegates a /60, it would only be able to delegate 15 /64 prefixes to clients | would only be able to delegate 15 /64 prefixes to clients). | |||
). | ||||
So while the enterprise network administrator might w | Perhaps: | |||
ant all phones in the network to request a prefix, it would be highly undesirabl | If every phone or laptop in a home network | |||
e for the same phone to request a prefix when connecting to a home network. | were to request a unique prefix suitable for SLAAC, the home | |||
</li> | network might run out of prefixes. If the prefix allocated to the | |||
<li> | Customer Premises Equipment (CPE) by its ISP is too small (e.g., if | |||
When the network supports both a unique prefix per cl | an ISP delegates a /60), it would only be able to delegate 15 | |||
ient and a PIO with A=1 as address assignment methods, it's highly desirable for | /64 prefixes to clients. | |||
the client NOT to use the PIO prefix to form global addresses and only use the | --> | |||
prefix delegated via DHCPv6-PD. | ||||
Starting both SLAAC using the PIO prefix and DHCPv6-P | <li>In small networks (e.g., home networks), where the number of clients | |||
D and deprecating that SLAAC addresses after receiving a delegated prefix would | is not too high, the number of available prefixes becomes a limiting | |||
be very disruptive for applications. | factor. If every phone or laptop in a home network were to request a | |||
If the client continues to use addresses formed from | unique prefix suitable for SLAAC, the home network might run out of | |||
the PIO prefix it would not only undermine the benefits of the proposed solution | prefixes, if the prefix allocated to the Customer Premises Equipment (CPE) | |||
(see <xref target="benefits"/>), but would also introduce complexity and unpred | by its ISP is too small | |||
ictability in the source address selection. | (e.g., if an ISP delegates a /60, it would only be able to delegate 15 | |||
Therefore, the client needs to know what address assi | /64 prefixes to clients). So while the enterprise network administrator | |||
gnment method to use and whether to use the prefix in PIO or not, if the network | might want all phones in the network to request a prefix, it would be | |||
provides the PIO with A flag set. | highly undesirable for the same phone to request a prefix when | |||
</li> | connecting to a home network.</li> | |||
</ul> | ||||
<t> | <!--[rfced] How may we update the text below for clarity? Specifically, what | |||
The deployment model described in this document does not require | two items does "both" refer to, and should "that SLAAC addresses" be plural or | |||
the network to signal support of DHCPv6-PD: for example, devices acting as <xre | singular? | |||
f target="RFC7084"/> compatible routers will be able to receive prefixes via DHC | ||||
Pv6-PD even without such signalling. Also, some clients may decide to start DHCP | Original: | |||
v6-PD, and acquire prefixes, if they detect that the network does not provide ad | ||||
dresses via SLAAC. To fully achieve the benefits described in this section, <xre | Starting both SLAAC using the PIO prefix and DHCPv6-PD and deprecating | |||
f target="I-D.collink-6man-pio-pflag"/> defines a new PIO flag to signal that DH | that SLAAC addresses after receiving a delegated prefix would be very | |||
CPv6-PD is the preferred method of obtaining prefixes. | disruptive for applications. | |||
</t> | ||||
Perhaps: | ||||
Starting both DHCPv6-PD and SLAAC using the PIO prefix and then | ||||
deprecating that SLAAC address after receiving a delegated prefix | ||||
would be very disruptive for applications. | ||||
--> | ||||
<li>When the network supports both a unique prefix per client and a PIO | ||||
with A=1 as address assignment methods, it's highly desirable for the | ||||
client NOT to use the PIO prefix to form global addresses and instead only | ||||
use | ||||
the prefix delegated via DHCPv6-PD. Starting both SLAAC using the PIO | ||||
prefix and DHCPv6-PD and deprecating that SLAAC addresses after | ||||
receiving a delegated prefix would be very disruptive for applications. | ||||
If the client continues to use addresses formed from the PIO prefix, it | ||||
would not only undermine the benefits of the proposed solution (see | ||||
<xref target="benefits"/>), but it would also introduce complexity and | ||||
unpredictability in the source address selection. Therefore, the client | ||||
needs to know what address assignment method to use and whether or not to | ||||
use | ||||
the prefix in the PIO, if the network provides the PIO with the 'A' flag | ||||
set.</li> | ||||
</ul> | ||||
<t>The deployment model described in this document does not require the | ||||
network to signal support of DHCPv6-PD: for example, devices acting as | ||||
compatible routers <xref target="RFC7084"/> will be able to receive | ||||
prefixes via DHCPv6-PD even without such signaling. Also, some clients | ||||
may decide to start DHCPv6-PD and acquire prefixes if they detect that | ||||
the network does not provide addresses via SLAAC. To fully achieve the | ||||
benefits described in this section, <xref | ||||
target="I-D.ietf-6man-pio-pflag"/> defines a new PIO flag to signal | ||||
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: | <!--[rfced] FYI - For ease of the reader, we have updated the text below as | |||
</t> | follows. Please review and let us know if this change alters your | |||
intended meaning. | ||||
Original: | ||||
DHCPv6-PD logs and first-hop routers routing tables provide | ||||
complete information... | ||||
Current: | ||||
DHCPv6-PD logs and routing tables for first-hop routers provide | ||||
complete information... | ||||
--> | ||||
<t>The proposed solution provides the following benefits:</t> | ||||
<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 for first-hop routers provide | |||
he router interface completely, so no global addresses are on-link for the link. | complete information on IPv6 to MAC mapping, which can be used | |||
This would lead to reducing the attack surface for Neighbor Discovery attacks d | for forensics and troubleshooting. Such information is much | |||
escribed in <xref target="RFC6583"/>. | less dynamic than the ND cache; therefore, it's much easier for an | |||
</li> | operator to collect and process it.</li> | |||
<li> | <li>A dedicated prefix per client allows the network | |||
DHCPv6-PD logs and first-hop routers routing tables p | administrator to create security policies per device (such as ACLs) | |||
rovide complete information on IPv6 to MAC mapping, which can be used for forens | even | |||
ics and troubleshooting. | if the client is using temporary addresses. This mitigates one | |||
Such information is much less dynamic than ND cache a | of the issues described in <xref target="I-D.ietf-opsec-ipv6-addres | |||
nd therefore it's much easier for an operator to collect and process it. | sing"/>.</li> | |||
</li> | <!-- [rfced] Does "or not" mean "not all of them work", "none of them work", or | |||
<li> | otherwise? Please clarify. | |||
A dedicated prefix per client allows the network administrator to create per-dev | ||||
ice security policies (ACLs) even if the client is using temporary addresses. Th | Original: | |||
is mitigates one of the issues described in <xref target="I-D.ietf-opsec-ipv6-ad | * Fate sharing: all global addresses used by a given client are | |||
dressing"/>. | routed as a single prefix. Either all of them work or not, which | |||
</li> | makes failures easier to diagnose and mitigate. | |||
<li> | --> | |||
Fate sharing: all global addresses used by a given cl | ||||
ient are routed as a single prefix. | <li>Fate sharing: all global addresses used by a given client | |||
Either all of them work or not, which makes failures | are routed as a single prefix. Either all of them work or not, | |||
easier to diagnose and mitigate. | 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 | |||
Lower level of multicast traffic: less Neighbor Disco | resolve only the clients' link-local addresses. Also, there is no Duplicate Ad | |||
very (<xref target="RFC4861"/>) multicast packets, as there are only clients lin | dress Detection (DAD) traffic | |||
k-local addresses the routers need to resolve. Also, no DAD traffic except for c | except for the clients' link-local addresses.</li> | |||
lients' link-local addresses. | <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 | |||
Ability to extend the network transparently. If the network delegates to the cli | is possible in IPv4 with NAT (e.g., by acting as an IPv6 Customer E | |||
ent a prefix of sufficient size to support SLAAC, the client can to provide conn | dge (CE) | |||
ectivity to other hosts, as is possible in IPv4 with NAT (e.g., by acting as an | router as described in <xref target="RFC7084"/>).</li> | |||
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/namespaces: each container/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: these include m | ||||
ultihomed | ||||
networks, networks using 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"/>, | |||
<contact fullname="Martin Hunek"/>, <contact fullname="Erik Kline"/>, | ||||
<contact fullname="Warren Kumari"/>, <contact fullname="David | ||||
Lamparter"/>, <contact fullname="Andrew McGregor"/>, <contact | ||||
fullname="Tomek Mrugalski"/>, <contact fullname="Alexandre Petrescu"/>, | ||||
<contact fullname="Jurgen Schonwalder"/>, <contact fullname="Pascal | ||||
Thubert"/>, <contact fullname="Ole Troan"/>, <contact fullname="Eric | ||||
Vyncke"/>, <contact fullname="Eduard Vasilenko"/>, <contact | ||||
fullname="Timothy Winters"/>, <contact fullname="Chongfeng Xie"/>, and | ||||
<contact fullname="Peter Yee"/> for the discussions, their input, and all | ||||
contributions.</t> | ||||
</section> | </section> | |||
<section anchor="Contributors" numbered="false"> | <!--[rfced] FYI - We have deleted the Contributors section of this document as | |||
<!-- [REPLACE/DELETE] a Contributors section is optional --> | it was empty. Please review. --> | |||
<name>Contributors</name> | ||||
</section> | <!--[rfced] Please review the following questions and changes regarding the | |||
terminology used in this document. | ||||
a. Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations must be | ||||
expanded upon first use. How may we expand AP, SSID, and ULA in the examples | ||||
below? | ||||
Originals: | ||||
When a client moves from between different attachment points on | ||||
the same link (e.g., roams between two APs while connected to the | ||||
same SSID or moves between two switchports belonging to the same | ||||
VLAN), the delegated prefix does not change | ||||
Many enterprise-scale wireless solutions | ||||
implement ND proxy to reduce the amount of broadcast and multicast | ||||
downstream (AP to clients) traffic and provide SAVI functions. | ||||
Networks assigning multiple prefixes to a given link: multihomed | ||||
networks, networks using ULA [RFC4193] and non-ULA prefixes | ||||
together, or network performing a graceful renumbering from one | ||||
prefix to another. | ||||
b. Per RFC 8415, IA_PD and IA_NA represent "Identity Association for Prefix | ||||
Delegation" and "Identity Association for Non-temporary Addresses", | ||||
respectively. Should these two terms be expanded and/or introduced in this | ||||
document's terminology list? | ||||
c. FYI - We have added expansions for abbreviations upon first use | ||||
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each | ||||
expansion in the document carefully to ensure correctness. | ||||
Local Internet Registry (LIR) | ||||
Customer Premises Equipment (CPE) | ||||
Virtual eXtensible Local Area Network (VXLAN) | ||||
DHCP Unique Identifiers (DUIDs) | ||||
Ternary Content-Addressable Memory (TCAM) | ||||
Duplicate Address Detection (DAD) | ||||
Customer Edge (CE) | ||||
interface identifier (IID) (per RFC 7421) | ||||
--> | ||||
<!--[rfced] Please review usage of the "/" character to separate terms in this | ||||
document (some instances included below). It may be unclear whether the | ||||
"/" stands for "or", "and", or "and/or". For clarity, please review and | ||||
let us know how/if these instances should be updated. | ||||
Originals: | ||||
Network devices need to maintain various types of | ||||
tables/hashes (Neighbor Cache on first-hop routers, Neighbor | ||||
Discovery Proxy caches on Layer 2 devices etc.). | ||||
However, providing a unique prefix per device is very uncommon in | ||||
enterprise-style networks, where nodes are usually connected to | ||||
broadcast segments/VLANs and each link has a single on-link prefix | ||||
assigned. | ||||
As most operators have some experience with IPv4, they can use a | ||||
similar approach for choosing the pool size and the timers (such as | ||||
T1/T2 timers). | ||||
Devices running containers/namespaces: each container/namespace would have | ||||
multiple addresses as described above. | ||||
--> | ||||
<!-- [rfced] Please review the "Inclusive Language" portion of the online | ||||
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> | ||||
and let us know if any changes are needed. Note that updates may result in more | ||||
precise language that better convey the meaning to the readers. | ||||
For example, please consider whether "blackholing" should be updated in the | ||||
text below: | ||||
This leads to traffic blackholing and degraded customer experience. | ||||
--> | ||||
-> | ||||
</back> | </back> | |||
</rfc> | </rfc> | |||
End of changes. 87 change blocks. | ||||
732 lines changed or deleted | 1027 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |