RFC 9527

DHCPv6 Options for the Homenet Naming Authority

📅 published January 2024, from ietf

RFC 9527: DHCPv6 Options for the Homenet Naming Authority 🎀

Written by D. Migault (Ericsson), R. Weber (Akamai), and T. Mrugalski (ISC) 💅 Stream: Internet Engineering Task Force (IETF) ✨ Category: Standards Track 🌈 ISSN: 2070-1721 Published: January 2024 🍓 This title block doesn't list anything it obsoletes or updates 🙈

Abstract ✨

okay so this doc defines DHCPv6 options 🧚 so a Homenet Naming Authority (HNA) can automatically set up its config and outsource the authoritative naming service for the home network 💅 and in most cases the outsourcing is totally transparent for the end user 🫶

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9527.

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, because 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.  Terminology
   3.  Procedure Overview
   4.  DHCPv6 Options
     4.1.  Registered Homenet Domain Option
     4.2.  Forward Distribution Manager Option
     4.3.  Reverse Distribution Manager Server Option
     4.4.  Supported Transport
   5.  DHCPv6 Behavior
     5.1.  DHCPv6 Server Behavior
     5.2.  DHCPv6 Client Behavior
     5.3.  DHCPv6 Relay Agent Behavior
   6.  IANA Considerations
     6.1.  DHCPv6 Option Codes
     6.2.  Supported Transport Parameter
   7.  Security Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Appendix A.  Scenarios and Impact on the End User
     A.1.  Base Scenario
     A.2.  Third-Party Registered Homenet Domain
     A.3.  Third-Party DNS Infrastructure
     A.4.  Multiple ISPs
     Acknowledgments
     Contributors
   Authors' Addresses

1. Introduction ✨

[RFC9526] specifies how an entity designated as the Homenet Naming Authority (HNA) outsources a Public Homenet Zone to a DNS Outsourcing Infrastructure (DOI).

This document describes how a network can provision the HNA with a specific DOI. This could be especially useful for a DOI that's partly managed by an ISP, or to make home networks resilient to HNA replacement 💖 The ISP delegates an IP prefix and the associated reverse zone to the home network. So the ISP knows who owns that IP prefix, which makes it a natural candidate for hosting the Homenet Reverse Zone, meaning the Reverse Distribution Manager (RDM) and potentially the Reverse Public Authoritative Servers 🎀

ISPs also often identify the line of the home network with a name. That name is used for their internal network management operations, and it isn't a name the home network owner has registered to. ISPs may leverage that infrastructure and provide the home network with a specific domain name designated per a Registered Homenet Domain [RFC9526]. Just like with the reverse zone, ISPs know who owns that domain name, so they may become a natural candidate for hosting the Homenet Zone, meaning the Distribution Manager (DM) and the Public Authoritative Servers 🌸

This document describes DHCPv6 options that enable an ISP to provide the necessary parameters to the HNA. More specifically, the ISP provides the Registered Homenet Domain and the necessary information on the DM and the RDM, so the HNA can manage and upload the Public Homenet Zone and the Reverse Public Homenet Zone as described in [RFC9526] 🧚

The use of DHCPv6 options may make the configuration completely transparent to the end user, and it provides a similar level of trust as the one used to provide the IP prefix when it's provisioned via DHCP 🔥

2. Terminology 💜

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.

The reader should be familiar with [RFC9526]. 📖

3. Procedure Overview 🦋

This section shows how an HNA receives the information it needs via DHCPv6 options to outsource its authoritative naming service to the DOI. To keep things simple, and just like in [RFC9526], this section assumes that the HNA and the home network DHCPv6 client are colocated on the Customer Premises Equipment (CPE) router [RFC7368]. Also, note that this is not mandatory, and the DHCPv6 client may remotely instruct the HNA with a protocol that will be standardized in the future 👀 This section also assumes that the entity responsible for the DHCPv6 server is provisioned with the DM and RDM information associated with the requested Registered Homenet Domain. This means a Registered Homenet Domain can be associated with the DHCPv6 client ✨

