DHCPv6 Option for IPv6 ND (DHCPv6ND)

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 13 April 2025.¶

Copyright Notice

Copyright (c) 2024 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

1. Introduction

On some IPv6 links, clients may have a reasonable expectation that routers on the link would be willing to support DHCPv6 address/prefix delegation services without the need to first examine the M/O bits in a received Router Advertisement (RA) message. Such clients should therefore be capable of invoking the IPv6 Neighbor Discovery (IPv6ND) router discovery and Dynamic Host Configuration Protocol for IPv6 (DHCPv6) address/prefix delegation services in a single message exchange instead of multiple. This document specifies a new IPv6ND option termed the "DHCPv6ND Option" that supports both functions in a single message exchange.¶

2. The DHCPv6ND Option

The IPv6ND specification [RFC4861] defines the protocol, message formats and option types for operation of the IPv6 protocol [RFC8200] over all manners of links. Routers on the link send Router Advertisement (RA) messages to a link-scoped multicast address allowing clients to detect their presence. After examining the M/O bits in a received RA, a client can then invoke DHCPv6 [RFC8415] services and/or StateLess Address AutoConfiguration (SLAAC) [RFC4862] procedures to obtain IPv6 addresses. (In some environments, the DHCPv6 Prefix Delegation (PD) service may also be available to satisfy client needs.)¶

This document concerns a service in which clients may send immediate Router Solicitation (RS) messages to invoke timely RA responses from routers on the link, i.e., whether or not an unsolicited multicast RA is also received. If the clients are further aware in advance that routers on the link would be willing to provide DHCPv6 address/prefix delegation services, it would be beneficial if the RS/RA message exchanges themselves could also convey DHCPv6 parameters. This would not only reduce message overhead but also reduce the attack surface since all operations are conducted in a single (secured) message exchange.¶

This document specifies a DHCPv6 option for IPv6 Neighbor Discovery ("DHCPv6ND") with the following format:¶

      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     |    msg-type   |  trans-id (0) |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      transaction-id (1-2)     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               ~
     |                                                               ~
     ~                        DHCPv6 options                         ~
     ~                 (variable number and length)                  ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Null Padding ....
     +-+-+-+-+-+-+-+-+-+-+-+-

In this format "Type" is assigned an integer IPv6 ND option type value "TBD" (see: IANA Considerations), "Length" is the length of the option in units of 8 octets and the remainder of the option is a standard-format DHCPv6 message per [RFC8415]. The DHCPv6 message begins with a 1-octet msg-type followed by a 3-octet transaction-id and ends with a variable length concatenation of DHCPv6 options. Null Padding is added following the end of the DHCPv6 options if necessary to ensure 8-octet alignment.¶

In a reference use case, when a client on the link wishes to invoke the combined services without necessarily waiting to receive an RA, it can send an RS message containing a DHCPv6ND Option. The DHCPv6 message will typically include a request for address and/or prefix delegations plus a Rapid Commit option. Upon receiving the RS message, one or more routers on the link that are willing to provide DHCPv6 services convey the DHCPv6 message to a nearby DHCPv6 server, e.g., via a loopback interface on the local node. When the DHCPv6 server responds, the router encapsulates the DHCPv6 response in an RA message DHCPv6ND option and sends the RA message to the unicast address of the client. It is important to understand that multiple routers on the link may send independent RA responses to a single RS message. The client should process the union of all DHCPv6 information received in RAs (keeping track of their respective routers of origin) and either accept or decline any offered addresses or prefixes.¶

Following an initial RS/RA exchange when a router successfully delivers DHCPv6 delegations to a client, the client is responsible for refreshing lease lifetimes prior to their expiration. For this purpose, the client can either initiate another RS/RA exchange (e.g., if parameters such as router or prefix lifetimes are also nearing expiration) or include a DHCPv6ND option in a Neighbor Solicitation (NS) message prepared according to Neighbor Unreachability Detection (NUD) procedures. When the router receives the NS message, it processes the DHCPv6ND option and returns a Neighbor Advertisement (NA) message that also includes a responsive DHCPv6ND option.¶

Note that it is not an error for a router that either does not recognize the option or cannot provide the requested service to return an NA/RA with a DHCPv6ND Option containing a negative response or no DHCPv6ND Option at all. The client can then attempt to obtain DHCPv6 services via another router on the link. However, routers SHOULD NOT return a DHCPv6 Option response in an NA/RA message sent to a multicast address, and clients MUST ignore a DHCPv6 Option response in a multicast NA/RA.¶

3. Implementation Status

In progress.¶

4. IANA Considerations

The IANA is instructed to allocate a new entry in the "IPv6 Neighbor Discovery Option Formats" table of the "icmpv6-parameters" registry. The entry should set "Type" to TBD, "Description" to "DHCPv6ND option" and "Reference" to "[RFCXXXX]" (i.e., this document).¶

IANA Registration procedures are "RFC Required".¶

5. Security Considerations

By combining the IPv6 ND router discovery and DHCPv6 managed address delegation procedures in a single RS/RA message exchange, the attack surface for the service is reduced since only the RS and RA messages need to be secured.¶

The DHCPv6ND option may appear in RS/RA or NS/NA messages for initial delegations or lease extensions. The option must be ignored if it appears in a Redirect message.¶

When link or physical-layer security services are absent or inadequate, network layer securing services for IPv6ND messages that contain the DHCPv6ND option should be applied to ensure integrity and authorization.¶

Nodes that do not recognize the DHCPv6ND option in the ND messages they process ignore the option and process any other recognized options present. This supports operation on links with a "mixed" set of clients and routers, where some recognize and process the option while others ignore it.¶

6. Acknowledgements

This work was inspired by continued investigations into 5G MANET operations in cooperation with the Virginia Tech National Security Institute (VTNSI).¶

Honoring life, liberty and the pursuit of happiness.¶

Author's Address