rfc9663.original   rfc9663.txt 
v6ops Working Group L. Colitti Internet Engineering Task Force (IETF) L. Colitti
Internet-Draft Google, LLC Request for Comments: 9663 Google, LLC
Intended status: Informational J. Linkova, Ed. Category: Informational J. Linkova, Ed.
Expires: 5 October 2024 X. Ma, Ed. ISSN: 2070-1721 X. Ma, Ed.
Google Google
3 April 2024 October 2024
Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6
Broadcast Networks Prefixes per Client in Large Broadcast Networks
draft-ietf-v6ops-dhcp-pd-per-device-08
Abstract Abstract
This document discusses an IPv6 deployment scenario when individual This document discusses an IPv6 deployment scenario when individual
nodes connected to large broadcast networks (such as enterprise nodes connected to large broadcast networks (such as enterprise
networks or public Wi-Fi networks) are allocated unique prefixes via networks or public Wi-Fi networks) are allocated unique prefixes via
DHCPv6 Prefix Delegation (DHCPv6-PD, RFC8415). DHCPv6 Prefix Delegation (DHCPv6-PD), as specified in RFC 8415.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 5 October 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9663.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology
4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 4. Design Principles
5. Applicability and Limitations . . . . . . . . . . . . . . . . 6 5. Applicability and Limitations
6. Routing and Addressing Considerations . . . . . . . . . . . . 6 6. Routing and Addressing Considerations
6.1. Prefix Pool Allocation . . . . . . . . . . . . . . . . . 6 6.1. Prefix Pool Allocation
6.2. First-Hop Router Requirements . . . . . . . . . . . . . . 7 6.2. First-Hop Router Requirements
6.3. Topologies with Multiple First-Hop Routers . . . . . . . 7 6.3. Topologies with Multiple First-Hop Routers
6.4. On-link Communication . . . . . . . . . . . . . . . . . . 8 6.4. On-Link Communication
7. DHCPv6-PD Server Considerations . . . . . . . . . . . . . . . 9 7. DHCPv6-PD Server Considerations
8. Prefix Length Considerations . . . . . . . . . . . . . . . . 10 8. Prefix Length Considerations
9. Client Mobility . . . . . . . . . . . . . . . . . . . . . . . 11 9. Client Mobility
10. Antispoofing and SAVI Interaction . . . . . . . . . . . . . . 12 10. Antispoofing and SAVI Interaction
11. Migration Strategies and Co-existence with SLAAC Using Prefixes 11. Migration Strategies and Co-existence with SLAAC Using Prefixes
From PIO . . . . . . . . . . . . . . . . . . . . . . . . 13 from the PIO
12. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. Benefits
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 13. Privacy Considerations
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 14. IANA Considerations
15. Security Considerations . . . . . . . . . . . . . . . . . . . 16 15. Security Considerations
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 16. References
16.1. Normative References . . . . . . . . . . . . . . . . . . 16 16.1. Normative References
16.2. Informative References . . . . . . . . . . . . . . . . . 17 16.2. Informative References
Appendix A. Appendix: Multiple Addresses Considerations . . . . 20 Appendix A. Multiple Addresses Considerations
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 Acknowledgements
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Often broadcast networks such as enterprise or public Wi-Fi Often, broadcast networks such as enterprise or public Wi-Fi
deployments place many devices on a shared link with a single on-link deployments place many devices on a shared link with a single on-link
prefix. This document describes an alternative deployment model prefix. This document describes an alternative deployment model
where individual devices obtain prefixes from the network. This where individual devices obtain prefixes from the network. This
provides two important advantages. provides two important advantages.
First, it offers better scalability. Unlike IPv4, IPv6 allows hosts First, it offers better scalability. Unlike IPv4, IPv6 allows hosts
to have multiple addresses, and this is the case in most deployments to have multiple addresses, and this is the case in most deployments
(see Appendix A for more details). However, increasing the number of (see Appendix A for more details). However, increasing the number of
addresses introduces scalability issues on the network addresses introduces scalability issues on the network
infrastructure. Network devices need to maintain various types of infrastructure. Network devices need to maintain various types of
tables/hashes (Neighbor Cache on first-hop routers, Neighbor tables and hashes (Neighbor Cache on first-hop routers, Neighbor
Discovery Proxy caches on Layer 2 devices etc.). On VXLAN [RFC7348] Discovery Proxy caches on Layer 2 devices, etc.). On Virtual
networks each address might be represented as a route so 8 addresses eXtensible Local Area Network (VXLAN) networks [RFC7348], each
instead of 1 requires the devices to support 8 times more routes, address might be represented as a route. This means, for example,
etc. If an infrastructure device resources are exhausted, the device that if every client has 10 addresses instead of one, the network
might drop some IPv6 addresses from the corresponding tables, while must support 10 times more routes, etc. If an infrastructure
the address owner might be still using the address to send traffic. device's resources are exhausted, the device might drop some IPv6
This leads to traffic blackholing and degraded customer experience. addresses from the corresponding tables, while the address owner
might still be using the address to send traffic. This leads to
traffic being discarded and a degraded customer experience.
Providing every host with one prefix allows the network to maintain Providing every host with one prefix allows the network to maintain
only one entry per device, while still providing the device the only one entry per device, while still providing the device the
ability to use an arbitrary number of addresses. ability to use an arbitrary number of addresses.
Second, it provides the ability to extend the network. In IPv4, a Second, this deployment model provides the ability to extend the
device that connects to the network can provide connectivity to network. In IPv4, a device that connects to the network can provide
subtended devices by using NAT. With DHCPv6 Prefix Delegation connectivity to subtended devices by using NAT. With DHCPv6 Prefix
(DHCPv6-PD, [RFC8415]), such a device can similarly extend the Delegation (DHCPv6-PD) [RFC8415], such a device can similarly extend
network, but unlike IPv4 NAT, it can provide its subtended devices the network, but unlike IPv4 NAT, it can provide its subtended
with full end-to-end connectivity. devices with full end-to-end connectivity.
Another method of deploying unique prefixes per device is documented Another method of deploying unique prefixes per device is documented
in [RFC8273]. Similarly, the standard deployment model in cellular in [RFC8273]. Similarly, the standard deployment model in cellular
IPv6 networks [RFC6459] provides a unique prefix to every device. IPv6 networks [RFC6459] provides a unique prefix to every device.
However, providing a unique prefix per device is very uncommon in However, providing a unique prefix per device is very uncommon in
enterprise-style networks, where nodes are usually connected to enterprise-style networks, where nodes are usually connected to
broadcast segments/VLANs and each link has a single on-link prefix broadcast segments such as VLANs and each link has a single on-link
assigned. This document takes a similar approach to [RFC8273], but prefix assigned. This document takes a similar approach to
allocates the prefix using DHCPv6-PD. [RFC8273], but allocates the prefix using DHCPv6-PD.
This document focuses on the behaviour of the network. Host This document focuses on the behavior of the network. Host behavior
behaviour is not defined in this document. is not defined in this document.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
Node: a device that implements IPv6, [RFC8200]. Node: a device that implements IPv6 [RFC8200]
Host: any node that is not a router, [RFC8200]. Host: any node that is not a router [RFC8200]
Client: a node which connects to a network and acquires addresses. Client: a node that connects to a network and acquires addresses.
The node may wish to obtain addresses for its own use, or may be a The node may wish to obtain addresses for its own use, or it may
router that wishes to extend the network to its physical or virtual be a router that wishes to extend the network to its physical or
subsystems, or both. It may be either a host or a router as defined virtual subsystems, or both. It may be either a host or a router
by [RFC8200]. as defined by [RFC8200].
ND: Neighbor Discovery, [RFC4861]. AP: (wireless) Access Point
NUD: Neighbor Unreachability Detection, [RFC4861]. DHCPv6 IA_NA: Identity Association for Non-temporary Addresses
(Section 21.4 of [RFC8415])
PIO: Prefix Information Option, [RFC4862]. DHCPv6 IA_PD: Identity Association for Prefix Delegation
(Section 21.21 of [RFC8415])
SLAAC: IPv6 Stateless Address Autoconfiguration, [RFC4862]. DHCPv6-PD: DHCPv6 Prefix Delegation [RFC8415]; a mechanism to
delegate IPv6 prefixes to clients.
DHCPv6-PD: DHCPv6 ([RFC8415]) mechanism to delegate IPv6 prefixes to ND: Neighbor Discovery [RFC4861]
clients.
NUD: Neighbor Unreachability Detection [RFC4861]
PIO: Prefix Information Option [RFC4862]
SLAAC: IPv6 Stateless Address Autoconfiguration [RFC4862]
4. Design Principles 4. Design Principles
Instead of all clients on a given link forming addresses from the Instead of all clients on a given link forming addresses from the
same shared prefix assigned to that link: same shared prefix assigned to that link, this deployment model
operates as described below:
* A device acts as DHCPv6-PD client and requests a prefix via * A device acts as a DHCPv6-PD client and requests a prefix via
DHCPv6-PD by sending an IA_PD request. DHCPv6-PD by sending an IA_PD request.
* The server delegates a prefix to the client and the delegated * The server delegates a prefix to the client and the delegated
prefix is installed into the routing table of the first-hop router prefix is installed into the routing table of the first-hop router
as a route pointing to the client's link-local address. The as a route pointing to the client's link-local address. The
first-hop router can act as a DHCPv6 relay and snoop DHCPv6 Reply first-hop router can act as a DHCPv6 relay and snoop DHCPv6 Reply
messages from an off-link DHCPv6 server, or it can act as a DHCPv6 messages from an off-link DHCPv6 server, or it can act as a DHCPv6
server itself. In both cases it can install the route locally, server itself. In both cases, it can install the route locally,
and if the network is running a dynamic routing protocol, and if the network is running a dynamic routing protocol,
distribute the route or the entire prefix pool into the protocol. distribute the route or the entire prefix pool into the protocol.
* For the router and all other infrastructure devices, the delegated * For the router and all other infrastructure devices, the delegated
prefix is considered off-link, so traffic to that prefix does not prefix is considered off-link, so traffic to that prefix does not
trigger any ND packets, other than the minimum ND required to trigger any ND packets, other than the minimum ND required to
sustain Neighbor Unreachability Detection (NUD) for the client's sustain Neighbor Unreachability Detection (NUD) for the client's
link-local address. link-local address.
* The device can use the delegated prefix in various ways. For * The device can use the delegated prefix in various ways. For
example, it can form addresses, as described in [RFC7084] example, it can form addresses, as described in requirement WAA-7
requirement WAA-7. It can also extend the network, as described of [RFC7084]. It can also extend the network, as described in
in [RFC7084] or [RFC7278]. [RFC7084] or [RFC7278].
An example scenario is shown in Figure 1. Note that the prefix An example scenario is shown in Figure 1. Note that the prefix
lengths used in the example are /64 because that is the prefix length lengths used in the example are /64 because that is the prefix length
currently supported by SLAAC and is not otherwise required by the currently supported by SLAAC and is not otherwise required by the
proposed deployment model. proposed deployment model.
+-----------------------------------------------------------------------------+ +------------------------------------------------------------------+
| DHCPv6 Servers | | DHCPv6 Servers |
| Pool 2001:db8:ddd0::/48 for clients on 2001:db8:c001::/64 link | | Pool 3fff:0:d::/48 for clients on 2001:db8:ff::/64 link |
+---------------+-------------------------+-----------------------------+-----+ +------------+---------------------+----------------------------+--+
^ | | ^ | ^ | | ^ |
| | | | | | | | | |
+-------+------+-------------------------+----------------------+------+-----+ +-------+------+---------------------+--------------------+-------+---+
|DHCPv6 | | IPv6 Network DHCPv6 | | | | DHCPv6| | IPv6 Network DHCPv6 | | |
|Relay-Forward | Relay-Forward | | |Relay-Forward | Relay-Forward | |
| ^ v Route for 2001:db8:ddd0::/48 ^ v | | ^ v Route for 3fff:0:d::/48 ^ v |
| | DHCPv6 | | | DHCPv6 | | | DHCPv6 | | | DHCPv6 |
| | Relay-Reply | | | Relay-Reply| | | Relay-Reply | | | Relay-Reply|
| | | | | | | | | | | | | | | |
+-----+-------+-------+-----+--------------------+-----+-------+-------+-----+ +------+-------+--+----------+------------+------+-------+--------+---+
| | | | | | | | | | | | | | | |
| v | v v | | v | v | v v | | v
+----+---------------+--------------+ +--------------+-------+-------------+ +----+----------+---------------+ +---------+-------+------------+
| First-hop router/DHCPv6 relay | | First-hop Router/DHCPv6 relay | | First-hop router/DHCPv6 relay | | First-hop Router/DHCPv6 relay|
| 2001:db8:ddd0:1::/64 -> fe80::aaaa| | 2001:db8:ddd0:1::/64 -> fe80::aaaa | | 3fff:0:d:1::/64 -> fe80::aa | | 3fff:0:d:1::/64 -> fe80::aa |
| 2001:db8:ddd0:2::/64 -> fe80::cccc| | 2001:db8:ddd0:2::/64 -> fe80::ccc | | 3fff:0:d:2::/64 -> fe80::cc | | 3fff:0:d:2::/64 -> fe80::cc |
+-----------+------------+----------+ +---------+--------------------+-----+ +------------+----------+-------+ +--------+----------------+----+
^ | | Shared IPv6 link, | ^ | ^ | | Shared IPv6 link | ^ |
| | | 2001:db8:c001::/64 | | | | | | 2001:db8:ff::/64 | | |
| | --+-------+-----------+-----------+------+--- | | | | -+-----+-----------+---------+-----+- | |
| | | | | | | | | | | | | |
| | | +----------------+--------------+ | DHCPv6 | | | | +---------------+-------------+ | DHCPv6 |
DHCPv6 | | |Legacy (no DHCPv6-PD) client B | | Request v DHCPv6 | | | Client B (no DHCPv6-PD) | | Request v
Request | | |link-local address fe80::bbbb | | ^ DHCPv6 Request | | |link-local address fe80::b | | ^ DHCPv6
^ | | |global address 2001:db8:c001::b| | | Reply ^ | | |global address 2001:db8:ff::b| | | Reply
| | | +-------------------------------+ | | | | | | +-----------------------------+ | | |
| v | | | v | v | | | v
| DHCPv6 | +-------------------+-----+------------+ | DHCPv6 | +--------------------+--+----------+
| Reply | | Client C | | Reply | | Client C |
| | | | link-local address fe80::cccc | | | | | link-local address fe80::cc |
| | | | delegated prefix 2001:db8:ddd0:2::/64| | | | | delegated prefix 3fff:0:d:2::/64 |
| | | +--------------+-+---------------------+ | | | +------------+-------------------+-+
| | | | | | v | | |
+----+-------+----+-----------------------------+ | | Router Advertisement +---+-------------+----------------------+ | Router |
| Client A | | | containing PIO | Client A | | Advertisement |
| link-local address: fe80::aaaa | | v 2001:db8:ddd0:2::/64 | link-local address: fe80::aa | | containing PIO v
| delegated prefix: 2001:db8:ddd0:1::/64 | | | delegated prefix: 3fff:0:d:1::/64 | | 3fff:0:d:2::/64
| +---------------------+ +------------------+ | -+-----------+--------- | +----------------+ +----------------+ | -+---------+-----------
| | virtual system | | virtual system | | | | | virtual system | | virtual system | | |
| | 2001:db8:ddd0:1::f00| |2001:db8:ddd0:1::2| | +---------+-----------+ | | 3fff:0:d:1::de | | 3fff:0:d:1::ad | | +------+----------+
| | 2001:db8:ddd0:1::caf| |2001:db8:ddd0:1::a| | | Tethered device | | | 3fff:0:d:1::ca | | 3fff:0:d:1::fe | | | Tethered device |
| +---------------------+ +------------------+ | |2001:db8:ddd0:2::6666| | +----------------+ +----------------+ | | 3fff:0:d:2::66 |
| | +---------------------+ | | +-----------------+
+-----------------------------------------------+ +----------------------------------------+
Figure 1: An Example Topology with Two First-Hop Routers. Figure 1: An Example Topology with Two First-Hop Routers
5. Applicability and Limitations 5. Applicability and Limitations
Delegating a unique prefix per client provides all the benefits of Delegating a unique prefix per client provides all the benefits of
both SLAAC and DHCPv6 address allocation, but at the cost of greater both SLAAC and DHCPv6 address allocation, but at the cost of greater
address space usage. This design would substantially benefit some address-space usage. This design would substantially benefit some
networks (see Section 12), in which the additional cost of an networks (see Section 12) in which the additional cost of an
additional service (DHCPv6 prefix delegation) and allocating a larger additional service (such as DHCPv6 Prefix Delegation) and allocation
amount of address space can easily be justified. Examples of such of a larger amount of address space can easily be justified.
networks include but are not limited to: Examples of such networks include but are not limited to:
* Large-scale networks where even 3-5 addresses per client might * Large-scale networks where even three to five addresses per client
introduce scalability issues. might introduce scalability issues.
* Networks with a high number of virtual hosts, so physical devices * Networks with a high number of virtual hosts, so physical devices
require multiple addresses. require multiple addresses.
* Managed networks where extensive troubleshooting, device traffic * Managed networks where extensive troubleshooting, device traffic
logging, or forensics might be required. logging, or forensics might be required.
In smaller networks, such as home networks or small enterprises, with In smaller networks, such as home networks or small enterprises with
smaller address space and lower number of clients, SLAAC is a simpler smaller address space and a lower number of clients, SLAAC is a
and often preferred option. simpler and often preferred option.
6. Routing and Addressing Considerations 6. Routing and Addressing Considerations
6.1. Prefix Pool Allocation 6.1. Prefix Pool Allocation
One simple deployment model is to assign a dedicated prefix pool to One simple deployment model is to assign a dedicated prefix pool to
each link. The prefixes from each link's pool are only issued to each link. The prefixes from each link's pool are only issued to
requesting clients on the link, and if clients move to another link requesting clients on the link; if clients move to another link, they
they will obtain a prefix from the pool associated with the new link will obtain a prefix from the pool associated with the new link (see
(see Section 9). Section 9).
This is very similar to how address pools are allocated when using This is very similar to how address pools are allocated when using
DHCP to assign individual addresses (e.g., DHCPv4 or DHCPv6 IA_NA), 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 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 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 route the entire pool to the link's first-hop routers, and the
routers do not need to advertise individual delegated prefixes into routers do not need to advertise individual delegated prefixes into
the network's dynamic routing protocol. the network's dynamic routing protocol.
Other deployment models, such as prefix pools shared over multiple Other deployment models, such as prefix pools shared over multiple
links or routers, are possible, but not described in this document. links or routers, are possible but are not described in this
document.
6.2. First-Hop Router Requirements 6.2. First-Hop Router Requirements
In large networks, DHCPv6 servers are usually centralized, and In large networks, DHCPv6 servers are usually centralized and reached
reached via DHCPv6 relays co-located with the first-hop routers. To via DHCPv6 relays co-located with the first-hop routers. To delegate
delegate IPv6 prefixes to clients, the first hop routers need to IPv6 prefixes to clients, the first hop routers need to implement
implement DHCPv6 relay functions and meet the requirements defined in DHCPv6 relay functions and meet the requirements defined in
[RFC8987]. In particular, per Section 4.2 of [RFC8987], the first- [RFC8987]. In particular, per Section 4.2 of [RFC8987], the first-
hop router must maintain a local routing table that contains all hop router must maintain a local routing table that contains all
prefixes delegated to clients. prefixes delegated to clients.
With the first-hop routers performing DHCPv6 relay functions, the With the first-hop routers performing DHCPv6 relay functions, the
proposed design neither requires any subsequent relays in the path proposed design neither requires any subsequent relays in the path
nor introduces any requirements (e.g., snooping) to such subsequent nor introduces any requirements (e.g., snooping) for such subsequent
relays, if they are deployed. relays, if they are deployed.
To ensure that routes to the delegated prefixes are preserved even if To ensure that routes to the delegated prefixes are preserved even if
a relay is rebooted or replaced, the operator MUST ensure that all a relay is rebooted or replaced, the operator MUST ensure that all
relays in the network infrastructure support DHCPv6 Bulk Leasequery relays in the network infrastructure support DHCPv6 Bulk Leasequery
as defined in [RFC5460]. While Section 4.3 of [RFC8987] lists as defined in [RFC5460]. While Section 4.3 of [RFC8987] lists
keeping active prefix delegations in persistent storage as an keeping active prefix delegations in persistent storage as an
alternative to DHCPv6 Bulk Leasequery, relying on persistent storage alternative to DHCPv6 Bulk Leasequery, relying on persistent storage
has the following drawbacks: has the following drawbacks:
* In a network with multiple relays, network state can change * In a network with multiple relays, network state can change
significantly while the relay is rebooting (new prefixes significantly while the relay is rebooting (new prefixes might be
delegated, some prefixes expiring etc). delegated or some prefixes might be expiring, etc).
* Persistent storage might not be preserved if the router is * Persistent storage might not be preserved if the router is
physically replaced. physically replaced.
Another mechanism for first-hop routers to obtain information about Another mechanism for first-hop routers to obtain information about
delegated prefixes is by using Active Leasequery [RFC7653], though delegated prefixes is by using Active Leasequery [RFC7653], though
this is not yet widely supported. this is not yet widely supported.
6.3. Topologies with Multiple First-Hop Routers 6.3. Topologies with Multiple First-Hop Routers
skipping to change at page 8, line 13 skipping to change at line 348
possible if the client multicasts the DHCPv6 messages it sends to the possible if the client multicasts the DHCPv6 messages it sends to the
server. The server will receive one copy of the client message server. The server will receive one copy of the client message
through each first-hop relay, and will reply unicast to each of them through each first-hop relay, and will reply unicast to each of them
via the relay (or chain of relays) from which it received the via the relay (or chain of relays) from which it received the
message. Thus, all first-hop relays will be able to snoop the message. Thus, all first-hop relays will be able to snoop the
replies. Per Section 14 of [RFC8415], clients always use multicast replies. Per Section 14 of [RFC8415], clients always use multicast
unless the server uses the Server Unicast option to explicitly allow unless the server uses the Server Unicast option to explicitly allow
unicast communication ([RFC8415], Section 21.12). Therefore, in unicast communication ([RFC8415], Section 21.12). Therefore, in
topologies with multiple first-hop routers, the DHCPv6 servers MUST topologies with multiple first-hop routers, the DHCPv6 servers MUST
be configured not to use the Server Unicast option. It should be be configured not to use the Server Unicast option. It should be
noted that [I-D.ietf-dhc-rfc8415bis] deprecates the Server Unicast noted that [RFC8415bis] deprecates the Server Unicast option
option precisely because it is not compatible with topologies with precisely because it is not compatible with topologies with multiple
multiple first-hop relays. first-hop relays.
To recover from crashes or reboots, relays can use Bulk Leasequery or To recover from crashes or reboots, relays can use Bulk Leasequery or
Active Leasequery to issue a QUERY_BY_RELAY_ID with the ID(s) of the 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 other relay(s), as configured by the operator. Additionally, some
vendors provide vendor-specific mechanisms to synchronize state vendors provide vendor-specific mechanisms to synchronize state
between DHCP relays. between DHCP relays.
6.4. On-link Communication 6.4. On-Link Communication
For security reasons, some networks block on-link device-to-device For security reasons, some networks block on-link device-to-device
traffic at layer 2 to prevent communication between clients on the traffic at Layer 2 to prevent communication between clients on the
same link. In this case, delegating a prefix to each client doesn't same link. In this case, delegating a prefix to each client doesn't
affect traffic flows, as all traffic is sent to the first-hop router affect traffic flows, as all traffic is sent to the first-hop router
anyway. Depending on the network security policy, the router may anyway. Depending on the network security policy, the router may
allow or drop the traffic. allow or drop the traffic.
If the network does allow peer-to-peer communication, the PIO for the 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 on-link prefix is usually advertised with the L-bit set to 1
[RFC4861]. As a result, all addresses from that prefix are [RFC4861]. As a result, all addresses from that prefix are
considered on-link, and traffic to those destinations is sent considered on-link, and traffic to those destinations is sent
directly (not via routers). If such a network delegates prefixes to directly (not via routers). If such a network delegates prefixes to
clients (as described in this document), then each client will clients (as described in this document), then each client will
consider other client's destination addresses to be off-link, because consider other client's destination addresses to be off-link, because
those addresses are from the delegated prefixes and are no longer those addresses are from the delegated prefixes and are no longer
within the on-link prefix. When a client sends traffic to another within the on-link prefix. When a client sends traffic to another
client, packets will initially be sent to the default router. The client, packets will initially be sent to the default router. The
router will respond with an ICMPv6 redirect message (Section 4.5 of router will respond with an ICMPv6 redirect message (Section 4.5 of
[RFC4861]). If the client receives and accepts the redirect, then [RFC4861]). If the client receives and accepts the redirect, then
traffic can flow directly from device to device. Therefore the traffic can flow directly from device to device. Therefore, the
administrator deploying the solution described in this document administrator deploying the solution described in this document
SHOULD ensure that the first-hop routers can send ICMPv6 redirects SHOULD ensure that the first-hop routers can send ICMPv6 redirects
(the routers are configured to do so and the security policies permit (the routers are configured to do so and the security policies permit
those messages). those messages).
7. DHCPv6-PD Server Considerations 7. DHCPv6-PD Server Considerations
This document does not introduce any changes to the DHCPv6 protocol This document does not introduce any changes to the DHCPv6 protocol
itself. However, for the proposed solution to work correctly, the itself. However, for the proposed solution to work correctly, the
DHCPv6-PD server needs to be configured as follows: DHCPv6-PD server needs to be configured as follows:
* The server MUST follow [RFC8168] recommendations on processing * The server MUST follow recommendations from [RFC8168] on
prefix-length hints. processing prefix-length hints.
* The server MUST provide a prefix short enough for the client to * The server MUST provide a prefix short enough for the client to
extend the network to at least one interface, and allow nodes on extend the network to at least one interface and allow nodes on
that interface to obtain addresses via SLAAC. The server MAY that interface to obtain addresses via SLAAC. The server MAY
provide more address space to clients that ask for it, either by provide more address space to clients that ask for it, either by
delegating multiple such prefixes, or by delegating a single delegating multiple such prefixes, or by delegating a single
prefix of a shorter length. It should be noted that [RFC8168] prefix of a shorter length. It should be noted that [RFC8168]
allows the server to provide a prefix shorter than the prefix- allows the server to provide a prefix shorter than the prefix-
length hint value received from the client. length hint value received from the client.
* If the server receives the same SOLICIT message from the same * If the server receives the same Solicit message from the same
client multiple times through multiple relays, it MUST reply to client multiple times through multiple relays, it MUST reply to
all of them with the same prefix(es). This ensures that all the all of them with the same prefix(es). This ensures that all the
relays will correctly configure routes to the delegated prefixes. relays will correctly configure routes to the delegated prefixes.
* The server MUST NOT send the Server Unicast option to the client * The server MUST NOT send the Server Unicast option to the client
unless the network topology guarantees that no client is connected unless the network topology guarantees that no client is connected
to a link with multiple relays (see Section 6.3). to a link with multiple relays (see Section 6.3).
* In order to ensure uninterrupted connectivity when a first-hop * In order to ensure uninterrupted connectivity when a first-hop
router crashes or reboots, the server MUST support Bulk Leasequery router crashes or reboots, the server MUST support Bulk Leasequery
or Active Leasequery. or Active Leasequery.
As most operators have some experience with IPv4, they can use a As most operators have some experience with IPv4, they can use a
similar approach for choosing the pool size and the timers (such as similar approach for choosing the pool size and the timers (such as
T1/T2 timers). In particular the following factors shall be taken T1 and T2 timers). In particular, the following factors should be
into account: taken into account:
* the expected maximum number of clients; * the expected maximum number of clients;
* average duration of a client connection; * the average duration of client connections;
* how mobile the clients are (a network where all clients are * how mobile the clients are (a network where all clients are
connected to a single wired VLAN might choose longer timers than a connected to a single wired VLAN might choose longer timers than a
network where clients can switch between multiple wireless SSIDs); network where clients can switch between multiple wireless
networks);
* expected level of recurring clients (for example, a corporate * how often clients are expected to reconnect to the network (for
authenticated Wi-Fi network might be using longer timers than an example, a corporate authenticated Wi-Fi network might be using
open public Wi-Fi). longer timers than an open public Wi-Fi).
DHCPv6 servers that delegate prefixes can interface with Dynamic DNS DHCPv6 servers that delegate prefixes can interface with Dynamic DNS
infrastructure to automatically populate reverse DNS, similarly to infrastructure to automatically populate reverse DNS using wildcard
what is described in section 2.5.2 of RFC [RFC8501]. Networks that records, similarly to what is described in Section 2.2 of [RFC8501].
also wish to populate forward DNS cannot do so automatically based Networks that also wish to populate forward DNS cannot do so
only on DHCPv6 prefix delegation transactions, but they can do so in automatically based only on DHCPv6 prefix delegation transactions,
other ways, such as by supporting DHCPv6 address registration as but they can do so in other ways, such as by supporting DHCPv6
described in [I-D.ietf-dhc-addr-notification]. address registration as described in [ADDR-NOTIFICATION].
Some additional recommendations driven by security and privacy Some additional recommendations driven by security and privacy
considerations are discussed in Section 15 and Section 13. considerations are discussed in Section 15 and Section 13.
8. Prefix Length Considerations 8. Prefix Length Considerations
Delegating a prefix of sufficient size to use SLAAC allows the client Delegating a prefix of sufficient size to use SLAAC allows the client
to extend the network, providing limitless addresses to IPv6 nodes to extend the network, providing limitless addresses to IPv6 nodes
connected to it (e.g., virtual machines, tethered devices), because connected to it (e.g., virtual machines or tethered devices), because
all IPv6 hosts are required to support SLAAC [RFC8504]. all IPv6 hosts are required to support SLAAC [RFC8504].
Additionally, even clients that support other forms of address Additionally, even clients that support other forms of address
assignment require SLAAC for some functions, such as forming assignment require SLAAC for some functions, such as forming
dedicated addresses for the use of 464XLAT (see Section 6.3 of dedicated addresses for the use of 464XLAT (see Section 6.3 of
[RFC6877]). [RFC6877]).
At the time of writing the only prefix size that will allow devices At the time of writing, the only prefix size that will allow devices
to use SLAAC is 64 bits. Also, as noted in [RFC7421], using an IID to use SLAAC is 64 bits. Also, as noted in [RFC7421], using an
shorter than 64 bits and a subnet prefix longer than 64 bits is interface identifier (IID) shorter than 64 bits and a subnet prefix
outside the current IPv6 specifications. Choosing longer prefixes longer than 64 bits is outside the current IPv6 specifications.
would require the client and any connected system to use other Choosing longer prefixes would require the client and any connected
address assignment mechanisms. This would limit the applicability of system to use other address assignment mechanisms. This would limit
the proposed solution, as other mechanisms are not currently the applicability of the proposed solution, as other mechanisms are
supported by many hosts. not currently supported by many hosts.
For the same reasons, a prefix length of /64 or shorter is required For the same reasons, a prefix length of /64 or shorter is required
to extend the network using [RFC7084] (see requirement L-2), and a to extend the network as described in [RFC7084] (see requirement
prefix length of /64 is required to provide global connectivity for L-2), and a prefix length of /64 is required to provide global
stub networks as per [I-D.ietf-snac-simple]. connectivity for stub networks as per [SNAC-SIMPLE].
Assigning a prefix of sufficient size to support SLAAC is possible on Assigning a prefix of sufficient size to support SLAAC is possible on
large networks. In general, any network that numbers clients from an large networks. In general, any network that numbers clients from an
IPv4 prefix of length X (e.g., X=/18, X=/24), would require an IPv6 IPv4 prefix of length X (e.g., X=/18, X=/24) would require an IPv6
prefix of length X+32 (e.g., X=/40, X=/56) to provide a /64 prefix to prefix of length X+32 (e.g., X=/40, X=/56) to provide a /64 prefix to
every device. As an example, Section 9.2 of [RFC7934] suggests that every device. As an example, Section 9.2 of [RFC7934] suggests that
even a very large network that assigns every single one of the 16 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 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 /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 more /40s in the current IPv6 unicast range 2000::/3 than there are
IPv4 addresses. Existing sites that currently use a /48 prefix IPv4 addresses. Existing sites that currently use a /48 prefix
cannot support more than 64k clients in this model without cannot support more than 64k clients in this model without
renumbering, though many networks of such size have LIR status and renumbering, though many networks of such size have Local Internet
can justify bigger address blocks. Registry (LIR) status and can justify bigger address blocks.
Note that assigning a prefix of sufficient size to support SLAAC does Note that assigning a prefix of sufficient size to support SLAAC does
not require that subtended nodes use SLAAC; they can use other not require that subtended nodes use SLAAC; they can use other
address assignment mechanisms as well. address assignment mechanisms as well.
9. Client Mobility 9. Client Mobility
As per Section 18.2.12 of [RFC8415], when the client moves to a new As per Section 18.2.12 of [RFC8415], when the client moves to a new
link, it MUST initiate a Rebind/Reply message exchange. Therefore link, it MUST initiate a Rebind/Reply message exchange. Therefore,
when the client moves between network attachment points it would when the client moves between network attachment points, it would
refresh its delegated prefix the same way it refreshes addresses refresh its delegated prefix the same way it refreshes addresses
assigned (via SLAAC or DHCPv6 IA_NA) from a shared on-link prefix: assigned (via SLAAC or DHCPv6 IA_NA) from a shared on-link prefix:
* When a client moves from between different attachment points on * When a client moves from between different attachment points on
the same link (e.g., roams between two APs while connected to the the same link (e.g., roams between two APs while connected to the
same SSID or moves between two switchports belonging to the same same wireless network or moves between two switchports belonging
VLAN), the delegated prefix does not change, and the first-hop to the same VLAN), the delegated prefix does not change, and the
routers have a route for the prefix with the nexthop set to the first-hop routers have a route for the prefix with the nexthop set
client link-local address on that link. As per requirement S-2 to the client link-local address on that link. As per requirement
(Section 4.3 of [RFC8987]), the DHCPv6-relays (the first-hop S-2 in Section 4.3 of [RFC8987], the DHCPv6-relays (the first-hop
routers) MUST retain the route for the delegating prefix until the routers) MUST retain the route for the delegating prefix until the
route is released or removed due to expiring DHCP timers. route is released or removed due to expiring DHCP timers.
Therefore, if the client reconnects to the same link, the prefix Therefore, if the client reconnects to the same link, the prefix
doesn't change. doesn't change.
* When a client moves to a different link, the DHCPv6 server * When a client moves to a different link, the DHCPv6 server
provides the client with a new prefix, so the behaviour is provides the client with a new prefix, so the behavior is
consistent with SLAAC or DHCPv6-assigned addresses, which are also consistent with SLAAC or DHCPv6-assigned addresses, which are also
different on the new link. different on the new link.
In theory, DHCPv6 servers can delegate the same prefix to the same In theory, DHCPv6 servers can delegate the same prefix to the same
client even if the client changes the attachment points. However, client even if the client changes the attachment points. However,
while allowing the client to keep the same prefix while roaming while allowing the client to keep the same prefix while roaming
between links might provide some benefits for the client, it is not between links might provide some benefits for the client, it is not
feasible without changing DHCPv6 relay behaviour: after the client feasible without changing DHCPv6 relay behavior: after the client
moves to a new link, the DHCPv6 relays would retain the route moves to a new link, the DHCPv6 relays would retain the route
pointing to the client's link-local address on the old link for the pointing to the client's link-local address on the old link for the
duration of DHCPv6 timers (see requirement S-2, Section 4.3 of duration of DHCPv6 timers (see requirement S-2, Section 4.3 of
[RFC8987]). As a result, the first-hop routers would have two routes [RFC8987]). As a result, the first-hop routers would have two routes
for the same prefix pointing to different links, causing connectivity for the same prefix pointing to different links, causing connectivity
issues for the client. issues for the client.
It should be noted that addressing clients from a shared on-link It should be noted that addressing clients from a shared on-link
prefix also does not allow clients to keep addresses while roaming prefix also does not allow clients to keep addresses while roaming
between links, so the proposed solution is not different in that between links, so the proposed solution is not different in that
regard. In addition to that, quite often different links have regard. In addition to that, different links often have different
different security policies applied (for example, corporate internal security policies applied (for example, corporate internal networks
network vs guest network), hence clients on different links need to versus guest networks), hence clients on different links need to use
use different prefixes. different prefixes.
10. Antispoofing and SAVI Interaction 10. Antispoofing and SAVI Interaction
Enabling the unicast Reverse Path Forwarding (uRPF, [RFC3704]) on the Enabling unicast Reverse Path Forwarding (uRPF) [RFC3704] on the
first-hop router interfaces towards clients provides the first layer first-hop router interfaces towards clients provides the first layer
of defense against spoofing. A spoofed packet sent by a malicious of defense against spoofing. A spoofed packet sent by a malicious
client would be dropped by the router unless the spoofed address client would be dropped by the router unless the spoofed address
belongs to a prefix delegated to another client on the same belongs to a prefix delegated to another client on the same
interface. Therefore the malicious client can only spoof addresses interface. Therefore the malicious client can only spoof addresses
already delegated to another client on the same link or another already delegated to another client on the same link or another
client link-local address. client's link-local address.
Source Address Validation Improvement (SAVI, [RFC7039]) provides more Source Address Validation Improvement (SAVI) [RFC7039] provides more
reliable protection against address spoofing. Administrators reliable protection against address spoofing. Administrators
deploying the proposed solution on SAVI-enabled infrastructure SHOULD deploying the proposed solution on SAVI-enabled infrastructure SHOULD
ensure that SAVI perimeter devices support DHCPv6-PD snooping to ensure that SAVI perimeter devices support DHCPv6-PD snooping to
create the correct binding for the delegated prefixes (see create the correct binding for the delegated prefixes (see
[RFC7513]). Using FCFS SAVI ([RFC6620]) for protecting link-local [RFC7513]). Using FCFS SAVI [RFC6620] to protect link-local
addresses and creating SAVI bindings for DHCPv6-PD assigned prefixes addresses and create SAVI bindings for DHCPv6-PD assigned prefixes
would prevent spoofing. would prevent spoofing.
Some infrastructure devices do not implement SAVI as defined in Some infrastructure devices do not implement SAVI as defined in
[RFC7039] but perform other forms of address tracking and snooping [RFC7039]; instead, they perform other forms of address tracking and
for security or performance improvement purposes (e.g., ND proxy). snooping for security or performance improvement purposes (e.g., ND
This is very common behaviour for wireless devices (access points and proxy). This is very common behavior for wireless devices (such as
controllers). Administrators SHOULD ensure that such devices are access points and controllers). Administrators SHOULD ensure that
able to snoop DHCPv6-PD packets, so the traffic from the delegated such devices are able to snoop DHCPv6-PD packets so the traffic from
prefixes is not dropped. the delegated prefixes is not dropped.
It should be noted that using DHCPv6-PD makes it harder for an It should be noted that using DHCPv6-PD makes it harder for an
attacker to select the spoofed source address. When all clients are attacker to select the spoofed source address. When all clients are
using the same shared link to form addresses, the attacker might using the same shared link to form addresses, the attacker might
learn addresses used by other clients by listening to multicast learn addresses used by other clients by listening to multicast
Neighbor Solicitations and Neighbour Advertisements. In DHCPv6-PD Neighbor Solicitations and Neighbor Advertisements. In DHCPv6-PD
environments, however, the attacker can only learn about other environments, however, the attacker can only learn about other
clients's global addresses by listening to multicast DHCPv6 messages, clients' global addresses by listening to multicast DHCPv6 messages,
which are not transmitted so often, and may not be received by the 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 client at all because they are sent to multicast groups that are
specific to DHCPv6 servers and relays. specific to DHCPv6 servers and relays.
11. Migration Strategies and Co-existence with SLAAC Using Prefixes 11. Migration Strategies and Co-existence with SLAAC Using Prefixes
From PIO from the PIO
It would be beneficial for the network to explicitly indicate its It would be beneficial for the network to explicitly indicate its
support of DHCPv6-PD for connected clients. support of DHCPv6-PD for connected clients.
* In small networks (e.g., home networks), where the number of * In small networks (e.g., home networks), where the number of
clients is not too high, the number of available prefixes becomes clients is not too high, the number of available prefixes becomes
a limiting factor. If every phone or laptop in a home network a limiting factor. If every phone or laptop in a home network
were to request a unique prefix suitable for SLAAC, the home were to request a unique prefix suitable for SLAAC, the home
network might run out of prefixes, if the prefix allocated to the network might run out of prefixes, if the prefix allocated to the
CPE by its ISP is too small (e.g., if an ISP delegates a /60, it Customer Premises Equipment (CPE) by its ISP is too long. For
would only be able to delegate 15 /64 prefixes to clients). So example, if an ISP delegates a /60, the CPE would only be able to
while the enterprise network administrator might want all phones delegate fifteen /64 prefixes to clients. So while the enterprise
in the network to request a prefix, it would be highly undesirable network administrator might want all phones in the network to
for the same phone to request a prefix when connecting to a home request a prefix, it would be highly undesirable for the same
network. phone to request a prefix when connecting to a home network.
* When the network supports both a unique prefix per client and a * When the network supports both a unique prefix per client and a
PIO with A=1 as address assignment methods, it's highly desirable 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 for the client NOT to use the PIO prefix to form global addresses
and only use the prefix delegated via DHCPv6-PD. Starting both and instead only use the prefix delegated via DHCPv6-PD. Starting
SLAAC using the PIO prefix and DHCPv6-PD and deprecating that both SLAAC using the PIO prefix and DHCPv6-PD, and then
SLAAC addresses after receiving a delegated prefix would be very deprecating the SLAAC addresses after receiving a delegated prefix
disruptive for applications. If the client continues to use would be very disruptive for applications. If the client
addresses formed from the PIO prefix it would not only undermine continues to use addresses formed from the PIO prefix, it would
the benefits of the proposed solution (see Section 12), but would not only undermine the benefits of the proposed solution (see
also introduce complexity and unpredictability in the source Section 12), but it would also introduce complexity and
address selection. Therefore, the client needs to know what unpredictability in the source address selection. Therefore, the
address assignment method to use and whether to use the prefix in client needs to know what address assignment method to use and
PIO or not, if the network provides the PIO with A flag set. whether or not to use the prefix in the PIO, if the network
provides the PIO with the 'A' flag set.
The deployment model described in this document does not require the The deployment model described in this document does not require the
network to signal support of DHCPv6-PD: for example, devices acting network to signal support of DHCPv6-PD: for example, devices acting
as [RFC7084] compatible routers will be able to receive prefixes via as compatible routers [RFC7084] will be able to receive prefixes via
DHCPv6-PD even without such signalling. Also, some clients may DHCPv6-PD even without such signaling. Also, some clients may decide
decide to start DHCPv6-PD, and acquire prefixes, if they detect that to start DHCPv6-PD and acquire prefixes if they detect that the
the network does not provide addresses via SLAAC. To fully achieve network does not provide addresses via SLAAC. To fully achieve the
the benefits described in this section, [I-D.collink-6man-pio-pflag] benefits described in this section, [PIO-PFLAG] defines a new PIO
defines a new PIO flag to signal that DHCPv6-PD is the preferred flag to signal that DHCPv6-PD is the preferred method of obtaining
method of obtaining prefixes. prefixes.
12. Benefits 12. Benefits
The proposed solution provides the following benefits: The proposed solution provides the following benefits:
* Network device resources (e.g., memory) need to scale to the * Network device resources (e.g., memory) need to scale to the
number of devices, not the number of IPv6 addresses. The first- number of devices, not the number of IPv6 addresses. The first-
hop routers have a single route per device pointing to the hop routers have a single route per device pointing to the
device's link-local address. This can potentially enable hardware device's link-local address. This can potentially enable hardware
cost savings, for example if hardware such as wireless LAN cost savings; for example, if hardware such as wireless LAN
controllers is limited to supporting only a specific number of controllers is limited to supporting only a specific number of
client addresses, or in VXLAN deployments where each client client addresses, or in VXLAN deployments where each client
address consumes one routing table entry. address consumes one routing table entry.
* The cost of having multiple addresses is offloaded to the clients. * The cost of having multiple addresses is offloaded to the clients.
Hosts are free to create and use as many addresses as they need Hosts are free to create and use as many addresses as they need
without imposing any additional costs onto the network. without imposing any additional costs onto the network.
* If all clients connected to the given link support this mode of * If all clients connected to the given link support this mode of
operation and can generate addresses from the delegated prefixes, operation and can generate addresses from the delegated prefixes,
there is no reason to advertise a common prefix assigned to that there is no reason to advertise a common prefix assigned to that
link in PIO with 'A' flag set. Therefore it is possible to remove link in the PIO with the 'A' flag set. Therefore, it is possible
the global shared prefix from that link and the router interface to remove the global shared prefix from that link and the router
completely, so no global addresses are on-link for the link. This interface completely, so no global addresses are on-link for the
would lead to reducing the attack surface for Neighbor Discovery link. This would lead to reducing the attack surface for Neighbor
attacks described in [RFC6583]. Discovery attacks described in [RFC6583].
* DHCPv6-PD logs and first-hop routers routing tables provide * DHCPv6-PD logs and routing tables obtained from first-hop routers
complete information on IPv6 to MAC mapping, which can be used for provide complete information on IPv6 to MAC mapping, which can be
forensics and troubleshooting. Such information is much less used for forensics and troubleshooting. Such information is much
dynamic than ND cache and therefore it's much easier for an less dynamic than the ND cache; therefore, it's much easier for an
operator to collect and process it. operator to collect and process it.
* A dedicated prefix per client allows the network administrator to * A dedicated prefix per client allows the network administrator to
create per-device security policies (ACLs) even if the client is create security policies per device (such as ACLs) even if the
using temporary addresses. This mitigates one of the issues client is using temporary addresses. This mitigates one of the
described in [I-D.ietf-opsec-ipv6-addressing]. issues described in [IPv6-ADDRESS].
* Fate sharing: all global addresses used by a given client are * Fate sharing: all global addresses used by a given client are
routed as a single prefix. Either all of them work or not, which routed as a single prefix. Either all of them work or none of
makes failures easier to diagnose and mitigate. them work, which makes failures easier to diagnose and mitigate.
* Lower level of multicast traffic: less Neighbor Discovery * Lower level of multicast traffic: less Neighbor Discovery
([RFC4861]) multicast packets, as there are only clients link- [RFC4861] multicast packets, as the routers need to resolve only
local addresses the routers need to resolve. Also, no DAD traffic the clients' link-local addresses. Also, there is no Duplicate
except for clients' link-local addresses. Address Detection (DAD) traffic except for the clients' link-local
addresses.
* Ability to extend the network transparently. If the network * Ability to extend the network transparently. If the network
delegates to the client a prefix of sufficient size to support delegates to the client a prefix of sufficient size to support
SLAAC, the client can to provide connectivity to other hosts, as SLAAC, the client can provide connectivity to other hosts, as is
is possible in IPv4 with NAT (e.g., by acting as an IPv6 CE router possible in IPv4 with NAT (e.g., by acting as an IPv6 Customer
as described in [RFC7084]). Edge (CE) router as described in [RFC7084]).
13. Privacy Considerations 13. Privacy Considerations
If an eavesdropper or information collector is aware that a given If an eavesdropper or information collector is aware that a given
client is using the proposed mechanism, then they may be able to client is using the proposed mechanism, then they may be able to
track the client based on its prefix. The privacy implications of track the client based on its prefix. The privacy implications of
this are equivalent to the privacy implications of networks using this are equivalent to the privacy implications of networks using
stateful DHCPv6 address assignment: in both cases, the IPv6 addresses stateful DHCPv6 address assignment: in both cases, the IPv6 addresses
are determined by the server, either because the server assigns a are determined by the server, either because the server assigns a
full 128-bit address in a shared prefix, or because the server full 128-bit address in a shared prefix, or because the server
determines what prefix is delegated to the client. Administrators determines what prefix is delegated to the client. Administrators
deploying the proposed mechanism can use similar methods to mitigate deploying the proposed mechanism can use similar methods to mitigate
the impact as the ones used today in networks that use stateful the impact as the ones used today in networks that use stateful
DHCPv6 address assignment. DHCPv6 address assignment.
Except for networks (such as datacenter networks) where hosts do not Except for networks (such as datacenter networks) where hosts do not
need temporary addresses ([RFC8981]), the network SHOULD: need temporary addresses [RFC8981], the network SHOULD:
* Ensure that when a client requests a prefix, the prefix is * Ensure that when a client requests a prefix, the prefix is
randomly assigned and not allocated deterministically. randomly assigned and not allocated deterministically.
* Use short prefix lifetimes (e.g., hours), to ensure that when a * Use short prefix lifetimes (e.g., hours) to ensure that when a
client disconnects and reconnects it gets a different prefix. client disconnects and reconnects it gets a different prefix.
* Allow the client to have more than one prefix at the same time. * Allow the client to have more than one prefix at the same time.
This allows the client to rotate prefixes using a mechanism This allows the client to rotate prefixes using a mechanism
similar to temporary addresses, but that operates on prefixes similar to temporary addresses, but that operates on prefixes
instead of on individual addresses. In this case the prefix's instead of on individual addresses. In this case, the prefix's
lifetime MUST be short enough to allow the client to use a lifetime MUST be short enough to allow the client to use a
reasonable rotation interval without using too much address space. reasonable rotation interval without using too much address space.
For example, if every 24 hours the the client asks for a new For example, if every 24 hours the client asks for a new prefix
prefix and stops renewing the old prefix, and the Valid Lifetime and stops renewing the old prefix, and the Valid Lifetime of
of delegated prefixes is one hour, then the client will consume delegated prefixes is one hour, then the client will consume two
two prefixes for one hour out of 24 hours, and thus will on prefixes for one hour out of 24 hours, and thus will consume just
average consume just under 1.05 prefixes. under 1.05 prefixes on average.
14. IANA Considerations 14. IANA Considerations
This memo includes no request to IANA. This document has no IANA actions.
15. Security Considerations 15. Security Considerations
A malicious (or just misbehaving) client might attempt to exhaust the A malicious (or just misbehaving) client might attempt to exhaust the
DHCPv6-PD pool by sending a large number of requests with differing DHCPv6-PD pool by sending a large number of requests with differing
DUIDs. To prevent a misbehaving client from denying service to other DHCP Unique Identifiers (DUIDs). To prevent a misbehaving client
clients, the DHCPv6 server or relay MUST support limiting the number from denying service to other clients, the DHCPv6 server or relay
of prefixes delegated to a given client at any given time. MUST support limiting the number of prefixes delegated to a given
client at any given time.
Networks can protect against malicious clients by authenticating Networks can protect against malicious clients by authenticating
devices using tokens that cannot be spoofed (e.g., 802.1x devices using tokens that cannot be spoofed (e.g., 802.1x
authentication) and limiting the number of link-local addresses or authentication) and limiting the number of link-local addresses or
MAC addresses that each client is allowed to use. Note that is not a MAC addresses that each client is allowed to use. Note that this is
new issue, as the same attack might be implemented using DHCPv4 or not a new issue, as the same attack might be implemented using DHCPv4
DHCPv6 IA_NA requests; in particular, while it is unlikely for or DHCPv6 IA_NA requests; in particular, while it is unlikely for
clients to be able to exhaust an IA_NA address pool, clients using clients to be able to exhaust an IA_NA address pool, clients using
IA_NA can exhaust other resources such as DHCPv6 and routing IA_NA can exhaust other resources such as DHCPv6 and routing
infrastructure resources such server RAM, ND cache entries, TCAM infrastructure resources such as server RAM, ND cache entries,
entries, SAVI entries, etc. Ternary Content-Addressable Memory (TCAM) entries, SAVI entries, etc.
A malicious client might request a prefix and then release it very A malicious client might request a prefix and then release it very
quickly, causing routing convergence events on the relays. The quickly, causing routing convergence events on the relays. The
impact of this attack can be reduced if the network rate-limits the impact of this attack can be reduced if the network rate-limits the
amount of broadcast and multicast messages from the client. amount of broadcast and multicast messages from the client.
Delegating the same prefix for the same client introduces privacy Delegating the same prefix for the same client introduces privacy
concerns. The proposed mitigation is discussed in Section 13. concerns. The proposed mitigation is discussed in Section 13.
Spoofing scenarios and prevention mechanisms are discussed in Spoofing scenarios and prevention mechanisms are discussed in
skipping to change at page 16, line 48 skipping to change at line 751
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
DOI 10.17487/RFC5460, February 2009, DOI 10.17487/RFC5460, February 2009,
<https://www.rfc-editor.org/info/rfc5460>. <https://www.rfc-editor.org/info/rfc5460>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses", Improvement for Locally Assigned IPv6 Addresses",
RFC 6620, DOI 10.17487/RFC6620, May 2012, RFC 6620, DOI 10.17487/RFC6620, May 2012,
<https://www.rfc-editor.org/info/rfc6620>. <https://www.rfc-editor.org/info/rfc6620>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013, RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>. <https://www.rfc-editor.org/info/rfc6877>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>.
[RFC8168] Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix-Length Hint [RFC8168] Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix-Length Hint
Issues", RFC 8168, DOI 10.17487/RFC8168, May 2017, Issues", RFC 8168, DOI 10.17487/RFC8168, May 2017,
<https://www.rfc-editor.org/info/rfc8168>. <https://www.rfc-editor.org/info/rfc8168>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
skipping to change at page 18, line 5 skipping to change at line 802
DOI 10.17487/RFC8981, February 2021, DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>. <https://www.rfc-editor.org/info/rfc8981>.
[RFC8987] Farrer, I., Kottapalli, N., Hunek, M., and R. Patterson, [RFC8987] Farrer, I., Kottapalli, N., Hunek, M., and R. Patterson,
"DHCPv6 Prefix Delegating Relay Requirements", RFC 8987, "DHCPv6 Prefix Delegating Relay Requirements", RFC 8987,
DOI 10.17487/RFC8987, February 2021, DOI 10.17487/RFC8987, February 2021,
<https://www.rfc-editor.org/info/rfc8987>. <https://www.rfc-editor.org/info/rfc8987>.
16.2. Informative References 16.2. Informative References
[ADDR-NOTIFICATION]
Kumari, W., Krishnan, S., Asati, R., Colitti, L., Linkova,
J., and S. Jiang, "Registering Self-generated IPv6
Addresses using DHCPv6", Work in Progress, Internet-Draft,
draft-ietf-dhc-addr-notification-13, 16 May 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-dhc-
addr-notification-13>.
[IPv6-ADDRESS]
Gont, F. and G. Gont, "Implications of IPv6 Addressing on
Security Operations", Work in Progress, Internet-Draft,
draft-ietf-opsec-ipv6-addressing-00, 2 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsec-
ipv6-addressing-00>.
[PIO-PFLAG]
Colitti, L., Linkova, J., Ma, X., and D. Lamparter,
"Signaling DHCPv6 Prefix per Client Availability to
Hosts", Work in Progress, Internet-Draft, draft-ietf-6man-
pio-pflag-10, 30 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
pio-pflag-10>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>. 2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
skipping to change at page 19, line 24 skipping to change at line 893
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204, "Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016, RFC 7934, DOI 10.17487/RFC7934, July 2016,
<https://www.rfc-editor.org/info/rfc7934>. <https://www.rfc-editor.org/info/rfc7934>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8415bis]
Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T.
Winters, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", Work in Progress, Internet-Draft, draft-ietf-
dhc-rfc8415bis-05, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-dhc-
rfc8415bis-05>.
[RFC8501] Howard, L., "Reverse DNS in IPv6 for Internet Service [RFC8501] Howard, L., "Reverse DNS in IPv6 for Internet Service
Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018, Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018,
<https://www.rfc-editor.org/info/rfc8501>. <https://www.rfc-editor.org/info/rfc8501>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>. January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[I-D.collink-6man-pio-pflag] [SNAC-SIMPLE]
Colitti, L., Linkova, J., Ma, X., and D. Lamparter,
"Signalling DHCPv6 Prefix Delegation Availability to
Hosts", Work in Progress, Internet-Draft, draft-collink-
6man-pio-pflag-03, 6 November 2023,
<https://datatracker.ietf.org/doc/html/draft-collink-6man-
pio-pflag-03>.
[I-D.ietf-dhc-rfc8415bis]
Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T.
Winters, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", Work in Progress, Internet-Draft, draft-ietf-
dhc-rfc8415bis-04, 26 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-dhc-
rfc8415bis-04>.
[I-D.ietf-dhc-addr-notification]
Kumari, W. A., Krishnan, S., Asati, R., Colitti, L.,
Linkova, J., and S. Jiang, "Registering Self-generated
IPv6 Addresses using DHCPv6", Work in Progress, Internet-
Draft, draft-ietf-dhc-addr-notification-10, 25 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-dhc-
addr-notification-10>.
[I-D.ietf-opsec-ipv6-addressing]
Gont, F. and G. Gont, "Implications of IPv6 Addressing on
Security Operations", Work in Progress, Internet-Draft,
draft-ietf-opsec-ipv6-addressing-00, 2 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsec-
ipv6-addressing-00>.
[I-D.ietf-snac-simple]
Lemon, T. and J. Hui, "Automatically Connecting Stub Lemon, T. and J. Hui, "Automatically Connecting Stub
Networks to Unmanaged Infrastructure", Work in Progress, Networks to Unmanaged Infrastructure", Work in Progress,
Internet-Draft, draft-ietf-snac-simple-04, 4 March 2024, Internet-Draft, draft-ietf-snac-simple-05, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-snac- <https://datatracker.ietf.org/doc/html/draft-ietf-snac-
simple-04>. simple-05>.
Appendix A. Appendix: Multiple Addresses Considerations Appendix A. Multiple Addresses Considerations
While a typical IPv4 host normally has only one IPv4 address per While a typical IPv4 host normally has only one IPv4 address per
interface, an IPv6 device almost always has multiple addresses interface, an IPv6 device almost always has multiple addresses
assigned to its interface. At the very least, a host can be expected assigned to its interface. At the very least, a host can be expected
to have one link-local address, one temporary address, and, in most to have one link-local address, one temporary address, and, in most
cases, one stable global address. On a network providing NAT64 cases, one stable global address. On a network providing NAT64
service, an IPv6-only host running the 464XLAT customer-side service, an IPv6-only host running the 464XLAT customer-side
translator (CLAT, [RFC6877]) would use a dedicated 464XLAT address, translator (CLAT) [RFC6877] would use a dedicated 464XLAT address,
configured via SLAAC (see Section 6.3 of [RFC6877]), which brings the configured via SLAAC (see Section 6.3 of [RFC6877]), which brings the
total number of addresses to 4. Other common scenarios where the total number of addresses to four. Other common scenarios where the
number of addresses per host interface might increase significantly, number of addresses per host interface might increase significantly
include but are not limited to: include but are not limited to:
* Devices running containers/namespaces: each container/namespace * Devices running containers or namespaces: each container or
would have multiple addresses as described above. As a result, a namespace would have multiple addresses as described above. As a
device running just a few containers in a bridge mode can easily result, a device running just a few containers in a bridge mode
have 20 or more IPv6 addresses on the given link. can easily have 20 or more IPv6 addresses on the given link.
* Networks assigning multiple prefixes to a given link: multihomed * Networks assigning multiple prefixes to a given link: multihomed
networks, networks using ULA [RFC4193] and non-ULA prefixes networks, networks using Unique Local IPv6 Unicast Addresses (ULA,
together, or network performing a graceful renumbering from one [RFC4193]) and non-ULA prefixes together, or networks performing a
prefix to another. graceful renumbering from one prefix to another.
[RFC7934] discusses this aspect and explicitly states that IPv6 [RFC7934] discusses this aspect and explicitly states that IPv6
deployments SHOULD NOT limit the number of IPv6 addresses a host can deployments SHOULD NOT limit the number of IPv6 addresses a host can
have. However, it has been been observed that networks often do have. However, it has been observed that networks often do limit the
limit the number of on-link addresses per device, likely in an number of on-link addresses per device, likely in an attempt to
attempt to protect network resources and prevent DoS attacks. protect network resources and prevent DoS attacks.
The most common scenario of network-imposed limitations is Neighbor The most common scenario of network-imposed limitations is ND proxy.
Discovery (ND) proxy. Many enterprise-scale wireless solutions Many enterprise-scale wireless solutions implement ND proxy to reduce
implement ND proxy to reduce the amount of broadcast and multicast the amount of broadcast and multicast downstream (AP to clients)
downstream (AP to clients) traffic and provide SAVI functions. To traffic and provide SAVI functions. To perform ND proxy, a device
perform ND proxy, a device usually maintains a table, containing IPv6 usually maintains a table containing IPv6 and MAC addresses of
and MAC addresses of connected clients. At least some connected clients. At least some implementations have hardcoded
implementations have hardcoded limits on how many IPv6 addresses per limits on how many IPv6 addresses per single MAC such a table can
single MAC such a table can contain. When the limit is exceeded the contain. When the limit is exceeded, the behavior is implementation
behaviour is implementation-dependent. Some vendors just fail to dependent. Some vendors just fail to install an N+1 address to the
install N+1 address to the table. Others delete the oldest entry for table. Others delete the oldest entry for this MAC and replace it
this MAC and replace it with the new address. In any case, the with the new address. In any case, the affected addresses lose
affected addresses lose network connectivity without receiving any network connectivity without receiving any implicit signal, with
implicit signal, with traffic being silently dropped. traffic being silently dropped.
Acknowledgements Acknowledgements
Thanks to Harald Alvestrand, Nick Buraglio, Brian Carpenter, Tim Thanks to Harald Alvestrand, Nick Buraglio, Brian Carpenter, Tim
Chown, Roman Danyliw, Gert Doering, David Farmer, Fernando Gont, Joel Chown, Roman Danyliw, Gert Doering, David Farmer, Fernando Gont, Joel
Halpern, Nick Hilliard, Bob Hinden, Martin Hunek, Erik Kline, Warren Halpern, Nick Hilliard, Bob Hinden, Martin Hunek, Erik Kline, Warren
Kumari, David Lamparter, Andrew McGregor, Tomek Mrugalski, Alexandre Kumari, David Lamparter, Andrew McGregor, Tomek Mrugalski, Alexandre
Petrescu, Jurgen Schonwalder, Pascal Thubert, Ole Troan, Eric Vyncke, Petrescu, Jurgen Schonwalder, Pascal Thubert, Ole Troan, Eric Vyncke,
Eduard Vasilenko, Timothy Winters, Chongfeng Xie, Peter Yee for the Eduard Vasilenko, Timothy Winters, Chongfeng Xie, and Peter Yee for
discussions, their input, and all contributions. the discussions, their input, and all contributions.
Contributors
Authors' Addresses Authors' Addresses
Lorenzo Colitti Lorenzo Colitti
Google, LLC Google, LLC
Shibuya 3-21-3, Shibuya 3-21-3,
Japan Japan
Email: lorenzo@google.com Email: lorenzo@google.com
Jen Linkova (editor) Jen Linkova (editor)
Google Google
1 Darling Island Rd 1 Darling Island Rd
Pyrmont NSW 2009 Pyrmont New South Wales 2009
Australia Australia
Email: furry13@gmail.com, furry@google.com Email: furry13@gmail.com, furry@google.com
Xiao Ma (editor) Xiao Ma (editor)
Google Google
Shibuya 3-21-3, Shibuya 3-21-3,
Japan Japan
Email: xiaom@google.com Email: xiaom@google.com
 End of changes. 103 change blocks. 
362 lines changed or deleted 375 lines changed or added

This html diff was produced by rfcdiff 1.48.