This scenario is believed to be the most popular one. This document does not ignore scenarios where the DHCPv6 server does not have privileged relations with the DM or RDM. Those cases are discussed in Appendix A. Such scenarios don't necessarily require configuration for the end user, and they can also be zero configuration 🫶

The scenario considered in this section goes like this:

  1. The HNA is willing to outsource the Public Homenet Zone or Homenet Reverse Zone. The DHCPv6 client is configured to include, in its Option Request Option (ORO), the Registered Homenet Domain Option (OPTION_REGISTERED_DOMAIN), the Forward Distribution Manager Option (OPTION_FORWARD_DIST_MANAGER), and the Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) option codes.
  2. The DHCPv6 server responds to the DHCPv6 client with the requested DHCPv6 options based on the identified homenet. The DHCPv6 client passes the information to the HNA.
  3. The HNA is authenticated (see "Securing the Control Channel" (Section 6.6) of [RFC9526]) by the DM and the RDM. The HNA builds the Homenet Zone (or the Homenet Reverse Zone) and proceeds as described in [RFC9526]. The DHCPv6 options provide the necessary non-optional parameters described in Appendix B of [RFC9526]. The HNA may complement the configurations with additional parameters via means not yet defined. Appendix B of [RFC9526] describes such parameters that may take some specific non-default value. 🌈

4. DHCPv6 Options 💅

This section details the payload of the DHCPv6 options, following the guidelines of [RFC7227].

4.1. Registered Homenet Domain Option 🍓

The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the fully qualified domain name (FQDN) associated with the home network. This is the main character of the whole options set 👑

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   OPTION_REGISTERED_DOMAIN    |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                   Registered Homenet Domain                   /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: Registered Domain Option

Here's what each field means 🎀

  • option-code (16 bits): OPTION_REGISTERED_DOMAIN; the option code for the Registered Homenet Domain (145).
  • option-len (16 bits): Length in octets of the Registered Homenet Domain field, as described in [RFC8415].
  • Registered Homenet Domain (variable): The FQDN registered for the homenet, encoded as described in Section 10 of [RFC8415].

4.2. Forward Distribution Manager Option ✨

okay bestie, the Forward Distribution Manager Option (OPTION_FORWARD_DIST_MANAGER) is how the HNA gets the FQDN of the DM, plus the transport protocols they can use to talk to each other 📮. Now, an FQDN needs a DNS lookup before the HNA and DM can actually connect, which is a tiny extra step compared to using an IP address 🤔. But FQDNs are still lowkey iconic 💅 because the option is easier to parse and ends up smaller, especially when IPv4 and IPv6 addresses are both expected to show up. An FQDN also feels like a more stable identifier than an IP address, and it can point to extra info that might be handy later for setting up the connection 🦋.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  OPTION_FORWARD_DIST_MANAGER  |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Supported Transport       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   /                  Distribution Manager FQDN                    /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Forward Distribution Manager Option

  • option-code (16 bits): OPTION_FORWARD_DIST_MANAGER, the option code for the Forward Distribution Manager Option (146) 🎀
  • option-len (16 bits): the length in octets of the enclosed data, as described in [RFC8415] 📏
  • Supported Transport (16 bits): tells you which Supported Transport the DM offers (see Section 4.4) 🧚. Each bit stands for one supported transport, and a DM MAY indicate support for multiple modes. The bit for DNS over mutually authenticated TLS (DomTLS) MUST be set 🔒
  • Distribution Manager FQDN (variable): the FQDN of the DM, encoded as described in Section 10 of [RFC8415] 🌸

It's worth noting that this DHCPv6 option describes the Supported Transport without naming any explicit port 👀. Unless the HNA and the DM have agreed on a specific port (for example, through configuration or some out-of-band mechanism), the default port is used and must be specified. That default port can be defined in the spec for the designated Supported Transport or in some other document. For DomTLS, the default port value is 853, per DNS over TLS [RFC7858] and DNS Zone Transfer over TLS [RFC9103] ✨.

The reason it works like this is that linking a port number to each Supported Transport in the DHCPv6 option was weighed against how annoying it is to handle a list of (transport, port) tuples. The other option on the table was a dedicated IP address for the DM, just in case the default port is already taken 🫶.

