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, hosts/clients may have advanced knowledge that all routers on the link would be willing to provide DHCPv6 address/prefix delegation services without the need for an initial RS/RA message exchange followed by one or more separate DHCPv6 exchanges. This document specifies a new IPv6 Neighbor Discovery option termed the "DHCPv6 Option" that supports the managed delegation of addresses/prefixes in a single message exchange.¶

2. IPv6 ND DHCPv6 Option

The IPv6 Neighbor Discovery (IPv6 ND) 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 hosts/clients to detect their presence. After receiving an RA, hosts/clients can then invoke the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC8415] 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 fulfill client needs.)¶

This document concerns a class of links on which hosts/clients may not receive timely unsolicited RA messages and may therefore be compelled to send Router Solicitation (RS) messages to invoke an RA response. If the hosts/clients are further aware in advance that all 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 document therefore proposes a DHCPv6 Option for IPv6 ND.¶

The DHCPv6 Option for IPv6 ND has 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     |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    msg-type   |               transaction-id                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                        DHCPv6 options                         ~
     ~                 (variable number and length)                  ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Null Padding ....
     +-+-+-+-+-+-+-+-+-+-+-+-

In this format "Type" is assigned an integer IPv6 ND option type value (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 beginning with a msg-type and transaction-id and ending with a variable-length concatenation of DHCPv6 options. If the message is not an integral number of 8 octets, Null Padding is added following the end of the DHCPv6 options.¶

In a reference use case, when a host/client on a link with known properties does not receive a timely RA message, it can send an RS message containing a DHCPv6 Option with the DHCPv6 message populated according to [RFC8415]. 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. When the DHCPv6 server responds, the router encapsulates the DHCPv6 response in an RA message DHCPv6 option and sends the RA message to the unicast address of the host/client.¶

It is important to understand that multiple routers on the link may send RA responses to a single RS message. The host/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.¶

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 RA with a DHCPv6 Option response containing a failure code or no DHCPv6 Option at all. The host/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 RA message sent to a multicast address, and hosts/clients MUST ignore a DHCPv6 Option response in a multicast RA.¶

3. Implementation Status

In progress.¶

4. IANA Considerations

The IANA is instructed to allocate a new IPv6 ND option Type for the DHCPv6 Option.¶

5. Security Considerations

TBD.¶

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