< draft-ietf-homenet-naming-architecture-dhc-options-13.txt   draft-ietf-homenet-naming-architecture-dhc-options-14.txt >
Homenet D. Migault Homenet D. Migault
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track R. Weber Intended status: Standards Track R. Weber
Expires: November 14, 2021 Akamai Expires: November 14, 2021 Akamai
T. Mrugalski T. Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
May 13, 2021 May 13, 2021
DHCPv6 Options for Home Network Naming Authority DHCPv6 Options for Home Network Naming Authority
draft-ietf-homenet-naming-architecture-dhc-options-13 draft-ietf-homenet-naming-architecture-dhc-options-14
Abstract Abstract
This document defines DHCPv6 options so an agnostic Homenet Naming This document defines DHCPv6 options so an agnostic Homenet Naming
Authority (HNA) can automatically proceed to the appropriate Authority (HNA) can automatically proceed to the appropriate
configuration and outsource the authoritative naming service for the configuration and outsource the authoritative naming service for the
home network. In most cases, the outsourcing mechanism is home network. In most cases, the outsourcing mechanism is
transparent for the end user. transparent for the end user.
Status of This Memo Status of This Memo
skipping to change at page 2, line 11 skipping to change at page 2, line 11
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 3. Procedure Overview . . . . . . . . . . . . . . . . . . . . . 3
4. Payload Description . . . . . . . . . . . . . . . . . . . . . 4 4. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Registered Homenet Domain Option . . . . . . . . . . . . 4 4.1. Registered Homenet Domain Option . . . . . . . . . . . . 4
4.2. Distribution Manager Option . . . . . . . . . . . . . . . 5 4.2. Distribution Manager Option . . . . . . . . . . . . . . . 5
4.2.1. Supported Transport . . . . . . . . . . . . . . . . . 6 4.2.1. Supported Transport . . . . . . . . . . . . . . . . . 6
4.3. Reverse Distribution Manager Server Option . . . . . . . 6 4.3. Reverse Distribution Manager Server Option . . . . . . . 6
5. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 5. DHCPv6 Behavior . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7 5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7
5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 7 5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 7
5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 7 5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9
skipping to change at page 2, line 44 skipping to change at page 2, line 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The reader is expected to be familiar with The reader should be familiar with
[I-D.ietf-homenet-front-end-naming-delegation] and its terminology [I-D.ietf-homenet-front-end-naming-delegation].
section.
2. Introduction 2. Introduction
[I-D.ietf-homenet-front-end-naming-delegation] specifies how an [I-D.ietf-homenet-front-end-naming-delegation] specifies how an
entity designated as the Homenet Naming Authority (HNA) outsources a entity designated as the Homenet Naming Authority (HNA) outsources a
Public Homenet Zone to an Outsourcing DNS Infrastructure (DOI). Public Homenet Zone to an Outsourcing DNS Infrastructure (DOI).
This document shows how an ISP can provision automatically the HNA This document describes how a network can provision the HNA with a
with a specific DOI. Most likely the DOI will be - at least partly specific DOI. This could be particularly useful for a DOI partly
be - managed or provided by its ISP, but other cases may envision the managed by an ISP, or to make home networks resilient to HNA
ISP storing some configuration so the homenet becomes resilient to replacement. The ISP delegates an IP prefix to the home network as
HNA replacement. well as the associated reverse zone. The ISP is thus aware of the
owner of that IP prefix, and as such becomes a natural candidate for
The ISP delegates the home network an IP prefix it owns as well as hosting the Homenet Reverse Zone - that is the Reverse Distribution
the associated reverse zone. The ISP is well aware of the owner of Manager (RDM) and potentially the Reverse Public Authoritative
that prefix, and as such becomes a natural candidate for hosting the Servers.
Homenet Reverse Zone - that is the Reverse Distribution Manager (RDM)
and potentially the Reverse Public Authoritative Servers.
In addition, the ISP often identifies the home network with a name. In addition, ISPs often identify the line of the home network with a
In most cases, the name is used by the ISP for its internal network name. Such name is used for their internal network management
management operations and is not a name the home network owner has operations and is not a name the home network owner has registered
registered to. The ISP may thus leverage such infrastructure and to. ISPs may leverage such infrastructure and provide the homenet
provide the homenet a specific domain name designated as per with a specific domain name designated as per
[I-D.ietf-homenet-front-end-naming-delegation] a Homenet Registered [I-D.ietf-homenet-front-end-naming-delegation] a Homenet Registered
Domain. Similarly to the reverse zone, the ISP is well aware of who Domain. Similarly to the reverse zone, ISPs are aware of who owns
owns that domain name and may become a natural candidate for hosting that domain name and may become a natural candidate for hosting the
the Homenet Zone - that is the Distribution Manager (DM) and the Homenet Zone - that is the Distribution Manager (DM) and the Public
Public Authoritative Servers. Authoritative Servers.
This document describes DHCPv6 options that enables the ISP to This document describes DHCPv6 options that enable an ISP to provide
provide the necessary parameters to the HNA, to proceed. More the necessary parameters to the HNA, to proceed. More specifically,
specifically, the ISP provides the Registered Homenet Domain, the ISP provides the Registered Homenet Domain, necessary information
necessary information on the DM and the RDM so the HNA can manage and on the DM and the RDM so the HNA can manage and upload the Public
upload the Public Homenet Zone and the Reverse Public Homenet Zone as Homenet Zone and the Reverse Public Homenet Zone as described in
described in [I-D.ietf-homenet-front-end-naming-delegation]. [I-D.ietf-homenet-front-end-naming-delegation].
The use of DHCPv6 options makes the configuration completely The use of DHCPv6 options may make the configuration completely
transparent to the end user and provides a similar level of trust as transparent to the end user and provides a similar level of trust as
the one used to provide the IP prefix. the one used to provide the IP prefix - when provisioned via DHCP.
3. Protocol Overview 3. Procedure Overview
This section illustrates how a HNA receives the necessary information This section illustrates how a HNA receives the necessary information
via DHCPv6 options to outsource its authoritative naming service to via DHCPv6 options to outsource its authoritative naming service to
the DOI. For the sake of simplicity, and similarly to the DOI. For the sake of simplicity, and similarly to
[I-D.ietf-homenet-front-end-naming-delegation], this section assumes [I-D.ietf-homenet-front-end-naming-delegation], this section assumes
that the HNA and the home network DHCPv6 client are collocated on the that the HNA and the home network DHCPv6 client are collocated on the
CPE. Note also that this is not mandatory and specific Customer Edge (CE) router [RFC7368]. Note also that this is not
communications between the HNA and the DHCPv6 client only are needed. mandatory and the DHCPv6 client may instruct remotely the HNA and the
In addition, this section assumes the responsible entity for the DHCPv6 either with a proprietary protocol or a protocol that will be
DHCPv6 server is able to configure the DM and RDM. In our case, this defined in the future. In addition, this section assumes the
means a Registered Homenet Domain can be associated to the DHCP responsible entity for the DHCPv6 server is configured with the DM
client. and RDM. This means a Registered Homenet Domain can be associated to
the DHCPv6 client.
This scenario has been chosen as it is believed to be the most This scenario is believed to be the most popular scenario. This
popular scenario. This document does not ignore scenarios where the document does not ignore scenarios where the DHCPv6 server does not
DHCP Server does not have privileged relations with the DM or RDM. have privileged relations with the DM or RDM. These cases are
These cases are discussed latter in Appendix A. Such scenarios do discussed in Appendix A. Such scenarios do not necessarily require
not necessarily require configuration for the end user and can also configuration for the end user and can also be zero-config.
be zero-config.
The scenario considered in this section is as follows: The scenario considered in this section is as follows:
1. The HNA is willing to outsource the Public Homenet Zone or 1. The HNA is willing to outsource the Public Homenet Zone or
Homenet Reverse Zone and configures its DHCP Client to include in Homenet Reverse Zone. The DHCPv6 client is configured to include
its Option Request Option (ORO) the Registered Homenet Domain in its Option Request Option (ORO) the Registered Homenet Domain
Option (OPTION_REGISTERED_DOMAIN), the Distribution Manager Option (OPTION_REGISTERED_DOMAIN), the Distribution Manager
Option (OPTION_DIST_MANAGER) and the Reverse Distribution Manager Option (OPTION_DIST_MANAGER) and the Reverse Distribution Manager
Option (OPTION_REVERSE_DIST_MANAGER) option codes. Option (OPTION_REVERSE_DIST_MANAGER) option codes.
2. The DHCP Server responds to the HNA with the requested DHCPv6 2. The DHCPv6 server responds to the HNA with the requested DHCPv6
options based on the identified homenet. The DHCP Client options based on the identified homenet. The DHCPv6 client
transmits the information to the HNA. passes the information to the HNA.
3. The HNA is able to get authenticated by the DM and the RDM. The 3. The HNA is authenticated (eventually by a self signed
HNA builds the Homenet Zone ( resp. the Homenet Reverse Zone) and certificate) by the DM and the RDM. The HNA builds the Homenet
proceed as described in Zone (or the Homenet Reverse Zone) and proceed as described in
[I-D.ietf-homenet-front-end-naming-delegation]. The DHCPv6 [I-D.ietf-homenet-front-end-naming-delegation]. The DHCPv6
options provide the necessary and non optional parameters options provide the necessary non optional parameters described
described in section 14 of in Section 14 of [I-D.ietf-homenet-front-end-naming-delegation].
[I-D.ietf-homenet-front-end-naming-delegation]. The HNA MAY set The HNA may complement the configurations with additional
complement the configurations with additional parameters. parameters via means not yet defined. Section 14 of
Section 14 of [I-D.ietf-homenet-front-end-naming-delegation] [I-D.ietf-homenet-front-end-naming-delegation] describes such
describes such parameters that MAY take a default value. parameters that MAY take some specific non default value.
4. Payload Description 4. DHCPv6 Option
This section details the payload of the DHCPv6 options. This section details the payload of the DHCPv6 options.
4.1. Registered Homenet Domain Option 4.1. Registered Homenet Domain Option
The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the
FQDN associated to the home network. FQDN associated to the home network.
0 1 2 3 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 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
skipping to change at page 5, line 18 skipping to change at page 5, line 18
| OPTION_REGISTERED_DOMAIN | option-len | | OPTION_REGISTERED_DOMAIN | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Registered Homenet Domain / / Registered Homenet Domain /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Registered Domain Option Figure 1: Registered Domain Option
o option-code (16 bits): OPTION_REGISTERED_DOMAIN, the option code o option-code (16 bits): OPTION_REGISTERED_DOMAIN, the option code
for the Registered Homenet Domain (TBD2). for the Registered Homenet Domain (TBD1).
o option-len (16 bits): length in octets of the option-data field as o option-len (16 bits): length in octets of the Registered Homenet
described in [RFC8415]. Domain field as described in [RFC8415].
o Registered Homenet Domain (variable): the FQDN registered for the o Registered Homenet Domain (variable): the FQDN registered for the
homenet encoded as described in section 10 of [RFC8415]. homenet encoded as described in Section 10 of [RFC8415].
4.2. Distribution Manager Option 4.2. Distribution Manager Option
The Distributed Manager Option (OPTION_DIST_MANAGER) provides the HNA The Distributed Manager Option (OPTION_DIST_MANAGER) provides the HNA
to FQDN of the DM as well as the transport protocol for the with the FQDN of the DM as well as the transport protocols for the
transaction between the HNA and the DM. communication between the HNA and the DM.
0 1 2 3 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 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_DIST_MANAGER | option-len | | OPTION_DIST_MANAGER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Transport | | | Supported Transport | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Distribution Manager FQDN / / Distribution Manager FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Distribution Manager Option Figure 2: Distribution Manager Option
o option-code (16 bits): OPTION_DIST_MANAGER, the option code for o option-code (16 bits): OPTION_DIST_MANAGER, the option code for
the Distribution Manager Option (TBD2). the Distribution Manager Option (TBD2).
o option-len (16 bits): length in octets of the option-data field as o option-len (16 bits): length in octets of the enclosed data as
described in [RFC8415]. described in [RFC8415].
o Supported Transport (16 bits): defines the supported transport by o Supported Transport (16 bits): defines the supported transport by
the DM. Each bit represents a supported transport, and a DM MAY the DM (see Section 4.2.1). Each bit represents a supported
indicate the support of multiple modes. The bit for DNS over TLS transport, and a DM MAY indicate the support of multiple modes.
[RFC7858] MUST be set. The bit for DNS over TLS [RFC7858] MUST be set.
o Distribution Manager FQDN (variable): the FQDN of the DM encoded o Distribution Manager FQDN (variable): the FQDN of the DM encoded
as described in section 10 of [RFC8415]. as described in Section 10 of [RFC8415].
4.2.1. Supported Transport 4.2.1. Supported Transport
The Supported Transport filed of the DHCPv6 option indicates the The Supported Transport field of the DHCPv6 option indicates the
supported transport protocol. Each bit represents a specific supported transport protocols. Each bit represents a specific
transport mechanism. The bit sets to 1 indicates the associated transport mechanism. A bit sets to 1 indicates the associated
transport protocol is supported. The corresponding bits are assigned transport protocol is supported. The corresponding bits are assigned
as described in Figure 3. as described in Figure 3 and Section 6.
Bit | Transport Protocol | Reference Bit Position | Transport Protocol | Reference
----+--------------------+----------- -------------+--------------------+-----------
0 | DNS over TLS | This-RFC 0 | DNS over TLS | This-RFC
1-15| unallocated | 1-15 | unallocated |
Figure 3: Supported Transport Figure 3: Supported Transport
o DNS over TLS: indicates the support of DNS over TLS as described DNS over TLS: indicates the support of DNS over TLS as described in
in [RFC7858]. [RFC7858].
4.3. Reverse Distribution Manager Server Option 4.3. Reverse Distribution Manager Server Option
The Reverse Distribution Manager Server Option The Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER)
(OPTION_REVERSE_DIST_MANAGER) provides the HNA to FQDN of the DM as provides the HNA with the FQDN of the DM as well as the transport
well as the transport protocol for the transaction between the HNA protocols for the communication between the HNA and the DM.
and the DM.
0 1 2 3 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 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 | | OPTION_REVERSE_DIST_MANAGER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Transport | | | Supported Transport | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Reverse Distribution Manager FQDN / / Reverse Distribution Manager FQDN /
skipping to change at page 7, line 12 skipping to change at page 7, line 12
Figure 4: Reverse Distribution Manager Option Figure 4: Reverse Distribution Manager Option
o option-code (16 bits): OPTION_REVERSE_DIST_MANAGER, the option o option-code (16 bits): OPTION_REVERSE_DIST_MANAGER, the option
code for the Reverse Distribution Manager Option (TBD3). code for the Reverse Distribution Manager Option (TBD3).
o option-len (16 bits): length in octets of the option-data field as o option-len (16 bits): length in octets of the option-data field as
described in [RFC8415]. described in [RFC8415].
o Supported Transport (16 bits): defines the supported transport by o Supported Transport (16 bits): defines the supported transport by
the RDM. Each bit represents a supported transport, and a DM MAY the RDM (see Section 4.2.1). Each bit represents a supported
indicate the support of multiple modes. The bit for DoT MUST be transport, and a RDM MAY indicate the support of multiple modes.
set. The bit for DNS over TLS [RFC7858] MUST be set.
o Reverse Distribution Manager FQDN (variable): the FQDN of the RDM o Reverse Distribution Manager FQDN (variable): the FQDN of the RDM
encoded as described in section 10 of [RFC8415]. encoded as described in section 10 of [RFC8415].
5. DHCP Behavior 5. DHCPv6 Behavior
5.1. DHCPv6 Server Behavior 5.1. DHCPv6 Server Behavior
Sections 17.2.2 and 18.2 of [RFC8415] govern server operation in Sections 17.2.2 and 18.2 of [RFC8415] govern server operation in
regards to option assignment. As a convenience to the reader, we regards to option assignment. As a convenience to the reader, we
mention here that the server will send option foo only if configured mention here that the server will send option foo only if configured
with specific values for foo and if the client requested it. In with specific values for foo and if the client requested it. In
particular, when configured the DHCP Server sends the Registered particular, when configured the DHCPv6 server sends the Registered
Homenet Domain Option, Distribution Manager Option, the Reverse Homenet Domain Option, Distribution Manager Option, the Reverse
Distribution Manager Option when requested by the DHCPv6 client by Distribution Manager Option when requested by the DHCPv6 client by
including necessary option codes in its ORO. including necessary option codes in its ORO.
5.2. DHCPv6 Client Behavior 5.2. DHCPv6 Client Behavior
The DHCPv6 client sends a ORO with the necessary option codes: The DHCPv6 client includes Registered Homenet Domain Option,
Registered Homenet Domain Option, Distribution Manager Option, the Distribution Manager Option, the Reverse Distribution Manager Option
Reverse Distribution Manager Option. in an ORO as specified in Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5,
18.2.6, and 21.7 of [RFC8415].
Upon receiving a DHCP option described in this document in the Reply Upon receiving a DHCPv6 option described in this document in the
message, the HNA SHOULD proceed as described in Reply message, the HNA SHOULD proceed as described in
[I-D.ietf-homenet-front-end-naming-delegation]. [I-D.ietf-homenet-front-end-naming-delegation].
5.3. DHCPv6 Relay Agent Behavior 5.3. DHCPv6 Relay Agent Behavior
There are no additional requirements for the DHCP Relay agents. There are no additional requirements for the DHCPv6 Relay agents.
6. IANA Considerations 6. IANA Considerations
IANA is requested to assign the following new DHCPv6 Option Codes in IANA is requested to assign the following new DHCPv6 Option Codes in
the registry maintained in: https://www.iana.org/assignments/dhcpv6- the registry maintained in: https://www.iana.org/assignments/dhcpv6-
parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2. parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2.
Value Description Client ORO Singleton Option Value Description Client ORO Singleton Option
TBD1 OPTION_REGISTERED_DOMAIN Yes Yes TBD1 OPTION_REGISTERED_DOMAIN Yes No
TBD2 OPTION_DIST_MANAGER Yes Yes TBD2 OPTION_DIST_MANAGER Yes Yes
TBD3 OPTION_REVERSE_DIST_MANAGER Yes Yes TBD3 OPTION_REVERSE_DIST_MANAGER Yes Yes
IANA is requested to maintain a new number space of Supported IANA is requested to maintain a new number space of Supported
Transport parameter in the Distributed Manager Option Transport parameter in the Distributed Manager Option
(OPTION_DIST_MANAGER) or the Reverse Distribution Manager Server (OPTION_DIST_MANAGER) or the Reverse Distribution Manager Option
Option (OPTION_REVERSE_DIST_MANAGER). The different parameters are (OPTION_REVERSE_DIST_MANAGER). The different parameters are defined
defined in Figure 3 in Section 4.2.1. Future code points are in Figure 3 in Section 4.2.1. Future code points are assigned under
assigned under Specification Required as per [RFC8126]. Specification Required as per [RFC8126].
7. Security Considerations 7. Security Considerations
The security considerations in [RFC2131] and [RFC8415] are to be The security considerations in [RFC8415] are to be considered. The
considered. The use of DHCPv6 options provides a similar level of use of DHCPv6 options provides a similar level of trust as the one
trust as the one used to provide the IP prefix. The link between the used to provide the IP prefix. The link between the HNA and the
HNA and the DHCPv6 server may benefit from additional security for DHCPv6 server may benefit from additional security for example by
example by using [I-D.ietf-dhc-sedhcpv6]. using [I-D.ietf-dhc-sedhcpv6].
8. Acknowledgments 8. Acknowledgments
We would like to thank Marcin Siodelski, Bernie Volz and Ted Lemon We would like to thank Marcin Siodelski, Bernie Volz and Ted Lemon
for their comments on the design of the DHCPv6 options. We would for their comments on the design of the DHCPv6 options. We would
also like to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti also like to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti
for their remarks on the architecture design. The designed solution for their remarks on the architecture design. The designed solution
has been largely been inspired by Mark Andrews's document has been largely been inspired by Mark Andrews's document
[I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We
also thank Ray Hunter for its reviews, its comments and for also thank Ray Hunter for its reviews, its comments and for
skipping to change at page 8, line 46 skipping to change at page 8, line 46
9. Contributors 9. Contributors
The co-authors would like to thank Chris Griffiths and Wouter The co-authors would like to thank Chris Griffiths and Wouter
Cloetens that provided a significant contribution in the early Cloetens that provided a significant contribution in the early
versions of the document. versions of the document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [I-D.ietf-homenet-front-end-naming-delegation]
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, Migault, D., Weber, R., Richardson, M., and R. Hunter,
<https://www.rfc-editor.org/info/rfc1034>. "Simple Provisioning of Public Names for Residential
Networks", draft-ietf-homenet-front-end-naming-
delegation-14 (work in progress), April 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
skipping to change at page 10, line 5 skipping to change at page 9, line 42
[I-D.andrews-dnsop-pd-reverse] [I-D.andrews-dnsop-pd-reverse]
Andrews, M., "Automated Delegation of IP6.ARPA reverse Andrews, M., "Automated Delegation of IP6.ARPA reverse
zones with Prefix Delegation", draft-andrews-dnsop-pd- zones with Prefix Delegation", draft-andrews-dnsop-pd-
reverse-02 (work in progress), November 2013. reverse-02 (work in progress), November 2013.
[I-D.ietf-dhc-sedhcpv6] [I-D.ietf-dhc-sedhcpv6]
Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D.
Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work
in progress), February 2017. in progress), February 2017.
[I-D.ietf-homenet-front-end-naming-delegation]
Migault, D., Weber, R., Richardson, M., and R. Hunter,
"Simple Provisioning of Public Names for Residential
Networks", draft-ietf-homenet-front-end-naming-
delegation-14 (work in progress), April 2021.
[I-D.sury-dnsext-cname-dname] [I-D.sury-dnsext-cname-dname]
Sury, O., "CNAME+DNAME Name Redirection", draft-sury- Sury, O., "CNAME+DNAME Name Redirection", draft-sury-
dnsext-cname-dname-00 (work in progress), April 2010. dnsext-cname-dname-00 (work in progress), April 2010.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>.
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
Weil, "IPv6 Home Networking Architecture Principles",
RFC 7368, DOI 10.17487/RFC7368, October 2014,
<https://www.rfc-editor.org/info/rfc7368>.
Appendix A. Scenarios and impact on the End User Appendix A. Scenarios and impact on the End User
This section details various scenarios and discuss their impact on This section details various scenarios and discuss their impact on
the end user. This section is not normative and limits the the end user. This section is not normative and limits the
description of a limited scope of scenarios that are assumed to be description of a limited scope of scenarios that are assumed to be
representative. Many other scenarios may be derived from these. representative. Many other scenarios may be derived from these.
Appendix B. Base Scenario Appendix B. Base Scenario
The base scenario is the one described in Section 3 in which an ISP The base scenario is the one described in Section 3 in which an ISP
manages the DHCP Server, the DM and RDM. manages the DHCPv6 server, the DM and RDM.
The end user subscribes to the ISP (foo), and at subscription time The end user subscribes to the ISP (foo), and at subscription time
registers for example.foo as its Registered Homenet Domain registers for example.foo as its Registered Homenet Domain
example.foo. example.foo.
In this scenario, the DHCP Server, DM and RDM are managed by the ISP In this scenario, the DHCPv6 server, DM and RDM are managed by the
so the DHCP Server and as such can provide authentication credentials ISP so the DHCPv6 server and as such can provide authentication
of the HNA to enable secure authenticated transaction with the DM and credentials of the HNA to enable secure authenticated transaction
the Reverse DM. with the DM and the Reverse DM.
The main advantage of this scenario is that the naming architecture The main advantage of this scenario is that the naming architecture
is configured automatically and transparently for the end user. The is configured automatically and transparently for the end user. The
drawbacks are that the end user uses a Registered Homenet Domain drawbacks are that the end user uses a Registered Homenet Domain
managed by the ISP and that it relies on the ISP naming managed by the ISP and that it relies on the ISP naming
infrastructure. infrastructure.
B.1. Third Party Registered Homenet Domain B.1. Third Party Registered Homenet Domain
This section considers the case when the end user wants its home This section considers the case when the end user wants its home
skipping to change at page 12, line 11 skipping to change at page 12, line 11
no additional configuration is needed anymore. More specifically, no additional configuration is needed anymore. More specifically,
the HNA may be changed, the zone can be updated as in Appendix B the HNA may be changed, the zone can be updated as in Appendix B
without any additional configuration from the end user. without any additional configuration from the end user.
The main advantage of this scenario is that the end user benefits The main advantage of this scenario is that the end user benefits
from the Zero Configuration of the Base Scenario Appendix B. Then, from the Zero Configuration of the Base Scenario Appendix B. Then,
the end user is able to register for its home network an unlimited the end user is able to register for its home network an unlimited
number of domain names provided by an unlimited number of different number of domain names provided by an unlimited number of different
third party providers. The drawback of this scenario may be that the third party providers. The drawback of this scenario may be that the
end user still rely on the ISP naming infrastructure. Note that the end user still rely on the ISP naming infrastructure. Note that the
only case this may be inconvenient is when the DNS Servers provided only case this may be inconvenient is when the DNS servers provided
by the ISPs results in high latency. by the ISPs results in high latency.
B.2. Third Party DNS Infrastructure B.2. Third Party DNS Infrastructure
This scenario considers that the end user uses example.com as a This scenario considers that the end user uses example.com as a
Registered Homenet Domain, and does not want to rely on the Registered Homenet Domain, and does not want to rely on the
authoritative servers provided by the ISP. authoritative servers provided by the ISP.
In this section we limit the outsourcing to the DM and Public In this section we limit the outsourcing to the DM and Public
Authoritative Server(s) to a third party. The Reverse Public Authoritative Server(s) to a third party. The Reverse Public
Authoritative Server(s) and the RDM remain managed by the ISP as the Authoritative Server(s) and the RDM remain managed by the ISP as the
IP prefix is managed by the ISP. IP prefix is managed by the ISP.
Outsourcing to a third party DM can be performed in the following Outsourcing to a third party DM can be performed in the following
ways: ways:
1. Updating the DHCP Server Information. One can imagine a GUI 1. Updating the DHCPv6 server Information. One can imagine a GUI
interface that enables the end user to modify its profile interface that enables the end user to modify its profile
parameters. Again, this configuration update is done once-for- parameters. Again, this configuration update is done once-for-
ever. ever.
2. Upload the configuration of the DM to the HNA. In some cases, 2. Upload the configuration of the DM to the HNA. In some cases,
the provider of the CPE hosting the HNA may be the registrar and the provider of the CE router hosting the HNA may be the
provide the CPE already configured. In other cases, the CPE may registrar and provide the CE router already configured. In other
request the end user to log into the registrar to validate the cases, the CE router may request the end user to log into the
ownership of the Registered Homenet Domain and agree on the registrar to validate the ownership of the Registered Homenet
necessary credentials to secure the communication between the HNA Domain and agree on the necessary credentials to secure the
and the DM. As described in communication between the HNA and the DM. As described in
[I-D.ietf-homenet-front-end-naming-delegation], such settings [I-D.ietf-homenet-front-end-naming-delegation], such settings
could be performed in an almost automatic way as to limit the could be performed in an almost automatic way as to limit the
necessary interactions with the end user. necessary interactions with the end user.
B.3. Multiple ISPs B.3. Multiple ISPs
This scenario considers a HNA connected to multiple ISPs. This scenario considers a HNA connected to multiple ISPs.
Suppose the HNA has been configured each of its interfaces Suppose the HNA has been configured each of its interfaces
independently with each ISPS as described in Appendix B. Each ISP independently with each ISPS as described in Appendix B. Each ISP
skipping to change at page 13, line 20 skipping to change at page 13, line 20
document. document.
If a HNA is not able to handle multiple Registered Homenet Domains, If a HNA is not able to handle multiple Registered Homenet Domains,
the HNA may remain connected to multiple ISP with a single Registered the HNA may remain connected to multiple ISP with a single Registered
Homenet Domain. In this case, one entity is chosen to host the Homenet Domain. In this case, one entity is chosen to host the
Registered Homenet Domain. This entity may be one of the ISP or a Registered Homenet Domain. This entity may be one of the ISP or a
third party. Note that having multiple ISPs can be motivated for third party. Note that having multiple ISPs can be motivated for
bandwidth aggregation, or connectivity fail-over. In the case of bandwidth aggregation, or connectivity fail-over. In the case of
connectivity fail-over, the fail-over concerns the access network and connectivity fail-over, the fail-over concerns the access network and
a failure of the access network may not impact the core network where a failure of the access network may not impact the core network where
the DM Server and Public Authoritative Primaries are hosted. In that the DM and Public Authoritative Primaries are hosted. In that sense,
sense, choosing one of the ISP even in a scenario of multiple ISPs choosing one of the ISP even in a scenario of multiple ISPs may make
may make sense. However, for sake of simplicity, this scenario sense. However, for sake of simplicity, this scenario assumes that a
assumes that a third party has been chosen to host the Registered third party has been chosen to host the Registered Homenet Domain.
Homenet Domain. Configuration is performed as described in Configuration is performed as described in Appendix B.1 and
Appendix B.1 and Appendix B.2. Appendix B.2.
With the configuration described in Appendix B.1, the HNA is expect With the configuration described in Appendix B.1, the HNA is expect
to be able to handle multiple Homenet Registered Domain, as the third to be able to handle multiple Homenet Registered Domain, as the third
party redirect to one of the ISPs Servers. With the configuration party redirect to one of the ISPs servers. With the configuration
described in Appendix B.2, DNS zone are hosted and maintained by the described in Appendix B.2, DNS zone are hosted and maintained by the
third party. A single DNS(SEC) Homenet Zone is built and maintained third party. A single DNS(SEC) Homenet Zone is built and maintained
by the HNA. This latter configuration is likely to match most HNA by the HNA. This latter configuration is likely to match most HNA
implementations. implementations.
The protocol and DHCPv6 options described in this document are fully The protocol and DHCPv6 options described in this document are fully
compatible with a HNA connected to multiple ISPs. To configure or compatible with a HNA connected to multiple ISPs. To configure or
not and how to configure the HNA depends on the HNA facilities. not and how to configure the HNA depends on the HNA facilities.
Appendix B and Appendix B.1 require the HNA to handle multiple Appendix B and Appendix B.1 require the HNA to handle multiple
Registered Homenet Domain, whereas Appendix B.2 does not have such Registered Homenet Domain, whereas Appendix B.2 does not have such
 End of changes. 50 change blocks. 
151 lines changed or deleted 149 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/