rfc9527.original   rfc9527.txt 
Homenet D. Migault Internet Engineering Task Force (IETF) D. Migault
Internet-Draft Ericsson Request for Comments: 9527 Ericsson
Intended status: Standards Track R. Weber Category: Standards Track R. Weber
Expires: 4 May 2023 Akamai ISSN: 2070-1721 Akamai
T. Mrugalski T. Mrugalski
Internet Systems Consortium, Inc. ISC
31 October 2022 January 2024
DHCPv6 Options for Home Network Naming Authority DHCPv6 Options for the Homenet Naming Authority
draft-ietf-homenet-naming-architecture-dhc-options-24
Abstract Abstract
This document defines DHCPv6 options so a Homenet Naming Authority This document defines DHCPv6 options so that a Homenet Naming
(HNA) can automatically proceed to the appropriate configuration and Authority (HNA) can automatically set the appropriate configuration
outsource the authoritative naming service for the home network. In and outsource the authoritative naming service for the home network.
most cases, the outsourcing mechanism is transparent for the end In most cases, the outsourcing mechanism is transparent for the end
user. user.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 4 May 2023. 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 Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Procedure Overview . . . . . . . . . . . . . . . . . . . . . 4 3. Procedure Overview
4. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . . . 5 4. DHCPv6 Options
4.1. Registered Homenet Domain Option . . . . . . . . . . . . 5 4.1. Registered Homenet Domain Option
4.2. Forward Distribution Manager Option . . . . . . . . . . . 5 4.2. Forward Distribution Manager Option
4.3. Reverse Distribution Manager Server Option . . . . . . . 7 4.3. Reverse Distribution Manager Server Option
4.4. Supported Transport . . . . . . . . . . . . . . . . . . . 7 4.4. Supported Transport
5. DHCPv6 Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 5. DHCPv6 Behavior
5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 8 5.1. DHCPv6 Server Behavior
5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 8 5.2. DHCPv6 Client Behavior
5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 8 5.3. DHCPv6 Relay Agent Behavior
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations
6.1. DHCPv6 Option Codes . . . . . . . . . . . . . . . . . . . 8 6.1. DHCPv6 Option Codes
6.2. Supported Transport parameter . . . . . . . . . . . . . . 9 6.2. Supported Transport parameter
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. References
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Scenarios and Impact on the End User
10.2. Informative References . . . . . . . . . . . . . . . . . 11 A.1. Base Scenario
Appendix A. Scenarios and impact on the End User . . . . . . . . 12 A.2. Third-Party Registered Homenet Domain
A.1. Base Scenario . . . . . . . . . . . . . . . . . . . . . . 12 A.3. Third-Party DNS Infrastructure
A.2. Third Party Registered Homenet Domain . . . . . . . . . . 12 A.4. Multiple ISPs
A.3. Third Party DNS Infrastructure . . . . . . . . . . . . . 13 Acknowledgments
A.4. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 14 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses
1. 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
[I-D.ietf-homenet-front-end-naming-delegation].
2. Introduction 1. Introduction
[I-D.ietf-homenet-front-end-naming-delegation] specifies how an [RFC9526] specifies how an entity designated as the Homenet Naming
entity designated as the Homenet Naming Authority (HNA) outsources a Authority (HNA) outsources a Public Homenet Zone to a DNS Outsourcing
Public Homenet Zone to an DNS Outsourcing Infrastructure (DOI). Infrastructure (DOI).
This document describes how a network can provision the HNA with a This document describes how a network can provision the HNA with a
specific DOI. This could be particularly useful for a DOI partly specific DOI. This could be particularly useful for a DOI partly
managed by an ISP, or to make home networks resilient to HNA managed by an ISP or to make home networks resilient to HNA
replacement. The ISP delegates an IP prefix to the home network as replacement. The ISP delegates an IP prefix and the associated
well as the associated reverse zone. The ISP is thus aware of the reverse zone to the home network. The ISP is thus aware of the owner
owner of that IP prefix, and as such becomes a natural candidate for of that IP prefix and, as such, becomes a natural candidate for
hosting the Homenet Reverse Zone - that is the Reverse Distribution hosting the Homenet Reverse Zone -- that is, the Reverse Distribution
Manager (RDM) and potentially the Reverse Public Authoritative Manager (RDM) and potentially the Reverse Public Authoritative
Servers. Servers.
In addition, ISPs often identify the line of the home network with a In addition, ISPs often identify the line of the home network with a
name. Such name is used for their internal network management name. Such name is used for their internal network management
operations and is not a name the home network owner has registered operations and is not a name the home network owner has registered
to. ISPs may leverage such infrastructure and provide the home to. ISPs may leverage such infrastructure and provide the home
network with a specific domain name designated as per network with a specific domain name designated per a Registered
[I-D.ietf-homenet-front-end-naming-delegation] a Homenet Registered Homenet Domain [RFC9526]. Similarly to the reverse zone, ISPs are
Domain. Similarly to the reverse zone, ISPs are aware of who owns aware of who owns that domain name and may become a natural candidate
that domain name and may become a natural candidate for hosting the for hosting the Homenet Zone -- that is, the Distribution Manager
Homenet Zone - that is the Distribution Manager (DM) and the Public (DM) and the Public Authoritative Servers.
Authoritative Servers.
This document describes DHCPv6 options that enable an ISP to provide This document describes DHCPv6 options that enable an ISP to provide
the necessary parameters to the HNA, to proceed. More specifically, the necessary parameters to the HNA to proceed. More specifically,
the ISP provides the Registered Homenet Domain, necessary information the ISP provides the Registered Homenet Domain and the necessary
on the DM and the RDM so the HNA can manage and upload the Public information on the DM and the RDM so the HNA can manage and upload
Homenet Zone and the Reverse Public Homenet Zone as described in the Public Homenet Zone and the Reverse Public Homenet Zone as
[I-D.ietf-homenet-front-end-naming-delegation]. described in [RFC9526].
The use of DHCPv6 options may make 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 - when provisioned via DHCP. the one used to provide the IP prefix, when 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 3. Procedure Overview
This section illustrates how a HNA receives the necessary information This section illustrates how an HNA receives the necessary
via DHCPv6 options to outsource its authoritative naming service to information via DHCPv6 options to outsource its authoritative naming
the DOI. For the sake of simplicity, and similarly to service to the DOI. For the sake of simplicity, and similarly to
[I-D.ietf-homenet-front-end-naming-delegation], this section assumes [RFC9526], this section assumes that the HNA and the home network
that the HNA and the home network DHCPv6 client are colocated on the DHCPv6 client are colocated on the Customer Premises Equipment (CPE)
Customer Edge (CPE) router [RFC7368]. Note also that this is not router [RFC7368]. Also, note that this is not mandatory, and the
mandatory and the DHCPv6 client may instruct remotely the HNA with a DHCPv6 client may remotely instruct the HNA with a protocol that will
protocol that will be standardized in the future. In addition, this be standardized in the future. In addition, this section assumes
section assumes the responsible entity for the DHCPv6 server is that the responsible entity for the DHCPv6 server is provisioned with
provisioned with the DM and RDM information - associated with the the DM and RDM information, which is associated with the requested
requested Registered Homenet Domain . This means a Registered Homenet Registered Homenet Domain. This means a Registered Homenet Domain
Domain can be associated with the DHCPv6 client. can be associated with the DHCPv6 client.
This scenario is believed to be the most popular scenario. This This scenario is believed to be the most popular scenario. This
document does not ignore scenarios where the DHCPv6 server does not document does not ignore scenarios where the DHCPv6 server does not
have privileged relations with the DM or RDM. These cases are have privileged relations with the DM or RDM. These cases are
discussed in Appendix A. Such scenarios do not necessarily require discussed in Appendix A. Such scenarios do not necessarily require
configuration for the end user and can also be zero-config. configuration for the end user and can also be zero configuration.
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. The DHCPv6 client is configured to include Homenet Reverse Zone. The DHCPv6 client is configured to include
in its Option Request Option (ORO) the Registered Homenet Domain in its Option Request Option (ORO) the Registered Homenet Domain
Option (OPTION_REGISTERED_DOMAIN), the Forward Distribution Option (OPTION_REGISTERED_DOMAIN), the Forward Distribution
Manager Option (OPTION_FORWARD_DIST_MANAGER) and the Reverse Manager Option (OPTION_FORWARD_DIST_MANAGER), and the Reverse
Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) option Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) option
codes. codes.
2. The DHCPv6 server responds to the DHCPv6 client with the 2. The DHCPv6 server responds to the DHCPv6 client with the
requested DHCPv6 options based on the identified homenet. The requested DHCPv6 options based on the identified homenet. The
DHCPv6 client passes the information to the HNA. DHCPv6 client passes the information to the HNA.
3. The HNA is authenticated (see Section "Securing the Control 3. The HNA is authenticated (see "Securing the Control Channel"
Channel" of [I-D.ietf-homenet-front-end-naming-delegation]) by (Section 6.6) of [RFC9526]) by the DM and the RDM. The HNA
the DM and the RDM. The HNA builds the Homenet Zone (or the builds the Homenet Zone (or the Homenet Reverse Zone) and
Homenet Reverse Zone) and proceed as described in proceeds as described in [RFC9526]. The DHCPv6 options provide
[I-D.ietf-homenet-front-end-naming-delegation]. The DHCPv6 the necessary non-optional parameters described in Appendix B of
options provide the necessary non optional parameters described [RFC9526]. The HNA may complement the configurations with
in Appendix B of [I-D.ietf-homenet-front-end-naming-delegation]. additional parameters via means not yet defined. Appendix B of
The HNA may complement the configurations with additional [RFC9526] describes such parameters that may take some specific
parameters via means not yet defined. Appendix B of non-default value.
[I-D.ietf-homenet-front-end-naming-delegation] describes such
parameters that may take some specific non default value.
4. DHCPv6 Option 4. DHCPv6 Options
This section details the payload of the DHCPv6 options following the This section details the payload of the DHCPv6 options following the
guidelines of [RFC7227]. guidelines of [RFC7227].
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 with the home network. fully qualified domain name (FQDN) associated with 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
* option-code (16 bits): OPTION_REGISTERED_DOMAIN, the option code option-code (16 bits): OPTION_REGISTERED_DOMAIN; the option code for
for the Registered Homenet Domain (TBD1). the Registered Homenet Domain (145).
* option-len (16 bits): length in octets of the Registered Homenet option-len (16 bits): Length in octets of the Registered Homenet
Domain field as described in [RFC8415]. Domain field as described in [RFC8415].
* Registered Homenet Domain (variable): the FQDN registered for the 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. Forward Distribution Manager Option 4.2. Forward Distribution Manager Option
The Forward Distributed Manager Option (OPTION_FORWARD_DIST_MANAGER) The Forward Distribution Manager Option (OPTION_FORWARD_DIST_MANAGER)
provides the HNA with the FQDN of the DM as well as the transport 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 protocols for the communication between the HNA and the DM. As
opposed to IP addresses, the FQDN requires a DNS resolution before opposed to IP addresses, the FQDN requires a DNS resolution before
establishing the communication between the HNA and the DM. However, establishing the communication between the HNA and the DM. However,
the use of a FQDN provides multiple advantages over IP addresses. the use of an FQDN provides multiple advantages over IP addresses.
Firstly, it makes the DHCPv6 Option easier to parse and smaller - Firstly, it makes the DHCPv6 option easier to parse and smaller,
especially when IPv4 and IPv6 addresses are expected to be provided. especially when IPv4 and IPv6 addresses are expected to be provided.
Then the FQDN can reasonably be seen as a more stable identifier than Then, the FQDN can reasonably be seen as a more stable identifier
IP addresses, as well as a pointer to additional information that may than IP addresses as well as a pointer to additional information that
be useful, in the future, to establish the communication between the may be useful, in the future, to establish the communication between
HNA and the DM. 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_FORWARD_DIST_MANAGER | option-len | | OPTION_FORWARD_DIST_MANAGER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Transport | | | Supported Transport | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Distribution Manager FQDN / / Distribution Manager FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Forward Distribution Manager Option Figure 2: Forward Distribution Manager Option
* option-code (16 bits): OPTION_FORWARD_DIST_MANAGER, the option option-code (16 bits): OPTION_FORWARD_DIST_MANAGER; the option code
code for the Forward Distribution Manager Option (TBD2). for the Forward Distribution Manager Option (146).
* option-len (16 bits): length in octets of the enclosed data as option-len (16 bits): Length in octets of the enclosed data as
described in [RFC8415]. described in [RFC8415].
* Supported Transport (16 bits): defines the supported transport by Supported Transport (16 bits): Defines the Supported Transport by
the DM (see Section 4.4). Each bit represents a supported the DM (see Section 4.4). Each bit represents a supported
transport, and a DM MAY indicate the support of multiple modes. transport, and a DM MAY indicate the support of multiple modes.
The bit for DNS over mutually authenticated TLS (DomTLS) MUST be The bit for DNS over mutually authenticated TLS (DomTLS) MUST be
set. set.
* Distribution Manager FQDN (variable): the FQDN of the DM encoded Distribution Manager FQDN (variable): The FQDN of the DM encoded as
as described in Section 10 of [RFC8415]. described in Section 10 of [RFC8415].
It is worth noticing that the DHCP Option specifies the Supported It is worth noting that the DHCPv6 option specifies the Supported
Transport without specifying any explicit port. Unless the HNA and Transport without specifying any explicit port. Unless the HNA and
the DM have agreed on using a specific port - for example by the DM have agreed on using a specific port -- for example, by
configuration, or any out of band mechanism -, the default port is configuration, or any out-of-band mechanism -- the default port is
used and must be specified. The specification of such default port used and must be specified. The specification of such default port
may be defined in the specification of the designated Supported may be defined in the specification of the designated Supported
Transport or in any other document. In the case of DNS over mutually Transport or in any other document. In the case of DomTLS, the
authenticated TLS (DomTLS), the default port value is 853 as per DNS default port value is 853 per DNS over TLS [RFC7858] and DNS Zone
over TLS [RFC7858] and DNS Zone Transfer over TLS [RFC9103]. Transfer over TLS [RFC9103].
The need to associate in the DHCP Option the port value to each The need to associate the port value to each Supported Transport in
Supported Transport has been balanced with the difficulty of handling the DHCPv6 option has been balanced with the difficulty of handling a
a list of tuples ( transport, port ) as well as the possibility to list of tuples (transport, port) and the possibility of using a
use a dedicated IP address for the DM in case the default port was dedicated IP address for the DM in case the default port is already
already in use. in use.
4.3. Reverse Distribution Manager Server Option 4.3. Reverse Distribution Manager Server Option
The Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) The Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER)
provides the HNA with the FQDN of the DM as well as the transport provides the HNA with the FQDN of the DM as well as the transport
protocols for the communication between the HNA and the DM. protocols for the 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_REVERSE_DIST_MANAGER | option-len | | OPTION_REVERSE_DIST_MANAGER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Transport | | | Supported Transport | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Reverse Distribution Manager FQDN / / Reverse Distribution Manager FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Reverse Distribution Manager Option Figure 3: Reverse Distribution Manager Option
* option-code (16 bits): OPTION_REVERSE_DIST_MANAGER, the option option-code (16 bits): OPTION_REVERSE_DIST_MANAGER; the option code
code for the Reverse Distribution Manager Option (TBD3). for the Reverse Distribution Manager Option (147).
* option-len (16 bits): length in octets of the option-data field as option-len (16 bits): Length in octets of the option-data field as
described in [RFC8415]. described in [RFC8415].
* Supported Transport (16 bits): defines the supported transport by Supported Transport (16 bits): Defines the Supported Transport by
the RDM (see Section 4.4). Each bit represents a supported the RDM (see Section 4.4). Each bit represents a supported
transport, and a RDM MAY indicate the support of multiple modes. transport, and an RDM MAY indicate the support of multiple modes.
The bit for DNS over mutually authenticated TLS [RFC7858] MUST be The bit for DomTLS [RFC7858] MUST be set.
set.
* Reverse Distribution Manager FQDN (variable): the FQDN of the RDM 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].
For the port number associated to the Supported Transport, the same For the port number associated to the Supported Transport, the same
considerations as described in Section 4.2 holds. considerations as described in Section 4.2 apply.
4.4. Supported Transport 4.4. Supported Transport
The Supported Transport field of the DHCPv6 option indicates the The Supported Transport field of the DHCPv6 option indicates the
supported transport protocols. Each bit represents a specific Supported Transport protocols. Each bit represents a specific
transport mechanism. A bit sets to 1 indicates the associated transport mechanism. A bit set 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 4 and Section 6. as described in Table 2.
Bit Position | Transport Protocol | Mnemonic | Reference DNS over mutually authenticated TLS (DomTLS): Indicates the support
left to right| Description | | of DNS over TLS [RFC7858] and DNS Zone Transfer over TLS [RFC9103]
-------------+--------------------+-----------+----------- as described in [RFC9526].
0 | DNS over mutually | DomTLS | This-RFC
| authenticated TLS | |
1-15 | unallocated | - | -
Figure 4: Supported Transport As an example, the Supported Transport field expressing support for
DomTLS looks as follows and has a numeric value of 0x0001:
DNS over mutually authenticated TLS (DomTLS): indicates the support 0 1
of DNS over TLS [RFC7858], DNS Zone Transfer over TLS [RFC9103] as 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
described in [I-D.ietf-homenet-front-end-naming-delegation]. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| must be zero |1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. DHCPv6 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 Section 18.3 of [RFC8415] governs server operation regarding option
regarding option assignment. As a convenience to the reader, we assignment. As a convenience to the reader, we mention here that the
mention here that the server will send option foo only if configured server will send option foo only if configured with specific values
with specific values for foo and if the client requested it. In for foo and if the client requested it. In particular, when
particular, when configured the DHCPv6 server sends the Registered configured, the DHCPv6 server sends the Registered Homenet Domain
Homenet Domain Option, Distribution Manager Option, the Reverse Option, Distribution Manager Option, and Reverse Distribution Manager
Distribution Manager Option when requested by the DHCPv6 client by Option when requested by the DHCPv6 client by including necessary
including necessary option codes in its ORO. option codes in its ORO.
5.2. DHCPv6 Client Behavior 5.2. DHCPv6 Client Behavior
The DHCPv6 client includes Registered Homenet Domain Option, The DHCPv6 client includes the Registered Homenet Domain Option,
Distribution Manager Option, the Reverse Distribution Manager Option Distribution Manager Option, and Reverse Distribution Manager Option
in an ORO as specified in Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, in an ORO as specified in Sections 18.2 and 21.7 of [RFC8415].
18.2.6, and 21.7 of [RFC8415].
Upon receiving a DHCPv6 option described in this document in the Upon receiving a DHCPv6 option, as described in this document, in the
Reply message, the HNA SHOULD proceed as described in Reply message, the HNA SHOULD proceed as described in [RFC9526].
[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 DHCPv6 Relay agents. There are no additional requirements for the DHCPv6 Relay agents.
6. IANA Considerations 6. IANA Considerations
6.1. DHCPv6 Option Codes 6.1. DHCPv6 Option Codes
IANA is requested to assign the following new DHCPv6 Option Codes in IANA has assigned the following new DHCPv6 Option Codes in the
the registry maintained in: https://www.iana.org/assignments/dhcpv6- "Option Codes" registry maintained at
parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2. <https://www.iana.org/assignments/dhcpv6-parameters>.
Value Description Client ORO Singleton Option Reference +=====+=============================+======+===========+===========+
TBD1 OPTION_REGISTERED_DOMAIN Yes No [This-RFC] Section 4.1 |Value| Description |Client| Singleton | Reference |
TBD2 OPTION_FORWARD_DIST_MANAGER Yes Yes [This-RFC] Section 4.2 | | |ORO | Option | |
TBD3 OPTION_REVERSE_DIST_MANAGER Yes Yes [This-RFC] Section 4.3 +=====+=============================+======+===========+===========+
|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 6.2. Supported Transport parameter
IANA is requested to maintain a new registry of Supported Transport IANA has created and maintains a new registry called "Supported
parameter in the Distributed Manager Option 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_FORWARD_DIST_MANAGER) or the Reverse Distribution Manager
Option (OPTION_REVERSE_DIST_MANAGER). The different parameters are Option (OPTION_REVERSE_DIST_MANAGER). The different parameters are
defined in Figure 4 in Section 4.4. defined in Table 2 (Section 6.2).
The Name of the registry is: Supported Transport parameter
The registry description is: 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.
The parent grouping is Dynamic Host Configuration Protocol for IPv6
(DHCPv6) at https://www.iana.org/assignments/dhcpv6-parameters/
dhcpv6-parameters.xhtml#dhcpv6-parameters-2.
New entry MUST specify the bit position, the Transport Protocol The Supported Transport field of the DHCPv6 option is a two-octet
Description a Mnemonic and a Reference as defined in Figure 5. field that indicates the Supported Transport protocols. Each bit
represents a specific transport mechanism.
The initial registry is as specified in Figure 5. New entries MUST specify the bit position, the transport protocol
description, a mnemonic, and a reference as shown in Table 2.
Changes of the format or policies of the registry is left to the IETF Changes to the format or policies of the registry are managed by the
via the IESG. IETF via the IESG.
Future code points are assigned under RFC Required as per [RFC8126]. Future code points are assigned under RFC Required per [RFC8126].
The initial registry is as specified in Table 2 below.
Bit Position | Transport Protocol | Mnemonic | Reference +======================+====================+==========+===========+
left to right| Description | | | Bit Position (least | Transport Protocol | Mnemonic | Reference |
-------------+--------------------+-----------+----------- | to most significant) | Description | | |
0 | DNS over mutually | DomTLS | This-RFC +======================+====================+==========+===========+
| authenticated TLS | | | 0 | DNS over mutually | DomTLS | RFC 9527 |
1-15 | unallocated | - | - | | authenticated TLS | | |
+----------------------+--------------------+----------+-----------+
| 1-15 | Unassigned | | |
+----------------------+--------------------+----------+-----------+
Figure 5: Supported Transport Table 2: Supported Transport Registry
7. Security Considerations 7. Security Considerations
The security considerations in [RFC8415] are to be considered. The The security considerations in [RFC8415] are to be considered. The
trust associated with the information carried by the DHCPv6 Options trust associated with the information carried by the DHCPv6 options
described in this document is similar to the one associated with the described in this document is similar to the one associated with the
IP prefix - when configured via DHCPv6. IP prefix, when configured via DHCPv6.
In some cases, the ISP MAY identify the HNA by its wire line, that is
to say physically which may not require to rely on TLS to
authenticate the HNA. As TLS is mandatory to be used, it is expected
the HNA is provisioned with a certificate. In some cases, the HNA
may use a self signed certificate.
8. Acknowledgments
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 been inspired by Mark Andrews's document
[I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We
also thank Ray Hunter and Michael Richardson for its reviews, its
comments and for suggesting an appropriated terminology.
9. Contributors
The co-authors would like to thank Chris Griffiths and Wouter
Cloetens that provided a significant contribution in the early
versions of the document.
10. References 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.
10.1. Normative References 8. References
[I-D.ietf-homenet-front-end-naming-delegation] 8.1. Normative References
Migault, D., Weber, R., Richardson, M., and R. Hunter,
"Simple Provisioning of Public Names for Residential
Networks", Work in Progress, Internet-Draft, draft-ietf-
homenet-front-end-naming-delegation-22, 31 October 2022,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
ietf-homenet-front-end-naming-delegation/>.
[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>.
[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>.
skipping to change at page 11, line 30 skipping to change at line 456
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
[RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. [RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.
Mankin, "DNS Zone Transfer over TLS", RFC 9103, Mankin, "DNS Zone Transfer over TLS", RFC 9103,
DOI 10.17487/RFC9103, August 2021, DOI 10.17487/RFC9103, August 2021,
<https://www.rfc-editor.org/info/rfc9103>. <https://www.rfc-editor.org/info/rfc9103>.
10.2. Informative References [RFC9526] Migault, D., Weber, R., Richardson, M., and R. Hunter,
"Simple Provisioning of Public Names for Residential
Networks", RFC 9526, DOI 10.17487/RFC9526, January 2024,
<https://www.rfc-editor.org/info/rfc9526>.
[I-D.andrews-dnsop-pd-reverse] 8.2. Informative References
[CNAME-PLUS-DNAME]
Surý, O., "CNAME+DNAME Name Redirection", Work in
Progress, Internet-Draft, draft-sury-dnsop-cname-plus-
dname-01, 15 July 2018,
<https://datatracker.ietf.org/doc/html/draft-sury-dnsop-
cname-plus-dname-01>.
[PD-REVERSE]
Andrews, M., "Automated Delegation of IP6.ARPA reverse Andrews, M., "Automated Delegation of IP6.ARPA reverse
zones with Prefix Delegation", Work in Progress, Internet- zones with Prefix Delegation", Work in Progress, Internet-
Draft, draft-andrews-dnsop-pd-reverse-02, 4 November 2013, Draft, draft-andrews-dnsop-pd-reverse-02, 5 November 2013,
<https://www.ietf.org/archive/id/draft-andrews-dnsop-pd- <https://datatracker.ietf.org/doc/html/draft-andrews-
reverse-02.txt>. dnsop-pd-reverse-02>.
[I-D.sury-dnsext-cname-dname]
Sury, O., "CNAME+DNAME Name Redirection", Work in
Progress, Internet-Draft, draft-sury-dnsext-cname-dname-
00, 15 April 2010, <https://www.ietf.org/archive/id/draft-
sury-dnsext-cname-dname-00.txt>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>. <https://www.rfc-editor.org/info/rfc2181>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
skipping to change at page 12, line 19 skipping to change at line 499
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options", S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<https://www.rfc-editor.org/info/rfc7227>. <https://www.rfc-editor.org/info/rfc7227>.
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
Weil, "IPv6 Home Networking Architecture Principles", Weil, "IPv6 Home Networking Architecture Principles",
RFC 7368, DOI 10.17487/RFC7368, October 2014, RFC 7368, DOI 10.17487/RFC7368, October 2014,
<https://www.rfc-editor.org/info/rfc7368>. <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 appendix details various scenarios and discuss their impact on This appendix details various scenarios and discusses their impact on
the end user. This appendix is not normative and limits the the end user. This appendix 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.
A.1. Base Scenario A.1. Base Scenario
The base scenario is the one described in Section 3 in which an ISP The base scenario, as described in Section 3, is one in which an ISP
manages the DHCPv6 server, the DM and RDM. manages the DHCPv6 server, 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 foo.example as its Registered Homenet Domain it registers foo.example as its Registered Homenet Domain.
foo.example.
In this scenario, the DHCPv6 server, DM and RDM are managed by the In this scenario, the DHCPv6 server, DM, and RDM are managed by the
ISP so the DHCPv6 server and as such can provide authentication ISP, so the DHCPv6 server and such can provide authentication
credentials of the HNA to enable secure authenticated transaction credentials of the HNA to enable secure authenticated transaction
with the DM and 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.
A.2. Third Party Registered Homenet Domain A.2. Third-Party Registered Homenet Domain
This appendix considers the case when the end user wants its home This appendix considers the case where the end user wants its home
network to use example.com not managed by her ISP (foo) as a network to use example.com but does not want it to be managed by the
Registered Homenet Domain. This appendix still considers the ISP ISP (foo) as a Registered Homenet Domain, and the ISP manages the
manages the home network and still provides foo.example as a home network and still provides foo.example as a Registered Homenet
Registered Homenet Domain. Domain.
When the end user buys the domain name example.com, it may request to When the end user buys the domain name example.com, it may request to
redirect the name example.com to foo.example using static redirection redirect example.com to foo.example using static redirection with
with CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME CNAME [RFC1034] [RFC2181], DNAME [RFC6672], or CNAME+DNAME
[I-D.sury-dnsext-cname-dname]. The only information the end user [CNAME-PLUS-DNAME]. The only information the end user needs to know
needs to know is the domain name assigned by the ISP. Once the is the domain name assigned by the ISP. Once the redirection has
redirection has been configured, the HNA may be changed, the zone can been configured, the HNA may be changed, and the zone can be updated
be updated as in Appendix A.1 without any additional configuration as described in Appendix A.1 without any additional configuration
from the end user. 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 A.1. Then, from the zero configuration of the base scenario in Appendix A.1.
the end user is able to register for its home network an unlimited Then, the end user is able to register an unlimited number of domain
number of domain names provided by an unlimited number of different names provided by an unlimited number of different third-party
third party providers. The drawback of this scenario may be that the providers for its home network. The drawback of this scenario may be
end user still rely on the ISP naming infrastructure. Note that the that the end user still needs to rely on the ISP naming
only case this may be inconvenient is when the DNS servers provided infrastructure. Note that this may be inconvenient in the case where
by the ISPs results in high latency. the DNS servers provided by the ISPs result in high latency.
A.3. Third Party DNS Infrastructure A.3. Third-Party DNS Infrastructure
This scenario considers that the end user uses example.com as a This scenario involves the end user using example.com as a Registered
Registered Homenet Domain, and does not want to rely on the Homenet Domain and not relying on the authoritative servers provided
authoritative servers provided by the ISP. by the ISP.
In this appendix we limit the outsourcing to the DM and Public 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) 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 DHCPv6 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 only needs to be
ever. performed one time.
2. Upload the configuration of the DM to the HNA. In some cases, 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 the provider of the CPE router hosting the HNA may be the
registrar and provide the CPE router already configured. In registrar, and the registrar may provide the CPE router already
other cases, the CPE router may request the end user to log into configured. In other cases, the CPE router may request the end
the registrar to validate the ownership of the Registered Homenet user to log into the registrar to validate the ownership of the
Domain and agree on the necessary credentials to secure the Registered Homenet Domain and agree on the necessary credentials
communication between the HNA and the DM. As described in to secure the communication between the HNA and the DM. As
[I-D.ietf-homenet-front-end-naming-delegation], such settings described in [RFC9526], such settings could be performed in an
could be performed in an almost automatic way as to limit the almost automatic way as to limit the necessary interactions with
necessary interactions with the end user. the end user.
A.4. Multiple ISPs A.4. Multiple ISPs
This scenario considers a HNA connected to multiple ISPs. This scenario involves an HNA connected to multiple ISPs.
Suppose the HNA has been configured each of its interfaces Suppose the HNA has configured each of its interfaces independently
independently with each ISPS as described in Appendix A.1. Each ISP with each ISP as described in Appendix A.1. Each ISP provides a
provides a different Registered Homenet Domain. different Registered Homenet Domain.
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 with multiple compatible with an HNA connected to multiple ISPs with multiple
Registered Homenet Domains. However, the HNA should be able to Registered Homenet Domains. However, the HNA should be able to
handle different Registered Homenet Domains. This is an handle different Registered Homenet Domains. This is an
implementation issue which is outside the scope of the current implementation issue, which is outside the scope of this document.
document.
If a HNA is not able to handle multiple Registered Homenet Domains, If an 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 ISPs with a single
Homenet Domain. In this case, one entity is chosen to host the Registered Homenet Domain. In this case, one entity is chosen to
Registered Homenet Domain. This entity may be one of the ISP or a host the Registered Homenet Domain. This entity may be an ISP or a
third party. Note that having multiple ISPs can be motivated for third party. Note that having multiple ISPs can be motivation for
bandwidth aggregation, or connectivity fail-over. In the case of bandwidth aggregation or connectivity failover. In the case of
connectivity fail-over, the fail-over concerns the access network and connectivity failover, the failover 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 and Public Authoritative Primaries are hosted. In that sense, the DM and Public Authoritative Primaries are hosted. In that sense,
choosing one of the ISP even in a scenario of multiple ISPs may make choosing one of the ISPs even in a scenario of multiple ISPs may make
sense. However, for sake of simplicity, this scenario assumes that a sense. However, for the sake of simplicity, this scenario assumes
third party has been chosen to host the Registered Homenet Domain. that a third party has been chosen to host the Registered Homenet
Configuration is performed as described in Appendix A.2 and Domain. Configuration is performed as described in Appendices A.2
Appendix A.3. and A.3.
With the configuration described in Appendix A.2, the HNA is expected With the configuration described in Appendix A.2, the HNA is expected
to be able to handle multiple Homenet Registered Domain, as the third to be able to handle multiple Registered Homenet Domains as the
party redirect to one of the ISPs servers. With the configuration third-party redirect to one of the ISP's servers. With the
described in Appendix A.3, DNS zone are hosted and maintained by the configuration described in Appendix A.3, DNS zones are hosted and
third party. A single DNS(SEC) Homenet Zone is built and maintained maintained by the third party. A single DNS(SEC) Homenet Zone is
by the HNA. This latter configuration is likely to match most HNA built and maintained by the HNA. This latter configuration is likely
implementations. to match most HNA 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 an HNA connected to multiple ISPs. Whether to
not and how to configure the HNA depends on the HNA facilities. configure the HNA or not, and how to configure the HNA, depends on
Appendix A.1 and Appendix A.2 require the HNA to handle multiple the HNA facilities. Appendices A.1 and A.2 require the HNA to handle
Registered Homenet Domain, whereas Appendix A.3 does not have such multiple Registered Homenet Domains, whereas Appendix A.3 does not
requirement. have such a requirement.
Acknowledgments
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.
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 Authors' Addresses
Daniel Migault Daniel Migault
Ericsson Ericsson
8275 Trans Canada Route 8275 Trans Canada Route
Saint Laurent, QC 4S 0B6 Saint Laurent QC 4S 0B6
Canada Canada
Email: daniel.migault@ericsson.com Email: daniel.migault@ericsson.com
Ralf Weber Ralf Weber
Akamai Akamai
Email: ralf.weber@akamai.com Email: ralf.weber@akamai.com
Tomek Mrugalski Tomek Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
950 Charter Street PO Box 360
Redwood City, 94063 Newmarket, NH 03857
United States of America United States of America
Email: tomasz.mrugalski@gmail.com Email: tomasz.mrugalski@gmail.com
 End of changes. 99 change blocks. 
345 lines changed or deleted 344 lines changed or added

This html diff was produced by rfcdiff 1.48.