Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large Broadcast Networks
draft-ietf-v6ops-dhcp-pd-per-device-08

v6ops Working Group                                           L. Colitti
Internet-Draft                                               Google, LLC
Intended status: Informational                           J. Linkova, Ed.
Expires: 5 October 2024                                       X. Ma, Ed.
                                                                  Google
                                                            3 April 2024

   Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large
                           Broadcast Networks
                 draft-ietf-v6ops-dhcp-pd-per-device-08

Abstract

   This document discusses an IPv6 deployment scenario when individual
   nodes connected to large broadcast networks (such as enterprise
   networks or public Wi-Fi networks) are allocated unique prefixes via
   DHCPv6 Prefix Delegation (DHCPv6-PD, RFC8415).

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 5 October 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Colitti, et al.          Expires 5 October 2024                 [Page 1]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   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 . . . . . . . . . . . . . . . . . . . . . . .  11
   10. Antispoofing and SAVI Interaction . . . . . . . . . . . . . .  12
   11. Migration Strategies and Co-existence with SLAAC Using Prefixes
           From PIO  . . . . . . . . . . . . . . . . . . . . . . . .  13
   12. Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   13. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  15
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   15. Security Considerations . . . . . . . . . . . . . . . . . . .  16
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     16.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Appendix A.  Appendix: Multiple Addresses Considerations  . . . .  20
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  21
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

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

Colitti, et al.          Expires 5 October 2024                 [Page 2]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   First, it offers better scalability.  Unlike IPv4, IPv6 allows hosts
   to have multiple addresses, and this is the case in most deployments
   (see Appendix A for more details).  However, increasing the number of
   addresses introduces scalability issues on the network
   infrastructure.  Network devices need to maintain various types of
   tables/hashes (Neighbor Cache on first-hop routers, Neighbor
   Discovery Proxy caches on Layer 2 devices etc.).  On 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 an 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 Prefix Delegation
   (DHCPv6-PD, [RFC8415]), such a device can similarly extend the
   network, but unlike IPv4 NAT, it can provide its subtended devices
   with full end-to-end connectivity.

   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 document.

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].

Colitti, et al.          Expires 5 October 2024                 [Page 3]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   Host: any node that is not a router, [RFC8200].

   Client: a node which connects to a network and acquires addresses.
   The node may wish to obtain addresses for its own use, or may be a
   router that wishes to extend the network to its physical or virtual
   subsystems, or both.  It may be either a host or a router as defined
   by [RFC8200].

   ND: Neighbor Discovery, [RFC4861].

   NUD: Neighbor Unreachability Detection, [RFC4861].

   PIO: Prefix Information Option, [RFC4862].

   SLAAC: IPv6 Stateless Address Autoconfiguration, [RFC4862].

   DHCPv6-PD: DHCPv6 ([RFC8415]) mechanism to delegate IPv6 prefixes to
   clients.

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 DHCPv6-PD client and requests a prefix via
      DHCPv6-PD by sending an IA_PD request.

   *  The server delegates a prefix to the client and the delegated
      prefix is installed into the routing table of the first-hop router
      as a route pointing to the client's link-local address.  The
      first-hop router can act as a DHCPv6 relay and snoop DHCPv6 Reply
      messages from an off-link DHCPv6 server, or it can act as a DHCPv6
      server itself.  In both cases it can install the route locally,
      and if the network is running a dynamic routing protocol,
      distribute the route or the entire prefix pool into the protocol.

   *  For the router and all other infrastructure devices, the delegated
      prefix is considered off-link, so traffic to that prefix does not
      trigger any ND packets, other than the minimum ND required to
      sustain Neighbor Unreachability Detection (NUD) for the client's
      link-local address.

   *  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].

Colitti, et al.          Expires 5 October 2024                 [Page 4]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   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 the
   proposed deployment model.

+-----------------------------------------------------------------------------+
|                                  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 | |               |

Colitti, et al.          Expires 5 October 2024                 [Page 5]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

 | | 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|
 |                                               |     +---------------------+
 +-----------------------------------------------+

      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 additional 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 a 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 simpler
   and often preferred 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.  In this model, the network can
   route the entire pool to the link's first-hop routers, and the
   routers do not need to advertise individual delegated prefixes into
   the network's dynamic routing protocol.

