draft-ietf-homenet-front-end-naming-delegation-13.txt   draft-ietf-homenet-front-end-naming-delegation-14.txt 
Homenet D. Migault Homenet D. Migault
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track R. Weber Intended status: Standards Track R. Weber
Expires: September 27, 2021 Nominum Expires: October 30, 2021 Nominum
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
R. Hunter R. Hunter
Globis Consulting BV Globis Consulting BV
C. Griffiths April 28, 2021
W. Cloetens
Deutsche Telekom
March 26, 2021
Simple Provisioning of Public Names for Residential Networks Simple Provisioning of Public Names for Residential Networks
draft-ietf-homenet-front-end-naming-delegation-13 draft-ietf-homenet-front-end-naming-delegation-14
Abstract Abstract
Home owners often have IPv6 devices that they wish to access over the Home owners often have IPv6 devices that they wish to access over the
Internet using names. It has been possible to register and populate Internet using names. It has been possible to register and populate
a DNS Zone with names since DNS became a thing, but it has been an a DNS Zone with names since DNS became a thing, but it has been an
activity typically reserved for experts. This document automates the activity typically reserved for experts. This document automates the
process through creation of a Homenet Naming Authority (HNA), whose process through creation of a Homenet Naming Authority (HNA), whose
responsibility is to select, sign and publish names to a set of responsibility is to select, sign and publish names to a set of
publicly visible servers. publicly visible servers.
skipping to change at page 2, line 10 skipping to change at page 2, line 7
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 September 27, 2021. This Internet-Draft will expire on October 30, 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 19 skipping to change at page 3, line 17
11.1. Hidden Primary . . . . . . . . . . . . . . . . . . . . . 24 11.1. Hidden Primary . . . . . . . . . . . . . . . . . . . . . 24
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26
13.1. HNA DM channels . . . . . . . . . . . . . . . . . . . . 26 13.1. HNA DM channels . . . . . . . . . . . . . . . . . . . . 26
13.2. Names are less secure than IP addresses . . . . . . . . 27 13.2. Names are less secure than IP addresses . . . . . . . . 27
13.3. Names are less volatile than IP addresses . . . . . . . 27 13.3. Names are less volatile than IP addresses . . . . . . . 27
14. Information Model for Outsourced information . . . . . . . . 27 14. Information Model for Outsourced information . . . . . . . . 27
14.1. Outsourced Information Model . . . . . . . . . . . . . . 28 14.1. Outsourced Information Model . . . . . . . . . . . . . . 28
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
16. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 30 16. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 30
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
17.1. Normative References . . . . . . . . . . . . . . . . . . 31 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
17.2. Informative References . . . . . . . . . . . . . . . . . 34 18.1. Normative References . . . . . . . . . . . . . . . . . . 31
18.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Envisioned deployment scenarios . . . . . . . . . . 36 Appendix A. Envisioned deployment scenarios . . . . . . . . . . 36
A.1. CPE Vendor . . . . . . . . . . . . . . . . . . . . . . . 36 A.1. CPE Vendor . . . . . . . . . . . . . . . . . . . . . . . 36
A.2. Agnostic CPE . . . . . . . . . . . . . . . . . . . . . . 36 A.2. Agnostic CPE . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Example: A manufacturer provisioned HNA product flow 37 Appendix B. Example: A manufacturer provisioned HNA product flow 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
The Homenet Naming Authority (HNA) is responsible for making devices The Homenet Naming Authority (HNA) is responsible for making devices
within the home network accessible by name within the home network as within the home network accessible by name within the home network as
skipping to change at page 9, line 11 skipping to change at page 9, line 11
the authoritative naming service from the HNA to the DOI in the authoritative naming service from the HNA to the DOI in
Section 3.1. Section 14 defines necessary parameter to configure the Section 3.1. Section 14 defines necessary parameter to configure the
HNA. HNA.
3.1. Architecture Overview 3.1. Architecture Overview
Figure 1 illustrates the architecture where the HNA outsources the Figure 1 illustrates the architecture where the HNA outsources the
publication of the Public Homenet Zone to the DOI. publication of the Public Homenet Zone to the DOI.
The Public Homenet Zone is identified by the Registered Homenet The Public Homenet Zone is identified by the Registered Homenet
Domain Name - myhome.isp.example. Domain Name - myhome.example. The ".local" as well as ".home.arpa"
are explicitly not considered as Public Homenet zones and represented
The ".local" as well as ".home.arpa" are explicitly not considered as as Homenet Zone in Figure 1.
Public Homenet zones.
The HNA SHOULD build the Public Homenet Zone in a single view The HNA SHOULD build the Public Homenet Zone in a single view
populated with all resource records that are expected to be published populated with all resource records that are expected to be published
on the Internet. on the Internet. As explained in Section 1.1, how the Public Homenet
Zone is populated is out of the scope of this document. The HNA also
As explained in {#selectingnames}, how the Public Homenet Zone is signs the Public Homenet Zone. The HNA handles all operations and
populated is out of the scope of this document. keying material required for DNSSEC, so there is no provision made in
this architecture for transferring private DNSSEC related keying
The HNA also signs the Public Homenet Zone. The HNA handles all material between the HNA and the DM.
operations and keying material required for DNSSEC, so there is no
provision made in this architecture for transferring private DNSSEC
related keying material between the HNA and the DM.
Once the Public Homenet Zone has been built, the HNA outsources it to Once the Public Homenet Zone has been built, the HNA outsources it to
the DOI as described in Figure 1. the DOI as described in Figure 1. The HNA acts as a hidden primary
while the DM behaves as a secondary responsible to distribute the
The HNA acts as a hidden primary while the DM behaves as a secondary Public Homenet Zone to the multiple Public Authoritative Servers that
responsible to distribute the Public Homenet Zone to the multiple DOI is responsible for. The DM has 3 communication channels:
Public Authoritative Servers that DOI is responsible for.
The DM has 3 communication channels:
o a DM Control Channel (see section Section 4) to configure the HNA o a DM Control Channel (see section Section 4) to configure the HNA
and the DOI, and the DOI,
o a DM Synchronization Channel (see section Section 5 to synchronize o a DM Synchronization Channel (see section Section 5 to synchronize
the Public Homenet Zone on the HNA and on the DM. the Public Homenet Zone on the HNA and on the DM.
o one or more Distribution Channels (see section Section 6 that o one or more Distribution Channels (see section Section 6 that
distributes the Public Homenet Zone from the DM to the Public distributes the Public Homenet Zone from the DM to the Public
Authoritative Server serving the Public Homenet Zone on the Authoritative Server serving the Public Homenet Zone on the
skipping to change at page 10, line 19 skipping to change at page 10, line 11
mentioned in the NS records of the Public Homenet zone, unless mentioned in the NS records of the Public Homenet zone, unless
additional security provisions necessary to protect the HNA from additional security provisions necessary to protect the HNA from
external attack have been taken. external attack have been taken.
The DOI is also responsible for ensuring the DS record has been The DOI is also responsible for ensuring the DS record has been
updated in the parent zone. updated in the parent zone.
Resolution is performed by the DNSSEC resolvers. When the resolution Resolution is performed by the DNSSEC resolvers. When the resolution
is performed outside the home network, the DNSSEC Resolver resolves is performed outside the home network, the DNSSEC Resolver resolves
the DS record on the Global DNS and the name associated to the Public the DS record on the Global DNS and the name associated to the Public
Homenet Zone (example.com) on the Public Authoritative Servers. Homenet Zone (myhome.example) on the Public Authoritative Servers.
When the resolution is performed from within the home network, the When the resolution is performed from within the home network, the
Homenet DNSSEC Resolver may proceed similarly. On the other hand, to Homenet DNSSEC Resolver may proceed similarly. On the other hand, to
provide resilience to the Public Homenet Zone in case of disruption, provide resilience to the Public Homenet Zone in case of disruption,
the Homenet DNSSEC Resolver SHOULD be able to perform the resolution the Homenet DNSSEC Resolver SHOULD be able to perform the resolution
on the Homenet Authoritative Servers. These servers are not expected on the Homenet Authoritative Servers. These servers are not expected
to be mentioned in the Public Homenet Zone, nor to be accessible from to be mentioned in the Public Homenet Zone, nor to be accessible from
the Internet. As such their information as well as the corresponding the Internet. As such their information as well as the corresponding
signed DS record MAY be provided by the HNA to the Homenet DNSSEC signed DS record MAY be provided by the HNA to the Homenet DNSSEC
Resolvers, e.g., using HNCP [RFC7788]. Such configuration is outside Resolvers, e.g., using HNCP [RFC7788]. Such configuration is outside
the scope of this document. the scope of this document. Since the scope of the Homenet
Authoritative Servers is limited to the home network, these servers
are expected to serve the Homenet Zone as represented in Figure 1.
How the Homenet Authoritative Servers are provisioned is also out of How the Homenet Authoritative Servers are provisioned is also out of
scope of this specification. It could be implemented using primary scope of this specification. It could be implemented using primary
secondaries servers, or via rsync. In some cases, the HNA and secondaries servers, or via rsync. In some cases, the HNA and
Homenet Authoritative Servers may be combined together which would Homenet Authoritative Servers may be combined together which would
result in a common instantiation of an authoritative server on the result in a common instantiation of an authoritative server on the
WAN and inner interface. Other mechanisms may also be used. WAN and inner interface. Other mechanisms may also be used.
Home network | Internet Home network | Internet
| |
| +----------------------------+ | +----------------------------+
| | DOI | | | DOI |
Control | | | Control | | |
+-----------------------+ Channel | | +-----------------------+ | +-----------------------+ Channel | | +-----------------------+ |
| HNA |<-------------->| Distribution Master | | | HNA |<-------------->| Distribution Master | |
|+---------------------+| | | |+---------------------+| | |+---------------------+| | | |+---------------------+| |
|| Public Homenet Zone ||Synchronization || Public Homenet Zone || | || Public Homenet Zone ||Synchronization || Public Homenet Zone || |
|| (example.com) || Channel | | || (example.com) || | || (myhome.example) || Channel | | || (myhome.example) || |
|+---------------------+|<-------------->|+---------------------+| | |+---------------------+|<-------------->|+---------------------+| |
+----------------------+| | | +-----------------------+ | +-----------^-----------+ | | +-----------------------+ |
| | ^ Distribution | . | | ^ Distribution |
| | | Channel | . | | | Channel |
+-----------------------+ | | v | +-----------v-----------+ | | v |
| Homenet Authoritative | | | +-----------------------+ | | Homenet Authoritative | | | +-----------------------+ |
| Server(s) | | | | Public Authoritative | | | Server(s) | | | | Public Authoritative | |
|+---------------------+| | | | Server(s) | | |+---------------------+| | | | Server(s) | |
||Public Homenet Zone || | | |+---------------------+| | ||Public Homenet Zone || | | |+---------------------+| |
|| (example.com) || | | || Public Homenet Zone || | || (myhome.example) || | | || Public Homenet Zone || |
|+---------------------+| | | || (example.com) || | |+---------------------+| | | || (myhome.example) || |
+-----------------------+ | | |+---------------------+| | || Homenet Zone || | | |+---------------------+| |
^ | | | +-----------------------+ | || (home.arpa) || | | +-----------------------+ |
| | | +----------^---|-------------+ |+---------------------+| | +----------^---|-------------+
| | | | | +----------^---|--------+ | | |
| | name resolution | | | | name resolution | |
| v | | v | v | | v
+----------------------+ | +-----------------------+ +----------------------+ | +-----------------------+
| Homenet | | | Internet | | Homenet | | | Internet |
| DNSSEC Resolver | | | DNSSEC Resolver | | DNSSEC Resolver | | | DNSSEC Resolver |
+----------------------+ | +-----------------------+ +----------------------+ | +-----------------------+
Figure 1: Homenet Naming Architecture Name Resolution Figure 1: Homenet Naming Architecture
3.2. Distribution Master Communication Channels 3.2. Distribution Master Communication Channels
This section details the interfaces and channels of the DM, that is This section details the interfaces and channels of the DM, that is
the Control Channel, the Synchronization Channel and the Distribution the Control Channel, the Synchronization Channel and the Distribution
Channel. Channel.
The Control Channel and the Synchronization Channel are the The Control Channel and the Synchronization Channel are the
interfaces used between the HNA and the DOI. The entity within the interfaces used between the HNA and the DOI. The entity within the
DOI responsible to handle these communications is the DM and DOI responsible to handle these communications is the DM and
skipping to change at page 12, line 17 skipping to change at page 12, line 17
The Control Channel is used to set up the Synchronization Channel. The Control Channel is used to set up the Synchronization Channel.
We assume that the HNA initiates the Control Channel connection with We assume that the HNA initiates the Control Channel connection with
the DM and as such has a prior knowledge of the DM identity (X509 the DM and as such has a prior knowledge of the DM identity (X509
certificate), the IP address and port to use and protocol to set certificate), the IP address and port to use and protocol to set
secure session. We also assume the DM has knowledge of the identity secure session. We also assume the DM has knowledge of the identity
of the HNA (X509 certificate) as well as the Registered Homenet of the HNA (X509 certificate) as well as the Registered Homenet
Domain. For more detail to see how this can be achieved, please see Domain. For more detail to see how this can be achieved, please see
section Section 10. section Section 10.
The information exchanged between the HNA and the DM is using DNS The information exchanged between the HNA and the DM is using DNS
messages. DNS messages can be protected using various kind of messages protected by DNS over TLS (DoT) [RFC7858]. Further
transport layers, among others, DNS over DTLS [RFC8094], DNS over TLS specifications may consider protecting DNS messages with other
(DoT) [RFC7858], or DNS over HTTPs (DoH) [RFC8484]. There was transport layers, among others, DNS over DTLS [RFC8094], or DNS over
consideration to using a standard TSIG [RFC2845] or SIG(0) [RFC2931] HTTPs (DoH) [RFC8484] or DNS over QUIC [I-D.ietf-dprive-dnsoquic].
to perform a dynamic DNS update to the DM. There are a number of There was consideration to using a standard TSIG [RFC2845] or SIG(0)
issues with this. The first one is that TSIG or SIG(0) make [RFC2931] to perform a dynamic DNS update to the DM. There are a
scenarios where the end user needs to interact via its web browser number of issues with this. The first one is that TSIG or SIG(0)
more complex. More precisely, authorization and access control make scenarios where the end user needs to interact via its web
granted via OAUTH would be unnecessarily complex with TSIG or SIG(0). browser more complex. More precisely, authorization and access
control granted via OAUTH would be unnecessarily complex with TSIG or
SIG(0).
The main one is that the Dynamic DNS update would also update the The main one is that the Dynamic DNS update would also update the
parent zone's (NS, DS and associated A or AAAA records) while the parent zone's (NS, DS and associated A or AAAA records) while the
goal is to update the DM configuration files. The visible NS records goal is to update the DM configuration files. The visible NS records
SHOULD remain pointing at the cloud provider's anycast addresses. SHOULD remain pointing at the cloud provider's anycast addresses.
Revealing the address of the HNA in the DNS is not desirable. Please Revealing the address of the HNA in the DNS is not desirable. Please
see section Section 4.2 for more details. see section Section 4.2 for more details.
This specification assumes: This specification assumes:
o the DM serves both the Control Channel and Synchronization Channel o the DM serves both the Control Channel and Synchronization Channel
on a single IP address, single port and with a single transport on a single IP address, single port and with a single transport
protocol. protocol.
o By default, the HNA uses a single IP address for both the Control o By default, the HNA uses a single IP address for both the Control
and Synchronization channel. However, the HNA MAY use distinct IP and Synchronization channel. However, the HNA MAY use distinct IP
addresses for the Control Channel and the Synchronization Channel addresses for the Control Channel and the Synchronization Channel
- see section Section 5 and section {sec-sync-info}} for more - see section Section 5 and section Section 4.3 for more details.
details.
The Distribution Channel is internal to the DOI and as such is not The Distribution Channel is internal to the DOI and as such is not
the primary concern of this specification. the primary concern of this specification.
4. Control Channel between Homenet Naming Authority (HNA) and 4. Control Channel between Homenet Naming Authority (HNA) and
Distribution Master (DM) Distribution Master (DM)
The DM Control Channel is used by the HNA and the DOI to exchange The DM Control Channel is used by the HNA and the DOI to exchange
information related to the configuration of the delegation which information related to the configuration of the delegation which
includes information to build the Public Homenet Zone (see includes information to build the Public Homenet Zone (see
skipping to change at page 14, line 16 skipping to change at page 14, line 16
the DS to the parent zone. Upon refusal, the DM clearly indicates it the DS to the parent zone. Upon refusal, the DM clearly indicates it
does not have the capacity to proceed to the update. does not have the capacity to proceed to the update.
4.3. Information to set the Synchronization Channel 4.3. Information to set the Synchronization Channel
The HNA works as a primary authoritative DNS server, while the DM The HNA works as a primary authoritative DNS server, while the DM
works like a secondary. As a result, the HNA MUST provide the IP works like a secondary. As a result, the HNA MUST provide the IP
address the DM is using to reach the HNA. The synchronization address the DM is using to reach the HNA. The synchronization
Channel will be set between that IP address and the IP address of the Channel will be set between that IP address and the IP address of the
DM. By default, the IP address used by the HNA in the Control DM. By default, the IP address used by the HNA in the Control
Channel is considered by the DM and teh specification of the IP by Channel is considered by the DM and the specification of the IP by
the HNA is only OPTIONAL. The transport channel (including port) is the HNA is only OPTIONAL. The transport channel (including port) is
the same as the one used between the HNA and the DM for the Control the same as the one used between the HNA and the DM for the Control
Channel. Channel.
4.4. Deleting the delegation 4.4. Deleting the delegation
The purpose of the previous sections were to exchange information in The purpose of the previous sections were to exchange information in
order to set a delegation. The HNA MUST also be able to delete a order to set a delegation. The HNA MUST also be able to delete a
delegation with a specific DM. Upon an instruction of deleting the delegation with a specific DM. Upon an instruction of deleting the
delegation, the DM MUST stop serving the Public Homenet Zone. delegation, the DM MUST stop serving the Public Homenet Zone.
skipping to change at page 20, line 37 skipping to change at page 20, line 37
Finally, the AXFR [RFC1034] or IXFR [RFC1995] query performed by the Finally, the AXFR [RFC1034] or IXFR [RFC1995] query performed by the
secondary is a small packet sent over TCP (section 4.2 [RFC5936]), secondary is a small packet sent over TCP (section 4.2 [RFC5936]),
which mitigates reflection attacks using a forged NOTIFY. which mitigates reflection attacks using a forged NOTIFY.
The AXFR request from the DM to the HNA SHOULD be secured and the use The AXFR request from the DM to the HNA SHOULD be secured and the use
of TLS is RECOMMENDED [I-D.ietf-dprive-xfr-over-tls] of TLS is RECOMMENDED [I-D.ietf-dprive-xfr-over-tls]
When using TLS, the HNA MAY authenticate inbound connections from the When using TLS, the HNA MAY authenticate inbound connections from the
DM using standard mechanisms, such as a public certificate with DM using standard mechanisms, such as a public certificate with
baked-in root certificates on the HNA, or via DANE {!RFC6698}}. In baked-in root certificates on the HNA, or via DANE [RFC6698]. In
addition, to guarantee the DM remains the same across multiple TLS addition, to guarantee the DM remains the same across multiple TLS
session, the HNA and DM MAY implement [RFC8672]. session, the HNA and DM MAY implement [RFC8672].
The HNA MAY apply a simple IP filter on inbound AXFR requests to The HNA MAY apply a simple IP filter on inbound AXFR requests to
ensure they only arrive from the DM Synchronization Channel. In this ensure they only arrive from the DM Synchronization Channel. In this
case, the HNA SHOULD regularly check (via DNS resolution) that the case, the HNA SHOULD regularly check (via DNS resolution) that the
address of the DM in the filter is still valid. address of the DM in the filter is still valid.
6. DM Distribution Channel 6. DM Distribution Channel
skipping to change at page 28, line 15 skipping to change at page 28, line 15
This format may also provide the basis for a future OAUTH2 [RFC6749] This format may also provide the basis for a future OAUTH2 [RFC6749]
flow that could do the setup automatically. flow that could do the setup automatically.
The HNA needs to be configured with the following parameters as The HNA needs to be configured with the following parameters as
described by this CDDL [RFC8610]. These are the parameters are described by this CDDL [RFC8610]. These are the parameters are
necessary to establish a secure channel between the HNA and the DM as necessary to establish a secure channel between the HNA and the DM as
well as to specify the DNS zone that is in the scope of the well as to specify the DNS zone that is in the scope of the
communication. communication.
hna-configuration = { hna-configuration = {
"registred_domain" : tstr, "registered_domain" : tstr,
"dm" : tstr, "dm" : tstr,
? "dm_transport" : "53" // "DoT" // "DoH" // "DoQ" ? "dm_transport" : "DoT"
? "dm_port" : uint, ? "dm_port" : uint,
? "dm_acl" : hna-acl // [ +hna-acl ] ? "dm_acl" : hna-acl / [ +hna-acl ]
? "hna_auth_method": hna-auth-method ? "hna_auth_method": hna-auth-method
? "hna_certificate": tstr ? "hna_certificate": tstr
} }
hna-acl = tstr hna-acl = tstr
hna-auth-method /= "certificate" hna-auth-method /= "certificate"
For example: For example:
{ {
skipping to change at page 29, line 13 skipping to change at page 29, line 13
employed. employed.
As the session between the HNA and the DM is authenticated with TLS, As the session between the HNA and the DM is authenticated with TLS,
the use of names is easier. the use of names is easier.
As certificates are more commonly emitted for FQDN than for IP As certificates are more commonly emitted for FQDN than for IP
addresses, it is preferred to use names and authenticate the name of addresses, it is preferred to use names and authenticate the name of
the DM during the TLS session establishment. the DM during the TLS session establishment.
Supported Transport (dm_transport) The transport that carries the Supported Transport (dm_transport) The transport that carries the
DNS exchanges between the HNA and the DM. Typical values are DNS exchanges between the HNA and the DM. Typical value is "DoT"
"53", "DoT", "DoH", "DoQ". This parameter is OPTIONAL and by but it may be extended in the future with "DoH", "DoQ" for
default the HNA uses DoT. example. This parameter is OPTIONAL and by default the HNA uses
DoT.
Distribution Master Port (dm_port) Indicates the port used by the Distribution Master Port (dm_port) Indicates the port used by the
DM. This parameter is OPTIONAL and the default value is provided DM. This parameter is OPTIONAL and the default value is provided
by the Supported Transport. In the future, additional transport by the Supported Transport. In the future, additional transport
may not have default port, in which case either a default port may not have default port, in which case either a default port
needs to be defined or this parameter become MANDATORY. needs to be defined or this parameter become MANDATORY.
Note that HNA does not defines ports for the Synchronization Channel. Note that HNA does not defines ports for the Synchronization Channel.
In any case, this is not expected to part of the configuration, but In any case, this is not expected to part of the configuration, but
instead negotiated through the Configuration Channel. Currently the instead negotiated through the Configuration Channel. Currently the
skipping to change at page 31, line 5 skipping to change at page 31, line 5
for providing alternative solutions; Paul Mockapetris, Christian for providing alternative solutions; Paul Mockapetris, Christian
Jacquenet, Francis Dupont and Ludovic Eschard for their remarks on Jacquenet, Francis Dupont and Ludovic Eschard for their remarks on
HNA and low power devices; Olafur Gudmundsson for clarifying DNSSEC HNA and low power devices; Olafur Gudmundsson for clarifying DNSSEC
capabilities of small devices; Simon Kelley for its feedback as capabilities of small devices; Simon Kelley for its feedback as
dnsmasq implementer; Andrew Sullivan, Mark Andrew, Ted Lemon, Mikael dnsmasq implementer; Andrew Sullivan, Mark Andrew, Ted Lemon, Mikael
Abrahamson, and Ray Bellis for their feedback on handling different Abrahamson, and Ray Bellis for their feedback on handling different
views as well as clarifying the impact of outsourcing the zone views as well as clarifying the impact of outsourcing the zone
signing operation outside the HNA; Mark Andrew and Peter Koch for signing operation outside the HNA; Mark Andrew and Peter Koch for
clarifying the renumbering. clarifying the renumbering.
17. References 17. Contributors
17.1. Normative References The co-authors would like to thank Chris Griffiths and Wouter
Cloetens that provided a significant contribution in the early
versions of the document.
18. References
18.1. Normative References
[I-D.ietf-dprive-xfr-over-tls] [I-D.ietf-dprive-xfr-over-tls]
Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.
Mankin, "DNS Zone Transfer-over-TLS", draft-ietf-dprive- Mankin, "DNS Zone Transfer-over-TLS", draft-ietf-dprive-
xfr-over-tls-05 (work in progress), January 2021. xfr-over-tls-11 (work in progress), April 2021.
[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>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996, DOI 10.17487/RFC1995, August 1996,
<https://www.rfc-editor.org/info/rfc1995>. <https://www.rfc-editor.org/info/rfc1995>.
[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>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997, RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>. <https://www.rfc-editor.org/info/rfc2136>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>. <https://www.rfc-editor.org/info/rfc4034>.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
DOI 10.17487/RFC4192, September 2005, DOI 10.17487/RFC4192, September 2005,
<https://www.rfc-editor.org/info/rfc4192>. <https://www.rfc-editor.org/info/rfc4192>.
skipping to change at page 34, line 23 skipping to change at page 34, line 19
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[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>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
17.2. Informative References 18.2. Informative References
[I-D.howard-dnsop-ip6rdns] [I-D.howard-dnsop-ip6rdns]
Howard, L., "Reverse DNS in IPv6 for Internet Service Howard, L., "Reverse DNS in IPv6 for Internet Service
Providers", draft-howard-dnsop-ip6rdns-00 (work in Providers", draft-howard-dnsop-ip6rdns-00 (work in
progress), June 2014. progress), June 2014.
[I-D.ietf-dprive-dnsoquic]
Huitema, C., Mankin, A., and S. Dickinson, "Specification
of DNS over Dedicated QUIC Connections", draft-ietf-
dprive-dnsoquic-02 (work in progress), February 2021.
[I-D.ietf-homenet-naming-architecture-dhc-options] [I-D.ietf-homenet-naming-architecture-dhc-options]
Migault, D., Weber, R., Mrugalski, T., Griffiths, C., and Migault, D., Weber, R., Mrugalski, T., Griffiths, C., and
W. Cloetens, "DHCPv6 Options for Home Network Naming W. Cloetens, "DHCPv6 Options for Home Network Naming
Authority", draft-ietf-homenet-naming-architecture-dhc- Authority", draft-ietf-homenet-naming-architecture-dhc-
options-08 (work in progress), October 2020. options-11 (work in progress), April 2021.
[I-D.ietf-homenet-simple-naming] [I-D.ietf-homenet-simple-naming]
Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming
and Service Discovery Architecture", draft-ietf-homenet- and Service Discovery Architecture", draft-ietf-homenet-
simple-naming-03 (work in progress), October 2018. simple-naming-03 (work in progress), October 2018.
[I-D.richardson-homerouter-provisioning] [I-D.richardson-homerouter-provisioning]
Richardson, M., "Provisioning Initial Device Identifiers Richardson, M., "Provisioning Initial Device Identifiers
into Home Routers", draft-richardson-homerouter- into Home Routers", draft-richardson-homerouter-
provisioning-00 (work in progress), November 2020. provisioning-00 (work in progress), November 2020.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>. <https://www.rfc-editor.org/info/rfc8094>.
[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>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8672] Sheffer, Y. and D. Migault, "TLS Server Identity Pinning [RFC8672] Sheffer, Y. and D. Migault, "TLS Server Identity Pinning
with Tickets", RFC 8672, DOI 10.17487/RFC8672, October with Tickets", RFC 8672, DOI 10.17487/RFC8672, October
2019, <https://www.rfc-editor.org/info/rfc8672>. 2019, <https://www.rfc-editor.org/info/rfc8672>.
skipping to change at page 38, line 38 skipping to change at line 1757
EMail: mcr+ietf@sandelman.ca EMail: mcr+ietf@sandelman.ca
Ray Hunter Ray Hunter
Globis Consulting BV Globis Consulting BV
Weegschaalstraat 3 Weegschaalstraat 3
Eindhoven 5632CW Eindhoven 5632CW
NL NL
EMail: v6ops@globis.net EMail: v6ops@globis.net
Chris Griffiths
EMail: cgriffiths@gmail.com
Wouter Cloetens
Deutsche Telekom
EMail: wouter.cloetens@external.telekom.de
 End of changes. 32 change blocks. 
83 lines changed or deleted 88 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/