draft-ietf-homenet-naming-architecture-dhc-options-04.txt   draft-ietf-homenet-naming-architecture-dhc-options-05.txt 
HOMENET D. Migault (Ed) HOMENET D. Migault (Ed)
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track T. Mrugalski Intended status: Standards Track T. Mrugalski
Expires: February 16, 2017 ISC Expires: April 30, 2018 ISC
C. Griffiths C. Griffiths
R. Weber R. Weber
Nominum Nominum
W. Cloetens W. Cloetens
SoftAtHome SoftAtHome
August 15, 2016 October 27, 2017
DHCPv6 Options for Homenet Naming Architecture DHCPv6 Options for Homenet Naming Architecture
draft-ietf-homenet-naming-architecture-dhc-options-04.txt draft-ietf-homenet-naming-architecture-dhc-options-05
Abstract Abstract
Home network devices are usually constrained devices with reduced
network and CPU capabilities. As such, a home network device
exposing the authoritative naming service for its home network on the
Internet may become vulnerable to resource exhaustion attacks. One
way to avoid exposing these devices is to outsource the authoritative
service to a third party, e.g. ISP.
The Homenet Naming Authority (HNA) is the designated device in charge The Homenet Naming Authority (HNA) is the designated device in charge
of outsourcing the service to a third party, which requires setting of outsourcing the service to a third party, which requires setting
up an architecture. up an architecture.
Such settings may be inappropriate for most end users. This document Such settings may be inappropriate for most end users. This document
defines DHCPv6 options so any agnostic HNA can automatically proceed defines DHCPv6 options so any agnostic HNA can automatically proceed
to the appropriate configuration and outsource the authoritative to the appropriate configuration and outsource the authoritative
naming service for the home network. In most cases, the outsourcing naming service for the home network. In most cases, the outsourcing
mechanism is transparent for the end user. mechanism is 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 http://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."
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 This Internet-Draft will expire on April 30, 2018.
This Internet-Draft will expire on February 16, 2017. Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 3, line 4 skipping to change at page 2, line 50
6.2. Update Field . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Update Field . . . . . . . . . . . . . . . . . . . . . . 14
6.3. Client Public Key Option . . . . . . . . . . . . . . . . 14 6.3. Client Public Key Option . . . . . . . . . . . . . . . . 14
6.4. Zone Template Option . . . . . . . . . . . . . . . . . . 14 6.4. Zone Template Option . . . . . . . . . . . . . . . . . . 14
6.5. Synchronization Server Option . . . . . . . . . . . . . . 15 6.5. Synchronization Server Option . . . . . . . . . . . . . . 15
6.6. Reverse Synchronization Server Option . . . . . . . . . . 16 6.6. Reverse Synchronization Server Option . . . . . . . . . . 16
7. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 17 7. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 17 7.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 17
7.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 18 7.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 18
7.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 18 7.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. DNSSEC is recommended to authenticate DNS hosted data . . 19 9.1. DNSSEC is recommended to authenticate DNS hosted data . . 19
9.2. Channel between the HNA and ISP DHCP Server MUST be 9.2. Channel between the HNA and ISP DHCP Server MUST be
secured . . . . . . . . . . . . . . . . . . . . . . . . . 19 secured . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.3. HNAs are sensitive to DoS . . . . . . . . . . . . . . . . 19 9.3. HNAs are sensitive to DoS . . . . . . . . . . . . . . . . 19
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informational References . . . . . . . . . . . . . . . . 21 11.2. Informational References . . . . . . . . . . . . . . . . 21
Appendix A. Scenarios and impact on the End User . . . . . . . . 22 Appendix A. Scenarios and impact on the End User . . . . . . . . 22
A.1. Base Scenario . . . . . . . . . . . . . . . . . . . . . . 22 A.1. Base Scenario . . . . . . . . . . . . . . . . . . . . . . 22
A.2. Third Party Registered Homenet Domain . . . . . . . . . . 23 A.2. Third Party Registered Homenet Domain . . . . . . . . . . 23
A.3. Third Party DNS Infrastructure . . . . . . . . . . . . . 23 A.3. Third Party DNS Infrastructure . . . . . . . . . . . . . 23
A.4. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 25 A.4. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 26 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 26
skipping to change at page 4, line 4 skipping to change at page 3, line 50
- Homenet Reverse Zone: The reverse zone file associated to the - Homenet Reverse Zone: The reverse zone file associated to the
Homenet Zone. Homenet Zone.
3. Introduction 3. Introduction
HNAs are usually constrained devices with reduced network and CPU HNAs are usually constrained devices with reduced network and CPU
capacities. As such, a HNA hosting on the Internet the authoritative capacities. As such, a HNA hosting on the Internet the authoritative
naming service for its home network may become vulnerable to resource naming service for its home network may become vulnerable to resource
exhaustion attacks. Outsourcing the authoritative service to a third exhaustion attacks. Outsourcing the authoritative service to a third
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016
party avoids exposing the HNA to such attacks. This third party can party avoids exposing the HNA to such attacks. This third party can
be the ISP or any other independent third party. be the ISP or any other independent third party.
Outsourcing the authoritative naming service to a third party Outsourcing the authoritative naming service to a third party
requires setting up an architecture designated in this document as requires setting up an architecture designated in this document as
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
the Outsourcing Infrastructure. These settings may be inappropriate the Outsourcing Infrastructure. These settings may be inappropriate
for most end users that do not have the sufficient knowledge. To for most end users that do not have the sufficient knowledge. To
address this issue, this document proposes DHCPv6 options so any address this issue, this document proposes DHCPv6 options so any
agnostic HNA can automatically set the Outsourcing Infrastructure. agnostic HNA can automatically set the Outsourcing Infrastructure.
In most cases, these DHCPv6 options are sufficient and do not require In most cases, these DHCPv6 options are sufficient and do not require
any additional interaction from the end user, thus achieving a zero- any additional interaction from the end user, thus achieving a zero-
config settings. In some other cases, the end user is expected to config settings. In some other cases, the end user is expected to
perform some limited manual configuration. perform some limited manual configuration.
When the HNA is plugged, the DHCPv6 options described in the document When the HNA is plugged, the DHCPv6 options described in the document
skipping to change at page 5, line 4 skipping to change at page 4, line 50
whether the Homenet Zone is signed or not, and if signed, which whether the Homenet Zone is signed or not, and if signed, which
entity is responsible to sign it. Such questions are out of entity is responsible to sign it. Such questions are out of
the scope of the current document. the scope of the current document.
- 3. To upload the Homenet Reverse Zone to the Reverse - 3. To upload the Homenet Reverse Zone to the Reverse
Synchronization Server in charge of publishing the Homenet Synchronization Server in charge of publishing the Homenet
Reverse Zone on the Reverse Public Authoritative Server(s). Reverse Zone on the Reverse Public Authoritative Server(s).
This document describes the Reverse Synchronization Server This document describes the Reverse Synchronization Server
Option that provides the FQDN of the appropriated server. Option that provides the FQDN of the appropriated server.
Similarly to item 2., we do not consider in this document if Similarly to item 2., we do not consider in this document if
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016
the Homenet Reverse Zone is signed or not, and if signed who the Homenet Reverse Zone is signed or not, and if signed who
signs it. signs it.
- 4. To provide authentication credential (a public key) to the DHCP - 4. To provide authentication credential (a public key) to the DHCP
Server: Information stored in the Homenet Zone Template, the Server: Information stored in the Homenet Zone Template, the
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
Homenet Zone and Homenet Reverse Zone belongs to the HNA, and Homenet Zone and Homenet Reverse Zone belongs to the HNA, and
only the HNA should be able to update or upload these zones. only the HNA should be able to update or upload these zones.
To authenticate the HNA, this document defines the Client To authenticate the HNA, this document defines the Client
Public Key Option. This option is sent by the HNA to the Public Key Option. This option is sent by the HNA to the
DHCPv6 server and provides the Client Public Key the HNA uses DHCPv6 server and provides the Client Public Key the HNA uses
to authenticate itself. This document does not describe to authenticate itself. This document does not describe
mechanisms used to transmit the Client Public Key from the mechanisms used to transmit the Client Public Key from the
DHCPv6 server to the appropriate entities. If the DHCPv6 DHCPv6 server to the appropriate entities. If the DHCPv6
server is not able to provide the Client Public Key to the server is not able to provide the Client Public Key to the
appropriated entities, then the end user is likely to provide appropriated entities, then the end user is likely to provide
skipping to change at page 6, line 4 skipping to change at page 5, line 50
needs to interact with the server, then, the end user is expected to needs to interact with the server, then, the end user is expected to
provide the HNA's Client Public Key to these servers (the Reverse provide the HNA's Client Public Key to these servers (the Reverse
Synchronization Server or the Synchronization Server) either manually Synchronization Server or the Synchronization Server) either manually
or using other mechanisms. Such mechanisms are outside the scope of or using other mechanisms. Such mechanisms are outside the scope of
this document. In that case, the authentication credentials need to this document. In that case, the authentication credentials need to
be provided every time the key is modified. Appendix A provides more be provided every time the key is modified. Appendix A provides more
details on how different scenarios impact the end users. details on how different scenarios impact the end users.
The remaining of this document is structured as follows. Section 4 The remaining of this document is structured as follows. Section 4
provides an overview of the DHCPv6 options as well as the expected provides an overview of the DHCPv6 options as well as the expected
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016
interactions between the HNA and the various involved entities. This interactions between the HNA and the various involved entities. This
section also provides an overview of available mechanisms to secure section also provides an overview of available mechanisms to secure
DNS transactions and update DNS data. Section 5 describes how the DNS transactions and update DNS data. Section 5 describes how the
HNA may securely synchronize and update DNS data. Section 6 HNA may securely synchronize and update DNS data. Section 6
describes the payload of the DHCPv6 options and Section 7 details how describes the payload of the DHCPv6 options and Section 7 details how
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
DHCPv6 client, server and relay agent behave. Section 8 lists the DHCPv6 client, server and relay agent behave. Section 8 lists the
new parameters to be registered at the IANA, Section 9 provides new parameters to be registered at the IANA, Section 9 provides
security considerations. Finally, Appendix A describes how the HNA security considerations. Finally, Appendix A describes how the HNA
may behave and be configured regarding various scenarios. may behave and be configured regarding various scenarios.
4. Protocol Overview 4. Protocol Overview
This section provides an overview of the HNA's interactions with the This section provides an overview of the HNA's interactions with the
Outsourcing Infrastructure in Section 4.1, and so the necessary for Outsourcing Infrastructure in Section 4.1, and so the necessary for
its setting. In this document, the configuration is provided via its setting. In this document, the configuration is provided via
skipping to change at page 7, line 4 skipping to change at page 6, line 49
latter in Appendix A. Such scenario does not necessarily require latter in Appendix A. Such scenario does not necessarily require
configuration for the end user and can also be zero-config. configuration for the end user and can also be zero-config.
The scenario is represented in Figure 1. The scenario is represented in Figure 1.
- 1: The HNA provides its Client Public Key to the DHCP Server using - 1: The HNA provides its Client Public Key to the DHCP Server using
a Client Public Key Option (OPTION_PUBLIC_KEY) and includes the a Client Public Key Option (OPTION_PUBLIC_KEY) and includes the
following option codes in its its Option Request Option (ORO): following option codes in its its Option Request Option (ORO):
Zone Template Option (OPTION_DNS_ZONE_TEMPLATE), the Zone Template Option (OPTION_DNS_ZONE_TEMPLATE), the
Synchronization Server Option (OPTION_SYNC_SERVER) and the Synchronization Server Option (OPTION_SYNC_SERVER) and the
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016
Reverse Synchronization Server Option Reverse Synchronization Server Option
(OPTION_REVERSE_SYNC_SERVER). (OPTION_REVERSE_SYNC_SERVER).
- 2: The DHCP Server makes the Client Public Key available to the - 2: The DHCP Server makes the Client Public Key available to the
DNS servers, so the HNA can secure its DNS transactions. How DNS servers, so the HNA can secure its DNS transactions. How
the Client Public Key is transmitted to the various DNS servers the Client Public Key is transmitted to the various DNS servers
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
is out of scope of this document. Note that the Client Public is out of scope of this document. Note that the Client Public
Key alone is not sufficient to perform the authentication and Key alone is not sufficient to perform the authentication and
the key should be, for example, associated with an identifier, the key should be, for example, associated with an identifier,
or the concerned domain name. How the binding is performed is or the concerned domain name. How the binding is performed is
out of scope of the document. It can be a centralized database out of scope of the document. It can be a centralized database
or various bindings may be sent to the different servers. or various bindings may be sent to the different servers.
Figure 1 represents the specific case where the DHCP Server Figure 1 represents the specific case where the DHCP Server
forwards the set (Client Public Key, Zone Template FQDN) to the forwards the set (Client Public Key, Zone Template FQDN) to the
DNS Template Server, the set (Client Public Key, IPv6 subnet) DNS Template Server, the set (Client Public Key, IPv6 subnet)
to the Reverse Synchronization Server and the set (Client to the Reverse Synchronization Server and the set (Client
skipping to change at page 8, line 4 skipping to change at page 7, line 48
- 5: Once the Homenet Reverse Zone has been set, the HNA uploads the - 5: Once the Homenet Reverse Zone has been set, the HNA uploads the
zone to the Reverse Synchronization Server. The Reverse zone to the Reverse Synchronization Server. The Reverse
Synchronization Server Option (OPTION_REVERSE_SYNC_SERVER) Synchronization Server Option (OPTION_REVERSE_SYNC_SERVER)
provides the Reverse Synchronization Server FQDN as well as the provides the Reverse Synchronization Server FQDN as well as the
upload method, and the Supported Authentication Methods upload method, and the Supported Authentication Methods
protocol to secure the upload. protocol to secure the upload.
- 6: Once the Homenet Zone has been set, the HNA uploads the zone to - 6: Once the Homenet Zone has been set, the HNA uploads the zone to
the Synchronization Server. The Synchronization Server Option the Synchronization Server. The Synchronization Server Option
(OPTION_SYNC_SERVER) provides the Synchronization Server FQDN (OPTION_SYNC_SERVER) provides the Synchronization Server FQDN
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016
as well as the upload method and the authentication method to as well as the upload method and the authentication method to
secure the upload. secure the upload.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
+---------------------+ +---------------------+
| DHCPv6 Server | | DHCPv6 Server |
+---------------------+ +---------------------+
^ ^ ^ ^ ^ ^
| | | | | |
1.| |3. |2. 1.| |3. |2.
| | | | | |
v v | v v |
+------+ | +--------------------------------+ +------+ | +--------------------------------+
| | 4. +--->| DNS Template Server | | | 4. +--->| DNS Template Server |
skipping to change at page 9, line 4 skipping to change at page 8, line 52
- Homenet Zone: every time a new device is connected, dis- - Homenet Zone: every time a new device is connected, dis-
connected. connected.
Step 2 and step 3 should be considered as independent steps and could Step 2 and step 3 should be considered as independent steps and could
be re-ordered. In fact, the DHCPv6 server does not have to wait for be re-ordered. In fact, the DHCPv6 server does not have to wait for
a confirmation from the DNS servers the Client Public Key has been a confirmation from the DNS servers the Client Public Key has been
properly received, and is operational by the DNS servers. The DHCP properly received, and is operational by the DNS servers. The DHCP
Server is expected to reply upon receiving the Client Public Key Server is expected to reply upon receiving the Client Public Key
Option. The reply to the message with a Client Public Key Option Option. The reply to the message with a Client Public Key Option
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016
from the DHCP Server is interpreted by the DHCPv6 client as a from the DHCP Server is interpreted by the DHCPv6 client as a
confirmation of the reception of the option by the DHCP Server only. confirmation of the reception of the option by the DHCP Server only.
It does not indicate whether the server had processed the option or It does not indicate whether the server had processed the option or
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
not. Debugging configurations errors or transmission error with one not. Debugging configurations errors or transmission error with one
of the DNS servers is let to the HNA and thus is outside of the scope of the DNS servers is let to the HNA and thus is outside of the scope
of the DHCPv6. First, it is unlikely a DNS server can validate that of the DHCPv6. First, it is unlikely a DNS server can validate that
the Client Public Key will be operational for the HNA, as multiple the Client Public Key will be operational for the HNA, as multiple
causes of errors could occur. For example, the Client Public Key may causes of errors could occur. For example, the Client Public Key may
have been changed during the transmission or by the DHCP Server, or have been changed during the transmission or by the DHCP Server, or
the DNS server may be misconfigured. Second, the number of error the DNS server may be misconfigured. Second, the number of error
codes would be too complex. In addition to multiple causes of codes would be too complex. In addition to multiple causes of
errors, multiple architectures and multiple DNS servers may be errors, multiple architectures and multiple DNS servers may be
involved. Third, this may cause significant DHCP Server performance involved. Third, this may cause significant DHCP Server performance
skipping to change at page 10, line 5 skipping to change at page 9, line 53
The key issue with TSIG is that a shared secret must be negotiated The key issue with TSIG is that a shared secret must be negotiated
between the HNA and the server. On the other hand, TSIG performs between the HNA and the server. On the other hand, TSIG performs
symmetric cryptography which is light in comparison with asymmetric symmetric cryptography which is light in comparison with asymmetric
cryptography used by SIG(0). As a result, over large zone transfer, cryptography used by SIG(0). As a result, over large zone transfer,
TSIG may be preferred to SIG(0). TSIG may be preferred to SIG(0).
This document does not provide means to distribute shared secret for This document does not provide means to distribute shared secret for
example using a specific DHCPv6 option. The only assumption made is example using a specific DHCPv6 option. The only assumption made is
that the HNA generates or is assigned a public key. that the HNA generates or is assigned a public key.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016
As a result, when the document specifies the transaction is secured As a result, when the document specifies the transaction is secured
with TSIG, it means that either the HNA and the DNS server have been with TSIG, it means that either the HNA and the DNS server have been
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
manually configured with a shared secret, or the shared secret has manually configured with a shared secret, or the shared secret has
been negotiated using TKEY [RFC2930], and the TKEY exchanged are been negotiated using TKEY [RFC2930], and the TKEY exchanged are
secured with SIG(0). secured with SIG(0).
Exchanges with the DNS Template Server to retrieve the Homenet Zone Exchanges with the DNS Template Server to retrieve the Homenet Zone
Template may be protected by SIG(0), TSIG or DNSSEC. When DNSSEC is Template may be protected by SIG(0), TSIG or DNSSEC. When DNSSEC is
used, it means the DNS Template Server only provides integrity used, it means the DNS Template Server only provides integrity
protection, and does not necessarily prevent someone else to query protection, and does not necessarily prevent someone else to query
the Homenet Zone Template. In addition, DNSSEC is only a way to the Homenet Zone Template. In addition, DNSSEC is only a way to
protect the AXFR queries transaction, in other words, DNSSEC cannot protect the AXFR queries transaction, in other words, DNSSEC cannot
skipping to change at page 11, line 4 skipping to change at page 10, line 52
[I-D.ietf-homenet-front-end-naming-delegation]. The primary / [I-D.ietf-homenet-front-end-naming-delegation]. The primary /
secondary mechanism is preferred as it better scales and avoids DoS secondary mechanism is preferred as it better scales and avoids DoS
attacks: First the primary notifies the secondary the zone must be attacks: First the primary notifies the secondary the zone must be
updated, and leaves the secondary to proceed to the update when updated, and leaves the secondary to proceed to the update when
possible. Then, the NOTIFY message sent by the primary is a small possible. Then, the NOTIFY message sent by the primary is a small
packet that is less likely to load the secondary. At last, the AXFR packet that is less likely to load the secondary. At last, the AXFR
query performed by the secondary is a small packet sent over TCP query performed by the secondary is a small packet sent over TCP
(section 4.2 [RFC5936]) which makes unlikely the secondary to perform (section 4.2 [RFC5936]) which makes unlikely the secondary to perform
reflection attacks with a forged NOTIFY. On the other hand, DNS reflection attacks with a forged NOTIFY. On the other hand, DNS
updates can use UDP, packets require more processing than a NOTIFY, updates can use UDP, packets require more processing than a NOTIFY,
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016
and they do not provide the server the opportunity to postpone the and they do not provide the server the opportunity to postpone the
update. update.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
5. HNA Configuration 5. HNA Configuration
5.1. HNA Primary / Secondary Synchronization Configurations 5.1. HNA Primary / Secondary Synchronization Configurations
The primary / secondary architecture is described in The primary / secondary architecture is described in
[I-D.ietf-homenet-front-end-naming-delegation]. The HNA hosts a [I-D.ietf-homenet-front-end-naming-delegation]. The HNA hosts a
Hidden Primary that synchronizes with a Synchronization Server or the Hidden Primary that synchronizes with a Synchronization Server or the
Reverse Synchronization Server. Reverse Synchronization Server.
When the HNA is plugged its IP address may be unknown to the When the HNA is plugged its IP address may be unknown to the
skipping to change at page 12, line 5 skipping to change at page 11, line 51
secret (TSIG) or the public key (SIG(0)). Once the NOTIFY has been secret (TSIG) or the public key (SIG(0)). Once the NOTIFY has been
authenticated, the Synchronization Servers might consider the source authenticated, the Synchronization Servers might consider the source
IP address of the NOTIFY query to configure the primaries attributes. IP address of the NOTIFY query to configure the primaries attributes.
5.1.2. HNA / Reverse Synchronization Server 5.1.2. HNA / Reverse Synchronization Server
The HNA is aware of the zone to be synchronized by looking at its The HNA is aware of the zone to be synchronized by looking at its
assigned prefix. The IP address of the secondary is provided by the assigned prefix. The IP address of the secondary is provided by the
Reverse Synchronization Server Option (OPTION_REVERSE_SYNC_SERVER). Reverse Synchronization Server Option (OPTION_REVERSE_SYNC_SERVER).
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016
Configuration of the secondary is performed as illustrated in Configuration of the secondary is performed as illustrated in
Section 5.1.1. Section 5.1.1.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
5.2. HNA DNS Data Handling and Update Policies 5.2. HNA DNS Data Handling and Update Policies
5.2.1. Homenet Zone Template 5.2.1. Homenet Zone Template
The Homenet Zone Template contains at least the related fields of the The Homenet Zone Template contains at least the related fields of the
Public Authoritative Server(s) as well as the Homenet Registered Public Authoritative Server(s) as well as the Homenet Registered
Domain, that is SOA, and NS fields. This template might be generated Domain, that is SOA, and NS fields. This template might be generated
automatically by the owner of the DHCP Server. For example, an ISP automatically by the owner of the DHCP Server. For example, an ISP
might provide a default Homenet Registered Domain as well as default might provide a default Homenet Registered Domain as well as default
Public Authoritative Server(s). This default settings should provide Public Authoritative Server(s). This default settings should provide
skipping to change at page 13, line 4 skipping to change at page 12, line 52
cases, the Homenet Zone might be generated without considering the cases, the Homenet Zone might be generated without considering the
Homenet Zone Template, but only considering specific configuration Homenet Zone Template, but only considering specific configuration
rules. rules.
In the current document the HNA only sets a single zone that is In the current document the HNA only sets a single zone that is
associated with one single Homenet Registered Domain. The domain associated with one single Homenet Registered Domain. The domain
might be assigned by the owner of the Homenet Zone Template. This might be assigned by the owner of the Homenet Zone Template. This
constraint does not prevent the HNA to use multiple domain names. constraint does not prevent the HNA to use multiple domain names.
How additional domains are considered is out of scope of this How additional domains are considered is out of scope of this
document. One way to handle these additional zones is to configure document. One way to handle these additional zones is to configure
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016
static redirections to the Homenet Zone using CNAME [RFC2181], static redirections to the Homenet Zone using CNAME [RFC2181],
[RFC1034], DNAME [RFC6672] or CNAME+DNAME [RFC1034], DNAME [RFC6672] or CNAME+DNAME
[I-D.sury-dnsext-cname-dname]. [I-D.sury-dnsext-cname-dname].
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
6. Payload Description 6. Payload Description
This section details the payload of the DHCPv6 options. A few DHCPv6 This section details the payload of the DHCPv6 options. A few DHCPv6
options are used to advertise a server the HNA may be expected to options are used to advertise a server the HNA may be expected to
interact with. Interaction may require to define update and interact with. Interaction may require to define update and
authentication methods. Update fields are shared by multiple DHCPv6 authentication methods. Update fields are shared by multiple DHCPv6
options and are described in separate sections. Section 6.1 options and are described in separate sections. Section 6.1
describes the Supported Authentication Method field, Section 6.2 describes the Supported Authentication Method field, Section 6.2
describes the Update field, the remaining Section 6.3, Section 6.4, describes the Update field, the remaining Section 6.3, Section 6.4,
Section 6.5, Section 6.6 describe the DHCPv6 options. Section 6.5, Section 6.6 describe the DHCPv6 options.
skipping to change at page 14, line 5 skipping to change at page 13, line 50
- SIG(0) (Bit 2): indicates, when set to 1, that transaction - SIG(0) (Bit 2): indicates, when set to 1, that transaction
protected by SIG(0) are supported. protected by SIG(0) are supported.
- TSIG (Bit 3): indicates, when set to 1, that transaction using - TSIG (Bit 3): indicates, when set to 1, that transaction using
TSIG is supported. Note that if a shared secret has not been TSIG is supported. Note that if a shared secret has not been
previously negotiated between the two party, it should be previously negotiated between the two party, it should be
negotiated using TKEY. The TKEY exchanges MUST be protected negotiated using TKEY. The TKEY exchanges MUST be protected
with SIG(0) even though SIG(0) is not supported. with SIG(0) even though SIG(0) is not supported.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016
- Remaining Bits (Bit 4-15): MUST be set to 0 by the DHCP Server - Remaining Bits (Bit 4-15): MUST be set to 0 by the DHCP Server
and MUST be ignored by the DHCPv6 client. and MUST be ignored by the DHCPv6 client.
A Supported Authentication Methods field with all bits set to zero A Supported Authentication Methods field with all bits set to zero
indicates the operation is not permitted. The Supported indicates the operation is not permitted. The Supported
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
Authentication Methods field may be set to zero when updates Authentication Methods field may be set to zero when updates
operations are not permitted for the DNS Homenet Template. In any operations are not permitted for the DNS Homenet Template. In any
other case this is an error. other case this is an error.
6.2. Update Field 6.2. Update Field
The Update Field of the DHCPv6 option is represented in Figure 3. It The Update Field of the DHCPv6 option is represented in Figure 3. It
indicates the update mechanism supported by the DNS server. See indicates the update mechanism supported by the DNS server. See
Section 4.3 for more details. Section 4.3 for more details.
skipping to change at page 15, line 5 skipping to change at page 15, line 5
6.4. Zone Template Option 6.4. Zone Template Option
The Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option indicates The Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option indicates
the HNA how to retrieve the Homenet Zone Template. It provides a the HNA how to retrieve the Homenet Zone Template. It provides a
FQDN the HNA SHOULD query with a DNS query of type AXFR as well as FQDN the HNA SHOULD query with a DNS query of type AXFR as well as
the authentication methods associated to the AXFR query or the the authentication methods associated to the AXFR query or the
nsupdate queries. Homenet Zone Template update, if permitted MUST nsupdate queries. Homenet Zone Template update, if permitted MUST
use the DNS Update mechanism. use the DNS Update mechanism.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
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_DNS_ZONE_TEMPLATE | option-len | | OPTION_DNS_ZONE_TEMPLATE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supp. Auth. Methods (axfr) | Supp. Auth. Methods (update) | | Supp. Auth. Methods (axfr) | Supp. Auth. Methods (update) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Zone Template FQDN / / Zone Template FQDN /
skipping to change at page 16, line 5 skipping to change at page 16, line 5
6.5. Synchronization Server Option 6.5. Synchronization Server Option
The Synchronization Server Option (OPTION_SYNC_SERVER) provides The Synchronization Server Option (OPTION_SYNC_SERVER) provides
information necessary for the HNA to upload the Homenet Zone to the information necessary for the HNA to upload the Homenet Zone to the
Synchronization Server. Finally, the option provides the Synchronization Server. Finally, the option provides the
authentication methods that are available to perform the upload. The authentication methods that are available to perform the upload. The
upload is performed via a DNS primary / secondary architecture or DNS upload is performed via a DNS primary / secondary architecture or DNS
updates. updates.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
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_SYNC_SERVER | option-len | | OPTION_SYNC_SERVER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Auth. Methods | Update | Server / | Supported Auth. Methods | Update | Server /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Port | | / Port | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
skipping to change at page 17, line 5 skipping to change at page 17, line 5
6.6. Reverse Synchronization Server Option 6.6. Reverse Synchronization Server Option
The Reverse Synchronization Server Option The Reverse Synchronization Server Option
(OPTION_REVERSE_SYNC_SERVER) provides information necessary for the (OPTION_REVERSE_SYNC_SERVER) provides information necessary for the
HNA to upload the Homenet Zone to the Synchronization Server. The HNA to upload the Homenet Zone to the Synchronization Server. The
option provides the authentication methods that are available to option provides the authentication methods that are available to
perform the upload. The upload is performed via a DNS primary / perform the upload. The upload is performed via a DNS primary /
secondary architecture or DNS updates. secondary architecture or DNS updates.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
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_SYNC_SERVER | option-len | | OPTION_REVERSE_SYNC_SERVER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Auth. Methods | Update | Server / | Supported Auth. Methods | Update | Server /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Port | | / Port | |
+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+ |
skipping to change at page 18, line 5 skipping to change at page 18, line 5
Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in Sections 17.2.2 and 18.2 of [RFC3315] 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 Zone Template particular, when configured the DHCP Server sends the Zone Template
Option, Synchronization Server Option, Reverse Synchronization Server Option, Synchronization Server Option, Reverse Synchronization Server
Option when requested by the DHCPv6 client by including necessary Option when requested by the DHCPv6 client by including necessary
option codes in its ORO. option codes in its ORO.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
The DHCP Server may receive a Client Public Key Option The DHCP Server may receive a Client Public Key Option
(OPTION_PUBLIC_KEY) from the HNA. Upon receipt of this DHCPv6 (OPTION_PUBLIC_KEY) from the HNA. Upon receipt of this DHCPv6
option, the DHCP Server SHOULD acknowledge the reception of the option, the DHCP Server SHOULD acknowledge the reception of the
Client Public Key Option as described in Section 4.1 and communicate Client Public Key Option as described in Section 4.1 and communicate
this credential to the available DNS Servers like the DNS Template this credential to the available DNS Servers like the DNS Template
Server, the Synchronization Server and the Reverse Synchronization Server, the Synchronization Server and the Reverse Synchronization
Server, unless not configured to do so. Server, unless not configured to do so.
A HNA may update its Client Public Key by sending a new value in the A HNA may update its Client Public Key by sending a new value in the
skipping to change at page 19, line 5 skipping to change at page 19, line 5
8. IANA Considerations 8. IANA Considerations
The DHCP options detailed in this document is: The DHCP options detailed in this document is:
- OPTION_DNS_ZONE_TEMPLATE: TBD1 - OPTION_DNS_ZONE_TEMPLATE: TBD1
- OPTION_SYNC_SERVER: TBD2 - OPTION_SYNC_SERVER: TBD2
- OPTION_REVERSE_SYNC_SERVER: TBD3 - OPTION_REVERSE_SYNC_SERVER: TBD3
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
9. Security Considerations 9. Security Considerations
9.1. DNSSEC is recommended to authenticate DNS hosted data 9.1. DNSSEC is recommended to authenticate DNS hosted data
It is recommended that the (Reverse) Homenet Zone is signed with It is recommended that the (Reverse) Homenet Zone is signed with
DNSSEC. The zone may be signed by the HNA or by a third party. We DNSSEC. The zone may be signed by the HNA or by a third party. We
recommend the zone to be signed by the HNA, and that the signed zone recommend the zone to be signed by the HNA, and that the signed zone
is uploaded. is uploaded.
skipping to change at page 20, line 4 skipping to change at page 20, line 4
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.
11. References 11. References
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
11.1. Normative References 11.1. Normative References
[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,
<http://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <http://www.rfc-editor.org/info/rfc1996>. August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc2136>. <https://www.rfc-editor.org/info/rfc2136>.
[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,
<http://www.rfc-editor.org/info/rfc2181>. <https://www.rfc-editor.org/info/rfc2181>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<http://www.rfc-editor.org/info/rfc2845>. <https://www.rfc-editor.org/info/rfc2845>.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000, RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000,
<http://www.rfc-editor.org/info/rfc2930>. <https://www.rfc-editor.org/info/rfc2930>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <http://www.rfc-editor.org/info/rfc2931>. 2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<http://www.rfc-editor.org/info/rfc3007>. <https://www.rfc-editor.org/info/rfc3007>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[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,
<http://www.rfc-editor.org/info/rfc4034>. <https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>. <https://www.rfc-editor.org/info/rfc4035>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<http://www.rfc-editor.org/info/rfc5936>. <https://www.rfc-editor.org/info/rfc5936>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[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,
<http://www.rfc-editor.org/info/rfc6672>. <https://www.rfc-editor.org/info/rfc6672>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
11.2. Informational References 11.2. Informational 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", draft-andrews-dnsop-pd- zones with Prefix Delegation", draft-andrews-dnsop-pd-
reverse-02 (work in progress), November 2013. reverse-02 (work in progress), November 2013.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
[I-D.ietf-dhc-sedhcpv6] [I-D.ietf-dhc-sedhcpv6]
Jiang, S., Li, L., Cui, Y., Jinmei, T., Lemon, T., and D. Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D.
Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-13 (work Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work
in progress), July 2016. in progress), February 2017.
[I-D.ietf-homenet-front-end-naming-delegation] [I-D.ietf-homenet-front-end-naming-delegation]
Migault, D., Weber, R., Hunter, R., Griffiths, C., and W. Migault, D., Weber, R., Hunter, R., Griffiths, C., and W.
Cloetens, "Outsourcing Home Network Authoritative Naming Cloetens, "Outsourcing Home Network Authoritative Naming
Service", draft-ietf-homenet-front-end-naming- Service", draft-ietf-homenet-front-end-naming-
delegation-04 (work in progress), September 2015. delegation-05 (work in progress), August 2016.
[I-D.sury-dnsext-cname-dname] [I-D.sury-dnsext-cname-dname]
Sury, O., "CNAME+DNAME Name Redirection", draft-sury- Sury, O., "CNAME+DNAME Name Redirection", draft-sury-
dnsext-cname-dname-00 (work in progress), April 2010. dnsext-cname-dname-00 (work in progress), April 2010.
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. the end user.
skipping to change at page 23, line 5 skipping to change at page 23, line 5
can provide authentication credentials of the HNA to enable secure can provide authentication credentials of the HNA to enable secure
authenticated transaction between the HNA and these DNS servers. authenticated transaction between the HNA and these DNS servers.
More specifically, credentials are provided to: More specifically, credentials are provided to:
- Synchronization Server - Synchronization Server
- Reverse Synchronization Server - Reverse Synchronization Server
- DNS Template Server - DNS Template Server
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
The HNA can update the zone using DNS update or a primary / secondary The HNA can update the zone using DNS update or a primary / secondary
configuration in a secure way. configuration in a secure way.
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. is configured automatically and transparently for the end user.
The drawbacks are that the end user uses a Registered Homenet Domain The 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.
skipping to change at page 24, line 5 skipping to change at page 24, line 5
the ISP naming infrastructure. Note that the only case this may be the ISP naming infrastructure. Note that the only case this may be
inconvenient is when the DNS Servers provided by the ISPs results in inconvenient is when the DNS Servers provided by the ISPs results in
high latency. 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 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.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
In this section we limit the outsourcing to the Synchronization In this section we limit the outsourcing to the Synchronization
Server and Public Authoritative Server(s) to a third party. All Server and Public Authoritative Server(s) to a third party. All
other DNS Servers DNS Template Server, Reverse Public Authoritative other DNS Servers DNS Template Server, Reverse Public Authoritative
Server(s) and Reverse Synchronization Server remain managed by the Server(s) and Reverse Synchronization Server remain managed by the
ISP. The reason we consider that Reverse Public Authoritative ISP. The reason we consider that Reverse Public Authoritative
Server(s) and Reverse Synchronization Server remains managed by the Server(s) and Reverse Synchronization Server remains managed by the
ISP are that the prefix is managed by the ISP, so outsourcing these ISP are that the prefix is managed by the ISP, so outsourcing these
resources requires some redirection agreement with the ISP. More resources requires some redirection agreement with the ISP. More
specifically the ISP will need to configure the redirection on one of specifically the ISP will need to configure the redirection on one of
skipping to change at page 25, line 5 skipping to change at page 25, line 5
Server and the third party, or a specific token that is plugged Server and the third party, or a specific token that is plugged
into the HNA, this operation is likely to be performed every into the HNA, this operation is likely to be performed every
time the HNA is changed, and every time the Client Public Key time the HNA is changed, and every time the Client Public Key
generated by the HNA is changed. generated by the HNA is changed.
The main advantage of this scenario is that the DNS infrastructure is The main advantage of this scenario is that the DNS infrastructure is
completely outsourced to the third party. Most likely the Client completely outsourced to the third party. Most likely the Client
Public Key that authenticate the HNA need to be configured for every Public Key that authenticate the HNA need to be configured for every
HNA. Configuration is expected to be HNA live-long. HNA. Configuration is expected to be HNA live-long.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
A.4. Multiple ISPs A.4. Multiple ISPs
This scenario considers a HNA connected to multiple ISPs. This scenario considers a HNA connected to multiple ISPs.
Firstly, suppose the HNA has been configured with the based scenarios Firstly, suppose the HNA has been configured with the based scenarios
exposed in Appendix A.1. The HNA has multiple interfaces, one for exposed in Appendix A.1. The HNA has multiple interfaces, one for
each ISP, and each of these interface is configured using DHCP. The each ISP, and each of these interface is configured using DHCP. The
HNA sends to each ISP its Client Public Key Option as well as a HNA sends to each ISP its Client Public Key Option as well as a
request for a Zone Template Option, a Synchronization Server Option request for a Zone Template Option, a Synchronization Server Option
skipping to change at page 26, line 5 skipping to change at page 26, line 5
ISP or a third party. Note that having multiple ISPs can be ISP or a third party. Note that having multiple ISPs can be
motivated for bandwidth aggregation, or connectivity fail-over. In motivated for bandwidth aggregation, or connectivity fail-over. In
the case of connectivity fail-over, the fail-over concerns the access the case of connectivity fail-over, the fail-over concerns the access
network and a failure of the access network may not impact the core network and a failure of the access network may not impact the core
network where the Synchronization Server and Public Authoritative network where the Synchronization Server and Public Authoritative
Primaries are hosted. In that sense, choosing one of the ISP even in Primaries are hosted. In that sense, choosing one of the ISP even in
a scenario of multiple ISPs may make sense. However, for sake of a scenario of multiple ISPs may make sense. However, for sake of
simplicity, this scenario assumes that a third party has be chosen to simplicity, this scenario assumes that a third party has be chosen to
host the Registered Homenet Domain. The DNS settings for each ISP is host the Registered Homenet Domain. The DNS settings for each ISP is
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
described in Appendix A.2 and Appendix A.3. With the configuration described in Appendix A.2 and Appendix A.3. With the configuration
described in Appendix A.2, the HNA is expect to be able to handle described in Appendix A.2, the HNA is expect to be able to handle
multiple Homenet Registered Domain, as the third party redirect to multiple Homenet Registered Domain, as the third party redirect to
one of the ISPs Servers. With the configuration described in one of the ISPs Servers. With the configuration described in
Appendix A.3, DNS zone are hosted and maintained by the third party. Appendix A.3, DNS zone are hosted and maintained by the third party.
A single DNS(SEC) Homenet Zone is built and maintained by the HNA. A single DNS(SEC) Homenet Zone is built and maintained by the HNA.
This latter configuration is likely to match most HNA This latter configuration is likely to match most HNA
implementations. implementations.
skipping to change at page 27, line 5 skipping to change at page 27, line 5
-03: Working Version Major modifications are: -03: Working Version Major modifications are:
- Redesigning options/scope: according to feed backs received from - Redesigning options/scope: according to feed backs received from
the IETF89 presentation in the dhc WG. the IETF89 presentation in the dhc WG.
- Redesigning architecture: according to feed backs received from - Redesigning architecture: according to feed backs received from
the IETF89 presentation in the homenet WG, discussion with Mark the IETF89 presentation in the homenet WG, discussion with Mark
and Lorenzo. and Lorenzo.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
-02: Working Version Major modifications are: -02: Working Version Major modifications are:
- Redesigning options/scope: As suggested by Bernie Volz - Redesigning options/scope: As suggested by Bernie Volz
-01: Working Version Major modifications are: -01: Working Version Major modifications are:
- Remove the DNS Zone file construction: As suggested by Bernie Volz - Remove the DNS Zone file construction: As suggested by Bernie Volz
- DHCPv6 Client behavior: Following options guide lines - DHCPv6 Client behavior: Following options guide lines
skipping to change at page 28, line 5 skipping to change at page 28, line 5
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Email: tomasz.mrugalski@gmail.com Email: tomasz.mrugalski@gmail.com
URI: http://www.isc.org URI: http://www.isc.org
Chris Griffiths Chris Griffiths
Email: cgriffiths@gmail.com Email: cgriffiths@gmail.com
Internet-DrafDHCPv6 Options for Homenet Naming Architecture August 2016 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2017
Ralf Weber Ralf Weber
Nominum Nominum
2000 Seaport Blvd #400 2000 Seaport Blvd #400
Redwood City, CA 94063 Redwood City, CA 94063
US US
Email: ralf.weber@nominum.com Email: ralf.weber@nominum.com
URI: http://www.nominum.com URI: http://www.nominum.com
 End of changes. 68 change blocks. 
85 lines changed or deleted 77 lines changed or added

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