Colitti, et al.          Expires 5 October 2024                 [Page 6]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

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

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.

   With the first-hop routers performing DHCPv6 relay functions, the
   proposed design neither requires any subsequent relays in the path
   nor introduces any requirements (e.g., snooping) to such subsequent
   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 is 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.

   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

Colitti, et al.          Expires 5 October 2024                 [Page 7]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   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 uses the Server Unicast option to explicitly allow
   unicast communication ([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 block on-link device-to-device
   traffic at layer 2 to prevent communication between clients on the
   same link.  In this case, delegating a prefix to each client doesn't
   affect traffic flows, as all traffic is sent to the first-hop router
   anyway.  Depending on the network security policy, the router may
   allow or drop the traffic.

   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 on-link, and traffic to those destinations is sent
   directly (not via routers).  If such a network delegates prefixes to
   clients (as described in this document), then each client will
   consider other client's destination addresses to be off-link, because
   those addresses are from the delegated prefixes and are no longer
   within the on-link prefix.  When a client sends traffic to another
   client, packets will initially be sent to the default router.  The
   router will respond with an ICMPv6 redirect message (Section 4.5 of
   [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 5 October 2024                 [Page 8]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

7.  DHCPv6-PD Server Considerations

   This document does not introduce any changes to the DHCPv6 protocol
   itself.  However, for the proposed solution to work correctly, the
   DHCPv6-PD server needs to be configured as follows:

   *  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 by
      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 than 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 a
   similar approach for choosing the pool size and the timers (such as
   T1/T2 timers).  In particular the following factors shall be taken
   into account:

   *  the expected maximum number of clients;

   *  average duration of a client connection;

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

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

Colitti, et al.          Expires 5 October 2024                 [Page 9]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

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

   Some additional recommendations driven by security and privacy
   considerations are discussed in Section 15 and Section 13.

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 other
   address assignment mechanisms.  This would limit the applicability of
   the proposed solution, as other mechanisms are not currently
   supported by many hosts.

   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].

Colitti, et al.          Expires 5 October 2024                [Page 10]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   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.  Existing sites that currently use a /48 prefix
   cannot support more than 64k clients in this model without
   renumbering, though many networks of such size have LIR status and
   can justify bigger address blocks.

   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 on-link prefix:

   *  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 first-hop
      routers have a route for the prefix with the nexthop set to the
      client link-local address on that link.  As per requirement S-2
      (Section 4.3 of [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 relay behaviour: after the client

Colitti, et al.          Expires 5 October 2024                [Page 11]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   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, [RFC3704]) on the
   first-hop router interfaces towards clients provides the first layer
   of defense against spoofing.  A spoofed packet sent by a malicious
   client would be dropped by the router unless the spoofed address
   belongs to a prefix delegated to another client on the same
   interface.  Therefore the malicious client can only spoof addresses
   already delegated to another client on the same link or another
   client link-local address.

   Source Address Validation Improvement (SAVI, [RFC7039]) provides more
   reliable protection against address spoofing.  Administrators
   deploying the proposed solution on SAVI-enabled infrastructure 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

Colitti, et al.          Expires 5 October 2024                [Page 12]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   environments, however, the attacker can only learn about other
   clients's global addresses by listening to multicast DHCPv6 messages,
   which are not transmitted so often, and may not be received by the
   client at all because they are sent to multicast groups that are
   specific to DHCPv6 servers and relays.

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

   *  When the network supports both a unique prefix per client and a
      PIO with A=1 as address assignment methods, it's highly desirable
      for the client NOT to use the PIO prefix to form global addresses
      and 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.

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

Colitti, et al.          Expires 5 October 2024                [Page 13]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

12.  Benefits

   The proposed solution provides the following benefits:

   *  Network device resources (e.g., memory) need to scale to the
      number of devices, not the number of IPv6 addresses.  The first-
      hop routers have a single route per device pointing to the
      device's link-local address.  This can potentially enable hardware
      cost savings, for example if hardware such as wireless LAN
      controllers is limited to supporting only a specific number of
      client addresses, or in VXLAN deployments where each client
      address consumes one routing table entry.

   *  The cost of having multiple addresses is offloaded to the clients.
      Hosts are free to create and use as many addresses as they need
      without imposing any additional costs onto the network.

   *  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].

   *  DHCPv6-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].

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

   *  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.

Colitti, et al.          Expires 5 October 2024                [Page 14]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   *  Ability to extend the network transparently.  If the network
      delegates to the client a prefix of sufficient size to support
      SLAAC, the client can to provide connectivity to other hosts, as
      is possible in IPv4 with NAT (e.g., by acting as an IPv6 CE router
      as described in [RFC7084]).

13.  Privacy Considerations

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

   Except for networks (such as datacenter networks) where hosts do not
   need temporary addresses ([RFC8981]), the network SHOULD:

   *  Ensure that when a client requests a prefix, the prefix is
      randomly assigned and not allocated deterministically.

   *  Use short prefix lifetimes (e.g., hours), to ensure that when a
      client disconnects and reconnects it gets a different prefix.

   *  Allow the client to have more than one prefix at the same time.
      This allows the client to rotate prefixes using a mechanism
      similar to temporary addresses, but that operates on prefixes
      instead of on individual addresses.  In this case the prefix's
      lifetime MUST be short enough to allow the client to use a
      reasonable rotation interval without using too much address space.
      For example, if every 24 hours the the client asks for a new
      prefix and stops renewing the old prefix, and the Valid Lifetime
      of delegated prefixes is one hour, then the client will consume
      two prefixes for one hour out of 24 hours, and thus will on
      average consume just under 1.05 prefixes.

14.  IANA Considerations

   This memo includes no request to IANA.

Colitti, et al.          Expires 5 October 2024                [Page 15]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

15.  Security Considerations

   A malicious (or just misbehaving) client might attempt to exhaust the
   DHCPv6-PD pool by sending a large number of requests with differing
   DUIDs.  To 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.

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

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

   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.  References

16.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>.

Colitti, et al.          Expires 5 October 2024                [Page 16]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   [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>.

   [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>.

16.2.  Informative References

Colitti, et al.          Expires 5 October 2024                [Page 17]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
              2004, <https://www.rfc-editor.org/info/rfc3704>.

   [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>.

   [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>.

Colitti, et al.          Expires 5 October 2024                [Page 18]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   [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>.

   [RFC8501]  Howard, L., "Reverse DNS in IPv6 for Internet Service
              Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018,
              <https://www.rfc-editor.org/info/rfc8501>.

   [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>.

   [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-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>.

Colitti, et al.          Expires 5 October 2024                [Page 19]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   [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
              Networks to Unmanaged Infrastructure", Work in Progress,
              Internet-Draft, draft-ietf-snac-simple-04, 4 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-snac-
              simple-04>.

Appendix A.  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 interface might increase significantly,
   include but are not limited to:

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

   *  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.

Colitti, et al.          Expires 5 October 2024                [Page 20]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   [RFC7934] discusses this aspect and explicitly states that IPv6
   deployments SHOULD NOT limit the number of IPv6 addresses a host can
   have.  However, it has been been observed that networks often do
   limit the number of on-link addresses per device, likely in an
   attempt to protect network resources and prevent DoS attacks.

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

Acknowledgements

   Thanks to Harald Alvestrand, Nick Buraglio, Brian Carpenter, Tim
   Chown, Roman Danyliw, Gert Doering, David Farmer, Fernando Gont, Joel
   Halpern, Nick Hilliard, Bob Hinden, Martin Hunek, Erik Kline, Warren
   Kumari, David Lamparter, Andrew McGregor, Tomek Mrugalski, Alexandre
   Petrescu, Jurgen Schonwalder, Pascal Thubert, Ole Troan, Eric Vyncke,
   Eduard Vasilenko, Timothy Winters, Chongfeng Xie, Peter Yee for the
   discussions, their input, and all contributions.

Contributors

Authors' Addresses

   Lorenzo Colitti
   Google, LLC
   Shibuya 3-21-3,
   Japan
   Email: lorenzo@google.com

   Jen Linkova (editor)
   Google
   1 Darling Island Rd
   Pyrmont NSW 2009
   Australia
   Email: furry13@gmail.com, furry@google.com

Colitti, et al.          Expires 5 October 2024                [Page 21]
Internet-Draft      Prefix per client using DHCPv6 PD         April 2024

   Xiao Ma (editor)
   Google
   Shibuya 3-21-3,
   Japan
   Email: xiaom@google.com

Colitti, et al.          Expires 5 October 2024                [Page 22]