| RFC 9527 | DHCPv6 Options for the HNA | January 2024 |
| Migault, et al. | Standards Track | [Page] |
This document defines DHCPv6 options so that a Homenet Naming Authority (HNA) can automatically set the appropriate configuration and outsource the authoritative naming service for the home network. In most cases, the outsourcing mechanism is transparent for the end user.¶
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, 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.¶
[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 particularly useful for a DOI 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. The ISP is thus aware of the owner of that IP prefix and, as such, becomes a natural candidate for hosting the Homenet Reverse Zone -- that is, the Reverse Distribution Manager (RDM) and potentially the Reverse Public Authoritative Servers.¶
In addition, ISPs often identify the line of the home network with a name. Such name is used for their internal network management operations and is not a name the home network owner has registered to. ISPs may leverage such infrastructure and provide the home network with a specific domain name designated per a Registered Homenet Domain [RFC9526]. Similarly to the reverse zone, ISPs are aware of who owns that domain name and may become a natural candidate for hosting the Homenet Zone -- that is, 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 to proceed. 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 provides a similar level of trust as the one used to provide the IP prefix, when provisioned via DHCP.¶
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.¶
This section illustrates how an HNA receives the necessary information via DHCPv6 options to outsource its authoritative naming service to the DOI. For the sake of simplicity, and similarly to [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. In addition, this section assumes that the responsible entity for the DHCPv6 server is provisioned with the DM and RDM information, which is 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 scenario. This document does not ignore scenarios where the DHCPv6 server does not have privileged relations with the DM or RDM. These cases are discussed in Appendix A. Such scenarios do not necessarily require configuration for the end user and can also be zero configuration.¶
The scenario considered in this section is as follows:¶
This section details the payload of the DHCPv6 options following the guidelines of [RFC7227].¶
The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the fully qualified domain name (FQDN) associated with the home network.¶
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 / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Forward Distribution Manager Option (OPTION_FORWARD_DIST_MANAGER) provides the HNA with the FQDN of the DM as well as the transport protocols for the communication between the HNA and the DM. As opposed to IP addresses, the FQDN requires a DNS resolution before establishing the communication between the HNA and the DM. However, the use of an FQDN provides multiple advantages over IP addresses. Firstly, it makes the DHCPv6 option easier to parse and smaller, especially when IPv4 and IPv6 addresses are expected to be provided. Then, the FQDN can reasonably be seen as a more stable identifier than IP addresses as well as a pointer to additional information that may be useful, in the future, to establish the communication 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_FORWARD_DIST_MANAGER | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supported Transport | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Distribution Manager FQDN / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It is worth noting that the DHCPv6 option specifies the Supported Transport without specifying any explicit port. Unless the HNA and the DM have agreed on using a specific port -- for example, by configuration, or any out-of-band mechanism -- the default port is used and must be specified. The specification of such default port may be defined in the specification of the designated Supported Transport or in any other document. In the case of DomTLS, the default port value is 853 per DNS over TLS [RFC7858] and DNS Zone Transfer over TLS [RFC9103].¶
The need to associate the port value to each Supported Transport in the DHCPv6 option has been balanced with the difficulty of handling a list of tuples (transport, port) and the possibility of using a dedicated IP address for the DM in case the default port is already in use.¶
The Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) provides the HNA with the FQDN of the DM as well as the transport protocols for the communication 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 / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For the port number associated to the Supported Transport, the same considerations as described in Section 4.2 apply.¶
The Supported Transport field of the DHCPv6 option indicates the Supported Transport protocols. Each bit represents a specific transport mechanism. A bit set to 1 indicates the associated transport protocol is supported. The corresponding bits are assigned as described in Table 2.¶
As an example, the Supported Transport field expressing support for DomTLS looks as follows and has 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Section 18.3 of [RFC8415] governs server operation regarding option assignment. As a convenience to the reader, we mention here that the server will send option foo only if configured with specific values for foo and if the client requested it. In particular, when configured, the DHCPv6 server sends the Registered Homenet Domain Option, Distribution Manager Option, and Reverse Distribution Manager Option when requested by the DHCPv6 client by including necessary option codes in its ORO.¶
The DHCPv6 client includes 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].¶
Upon receiving a DHCPv6 option, as described in this document, in the Reply message, the HNA SHOULD proceed as described in [RFC9526].¶
There are no additional requirements for the DHCPv6 Relay agents.¶
IANA has assigned the following new DHCPv6 Option Codes in the "Option Codes" registry maintained at <https://www.iana.org/assignments/dhcpv6-parameters>.¶
| Value | Description | Client ORO | Singleton Option | Reference |
|---|---|---|---|---|
| 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 |
IANA has created and maintains a 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 contains Supported Transport parameters in 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 indicates the Supported Transport protocols. Each bit represents a 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 as specified in Table 2 below.¶
| Bit Position (least to most significant) | Transport Protocol Description | Mnemonic | Reference |
|---|---|---|---|
| 0 | DNS over mutually authenticated TLS | DomTLS | RFC 9527 |
| 1-15 | Unassigned |
The security considerations in [RFC8415] are to be considered. The trust associated with the information carried by the DHCPv6 options described in this document is similar to the one associated with the IP prefix, when 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 is expected that the HNA will be provisioned with a certificate. In some cases, the HNA may use a self-signed certificate.¶
This appendix details various scenarios and discusses their impact on the end user. This appendix is not normative and limits the description of a limited scope of scenarios that are assumed to be representative. Many other scenarios may be derived from these.¶
The base scenario, as described in Section 3, is one in which 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.¶
The main advantage of this scenario is that the naming architecture is configured automatically and transparently for the end user. 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.¶
This appendix considers the case where the end user wants its home network to use example.com but does not want it to be managed by the ISP (foo) as a Registered Homenet Domain, and the ISP 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 information the end user needs to know is the domain name assigned by the ISP. Once the redirection has been 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.¶
The main advantage of this scenario is that the end user benefits from 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 of this scenario may be that the end user still needs to rely on the ISP naming infrastructure. Note that this may be inconvenient in the case where the DNS servers provided by the ISPs result in high latency.¶
This scenario involves the end user using example.com as a Registered Homenet Domain and not relying on the authoritative servers provided by the ISP.¶
In this appendix, we limit the outsourcing of the DM and Public Authoritative Server(s) to a third party. The Reverse Public Authoritative Server(s) and the RDM remain managed by the ISP as the IP prefix is managed by the ISP.¶
Outsourcing to a third-party DM can be performed in the following ways:¶
This scenario involves 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. This entity may be an ISP or a third party. Note that having multiple ISPs can be 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 redirect 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.¶
We would like to thank Marcin Siodelski, Bernie Volz, and Ted Lemon for their comments on the design of the DHCPv6 options. We would also like 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.¶
The coauthors would like to thank Chris Griffiths and Wouter Cloetens for providing significant contributions to the early draft versions of this document.¶