Skip to main content

DHCPv6 Option for IPv6 ND (DHCPv6ND)
draft-templin-6man-dhcpv6nd-01

Document Type Active Internet-Draft (individual)
Author Fred Templin
Last updated 2024-10-10
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-templin-6man-dhcpv6nd-01
Network Working Group                                 F. L. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Intended status: Standards Track                         10 October 2024
Expires: 13 April 2025

                  DHCPv6 Option for IPv6 ND (DHCPv6ND)
                     draft-templin-6man-dhcpv6nd-01

Abstract

   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.

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

Templin                   Expires 13 April 2025                 [Page 1]
Internet-Draft                  DHCPv6ND                    October 2024

   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.  The DHCPv6ND Option . . . . . . . . . . . . . . . . . . . . .   2
   3.  Implementation Status . . . . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

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

Templin                   Expires 13 April 2025                 [Page 2]
Internet-Draft                  DHCPv6ND                    October 2024

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

                     Figure 1: DHCPv6ND Option Format

   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

Templin                   Expires 13 April 2025                 [Page 3]
Internet-Draft                  DHCPv6ND                    October 2024

   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.

Templin                   Expires 13 April 2025                 [Page 4]
Internet-Draft                  DHCPv6ND                    October 2024

   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.

7.  References

7.1.  Normative 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>.

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

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

7.2.  Informative References

Templin                   Expires 13 April 2025                 [Page 5]
Internet-Draft                  DHCPv6ND                    October 2024

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

Appendix A.  Change Log

   << RFC Editor - remove prior to publication >>

   Differences from earlier versions:

   Draft -00 to -01
      *  Clarifications based on list input.

      *  Include support for NS/NA/RS/RA.

      *  IANA Considerations and Security Considerations.

   Draft -00
      *  First draft publication.

Author's Address

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA 98124
   United States of America
   Email: fltemplin@acm.org

Templin                   Expires 13 April 2025                 [Page 6]