Signalling DHCPv6 Prefix Delegation Availability to Hosts

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 7 January 2024.¶

Copyright Notice

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

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

3. Rationale

As described above, if the network supports both SLAAC and DHCPv6-PD, the network administrator might want to indicate to hosts that DHCPv6-PD address assignemnt (see [I-D.ietf-v6ops-dhcp-pd-per-device]) should be preferred over SLAAC. The information is passed to the host via a P flag in the Prefix Information Option (PIO). The reason is as follows:¶

• The information should be contained in the Router Advertisement because it must be available to the host before it decides to form IPv6 addresses from the prefix using SLAAC. Otherwise, the host might form IPv6 addresses from the PIO provided and start using them. This is suboptimal because if the host later acquires a prefix using DHCPv6 PD, it can either use both the prefix and SLAAC addresses, reducing the scalability benefits of using DHCPv6 PD, or can remove the SLAAC addresses, which would be disruptive for applications that are using them.¶
• This information is specific to the particular prefix being announced. For example, a network might want to assign global addresses via DHCPv6 PD, but use SLAAC for ULA addresses. Also, in a multihoming situation, one upstream network might choose to assign addresses via prefix delegation, and another via SLAAC.¶

4. Router Behaviour

The router SHOULD set P flag to zero by default, unless explicitly configured by the administrator. The router SHOULD have a configuration knob to set the P flag value for the given prefix.¶

5. Host Behaviour

6. Multihoming

In multi-prefix multihoming, the host generally needs to associate the prefix with the router that advertised it (see for example, [RFC6724] Rule 5.5). If the host supports Rule 5.5, then it SHOULD associate each prefix with the link-local address of the DHCPv6 relay from which it received the REPLY packet. When receiving multiple REPLYs carrying the same prefix from distinct link-local addresses, the host SHOULD associate that prefix with all of these addresses. This can commonly happen in networks with redundant routers and DHCPv6 relays.¶

7. Modifications to RFC-Mandated Behavior

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     | Prefix Length |L|A|R|Reserved1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     | Prefix Length |L|A|R|P| Rsvd1 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8. Security Considerations

The mechanism described in this document relies on the information provided in the Router Advertisement and therefore shares the same security model as SLAAC. If the network doesn't implement RA Guard [RFC6105], an attacker might sent RAs containing the PIO used by the network, set P flag to 1 and force hosts to ignore A flag. In the absense of DHCPv6 PD infrastructure, hosts would experience delays in obtaining IPv6 addresses (as no delegated prefixes are available, hosts MAY choose to fallback to SLAAC).¶

The attacker might force hosts to oscillate between DHCPv6 PD and PIO-based SLAAC by sending the same set of PIOs with and then w/o P flag set. That would cause the clients to issue REBIND requests, increasing the load on the DHCP infrastructure. However Section 14.1 of [RFC8415] requires that DHCPv6 PD clients rate limit transmitted DHCPv6 messages.¶

It should be noted that if the network allows rogue RAs to be sent, the attacker would be able to disrupt hosts connectivity anyway, so this document doesn't introduce any fundamentally new security considerations.¶

9. Privacy Considerations

Implementing the P flag on a host / receiving side enables other systems on the network to trigger running DHCPv6 on that network. Doing so may reveal some minor additional information about the host, most prominently the hostname. This is the same consideration as for the M flag.¶

No privacy considerations result from supporting the P flag on the sender side.¶

10. IANA Considerations

This memo requests that IANA allocate bit 3 from the "IPv6 Neighbor Discovery Prefix Information Option Flags" registry created by [RFC8425] for use as the P flag as described in this document. The following entry should be appended:¶

Acknowledgements

Thanks to Fernando Gont, Suresh Krishnan, Andrew McGregor, Tomek Mrugalski, Timothy Winters for the discussions, the input and all contribution.¶

Authors' Addresses