4.3. Reverse Distribution Manager Server Option

The Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) gives the HNA the FQDN of the DM, plus the transport protocols for talking between the HNA and the DM 💜.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OPTION_REVERSE_DIST_MANAGER   |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Supported Transport       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   /              Reverse Distribution Manager FQDN                /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Reverse Distribution Manager Option

  • option-code (16 bits): OPTION_REVERSE_DIST_MANAGER, the option code for the Reverse Distribution Manager Option (147) 🍓
  • option-len (16 bits): the length in octets of the option-data field, as described in [RFC8415] 📐
  • Supported Transport (16 bits): tells you which Supported Transport the RDM offers (see Section 4.4) 🌈. Each bit stands for one supported transport, and an RDM MAY indicate support for multiple modes. The bit for DomTLS [RFC7858] MUST be set 🔐
  • Reverse Distribution Manager FQDN (variable): the FQDN of the RDM, encoded as described in Section 10 of [RFC8415] 🦄

For the port number tied to the Supported Transport, the same considerations as in Section 4.2 apply 🙌.

4.4. Supported Transport

The Supported Transport field of the DHCPv6 option tells you which Supported Transport protocols are on offer 🌟. Each bit stands for one specific transport mechanism. A bit set to 1 means the matching transport protocol is supported. The bits are assigned as shown in Table 2 💅.

DNS over mutually authenticated TLS (DomTLS): indicates support for DNS over TLS [RFC7858] and DNS Zone Transfer over TLS [RFC9103], as described in [RFC9526] 💖.

As an example, a Supported Transport field that expresses support for DomTLS looks like this, with a numeric value of 0x0001 🧁:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        must be zero         |1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. DHCPv6 Behavior 🎀

5.1. DHCPv6 Server Behavior

Section 18.3 of [RFC8415] is the part that covers how servers handle option assignment 🗂️. Just so you have it handy, the server will send option foo only if it's configured with specific values for foo and the client asked for it 👀. Specifically, when it's configured, the DHCPv6 server sends the Registered Homenet Domain Option, Distribution Manager Option, and Reverse Distribution Manager Option when the DHCPv6 client requests them by including the necessary option codes in its ORO 💫.

5.2. DHCPv6 Client Behavior

The DHCPv6 client puts the Registered Homenet Domain Option, Distribution Manager Option, and Reverse Distribution Manager Option in an ORO, as specified in Sections 18.2 and 21.7 of [RFC8415] 📨.

When the HNA gets one of the DHCPv6 options described in this document in the Reply message, it SHOULD proceed as described in [RFC9526] 🫧.

5.3. DHCPv6 Relay Agent Behavior

There are no additional requirements for the DHCPv6 Relay agents 🦋. Easy vibes for relays 🌸.

6. IANA Considerations 🌈

6.1. DHCPv6 Option Codes

IANA has assigned the following new DHCPv6 Option Codes in the "Option Codes" registry, which lives at <https://www.iana.org/assignments/dhcpv6-parameters> 🗃️.

+=====+=============================+======+===========+===========+
|Value| Description                 |Client| Singleton | Reference |
|     |                             |ORO   | Option    |           |
+=====+=============================+======+===========+===========+
|145  | OPTION_REGISTERED_DOMAIN    |Yes   | No        | RFC 9527, |
|     |                             |      |           | Section   |
|     |                             |      |           | 4.1       |
+-----+-----------------------------+------+-----------+-----------+
|146  | OPTION_FORWARD_DIST_MANAGER |Yes   | Yes       | RFC 9527, |
|     |                             |      |           | Section   |
|     |                             |      |           | 4.2       |
+-----+-----------------------------+------+-----------+-----------+
|147  | OPTION_REVERSE_DIST_MANAGER |Yes   | Yes       | RFC 9527, |
|     |                             |      |           | Section   |
|     |                             |      |           | 4.3       |
+-----+-----------------------------+------+-----------+-----------+

Table 1: Option Codes Registry

6.2. Supported Transport Parameter

