draft-ietf-homenet-naming-architecture-dhc-options-09.txt   draft-ietf-homenet-naming-architecture-dhc-options-10.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: 11 September 2021 Akamai Expires: October 3, 2021 Akamai
T. Mrugalski T. Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
C. Griffiths C. Griffiths
W. Cloetens W. Cloetens
Deutsche Telekom Deutsche Telekom
10 March 2021 April 01, 2021
DHCPv6 Options for Home Network Naming Authority DHCPv6 Options for Home Network Naming Authority
draft-ietf-homenet-naming-architecture-dhc-options-09 draft-ietf-homenet-naming-architecture-dhc-options-10
Abstract Abstract
This document defines DHCPv6 options so any 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
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 September 2021. This Internet-Draft will expire on October 3, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
4. Payload Description . . . . . . . . . . . . . . . . . . . . . 4 4. Payload Description . . . . . . . . . . . . . . . . . . . . . 4
4.1. Registered Homenet Domain Option . . . . . . . . . . . . 5 4.1. Registered Homenet Domain Option . . . . . . . . . . . . 5
4.2. Distribution Master Option . . . . . . . . . . . . . . . 6 4.2. Distribution Master Option . . . . . . . . . . . . . . . 5
4.2.1. Supported Transport . . . . . . . . . . . . . . . . . 6 4.2.1. Supported Transport . . . . . . . . . . . . . . . . . 6
4.3. Reverse Distribution Master Server Option . . . . . . . . 7 4.3. Reverse Distribution Master Server Option . . . . . . . . 6
5. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 5. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7 5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7
5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 8 5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 7
5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 8 5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations" . . . . . . . . . . . . . . . . . . 8 7. Security Considerations" . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Scenarios and impact on the End User . . . . . . . . 10 Appendix A. Scenarios and impact on the End User . . . . . . . . 11
Appendix B. Base Scenario . . . . . . . . . . . . . . . . . . . 10 Appendix B. Base Scenario . . . . . . . . . . . . . . . . . . . 11
B.1. Third Party Registered Homenet Domain . . . . . . . . . . 10 B.1. Third Party Registered Homenet Domain . . . . . . . . . . 11
B.2. Third Party DNS Infrastructure . . . . . . . . . . . . . 11 B.2. Third Party DNS Infrastructure . . . . . . . . . . . . . 12
B.3. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 12 B.3. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 12
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.
skipping to change at page 3, line 12 skipping to change at page 3, line 12
[I-D.ietf-homenet-front-end-naming-delegation] and its terminology [I-D.ietf-homenet-front-end-naming-delegation] and its terminology
section. section.
2. Introduction 2. Introduction
[I-D.ietf-homenet-front-end-naming-delegation] describes how Homenet [I-D.ietf-homenet-front-end-naming-delegation] describes how Homenet
Naming Authority (HNA) outsources the Public Homenet Zone to an Naming Authority (HNA) outsources the Public Homenet Zone to an
Outsourcing Infrastructure. Outsourcing Infrastructure.
This document shows how an ISP can provision automatically the HNA This document shows how an ISP can provision automatically the HNA
with an DNS Outsourcing Infrastructure (DOI). Most likely the DOI with a DNS Outsourcing Infrastructure (DOI). Most likely the DOI
will be - at least partly be - managed or provided by its ISP, but will be - at least partly be - managed or provided by its ISP, but
other cases may envision the ISP storing some configuration so the other cases may envision the ISP storing some configuration so the
homenet becomes resilient to HNA replacement. homenet becomes resilient to HNA replacement.
The ISP delegates the home network an IP prefix it owns as well as The ISP delegates the home network an IP prefix it owns as well as
the associated reverse zone. The ISP is well aware of the owner of the associated reverse zone.
that prefix, and as such becomes a natural candidate for hosting the The ISP is well aware of the owner of that prefix, and as such
Homenet Reverse Zone - that is the Reverse Distribution Master (RDM) becomes a natural candidate for hosting the Homenet Reverse Zone -
and potentially the Reverse Public Authoritative Servers. that is the Reverse Distribution Master (RDM) and potentially the
Reverse Public Authoritative Servers.
In addition, the ISP often identifies the home network with a name. In addition, the ISP often identifies the home network with a name.
In most cases, the name is used by the ISP for its internal network In most cases, the name is used by the ISP for its internal network
management operations and is not a name the home network owner has management operations and is not a name the home network owner has
registered to. The ISP may thus leverage such infrastructure and registered to. The ISP may thus leverage such infrastructure and
provide the homenet a specific domain name designated as per provide the homenet 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, the ISP is well aware of who
owns that domain name and may become a natural candidate for hosting owns that domain name and may become a natural candidate for hosting
the Homenet Zone - that is the Distribution Master (DM) and the the Homenet Zone - that is the Distribution Master (DM) and the
Public Authoritative Servers. Public Authoritative Servers.
This document describes DHCPv6 options that enables the ISP to This document describes DHCPv6 options that enables the ISP to
provide the necessary parameters to the HNA, to proceed. More provide the necessary parameters to the HNA, to proceed.
specifically, the ISP provides the Registered Homenet Domain, More specifically, the ISP provides the Registered Homenet Domain,
necessary information on the DM and the RDM so the HNA can manage and necessary information on the DM and the RDM so the HNA can manage and
upload the Public Homenet Zone and the Reverse Public Homenet Zone as upload the Public Homenet Zone and the Reverse Public Homenet Zone as
described in [I-D.ietf-homenet-front-end-naming-delegation]. described in [I-D.ietf-homenet-front-end-naming-delegation].
The use of DHCPv6 options makes the configuration completely The use of DHCPv6 options makes 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 link between the HNA and the one used to provide the IP prefix. The link between the HNA and
the DHCPv6 server may benefit from additional security for example by the DHCPv6 server may benefit from additional security for example by
using [I-D.ietf-dhc-sedhcpv6]. using [I-D.ietf-dhc-sedhcpv6].
skipping to change at page 4, line 30 skipping to change at page 4, line 25
popular scenario. This document does not ignore scenarios where the popular scenario. This document does not ignore scenarios where the
DHCP Server does not have privileged relations with the DM or RDM. DHCP Server does not have privileged relations with the DM or RDM.
These cases are discussed latter in Appendix A. Such scenarios do These cases are discussed latter in Appendix A. Such scenarios do
not necessarily require configuration for the end user and can also not necessarily require 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 and configures its DHCP Client to include in
its Option Request Option (ORO) the Registered Homnet Domain its Option Request Option (ORO) the Registered Homenet Domain
Option (OPTION_REGISTERED_DOMAIN), the Distribution Master Option Option (OPTION_REGISTERED_DOMAIN), the Distribution Master Option
(OPTION_DIST_MASTER) and the Reverse Distribution Master Option (OPTION_DIST_MASTER) and the Reverse Distribution Master Option
(OPTION_REVERSE_DIST_MASTER) option codes. (OPTION_REVERSE_DIST_MASTER) option codes.
2. The DHCP Server responds to the HNA with the requested DHCPv6 2. The DHCP 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 DHCP Client
transmits the information to the HNA. transmits the information to the HNA.
3. The HNA is able to get authenticated by the DM and the RDM. The 3. The HNA is able to get authenticated by the DM and the RDM. The
HNA builds the Homenet Zone ( resp. the Homenet Reverse Zone) and HNA builds the Homenet Zone ( resp. the Homenet Reverse Zone) and
proceed as described in proceed as described in
[I-D.ietf-homenet-front-end-naming-delegation]. [I-D.ietf-homenet-front-end-naming-delegation]. The DHCPv6
options provide the necessary and non optional parameters
described in section 14 of
[I-D.ietf-homenet-front-end-naming-delegation]. The HNA MAY set
complement the configurations with additional parameters.
Section 14 of [I-D.ietf-homenet-front-end-naming-delegation]
describes such parameters that MAY take a default value.
4. Payload Description 4. Payload Description
This section details the payload of the DHCPv6 options. <!-- ## This section details the payload of the DHCPv6 options.
Client Public Key Option {#sec-key}
The Client Public Key Option (OPTION_PUBLIC_KEY) indicates the Client
Public Key that is used to authenticate the HNA. This option is also
defined in [I-D.ietf-dhc-sedhcpv6].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PUBLIC_KEY | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Public Key Data /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Client Public Key Option
* option-code (16 bits): OPTION_PUBLIC_KEY, the option code for the
Client Public Key Option (TBD1).
* option-len (16 bits): length in octets of the option-data field as
described in [RFC3315].
* Client Public Key Data: contains the Client Public Key. The format
is the DNSKEY RDATA format as defined in [RFC4034].
-->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_REGISTERED_DOMAIN | option-len | | OPTION_REGISTERED_DOMAIN | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Registered Homenet Domain / / Registered Homenet Domain /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Registered Domain Option Figure 1: Registered Domain Option
* 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 (TBD2).
* 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 [RFC3315]. described in [RFC8415].
* Registered Homenet Domain (varaiable): the FQDN registered for the o Registered Homenet Domain (variable): the FQDN registered for the
homenet homenet encoded as described in section 10 of [RFC8415].
4.2. Distribution Master Option 4.2. Distribution Master Option
The Distributed Master Option (OPTION_DIST_MASTER) provides the HNA The Distributed Master Option (OPTION_DIST_MASTER) provides the HNA
to FQDN of the DM as well as the transport protocol for the to FQDN of the DM as well as the transport protocol for the
transaction between the HNA and the DM. transaction 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_MASTER | option-len | | OPTION_DIST_MASTER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Transport | | | Supported Transport | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Distribution Master FQDN / / Distribution Master FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Distribution Master Option Figure 2: Distribution Master Option
* option-code (16 bits): OPTION_DIST_MASTER, the option code for the o option-code (16 bits): OPTION_DIST_MASTER, the option code for the
DM Option (TBD3). DM Option (TBD3).
* 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 [RFC3315]. described in [RFC8415].
* 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. Each bit represents a supported transport, and a DM MAY
indicate the support of multiple modes. The bit for DoT MUST be indicate the support of multiple modes. The bit for DNS over TLS
set. [RFC7858] MUST be set.
* Distribution Master FQDN (variable): the FQDN of the DM. o Distribution Master FQDN (variable): the FQDN of the DM encoded 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 filed of the DHCPv6 option indicates the
supported transport protocol. Each bit represents a specific supported transport protocol. Each bit represents a specific
transport mechanism. The bit sets to 1 indicates the associated transport mechanism. The 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 4. as described in Figure 3.
Bit | Transport Protocol | Reference Bit | Transport Protocol | Reference
----+--------------------+----------- ----+--------------------+-----------
0 | DNS over TLS | 0 | DNS | This-RFC
1 | DNS over HTTPS | 1 | DNS over TLS | This-RFC
2-7 | unallocated | 2 | DNS over HTTPS | This-RFC
3 | DNS over QUIC | This-RFC
4-15| unallocated | This-RFC
Figure 4: Supported Protocols Figure 3: Supported Transport
o DNS: indicates the support of DNS over port 53 as described in
[RFC1035].
o DNS over TLS: indicates the support of DNS over TLS as described
in [RFC7858].
o DNS over HTTPS: indicates the support of DNS over HTTPS as
described in [RFC8484].
o DNS over QUIC: indicates the support of DNS over QUIC as defined
in [I-D.ietf-dprive-dnsoquic].
4.3. Reverse Distribution Master Server Option 4.3. Reverse Distribution Master Server Option
The Reverse Distribution Master Server Option The Reverse Distribution Master Server Option
(OPTION_REVERSE_DIST_MASTER) provides the HNA to FQDN of the DM as (OPTION_REVERSE_DIST_MASTER) provides the HNA to FQDN of the DM as
well as the transport protocol for the transaction between the HNA well as the transport protocol for the transaction 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_MASTER | option-len | | OPTION_REVERSE_DIST_MASTER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Transport | | | Supported Transport | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Reverse Distribution Master FQDN / / Reverse Distribution Master FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Reverse Distribution Master Option Figure 4: Reverse Distribution Master Option
* option-code (16 bits): OPTION_REVERSE_DIST_MASTER, the option code o option-code (16 bits): OPTION_REVERSE_DIST_MASTER, the option code
for the Reverse Distribution Master Option (TBD4). for the Reverse Distribution Master Option (TBD4).
* 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 [RFC3315]. described in [RFC8415].
* 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. Each bit represents a supported transport, and a DM MAY
indicate the support of multiple modes. The bit for DoT MUST be indicate the support of multiple modes. The bit for DoT MUST be
set. set.
* Reverse Distribution Master FQDN (variable): the FQDN of the RDM. o Reverse Distribution Master FQDN (variable): the FQDN of the RDM
encoded as described in section 10 of [RFC8415].
5. DHCP Behavior 5. DHCP Behavior
5.1. DHCPv6 Server Behavior 5.1. DHCPv6 Server Behavior
Sections 17.2.2 and 18.2 of [RFC3315] 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 DHCP Server sends the Registered
Homenet Domain Option, Distribution Master Option, the Reverse Homenet Domain Option, Distribution Master Option, the Reverse
Distribution Master Option when requested by the DHCPv6 client by Distribution Master 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
skipping to change at page 8, line 21 skipping to change at page 8, line 15
Upon receiving a DHCP option described in this document in the Reply Upon receiving a DHCP option described in this document in the Reply
message, the HNA SHOULD proceed as described in 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 DHCP Relay agents.
6. IANA Considerations 6. IANA Considerations
The DHCP options detailed in this document are: * IANA is requested to assign the following new DHCPv6 Option Codes in
OPTION_REGISTERED_DOMAIN: TBD1 * OPTION_DIST_MASTER: TBD2 * the registry maintained in: https://www.iana.org/assignments/dhcpv6-
OPTION_REVERSE_DIST_MASTER: TBD3 parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2.
The document also requests a Supported Transport Registry: Value Description Client ORO Singleton Option
TBD1 OPTION_REGISTERED_DOMAIN Yes Yes
TBD2 OPTION_DIST_MASTER Yes Yes
TBD3 OPTION_REVERSE_DIST_MASTER Yes Yes
Bit | Transport Protocol | Reference IANA is requested to maintain a new number space of Supported
----+--------------------+----------- Transport parameter in the Distributed Master Option
0 | DNS over TLS | (OPTION_DIST_MASTER) or the Reverse Distribution Master Server Option
1 | DNS over HTTPS | (OPTION_REVERSE_DIST_MASTER). The different parameters are defined
2-7 | unallocated | in Figure 3 in Section 4.2.1. Future code points 4 - 8 are assigned
under the IETF Review, other code points are assigned under
Specification Required as per [RFC8126].
7. Security Considerations" 7. Security Considerations"
8. Acknowledgments 8. Acknowledgments
We would like to thank Marcin Siodelski and Bernie Volz for their We would like to thank Marcin Siodelski and Bernie Volz for their
comments on the design of the DHCPv6 options. We would also like to comments on the design of the DHCPv6 options. We would also like to
thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their
remarks on the architecture design. The designed solution has been remarks on the architecture design. The designed solution has been
largely been inspired by Mark Andrews's document 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
suggesting an appropriated terminology. suggesting an appropriated terminology.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-dprive-dnsoquic]
Huitema, C., Mankin, A., and S. Dickinson, "Specification
of DNS over Dedicated QUIC Connections", draft-ietf-
dprive-dnsoquic-01 (work in progress), October 2020.
[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>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[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>.
[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>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>. <https://www.rfc-editor.org/info/rfc6672>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
9.2. Informative References 9.2. Informative References
[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", Work in Progress, Internet- zones with Prefix Delegation", draft-andrews-dnsop-pd-
Draft, draft-andrews-dnsop-pd-reverse-02, 4 November 2013, reverse-02 (work in progress), November 2013.
<http://www.ietf.org/internet-drafts/draft-andrews-dnsop-
pd-reverse-02.txt>.
[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", Work in Progress, Internet-Draft, Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work
draft-ietf-dhc-sedhcpv6-21, 21 February 2017, in progress), February 2017.
<http://www.ietf.org/internet-drafts/draft-ietf-dhc-
sedhcpv6-21.txt>.
[I-D.ietf-homenet-front-end-naming-delegation] [I-D.ietf-homenet-front-end-naming-delegation]
Migault, D., Weber, R., Richardson, M., Hunter, R., Migault, D., Weber, R., Richardson, M., Hunter, R.,
Griffiths, C., and W. Cloetens, "Simple Provisioning of Griffiths, C., and W. Cloetens, "Simple Provisioning of
Public Names for Residential Networks", Work in Progress, Public Names for Residential Networks", draft-ietf-
Internet-Draft, draft-ietf-homenet-front-end-naming- homenet-front-end-naming-delegation-12 (work in progress),
delegation-12, 2 November 2020, <http://www.ietf.org/ November 2020.
internet-drafts/draft-ietf-homenet-front-end-naming-
delegation-12.txt>.
[I-D.sury-dnsext-cname-dname] [I-D.sury-dnsext-cname-dname]
Sury, O., "CNAME+DNAME Name Redirection", Work in Sury, O., "CNAME+DNAME Name Redirection", draft-sury-
Progress, Internet-Draft, draft-sury-dnsext-cname-dname- dnsext-cname-dname-00 (work in progress), April 2010.
00, 15 April 2010, <http://www.ietf.org/internet-drafts/
draft-sury-dnsext-cname-dname-00.txt>.
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
skipping to change at page 10, line 45 skipping to change at page 11, line 36
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
network to use example.com not managed by her ISP (foo) as a network to use example.com not managed by her ISP (foo) as a
Registered Homenet Domain. This section still consider the ISP
manages the home network and still provides example.foo as a
Registered Homenet Domain. Registered Homenet Domain.
This section still consider the ISP manages the home network and
still provides example.foo as a Registered Homenet 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 example.foo using static redirection redirect the name example.com to example.foo using static redirection
with CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME with CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME
[I-D.sury-dnsext-cname-dname]. [I-D.sury-dnsext-cname-dname].
This configuration is performed once when the domain name example.com This configuration is performed once when the domain name example.com
is registered. The only information the end user needs to know is is registered. The only information the end user needs to know is
the domain name assigned by the ISP. Once this configuration is done the domain name assigned by the ISP. Once this configuration is done
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 The drawback of this from the Zero Configuration of the Base Scenario Appendix B. Then,
scenario may be that the end user still rely on the ISP naming the end user is able to register for its home network an unlimited
infrastructure. Note that the only case this may be inconvenient is number of domain names provided by an unlimited number of different
when the DNS Servers provided by the ISPs results in high third party providers.
latency.Appendix B. Then, the end user is able to register for its The drawback of this scenario may be that the end user still rely on
home network an unlimited number of domain names provided by an the ISP naming infrastructure. Note that the only case this may be
unlimited number of different third party providers. inconvenient is when the DNS Servers provided 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
skipping to change at page 13, line 20 skipping to change at page 13, line 50
requirement. requirement.
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 950 Charter Street
Redwood City, 94063 Redwood City 94063
United States of America US
Email: tomasz.mrugalski@gmail.com EMail: tomasz.mrugalski@gmail.com
Chris Griffiths Chris Griffiths
Email: cgriffiths@gmail.com EMail: cgriffiths@gmail.com
Wouter Cloetens Wouter Cloetens
Deutsche Telekom Deutsche Telekom
Email: wouter.cloetens@external.telekom.de EMail: wouter.cloetens@external.telekom.de
 End of changes. 57 change blocks. 
137 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/