v6ops Working Group L. Colitti
Internet-Draft Google, LLC
Intended status: Informational J. Linkova, Ed.
Expires: 8 May 2024 X. Ma, Ed.
Google
5 November 2023
Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large
Broadcast Networks
draft-ietf-v6ops-dhcp-pd-per-device-05
Abstract
This document discusses an IPv6 deployment scenario when individual
clients connected to large broadcast networks (such as enterprise
networks or public Wi-Fi networks) are allocated unique prefixes via
DHCPv6 Prefix Delegation (DHCPv6-PD).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 May 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Colitti, et al. Expires 8 May 2024 [Page 1]
Internet-Draft MultAddrr November 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4
5. Applicability and Limitations . . . . . . . . . . . . . . . . 6
6. Routing and Addressing Considerations . . . . . . . . . . . . 6
6.1. Prefix Pool Allocation . . . . . . . . . . . . . . . . . 6
6.2. First-Hop Router Requirements . . . . . . . . . . . . . . 7
6.3. Topologies with Multiple First-Hop Routers . . . . . . . 7
6.4. On-link Communication . . . . . . . . . . . . . . . . . . 8
7. DHCPv6-PD Server Considerations . . . . . . . . . . . . . . . 9
8. Prefix Length Considerations . . . . . . . . . . . . . . . . 10
9. Client Mobility . . . . . . . . . . . . . . . . . . . . . . . 10
10. Antispoofing and SAVI Interaction . . . . . . . . . . . . . . 11
11. Migration Strategies and Co-existence with SLAAC Using Prefixes
From PIO . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 13
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
15. Security Considerations . . . . . . . . . . . . . . . . . . . 14
16. Appendix: Multiple Addresses Considerations . . . . . . . . . 15
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
17.1. Normative References . . . . . . . . . . . . . . . . . . 16
17.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
Often, large 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 clients obtain prefixes from the network. This
provides two important advantages.
Colitti, et al. Expires 8 May 2024 [Page 2]
Internet-Draft MultAddrr November 2023
First, it offers better scalability. Unlike IPv4, IPv6 allows (and
often requires) hosts to have multiple addresses (see Section 16 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 L2
devices etc). On VXLAN [RFC7348] networks each address might be
represented as a route so 8 addresses instead of 1 requires the
devices to support 8 times more routes, etc. If an infrastructure
device resources are exhausted, the device might drop some IPv6
addresses from the corresponding tables, while the address owner
might be still using the address to send traffic. This leads to
traffic blackholing and 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
arbitrary number of addresses.
Second, it provides the ability to extend the network. In IPv4, a
device that connects to the network can provide connectivity to
subtended devices by using NAT. With DHCPv6 PD, such a device can
similarly extend the network, but unlike IPv4 NAT, it can provide its
subtended devices with full end-to-end connectivity.
Another method of deploying unique prefixes per device is documented
in [RFC8273]. Similarly, the standard deployment model in cellular
IPv6 networks [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 [RFC8273], but
allocates the prefix using DHCPv6-PD.
This document focuses on the behaviour of the network. Host
behaviour is not defined in this specification.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology
Node: a device that implements IPv6, [RFC8200].
Host: any node that is not a router, [RFC8200].
Colitti, et al. Expires 8 May 2024 [Page 3]
Internet-Draft MultAddrr November 2023
Client: a node which connects to a network and acquires addresses.
The node may wish to obtain addresses for its own use, or may be a
router that wishes to extend the network to its physical or virtual
subsystems, or both. It may be either a host or a router as defined
by [RFC8200].
ND: Neighbor Discovery, [RFC4861].
SLAAC: IPv6 Stateless Address Autoconfiguration, [RFC4862].
DHCPv6-PD: DHCPv6 ([RFC8415]) mechanism to delegate IPv6 prefixes to
clients.
4. Design Principles
Instead of all clients on a given link forming addresses from the
same shared prefix assigned to that link:
* A device acts as DHCP-PD client and requests a prefix via
DHCPv6-PD by sending an IA_PD request.
* The first-hop router acts as a DHCPv6 relay and sends the request
to the DHCPv6-PD servers. In smaller networks it's entirely
possible for the first-hop router to act as a DHCPv6-PD server and
assign the prefix from a larger pool allocated for the given link
or the whole site.
* The allocated prefix is installed into the first-hop router
routing table as a route pointing to the client's link-local
address. That route can be redistributed into a dynamic routing
protocol (if the network is running one). For the router and all
other infrastructure devices that prefix is considered off-link,
so traffic to that prefix does not trigger any ND packets, other
than the minimum ND required to sustain NUD for the client's link-
local address.
* The device can use the delegated prefix in various ways. For
example, it can form addresses, as described in [RFC7084]
requirement WAA-7. It can also extend the network, as described
in [RFC7084] or [RFC7278].
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
currently supported by SLAAC and is not otherwise required by this
specification.
Colitti, et al. Expires 8 May 2024 [Page 4]
Internet-Draft MultAddrr November 2023
+-----------------------------------------------------------------------------+
| DHCPv6 Servers |
| Pool 2001:db8:ddd0::/48 for clients on 2001:db8:c001::/64 link |
+---------------+-------------------------+-----------------------------+-----+
^ | | ^ |
| | | | |
+-------+------+-------------------------+----------------------+------+-----+
|DHCPv6 | | IPv6 Network DHCPv6 | | |
|Relay-Forward | Relay-Forward | |
| ^ v Route for 2001:db8:ddd0::/48 ^ v |
| | DHCPv6 | | | DHCPv6 |
| | Relay-Reply | | | Relay-Reply|
| | | | | | | |
+-----+-------+-------+-----+--------------------+-----+-------+-------+-----+
| | | | | | | |
| v | v v | | v
+----+---------------+--------------+ +--------------+-------+-------------+
| First-hop router/DHCPv6 relay | | First-hop Router/DHCPv6 relay |
| 2001:db8:ddd0:1::/64 -> fe80::aaaa| | 2001:db8:ddd0:1::/64 -> fe80::aaaa |
| 2001:db8:ddd0:2::/64 -> fe80::cccc| | 2001:db8:ddd0:2::/64 -> fe80::ccc |
+-----------+------------+----------+ +---------+--------------------+-----+
^ | | Shared IPv6 link, | ^ |
| | | 2001:db8:c001::/64 | | |
| | --+-------+-----------+-----------+------+--- | |
| | | | | | |
| | | +----------------+--------------+ | DHCPv6 |
DHCPv6 | | |Legacy (no DHCPv6-PD) client B | | Request v
Request | | |link-local address fe80::bbbb | | ^ DHCPv6
^ | | |global address 2001:db8:c001::b| | | Reply
| | | +-------------------------------+ | | |
| v | | | v
| DHCPv6 | +-------------------+-----+------------+
| Reply | | Client C |
| | | | link-local address fe80::cccc |
| | | | delegated prefix 2001:db8:ddd0:2::/64|
| | | +--------------+-+---------------------+
| | | | |
+----+-------+----+-----------------------------+ | | Router Advertisement
| Client A | | | containing PIO
| link-local address: fe80::aaaa | | v 2001:db8:ddd0:2::/64
| delegated prefix: 2001:db8:ddd0:1::/64 | |
| +---------------------+ +------------------+ | -+-----------+---------
| | virtual system | | virtual system | | |
| | 2001:db8:ddd0:1::f00| |2001:db8:ddd0:1::2| | +---------+----------+
| | 2001:db8:ddd0:1::caf| |2001:db8:ddd0:1::a| | | Tethered device |
| +---------------------+ +------------------+ | |2001:db8:ddd0:2:6666|
| | +--------------------+
+-----------------------------------------------+
Colitti, et al. Expires 8 May 2024 [Page 5]
Internet-Draft MultAddrr November 2023
Figure 1: An Example Topology with Two First-Hop Routers.
5. Applicability and Limitations
Delegating a unique prefix per client provides all the benefits of
both SLAAC and DHCPv6 address allocation, but at the cost of greater
address space usage. This design would substantially benefit some
networks (see Section 12), in which the addional cost of an
additional service (DHCPv6 prefix delegation) and allocating a larger
amount of address space can easily be justified. Examples of such
networks include but are not limited to:
* Large-scale networks where even 3-5 addresses per client might
introduce scalability issues.
* Networks with high number of virtual hosts, so physical devices
require multiple addresses.
* Managed networks where extensive troubleshooting, device traffic
logging or forensics might be required.
In smaller networks, such as home networks or small enterprises, with
smaller address space and lower number of clients, SLAAC is a better
and simpler option.
6. Routing and Addressing Considerations
6.1. Prefix Pool Allocation
One simple deployment model is to assign a dedicated prefix pool to
each link. The prefixes from each link's pool are only issued to
requesting clients on the link, and if clients move to another link
they will obtain a prefix from the pool associated with the new link
(see Section 9). This is very similar to how address pools are
allocated when using DHCP to assign individual addresses (e.g.,
DHCPv4 or DHCPv6 IA_NA), where each link has a dedicated pool of
addresses, and clients on the link obtain addresses from the pool.
Other deployment models, such as prefix pools shared over multiple
links or routers, are possible, but not described in this document.
Colitti, et al. Expires 8 May 2024 [Page 6]
Internet-Draft MultAddrr November 2023
6.2. First-Hop Router Requirements
In large networks, DHCPv6 servers are usually centralized, and
reached via DHCPv6 relays co-located with the first-hop routers. To
delegate IPv6 prefixes to clients, the first hop routers need to
implement DHCPv6 relay functions and meet the requirements defined in
[RFC8987]. In particular, per Section 4.2 of [RFC8987], the first-
hop router must maintain a local routing table that contains all
prefixes delegated to clients.
When using a dedicated prefix pool for each link, 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.
With the first-hop routers performing DHCPv6 relay functions, the
proposed design neither requires any subsequent relays in the path
nor introduce any requirements (e.g. snooping) to such relays, if
they are deployed.
To ensure that routes to the delegated prefixes are preserved even if
a relay is rebooted or replaced, the operator MUST ensure that all
relays in the network infrastructure support DHCPv6 Bulk Leasequery
as defined in [RFC5460]. While Section 4.3 of [RFC8987] lists
keeping active prefix delegations in persistent storage as an
alternative to DHCPv6 Bulk Leasequery, relying on persistent storage
has the following drawbacks:
* In a network with multiple relays, network state can change
significantly while the relay was rebooting (new prefixes
delegated, some prefixes expiring etc).
* Persistent storage might not be preserved if the router is
physically replaced.
Another mechanism for first-hop routers to obtain information about
delegated prefixes is by using Active Leasequery [RFC7653], though
this is not yet widely supported.
6.3. Topologies with Multiple First-Hop Routers
In a topology with redundant first-hop routers, all the routers need
to relay DHCPv6 traffic, install the delegated prefixes into their
routing tables and, if needed, advertise those prefixes to the
network.
Colitti, et al. Expires 8 May 2024 [Page 7]
Internet-Draft MultAddrr November 2023
If the first-hop routers obtain information about delegated prefixes
by snooping DHCPv6 Reply messages sent by the server, then all the
first-hop routers must be able to snoop these messages. This is
possible if the client multicasts the DHCPv6 messages it sends to the
server. The server will receive one copy of the client message
through each first-hop relay, and will reply unicast to each of them
via the relay (or chain of relays) from which it received the
message. Thus, all first-hop relays will be able to snoop the
replies. Per Section 14 of [RFC8415], clients always use multicast
unless the server explicitly allows it using the Server Unicast
option ([RFC8415], Section 21.12). Therefore, in topologies with
multiple first-hop routers, the DHCPv6 servers MUST be configured not
to use the Server Unicast option. It should be noted that
[I-D.ietf-dhc-rfc8415bis] deprecates the Server Unicast option
precisely because it is not compatible with topologies with multiple
first-hop relays.
To recover from crashes or reboots, relays can use Bulk Leasequery or
Active Leasequery to issue a QUERY_BY_RELAY_ID with the ID(s) of the
other relay(s), as configured by the operator. Additionally, some
vendors provide vendor-specific mechanisms to synchronize state
between DHCP relays.
6.4. On-link Communication
For security reasons, some networks do not allow communication
between clients on the same link, by dropping device-to-device
traffic below the IP layer (layer 2). In this case, delegating a
prefix to each client doesn't affect traffic flows, as all traffic is
sent to the first-hop router anyway. The router may allow or drop
the traffic depending on the network security policy.
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
[RFC4861]. As a result, all addresses from that prefix are
considered onlink, 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 they are no
longer within the on-link prefix, but are within the delegated
prefixes. 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 [RFC4861]).
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 SHOULD ensure that
the first-hop routers can send ICMPv6 redirects (the routers are
configured to do so and the security policies permit those messages).
Colitti, et al. Expires 8 May 2024 [Page 8]
Internet-Draft MultAddrr November 2023
7. DHCPv6-PD Server Considerations
This document doesn't introduce any changes to DHCPv6 protocol in
general and DHCPv6 server behaviour in particular. However, for the
proposed solution to work correctly, the DHCPv6-PD server needs to be
configured as follows:
* The server MUST follow [RFC8168] recommendations on processing
prefix-length hints.
* The server MUST provide a prefix short enough for the client to
extend the network to at least one interface, and allow nodes on
that interface to obtain addresses via SLAAC. The server MAY
provide more address space to clients that ask for it, either via
delegating multiple such prefixes, or by delegating a single
prefix of a shorter length. It should be noted that [RFC8168]
allows the server to provide a prefix shorter that the prefix-
length hint value received from the client.
* 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 configure routes to the delegated prefixes.
* The server MUST NOT 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 Section 6.3).
* In order to ensure uninterrupted connectivity when a first-hop
router crashes or reboots, the server MUST support Bulk Leasequery
or Active Leasequery.
As most operators have some experience with IPv4, they can use the
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:
* 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 WiFI network might be using longer timers than an
open public WiFi).
Colitti, et al. Expires 8 May 2024 [Page 9]
Internet-Draft MultAddrr November 2023
8. Prefix Length Considerations
Delegating a prefix of sufficient size to use SLAAC allows the client
to extend the network, providing limitless addresses to IPv6 nodes
connected to it (e.g., virtual machines, tethered devices), because
all IPv6 hosts are required to support SLAAC [RFC8504].
Additionally, even clients that support other forms of address
assignment require SLAAC for some functions, such as forming
dedicated addresses for the use of 464xlat (see Section 6.3 of
[RFC6877]).
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
shorter than 64 bits and a subnet prefix longer than 64 bits is
outside the current IPv6 specifications. Choosing longer prefixes
would require the client and any connected system to use some other
form of address assignment, which many hosts do not support, and
therefore limits the applicability of the proposed solution.
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
prefix length of /64 is required to provide global connectivity for
stub networks as per [I-D.ietf-snac-simple].
Assigning a prefix of sufficient size to support SLAAC is possible on
large networks. In general, any network that numbers clients from an
IPv4 prefix of length X (e.g., X=/18, X=/24), would require an IPv6
prefix of length X+32 (e.g., X=/40, X=/56) to provide a /64 prefix to
every device. As an example, Section 9.2 of [RFC7934] 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.
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.
9. Client Mobility
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
when the client moves between network attachment points it would
refresh its delegated prefix the same way it refreshes addresses
assigned (via SLAAC or DHCPv6 IA_NA) from a shared onlink prefix:
Colitti, et al. Expires 8 May 2024 [Page 10]
Internet-Draft MultAddrr November 2023
* 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, and the fist-hop
routers have a route for the prefix with the nexthop set to the
client link-local address on that link. As per requirement S-2
(Section 4.3 of [RFC8987]), the DHCPv6-relays (the first-hop
routers) MUST 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.
* When a client moves to a different link, the DHCPv6 server
provides the client with a new prefix, so the behaviour is
consistent with SLAAC or DHCPv6-assigned addresses, which are also
different on the new link.
In theory, DHCPv6 servers can delegate the same prefix to the same
client even if the client changes the attachment points. However,
while allowing the client to keep the same prefix while roaming
between links might provide some benefits for the client, it is not
feasible without changing DHCPv6 relays behaviour: after the client
moves to a new link, the DHCPv6 relays would retain the route
pointing to the client's link-local address on the old link for the
duration of DHCPv6 timers (see requirement S-2, Section 4.3 of
[RFC8987]). As a result, the first-hop routers would have two routes
for the same prefix pointing to different links, causing connectivity
issues for the client.
It should be noted that addressing clients from a shared on-link
prefix also does not allow clients to keep addresses while roaming
between links, so the proposed solution is not different in that
regard. In addition to that, quite often different links have
different security policies applied (for example, corporate internal
network vs guest network), hence clients on different links need to
use different prefixes.
10. Antispoofing and SAVI Interaction
Enabling the unicast Reverse Path Forwarding (uRPF) on the first-hop
router interfaces towards clients provides the first layer of defence
agains spoofing. If the malicious client sends a spoofed packet it
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.
Colitti, et al. Expires 8 May 2024 [Page 11]
Internet-Draft MultAddrr November 2023
Source Address Validation Improvement (SAVI, [RFC7039]) provides more
reliable protection against address spoofing. Administrators
deploying the proposed solution on the SAVI-enabled infastructure
SHOULD ensure that SAVI perimeter devices support DHCPv6-PD snooping
to create the correct binding for the delegated prefixes (see
[RFC7513]). Using FCFS SAVI ([RFC6620]) for protecting link-local
addresses and creating SAVI bindings for DHCPv6-PD assigned prefixes
would prevent spoofing.
Some infrastructure devices do not implement SAVI as defined in
[RFC7039] but perform other forms of address tracking and snooping
for security or performance improvement purposes (e.g. ND proxy).
This is very common behaviour for wireless devices (access points and
controllers). Administrators SHOULD ensure that such devices are
able to snoop DHCPv6-PD packets, so the traffic from the delegated
prefixes is not dropped.
It should be noted that using DHCPv6-PD makes it harder for an
attacker to select the spoofed source address. When all clients are
using the same shared link to form addresses, the attacker might
learn addresses used by other clients by listening to multicast
Neighbor Solicitations and Neighbour 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.
11. Migration Strategies and Co-existence with SLAAC Using Prefixes
From PIO
It would be beneficial for the network to explicitly indicate its
support of DHCPv6-PD for connected clients.
* In small networks (e.g. home ones), where the number of clients is
not too high, the number of available prefixes becomes a limiting
factor. If every phone or laptop in a home network would request
an unique prefix suitable for SLAAC, the home network might run
out of prefixes, if the prefix allocated to the CPE by its ISP is
too small (e.g. if an ISP allocates /60, it would only allow 16
clients to request /64). So while the enterprise network
administrator might want all phones in the network to request a
prefix, it would be highly undesirable for the same phone to
request a prefix when connecting to a home network.
* 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
Colitti, et al. Expires 8 May 2024 [Page 12]
Internet-Draft MultAddrr November 2023
and 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 Section 12), but 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 to use the prefix in
PIO or not, if the network provides the PIO with A flag set.
To allow the network to signal DHCPv6-PD support,
[I-D.collink-6man-pio-pflag] defines a new PIO flag, indicating that
DHCPv6-PD is preferred method of obtaining prefixes. It should be
noted that the deployment model described in this document does not
depened on [I-D.collink-6man-pio-pflag] and can be implemented
without deploying that PIO flag. For example, devices acting as
[RFC7084] compatible routers would be able to receive prefixes via
DHCPv-PD.
12. Benefits
The proposed solution provides the following benefits:
* The network devices resources (e.g. memory) need to scale to the
number of devices, not the number of IPv6 addresses. The first-
hop routers have a single route per device pointing to the
device's link-local address.
* If all clients connected to the given link support this mode of
operation and can generate addresses from the delegated prefixes,
there is no reason to advertise a common prefix assigned to that
link in PIO with 'A' flag set. Therefore it is possible to remove
the global shared prefix from that link and the router interface
completely, so no global addresses are on-link for the link. This
would lead to reducing the attack surface for Neighbor Discovery
attacks described in [RFC6583].
* DHCP-PD logs and first-hop routers routing tables provide complete
information on IPv6 to MAC mapping, which can be used for
forensics and troubleshooting. Such information is much less
dynamic than ND cache and therefore it's much easier for an
operator to collect and process it.
* A dedicated prefix per client allows the network administrator to
create per-device security policies (ACLs) even if the client is
using temporary addresses. This mitigates one of the issues
described in [I-D.ietf-opsec-ipv6-addressing].
Colitti, et al. Expires 8 May 2024 [Page 13]
Internet-Draft MultAddrr November 2023
* The cost of having multiple addresses is offloaded to the clients.
Hosts are free to create and use as many addresses as they need.
* Fate sharing: all global addresses used by a given client are
routed as a single prefix. Either all of them work or not, which
makes the failures easier to diagnoze and mitigate.
* Lower level of multicast traffic: less Neighbor Discovery
([RFC4861]) multicast packets, as there are only clients link-
local addresses the routers need to resolve. Also, no DAD traffic
except for clients' link-local addresses.
* Ability to extend the network transparently. If the client uses
SLAAC, delegating a prefix allows the client to provide
connectivity to other hosts, like as it is possible in IPv4 with
NAT.
13. Privacy Considerations
Eventually, if/when the vast majority of clients support the proposed
mechanism, an eavesdropper/information collector might be able to
correlate the prefix to the client. To mitigate the threat the
client might implement a mechanism similar to SLAAC temporary
extensions ([RFC8981]) but for delegated prefixes:
* The client requests another prefix.
* Upon receiving the new prefix the client deprecates all addresses
from the old one.
* After some time (shall it be T2 from IA_PD for the original
prefix?) the client sends RELEASE for the old prefix.
14. IANA Considerations
This memo includes no request to IANA.
15. Security Considerations
A malicious or just misbehaving client might exhaust the DHCP-PD pool
by sending a large number of requests with various DUIDs. This is
not a new issue as the same attack might be implemented in DHCPv4 or
DHCPv6 for IA_NA requests. To prevent a misbehaving client from
denying service to other clients, the DHCPv6 server or relay MUST
support limiting the number of prefixes delegated to a given client
at any given time.
Colitti, et al. Expires 8 May 2024 [Page 14]
Internet-Draft MultAddrr November 2023
A malicious client might request a prefix and then release it very
quickly, causing routing convergence events on the relays. The
probability of such attack can be reduced if the network rate limits
the amount of broadcast and multicast messages from the client.
Delegating the same prefix for the same client introduces privacy
concerns. The proposed mitigation is discussed in Section 13.
Spoofing scenarios and prevention mechanisms are discussed in
Section 10.
16. Appendix: Multiple Addresses Considerations
While a typical IPv4 host normally has only one IPv4 address per
interface, an IPv6 device almost always has multiple addresses
assigned to its interface. At the very least, a host can be expected
to have one link-local address, one temporary address and, in most
cases, one stable global address. On a network providing NAT64
service, an IPv6-only host running the 464XLAT customer-side
translator (CLAT, [RFC6877]) would use a dedicated 464XLAT address,
configured via SLAAC (see Section 6.3 of [RFC6877]), which brings the
total number of addresses to 4. Other common scenarios where the
number of addresses per host's interface might increase
significantly, include but are not limited to:
* Devices running containers/namespaces: each container/namespace
would have muliple addresses as described above. As a result a
device running just a few containers in a bridge mode can easily
have 20 or more IPv6 addresses on the given link.
* 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.
[RFC7934] discusses this aspect and explicitly states that IPv6
deployments SHOULD NOT limit the number of IPv6 addresses a host can
have. However it's been observed that networks often do limit the
number of on-link addresses per device, likely in an attempt to
protect the network resources and prevent DoS attacks.
The most common scenario of network-imposed limitations is Neighbor
Discovery (ND) proxy. Many enterprise-scale wireless solutions
implement ND proxy to reduce amount of broadcast and multicast
downstream (AP to clients) traffic and 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 IPv6 addresses per
Colitti, et al. Expires 8 May 2024 [Page 15]
Internet-Draft MultAddrr November 2023
a single MAC such a table can contain. When the limit is exceeded
the behaviour is implementation-dependent. Some vendors just fail to
install N+1 address to the table. Other delete the oldest entry for
this MAC and replace it with the new address. In any case the
affected addresses lose network connectivity without receiving any
implict signal, with traffic being silently dropped.
17. References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<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,
DOI 10.17487/RFC5460, February 2009,
<https://www.rfc-editor.org/info/rfc5460>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses",
RFC 6620, DOI 10.17487/RFC6620, May 2012,
<https://www.rfc-editor.org/info/rfc6620>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>.
[RFC8168] Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix-Length Hint
Issues", RFC 8168, DOI 10.17487/RFC8168, May 2017,
<https://www.rfc-editor.org/info/rfc8168>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Colitti, et al. Expires 8 May 2024 [Page 16]
Internet-Draft MultAddrr November 2023
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/info/rfc8273>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>.
[RFC8987] Farrer, I., Kottapalli, N., Hunek, M., and R. Patterson,
"DHCPv6 Prefix Delegating Relay Requirements", RFC 8987,
DOI 10.17487/RFC8987, February 2021,
<https://www.rfc-editor.org/info/rfc8987>.
17.2. Informative References
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, DOI 10.17487/RFC6459, January 2012,
<https://www.rfc-editor.org/info/rfc6459>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583,
DOI 10.17487/RFC6583, March 2012,
<https://www.rfc-editor.org/info/rfc6583>.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
"Source Address Validation Improvement (SAVI) Framework",
RFC 7039, DOI 10.17487/RFC7039, October 2013,
<https://www.rfc-editor.org/info/rfc7039>.
Colitti, et al. Expires 8 May 2024 [Page 17]
Internet-Draft MultAddrr November 2023
[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6
/64 Prefix from a Third Generation Partnership Project
(3GPP) Mobile Interface to a LAN Link", RFC 7278,
DOI 10.17487/RFC7278, June 2014,
<https://www.rfc-editor.org/info/rfc7278>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
Boundary in IPv6 Addressing", RFC 7421,
DOI 10.17487/RFC7421, January 2015,
<https://www.rfc-editor.org/info/rfc7421>.
[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
Validation Improvement (SAVI) Solution for DHCP",
RFC 7513, DOI 10.17487/RFC7513, May 2015,
<https://www.rfc-editor.org/info/rfc7513>.
[RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6
Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,
October 2015, <https://www.rfc-editor.org/info/rfc7653>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016,
<https://www.rfc-editor.org/info/rfc7934>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>.
Colitti, et al. Expires 8 May 2024 [Page 18]
Internet-Draft MultAddrr November 2023
[I-D.collink-6man-pio-pflag]
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-02, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-collink-6man-
pio-pflag-02>.
[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-03, 22 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-dhc-
rfc8415bis-03>.
[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
Networks to Unmanaged Infrastructure", Work in Progress,
Internet-Draft, draft-ietf-snac-simple-02, 28 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-snac-
simple-02>.
Acknowledgements
Thanks to Nick Buraglio, Brian Carpenter, Gert Doering, David Farmer,
Fernando Gont, Joel Halpern, Nick Hilliard, Bob Hinden, Martin Hunek,
Erik Kline, David Lamparter, Andrew McGregor, Tomek Mrugalski, Pascal
Thubert, Ole Troan, Eduard Vasilenko, Timothy Winters, Chongfeng Xie
for the discussions, their input and all contribution.
Contributors
Authors' Addresses
Lorenzo Colitti
Google, LLC
Shibuya 3-21-3,
Japan
Email: lorenzo@google.com
Colitti, et al. Expires 8 May 2024 [Page 19]
Internet-Draft MultAddrr November 2023
Jen Linkova (editor)
Google
1 Darling Island Rd
Pyrmont NSW 2009
Australia
Email: furry13@gmail.com, furry@google.com
Xiao Ma (editor)
Google
Shibuya 3-21-3,
Japan
Email: xiaom@google.com
Colitti, et al. Expires 8 May 2024 [Page 20]