IANA has created and maintains a brand new registry called "Supported Transport" under the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry at <https://www.iana.org/assignments/dhcpv6-parameters> 🪄. This registry holds Supported Transport parameters for the Distributed Manager Option (OPTION_FORWARD_DIST_MANAGER) or the Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The different parameters are defined in Table 2 (Section 6.2) 💜.

The Supported Transport field of the DHCPv6 option is a two-octet field that shows which Supported Transport protocols are available. Each bit stands for one specific transport mechanism 🍭.

New entries MUST specify the bit position, the transport protocol description, a mnemonic, and a reference, as shown in Table 2 🙏.

Changes to the format or policies of the registry are managed by the IETF via the IESG 🏛️.

Future code points are assigned under RFC Required, per [RFC8126]. The initial registry is the one specified in Table 2 below 📋.

+======================+====================+==========+===========+
| Bit Position (least  | Transport Protocol | Mnemonic | Reference |
| to most significant) | Description        |          |           |
+======================+====================+==========+===========+
| 0                    | DNS over mutually  | DomTLS   | RFC 9527  |
|                      | authenticated TLS  |          |           |
+----------------------+--------------------+----------+-----------+
| 1-15                 | Unassigned         |          |           |
+----------------------+--------------------+----------+-----------+

Table 2: Supported Transport Registry

7. Security Considerations 🔐

This one's serious, bestie 😭 The security considerations in [RFC8415] are to be considered. The trust attached to the information carried by the DHCPv6 options described in this document is similar to the trust attached to the IP prefix when it's configured via DHCPv6 🛡️.

In some cases, the ISP MAY identify the HNA by its wire line (i.e., physically), which may not require relying on TLS to authenticate the HNA 🔌. As the use of TLS is mandatory, it's expected that the HNA will be provisioned with a certificate 📜. In some cases, the HNA may use a self-signed certificate 🫣.

8. References ✨

8.1. Normative References

8.2. Informative References

Appendix A. Scenarios and Impact on the End User ✨

This appendix is a little peek at various scenarios and how they hit the end user 🦋. It is not normative, and it only covers a limited set of scenarios that are assumed to be representative. Many other scenarios may be derived from these, bestie 💅.

A.1. Base Scenario

Okay, so the base scenario (see Section 3 🧚) is one where an ISP manages the DHCPv6 server, DM, and RDM. 💖

The end user subscribes to the ISP (foo), and at subscription time, it registers foo.example as its Registered Homenet Domain. 🎀

In this scenario, the DHCPv6 server, DM, and RDM are managed by the ISP, so the DHCPv6 server and such can provide authentication credentials of the HNA to enable secure authenticated transaction with the DM and the Reverse DM. It's giving security, fr fr 🔐✨

The main advantage here is that the naming architecture gets configured automatically and transparently for the end user, which is so iconic 👑. The drawbacks are that the end user uses a Registered Homenet Domain managed by the ISP, and that it relies on the ISP naming infrastructure 🥲.

A.2. Third-Party Registered Homenet Domain

This appendix looks at the case where the end user wants its home network to use example.com, but doesn't want the ISP (foo) to manage it as a Registered Homenet Domain. Instead, the ISP still manages the home network and still provides foo.example as a Registered Homenet Domain 🌸.

When the end user buys the domain name example.com, it may request to redirect example.com to foo.example using static redirection with CNAME [RFC1034] [RFC2181], DNAME [RFC6672], or CNAME+DNAME [CNAME-PLUS-DNAME]. The only info the end user needs is the domain name assigned by the ISP 🧠. Once the redirection is configured, the HNA may be changed, and the zone can be updated as described in Appendix A.1 without any additional configuration from the end user. Zero effort, periodt 💅.

The main advantage of this scenario is that the end user gets to enjoy the zero configuration of the base scenario in Appendix A.1. Then, the end user is able to register an unlimited number of domain names provided by an unlimited number of different third-party providers for its home network 🌈. The drawback may be that the end user still needs to rely on the ISP naming infrastructure. Note that this may be inconvenient where the DNS servers provided by the ISPs result in high latency 😭.

A.3. Third-Party DNS Infrastructure

This scenario has the end user using example.com as a Registered Homenet Domain, without relying on the authoritative servers provided by the ISP 🦋.

In this appendix, we only outsource the DM and Public Authoritative Server(s) to a third party. The Reverse Public Authoritative Server(s) and the RDM stay managed by the ISP, since the IP prefix is managed by the ISP 🫶.

Outsourcing to a third-party DM can be done in the following ways:

  1. Updating the DHCPv6 server information. One can imagine a GUI interface that lets the end user modify its profile parameters. Again, this configuration update only needs to be performed one time 💜.
  2. Uploading the configuration of the DM to the HNA. In some cases, the provider of the CPE router hosting the HNA may be the registrar, and the registrar may provide the CPE router already configured. In other cases, the CPE router may ask the end user to log into the registrar to validate ownership of the Registered Homenet Domain and agree on the necessary credentials to secure the communication between the HNA and the DM. As described in [RFC9526], such settings could be performed in an almost automatic way, so the end user has to do way less 🧚✨.

A.4. Multiple ISPs

This scenario has an HNA connected to multiple ISPs 🌐.

Suppose the HNA has configured each of its interfaces independently with each ISP as described in Appendix A.1. Each ISP provides a different Registered Homenet Domain 🍓.

The protocol and DHCPv6 options described in this document are fully compatible with an HNA connected to multiple ISPs with multiple Registered Homenet Domains. However, the HNA should be able to handle different Registered Homenet Domains. This is an implementation issue, which is outside the scope of this document 🙈.

If an HNA is not able to handle multiple Registered Homenet Domains, the HNA may remain connected to multiple ISPs with a single Registered Homenet Domain. In this case, one entity is chosen to host the Registered Homenet Domain, and this entity may be an ISP or a third party. Note that having multiple ISPs can be a motivation for bandwidth aggregation or connectivity failover. In the case of connectivity failover, the failover concerns the access network, and a failure of the access network may not impact the core network where the DM and Public Authoritative Primaries are hosted. In that sense, choosing one of the ISPs even in a scenario of multiple ISPs may make sense 🤔. However, for the sake of simplicity, this scenario assumes that a third party has been chosen to host the Registered Homenet Domain. Configuration is performed as described in Appendices A.2 and A.3 💅.

With the configuration described in Appendix A.2, the HNA is expected to be able to handle multiple Registered Homenet Domains, as the third-party redirects to one of the ISP's servers. With the configuration described in Appendix A.3, DNS zones are hosted and maintained by the third party. A single DNS(SEC) Homenet Zone is built and maintained by the HNA. This latter configuration is likely to match most HNA implementations 💖.

The protocol and DHCPv6 options described in this document are fully compatible with an HNA connected to multiple ISPs. Whether to configure the HNA or not, and how to configure the HNA, depends on the HNA facilities. Appendices A.1 and A.2 require the HNA to handle multiple Registered Homenet Domains, whereas Appendix A.3 does not have such a requirement 🦋✨.

Acknowledgments

Huge thanks to Marcin Siodelski, Bernie Volz, and Ted Lemon for their comments on the design of the DHCPv6 options 🫶. We also want to thank Mark Andrews, Andrew Sullivan, and Lorenzo Colliti for their remarks on the architecture design 🧠. The designed solution has been largely inspired by Mark Andrews's document [PD-REVERSE], as well as discussions with Mark 💜. We also thank Ray Hunter and Michael Richardson for their reviews and comments, and for suggesting appropriate terminology 👑.

Contributors

The coauthors would like to thank Chris Griffiths and Wouter Cloetens for providing significant contributions to the early draft versions of this document 🌷.

Authors' Addresses

  • Daniel Migault: Ericsson, 8275 Trans Canada Route, Saint Laurent QC 4S 0B6, Canada. Email: daniel.migault@ericsson.com
  • Ralf Weber: Akamai. Email: ralf.weber@akamai.com
  • Tomek Mrugalski: Internet Systems Consortium, Inc., PO Box 360, Newmarket, NH 03857, United States of America. Email: tomasz.mrugalski@gmail.com
📦 where this page comes from