draft-ietf-homenet-naming-architecture-dhc-options-06.txt   draft-ietf-homenet-naming-architecture-dhc-options-07.txt 
HOMENET D. Migault (Ed) Homenet D. Migault
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track T. Mrugalski Intended status: Standards Track R. Weber
Expires: December 27, 2018 ISC Expires: October 21, 2020 Akamai
T. Mrugalski
Internet Systems Consortium, Inc.
C. Griffiths C. Griffiths
R. Weber
Nominum
W. Cloetens W. Cloetens
SoftAtHome April 19, 2020
June 25, 2018
DHCPv6 Options for Homenet Naming Architecture DHCPv6 Options for Home Network Authoritative Naming Service
draft-ietf-homenet-naming-architecture-dhc-options-06 draft-ietf-homenet-naming-architecture-dhc-options-07
Abstract Abstract
The Homenet Naming Authority (HNA) is the designated device in charge This document defines DHCPv6 options so any agnostic Homnet Naming
of outsourcing the service to a third party, which requires setting Authority (HNA) can automatically proceed to the appropriate
up an architecture. configuration and outsource the authoritative naming service for the
home network. In most cases, the outsourcing mechanism is
Such settings may be inappropriate for most end users. This document transparent for the end user.
defines DHCPv6 options so any agnostic HNA can automatically proceed
to the appropriate configuration and outsource the authoritative
naming service for the home network. In most cases, the outsourcing
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 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 December 27, 2018. This Internet-Draft will expire on October 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2020 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
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Payload Description . . . . . . . . . . . . . . . . . . . . . 4
4.1. Architecture and DHCPv6 Options Overview . . . . . . . . 6 4.1. Client Public Key Option . . . . . . . . . . . . . . . . 5
4.2. Mechanisms Securing DNS Transactions . . . . . . . . . . 9 4.2. Distribution Master Option . . . . . . . . . . . . . . . 5
4.3. Primary / Secondary Synchronization versus DNS Update . . 10 4.3. Reverse Synchronization Server Option . . . . . . . . . . 6
5. HNA Configuration . . . . . . . . . . . . . . . . . . . . . . 11 5. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. HNA Primary / Secondary Synchronization Configurations . 11 5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7
5.1.1. HNA / Synchronization Server . . . . . . . . . . . . 11 5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 7
5.1.2. HNA / Reverse Synchronization Server . . . . . . . . 11 5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 8
5.2. HNA DNS Data Handling and Update Policies . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.2.1. Homenet Zone Template . . . . . . . . . . . . . . . . 12 7. Security Considerations" . . . . . . . . . . . . . . . . . . 8
5.2.2. DNS (Reverse) Homenet Zone . . . . . . . . . . . . . 12 7.1. DNSSEC is recommended to authenticate DNS hosted data . . 8
6. Payload Description . . . . . . . . . . . . . . . . . . . . . 13 7.2. Channel between the HNA and ISP DHCP Server MUST be
6.1. Supported Authentication Methods Field . . . . . . . . . 13 secured . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Update Field . . . . . . . . . . . . . . . . . . . . . . 14 7.3. HNAs are sensitive to DoS . . . . . . . . . . . . . . . . 8
6.3. Client Public Key Option . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
6.4. Zone Template Option . . . . . . . . . . . . . . . . . . 14 9. Scenarios and impact on the End User . . . . . . . . . . . . 9
6.5. Synchronization Server Option . . . . . . . . . . . . . . 15 10. Base Scenario . . . . . . . . . . . . . . . . . . . . . . . . 9
6.6. Reverse Synchronization Server Option . . . . . . . . . . 16 10.1. Third Party Registered Homenet Domain . . . . . . . . . 9
7. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 17 10.2. Third Party DNS Infrastructure . . . . . . . . . . . . . 10
7.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 17 10.3. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . 11
7.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. DNSSEC is recommended to authenticate DNS hosted data . . 19
9.2. Channel between the HNA and ISP DHCP Server MUST be
secured . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.3. HNAs are sensitive to DoS . . . . . . . . . . . . . . . . 19
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informational References . . . . . . . . . . . . . . . . 21
Appendix A. Scenarios and impact on the End User . . . . . . . . 22
A.1. Base Scenario . . . . . . . . . . . . . . . . . . . . . . 22
A.2. Third Party Registered Homenet Domain . . . . . . . . . . 23
A.3. Third Party DNS Infrastructure . . . . . . . . . . . . . 23
A.4. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Requirements notation 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
2. Terminology capitals, as shown here.
The reader is expected to be familiar with The reader is expected to be familiar with
[I-D.ietf-homenet-front-end-naming-delegation] and its terminology [I-D.ietf-homenet-front-end-naming-delegation] and its terminology
section. This section defines terms that have not been defined in section. This section defines terms that have not been defined in
[I-D.ietf-homenet-front-end-naming-delegation]: [I-D.ietf-homenet-front-end-naming-delegation]:
- Client Public Key: designates a public key generated by the HNA. o Client Public Key: designates a public key generated by the HNA
This key is used as an authentication credential for the HNA. and used as an authentication credential for the HNA.
- Homenet Zone Template: The template used as a basis to generate
the Homenet Zone.
- DNS Template Server: The DNS server that hosts the Homenet Zone
Template.
- Homenet Reverse Zone: The reverse zone file associated to the
Homenet Zone.
3. Introduction
HNAs are usually constrained devices with reduced network and CPU
capacities. As such, a HNA hosting on the Internet the authoritative
naming service for its home network may become vulnerable to resource
exhaustion attacks. Outsourcing the authoritative service to a third
party avoids exposing the HNA to such attacks. This third party can
be the ISP or any other independent third party.
Outsourcing the authoritative naming service to a third party
requires setting up an architecture designated in this document as
the Outsourcing Infrastructure. These settings may be inappropriate
for most end users that do not have the sufficient knowledge. To
address this issue, this document proposes DHCPv6 options so any
agnostic HNA can automatically set the Outsourcing Infrastructure.
In most cases, these DHCPv6 options are sufficient and do not require
any additional interaction from the end user, thus achieving a zero-
config settings. In some other cases, the end user is expected to
perform some limited manual configuration.
When the HNA is plugged, the DHCPv6 options described in the document
enable:
- 1. To build the Homenet Zone: Building the Homenet Zone requires
filling the zone with appropriated bindings such as bindings
between the names and the IP addresses of the different devices
of the home networks. How the HNA is aware of these binding is
out of scope of the document. They may be provided, for
example, by the DHCPv6 server hosted on the HNA. On the other
hand, building the Homenet Zone also requires configuration
parameters like the name of the Registered Domain Name
associated to the home network or the Public Authoritative
Server(s) the Homenet Zone is outsourced to. These
configuration parameters are stored in the Homenet Zone
Template. This document describes the Zone Template Option
which carries the FQDN associated to the Homenet Zone Template.
In order to retrieve the Homenet Zone Template, the HNA sends a
query of type AXFR [RFC1034], [RFC5936].
- 2. To upload the Homenet Zone to the Synchronization Server, in
charge of publishing the Homenet Zone on the Public
Authoritative Server(s). This document describes the
Synchronization Server Option that provides the FQDN of the
appropriated server. Note that, the document does not consider
whether the Homenet Zone is signed or not, and if signed, which
entity is responsible to sign it. Such questions are out of
the scope of the current document.
- 3. To upload the Homenet Reverse Zone to the Reverse
Synchronization Server in charge of publishing the Homenet
Reverse Zone on the Reverse Public Authoritative Server(s).
This document describes the Reverse Synchronization Server
Option that provides the FQDN of the appropriated server.
Similarly to item 2., we do not consider in this document if
the Homenet Reverse Zone is signed or not, and if signed who
signs it.
- 4. To provide authentication credential (a public key) to the DHCP 2. Introduction
Server: Information stored in the Homenet Zone Template, the
Homenet Zone and Homenet Reverse Zone belongs to the HNA, and
only the HNA should be able to update or upload these zones.
To authenticate the HNA, this document defines the Client
Public Key Option. This option is sent by the HNA to the
DHCPv6 server and provides the Client Public Key the HNA uses
to authenticate itself. This document does not describe
mechanisms used to transmit the Client Public Key from the
DHCPv6 server to the appropriate entities. If the DHCPv6
server is not able to provide the Client Public Key to the
appropriated entities, then the end user is likely to provide
manually the Client Public Key to these entities. This
document illustrates two scenarios: one where the DHCPv6 server
is responsible for distributing the Client Public Key to the
Synchronization Servers and Reverse Synchronization Server. In
the other scenarios, the Client Public Key is distributed out
of band.
The DHCPv6 options described in this document make possible to [I-D.ietf-homenet-front-end-naming-delegation] describes how Homenet
configure an Outsourcing Infrastructure with no or little Naming Authority (HNA) outsources the Public Homenet Zone to an
configurations from the end user. A zero-config setting is achieved Outsourcing Infrastructure.
if the the link between the HNA and the DHCPv6 server and the link
between the DHCPv6 server and the various DNS servers (Homenet Zone
Server, the Reverse Synchronization Server, Synchronization Server)
are trusted. For example, one way to provide a thrustworhy
connection between the HNA and the DHCPv6 server is defined in
[I-D.ietf-dhc-sedhcpv6]. When both links are trusted, the HNA is
able to provide its authentication credentials (a Client Public Key)
to the DHCPv6 server, that in turn forwards it to the various DNS
servers. With the authentication credentials on the DNS servers, the
HNA is able to securely update.
If the DHCPv6 server cannot provide the Client Public Key to one of In most cases the setting of the relation between the HNA and the
these servers (most likely the Synchronization Server) and the HNA Outsourcing Infrastructure is not fully automated and involves the
needs to interact with the server, then, the end user is expected to end user. More specifically, the Outsourcing Infrastructure needs to
provide the HNA's Client Public Key to these servers (the Reverse be able to authenticate the HNA as well as needs to ensure the HNA
Synchronization Server or the Synchronization Server) either manually owns the Registered Homenet Domain. As a result, the Outsourcing
or using other mechanisms. Such mechanisms are outside the scope of Infrastructure is likely to be provided by a registrar.
this document. In that case, the authentication credentials need to
be provided every time the key is modified. Appendix A provides more
details on how different scenarios impact the end users.
The remaining of this document is structured as follows. Section 4 This document describes DHCPv6 options that leverage a relation
provides an overview of the DHCPv6 options as well as the expected between the ISP and an end user to fully automated these steps. This
interactions between the HNA and the various involved entities. This enables an end user to provide the home network configuration to the
section also provides an overview of available mechanisms to secure DHCPv6 server, so an HNA can outsource without any configuration. In
DNS transactions and update DNS data. Section 5 describes how the this case, outsourcing is achieved with zero-config and is resilient
HNA may securely synchronize and update DNS data. Section 6 to HNA change. This may provide the ability for an ISP to provide a
describes the payload of the DHCPv6 options and Section 7 details how default outsourcing service to its customers, however this service
DHCPv6 client, server and relay agent behave. Section 8 lists the can be used by the end user for any specific Homenet registered
new parameters to be registered at the IANA, Section 9 provides domain, not just the ones provided by the ISP and as such benefits
security considerations. Finally, Appendix A describes how the HNA the end user.
may behave and be configured regarding various scenarios.
4. Protocol Overview The overall principle is that the HNA advertises the DHCPv6 server of
its Public Key. This Public Key will be used by the HNA for the
authentication during the TLS key exchange between the HNA and the
Distribution Master (DM) of the Public Homenet Zone and the Reverse
Homenet Zone. Note that a specific relation between the DHCPv6
server and the DM is required. When the DHCPv6 server is managed by
the ISP, such relation exist between DHCPv6 server and the DM of the
Reverse Homenet Zone. Such relation may also exist - but not
necessarily - between the DHCPv6 server and the DM of the Public
Homenet Zone. The DHCHv6 server provides the HNA the FQDN and Public
Keys of the respective DMs.
This section provides an overview of the HNA's interactions with the This document assumes the link between the HNA and the DHCPv6 server
Outsourcing Infrastructure in Section 4.1, and so the necessary for is trustworthy for example using [I-D.ietf-dhc-sedhcpv6].
its setting. In this document, the configuration is provided via
DHCPv6 options. Once configured, the HNA is expected to be able to
update and publish DNS data on the different components of the
Outsourcing Infrastructure. As a result authenticating and updating
mechanisms play an important role in the specification. Section 4.2
provides an overview of the different authentication methods and
Section 4.3 provides an overview of the different update mechanisms
considered to update the DNS data.
4.1. Architecture and DHCPv6 Options Overview 3. Protocol Overview
This section illustrates how a HNA receives the necessary information This section illustrates how a HNA receives the necessary information
via DHCPv6 options to outsource its authoritative naming service on via DHCPv6 options to outsource its authoritative naming service on
the Outsourcing Infrastructure. For the sake of simplicity, this the Outsourcing Infrastructure. For the sake of simplicity, this
section assumes that the DHCPv6 server is able to communicate to the section assumes that the DHCPv6 server is able to communicate to the
various DNS servers and to provide them the public key associated various DNS servers and to provide them the public key associated
with the HNA. Once each server got the public key, the HNA can with the HNA. Once each server got the public key, the HNA can
proceed to transactions in an authenticated and secure way. proceed to transactions in an authenticated and secure way.
This scenario has been chosen as it is believed to be the most This scenario has been chosen as it is believed to be the most
popular scenario. This document does not ignore that scenarios where popular scenario. This document does not ignore scenarios where the
the DHCP Server does not have privileged relations with the DHCP Server does not have privileged relations with the DM.
Synchronization Server must be considered. These cases are discussed
latter in Appendix A. Such scenario does not necessarily require
configuration for the end user and can also be zero-config.
The scenario is represented in Figure 1.
- 1: The HNA provides its Client Public Key to the DHCP Server using
a Client Public Key Option (OPTION_PUBLIC_KEY) and includes the
following option codes in its its Option Request Option (ORO):
Zone Template Option (OPTION_DNS_ZONE_TEMPLATE), the
Synchronization Server Option (OPTION_SYNC_SERVER) and the
Reverse Synchronization Server Option
(OPTION_REVERSE_SYNC_SERVER).
- 2: The DHCP Server makes the Client Public Key available to the
DNS servers, so the HNA can secure its DNS transactions. How
the Client Public Key is transmitted to the various DNS servers
is out of scope of this document. Note that the Client Public
Key alone is not sufficient to perform the authentication and
the key should be, for example, associated with an identifier,
or the concerned domain name. How the binding is performed is
out of scope of the document. It can be a centralized database
or various bindings may be sent to the different servers.
Figure 1 represents the specific case where the DHCP Server
forwards the set (Client Public Key, Zone Template FQDN) to the
DNS Template Server, the set (Client Public Key, IPv6 subnet)
to the Reverse Synchronization Server and the set (Client
Public Key, Registered Homenet Domain) to the Synchronization
Server.
- 3: The DHCP Server responds to the HNA with the requested DHCPv6
options, i.e. the Client Public Key Option (OPTION_PUBLIC_KEY),
Zone Template Option OPTION_DNS_ZONE_TEMPLATE, Synchronization
Server Option (OPTION_SYNC_SERVER), Reverse Synchronization
Server Option (OPTION_REVERSE_SYNC_SERVER). Note that this
step may be performed in parallel to step 2, or even before.
In other words, there is no requirements that step 3 is
conducted after step 2.
- 4: Upon receiving the Zone Template Option
(OPTION_DNS_ZONE_TEMPLATE), the HNA performs an AXFR DNS query
for the Zone Template FQDN. The exchange is authenticated
according to the authentication methods defined in the
Supported Authentication Methods field of the DHCP option.
Once the HNA has retrieved the DNS Zone Template, the HNA can
build the Homenet Zone and the Homenet Reverse Zone.
Eventually the HNA signs these zones.
- 5: Once the Homenet Reverse Zone has been set, the HNA uploads the
zone to the Reverse Synchronization Server. The Reverse
Synchronization Server Option (OPTION_REVERSE_SYNC_SERVER)
provides the Reverse Synchronization Server FQDN as well as the
upload method, and the Supported Authentication Methods
protocol to secure the upload.
- 6: Once the Homenet Zone has been set, the HNA uploads the zone to
the Synchronization Server. The Synchronization Server Option
(OPTION_SYNC_SERVER) provides the Synchronization Server FQDN
as well as the upload method and the authentication method to
secure the upload.
+---------------------+
| DHCPv6 Server |
+---------------------+
^ ^ ^
| | |
1.| |3. |2.
| | |
v v |
+------+ | +--------------------------------+
| | 4. +--->| DNS Template Server |
| |<---------->| |
| | | +--------------------------------+
| HNA | |
| | | +--------------------------------+
| | 5./6. +--->| Reverse Synchronization |
| |<---------->| Server |
| | | +--------------------------------+
| | |
| | | +--------------------------------+
+------+ +--->| Synchronization Server |
| |
+--------------------------------+
Figure 1: Protocol Overview
As described above, the HNA is likely to interact with various DNS
content. More specifically, the HNA is likely to update the:
- Homenet Zone Template: if the configuration of the zone may be
changed. This may include additional Public Authoritative
Server(s), a different Registered Homenet Domain as the one
initially proposed, or a redirection to another domain.
- Homenet Reverse Zone: every time a new device is connected or
dis-connected.
- Homenet Zone: every time a new device is connected, dis-
connected.
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
a confirmation from the DNS servers the Client Public Key has been
properly received, and is operational by the DNS servers. The DHCP
Server is expected to reply upon receiving the Client Public Key
Option. The reply to the message with a Client Public Key Option
from the DHCP Server is interpreted by the DHCPv6 client as a
confirmation of the reception of the option by the DHCP Server only.
It does not indicate whether the server had processed the option or
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 DHCPv6. First, it is unlikely a DNS server can validate that
the Client Public Key will be operational for the HNA, as multiple
causes of errors could occur. For example, the Client Public Key may
have been changed during the transmission or by the DHCP Server, or
the DNS server may be misconfigured. Second, the number of error
codes would be too complex. In addition to multiple causes of
errors, multiple architectures and multiple DNS servers may be
involved. Third, this may cause significant DHCP Server performance
degradation.
In fact, the HNA performs these updates in a secure manner. There
are multiple ways to secure a DNS transaction and this document
considers two mechanisms: nsupdate and primary/secondary
synchronization. Section 4.2 describes the authentication method
that may be use to secure the DNS transactions of the HNA. The
appropriate authentication methods may, for example, be chosen
according to the level of confidentiality or the level of
authentication requested by the HNA transactions. Section 4.3
positions the nsupdate and primary/secondary synchronization
mechanisms. The update appropriate update mechanism may depend on
the for example on the update frequency or the size of the DNS data
to update.
4.2. Mechanisms Securing DNS Transactions
Multiple protocols like IPsec [RFC4301] or TLS / DTLS [RFC5246] /
[RFC6347] may be used to secure DNS transactions between the HNA and
the DNS servers. This document limits its scope to authentication
method that have been designed specifically for DNS. This includes
DNSSEC [RFC4033], [RFC4034], [RFC4035] that authenticates and
provides integrity protection of DNS data, TSIG [RFC2845], [RFC2930]
that use a shared secret to secure a transaction between two end
points and SIG(0) [RFC2931] authenticates the DNS packet exchanged.
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
symmetric cryptography which is light in comparison with asymmetric
cryptography used by SIG(0). As a result, over large zone transfer,
TSIG may be preferred to SIG(0).
This document does not provide means to distribute shared secret for
example using a specific DHCPv6 option. The only assumption made is
that the HNA generates or is assigned a public key.
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
manually configured with a shared secret, or the shared secret has
been negotiated using TKEY [RFC2930], and the TKEY exchanged are
secured with SIG(0).
Exchanges with the DNS Template Server to retrieve the Homenet Zone
Template may be protected by SIG(0), TSIG or DNSSEC. When DNSSEC is
used, it means the DNS Template Server only provides integrity
protection, and does not necessarily prevent someone else to query
the Homenet Zone Template. In addition, DNSSEC is only a way to
protect the AXFR queries transaction, in other words, DNSSEC cannot
be used to secure updates. If DNSSEC is used to provide integrity
protection for the AXFR response, the HNA should proceed to the
DNSSEC signature checks. If signature check fails, it MUST reject
the response. If the signature check succeeds, the HNA removes all
DNSSEC related RRsets (DNSKEY, RRSIG, NSEC* ...) before building the
Homenet Zone. In fact, these DNSSEC related fields are associated to
the Homenet Zone Template and not the Homenet Zone.
Any update exchange should use SIG(0) or TSIG to authenticate the
exchange.
4.3. Primary / Secondary Synchronization versus DNS Update
As updates only concern DNS zones, this document only considers DNS
update mechanisms such as DNS update [RFC2136] [RFC3007] or a
primary / secondary synchronization.
The Homenet Zone Template SHOULD be updated with DNS update as it
contains static configuration data that is not expected to evolve
over time.
The Homenet Reverse Zone and the Homenet Zone can be updated either
with DNS update or using a primary / secondary synchronization. As
these zones may be large, with frequent updates, we recommend to use
the primary / secondary architecture as described in
[I-D.ietf-homenet-front-end-naming-delegation]. The primary /
secondary mechanism is preferred as it better scales and avoids DoS
attacks: First the primary notifies the secondary the zone must be
updated, and leaves the secondary to proceed to the update when
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
query performed by the secondary is a small packet sent over TCP
(section 4.2 [RFC5936]) which makes unlikely the secondary to perform
reflection attacks with a forged NOTIFY. On the other hand, DNS
updates can use UDP, packets require more processing than a NOTIFY,
and they do not provide the server the opportunity to postpone the
update.
5. HNA Configuration
5.1. HNA Primary / Secondary Synchronization Configurations
The primary / secondary architecture is described in
[I-D.ietf-homenet-front-end-naming-delegation]. The HNA hosts a
Hidden Primary that synchronizes with a Synchronization Server or the
Reverse Synchronization Server.
When the HNA is plugged its IP address may be unknown to the
secondary. The section details how the HNA or primary communicates
the necessary information to set up the secondary.
In order to set the primary / secondary configuration, both primary
and secondaries must agree on 1) the zone to be synchronized, 2) the
IP address and ports used by both primary and secondary.
5.1.1. HNA / Synchronization Server
The HNA is aware of the zone to be synchronized by reading the
Registered Homenet Domain in the Homenet Zone Template provided by
the Zone Template Option (OPTION_DNS_ZONE_TEMPLATE). The IP address
of the secondary is provided by the Synchronization Server Option
(OPTION_SYNC_SERVER).
The Synchronization Server has been configured with the Registered
Homenet Domain and the Client Public Key that identifies the HNA.
The only missing information is the IP address of the HNA. This IP
address is provided by the HNA by sending a NOTIFY [RFC1996].
When the HNA has built its Homenet Zone, it sends a NOTIFY message to
the Synchronization Servers. Upon receiving the NOTIFY message, the
secondary reads the Registered Homenet Domain and checks the NOTIFY
is sent by the authorized primary. This can be done using the shared
secret (TSIG) or the public key (SIG(0)). Once the NOTIFY has been
authenticated, the Synchronization Servers might consider the source
IP address of the NOTIFY query to configure the primaries attributes.
5.1.2. HNA / Reverse Synchronization Server
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
Reverse Synchronization Server Option (OPTION_REVERSE_SYNC_SERVER).
Configuration of the secondary is performed as illustrated in
Section 5.1.1.
5.2. HNA DNS Data Handling and Update Policies
5.2.1. Homenet Zone Template
The Homenet Zone Template contains at least the related fields of the
Public Authoritative Server(s) as well as the Homenet Registered
Domain, that is SOA, and NS fields. This template might be generated
automatically by the owner of the DHCP Server. For example, an ISP
might provide a default Homenet Registered Domain as well as default
Public Authoritative Server(s). This default settings should provide
the HNA the necessary pieces of information to set the homenet naming
architecture.
If the Homenet Zone Template is not subject to modifications or
updates, the owner of the template might only use DNSSEC to enable
integrity check.
On the other hand, the Homenet Zone Template might also be subject to
modification by the HNA. The advantage of using the standard DNS
zone format is that standard DNS update mechanism can be used to
perform updates. These updates might be accepted or rejected by the
owner of the Homenet Zone Template. Policies that defines what is
accepted or rejected is out of scope of this document. However, this
document assumes the Registered Homenet Domain is used as an index by
the Synchronization Server, and SIG(0), TSIG are used to authenticate
the HNA. As a result, the Registered Homenet Domain should not be
modified unless the Synchronization Server can handle with it.
5.2.2. DNS (Reverse) Homenet Zone
The Homenet Zone might be generated from the Homenet Zone Template.
How the Homenet Zone is generated is out of scope of this document.
In some cases, the Homenet Zone might be the exact copy of the
Homenet Zone Template. In other cases, it might be generated from
the Homenet Zone Template with additional RRsets. In some other
cases, the Homenet Zone might be generated without considering the
Homenet Zone Template, but only considering specific configuration
rules.
In the current document the HNA only sets a single zone that is
associated with one single Homenet Registered Domain. The domain
might be assigned by the owner of the Homenet Zone Template. This
constraint does not prevent the HNA to use multiple domain names.
How additional domains are considered is out of scope of this
document. One way to handle these additional zones is to configure
static redirections to the Homenet Zone using CNAME [RFC2181],
[RFC1034], DNAME [RFC6672] or CNAME+DNAME
[I-D.sury-dnsext-cname-dname].
6. Payload Description
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
interact with. Interaction may require to define update and
authentication methods. Update fields are shared by multiple DHCPv6
options and are described in separate sections. Section 6.1
describes the Supported Authentication Method field, Section 6.2
describes the Update field, the remaining Section 6.3, Section 6.4,
Section 6.5, Section 6.6 describe the DHCPv6 options.
6.1. Supported Authentication Methods Field
The Supported Authentication Methods field of the DHCPv6 option
represented in Figure 2 indicates the authentication method supported
by the DNS server. One of these mechanism MUST be chosen by the HNA
in order to perform a transaction with the DNS server. See
Section 4.2 for more details.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Auth. Methods |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Supported Authentication Methods Filed
- DNS (Bit 0): indicates, when set to 1, that DNS without any
security extension is supported.
- DNSSEC (Bit 1): indicates, when set to 1, that DNSSEC provides
integrity protection. This can only be used for read
operations like retrieving the Homenet Zone Template.
- SIG(0) (Bit 2): indicates, when set to 1, that transaction
protected by SIG(0) are supported.
- TSIG (Bit 3): indicates, when set to 1, that transaction using
TSIG is supported. Note that if a shared secret has not been
previously negotiated between the two party, it should be
negotiated using TKEY. The TKEY exchanges MUST be protected
with SIG(0) even though SIG(0) is not supported.
- Remaining Bits (Bit 4-15): MUST be set to 0 by the DHCP Server
and MUST be ignored by the DHCPv6 client.
A Supported Authentication Methods field with all bits set to zero These cases are discussed latter in Section 9. Such scenario does
indicates the operation is not permitted. The Supported not necessarily require configuration for the end user and can also
Authentication Methods field may be set to zero when updates be zero-config.
operations are not permitted for the DNS Homenet Template. In any
other case this is an error.
6.2. Update Field The scenario is as follows:
The Update Field of the DHCPv6 option is represented in Figure 3. It o 1) The HNA provides its Client Public Key to the DHCP Server using
indicates the update mechanism supported by the DNS server. See a Client Public Key Option (OPTION_PUBLIC_KEY) and includes the
Section 4.3 for more details. following option codes in its its Option Request Option (ORO): the
Distribution Master Option (OPTION_DM) and the Reverse
Distribution Master Option (OPTION_REVERSE_DM).
0 o 2) The DHCP Server makes the Client Public Key available to the DM
0 1 2 3 4 5 6 7 servers, so the HNA can secure its DNS transactions. How the
+-+-+-+-+-+-+-+-+ Client Public Key is transmitted to the various DNS servers is out
| Update | of scope of this document. Note that the Client Public Key alone
+-+-+-+-+-+-+-+-+ is not sufficient to perform the authentication and the key should
be, for example, associated with an identifier, or the concerned
domain name. How the binding is performed is out of scope of the
document. It can be a centralized database or various bindings
may be sent to the different servers.
Figure 3: Update Field o 3) The DHCP Server responds to the HNA with the requested DHCPv6
options, i.e. the Distribution Master Option (OPTION_DM) and the
Reverse Distribution Master Option (OPTION_REVERSE_DM).
- Primary / Secondary (Bit 0): indicates, when set to 1, that DNS o 4) Once the Homenet Zone has been set, the HNA uploads the zone to
Server supports data synchronization using a Primary / the respective DMs.
Secondary mechanism.
- DNS Update (Bit 1): indicates, when set to 1, that DNS Server 4. Payload Description
supports data synchronization using DNS Updates.
- Remaining Bits (Bit 2-7): MUST be set to 0 by the DHCPv6 server This section details the payload of the DHCPv6 options.
and MUST be ignored by the DHCPv6 client.
6.3. Client Public Key Option 4.1. Client Public Key Option
The Client Public Key Option (OPTION_PUBLIC_KEY) indicates the Client The Client Public Key Option (OPTION_PUBLIC_KEY) indicates the Client
Public Key that is used to authenticate the HNA. This option is Public Key that is used to authenticate the HNA. This option is
defined in [I-D.ietf-dhc-sedhcpv6]. defined in [I-D.ietf-dhc-sedhcpv6].
6.4. Zone Template Option
The Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option indicates
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
the authentication methods associated to the AXFR query or the
nsupdate queries. Homenet Zone Template update, if permitted MUST
use the DNS Update mechanism.
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_PUBLIC_KEY | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supp. Auth. Methods (axfr) | Supp. Auth. Methods (update) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Zone Template FQDN / / Public Key Data /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Zone Template Option { #fig-public-key title="Client Public Key Option"}
- option-code: (16 bits): OPTION_DNS_ZONE_TEMPLATE, the option code
for the Zone Template Option (TBD1).
- option-len (16 bits): length in octets of the option-data field as
described in [RFC3315].
- Supported Authentication Methods(axfr) (16 bits): defines which o option-code (16 bits): OPTION_PUBLIC_KEY, the option code for the
authentication methods are supported by the DNS server. This Client Public Key Option (TBD1).
field concerns the AXFR and consultation queries, not the
update queries. See Section 6.1 for more details.
- Supported Authentication Methods (16 bits): defines which o option-len (16 bits): length in octets of the option-data field as
authentication methods are supported by the DNS server. This described in [RFC3315].
field concerns the update. See Section 6.1 for more details.
- Zone Template FQDN FQDN (variable): the FQDN of the DNS server o Client Public Key Data: contains the Client Public Key. The format
hosting the Homenet Zone Template. is the DNSKEY RDATA format as defined in [RFC4034].
6.5. Synchronization Server Option 4.2. Distribution Master 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.
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_DIST_MASTER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Auth. Methods | Update | Server /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Port | | | Server Port | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Synchronization Server FQDN / / DM FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{ #fig-name-srv-set title="Synchronization Server Option"}
Figure 5: Synchronization Server Option o option-code (16 bits): OPTION_SYNC_SERVER, the option code for the
Synchronization Server Option (TBD2).
- option-code (16 bits): OPTION_SYNC_SERVER, the option code for the
Synchronization Server Option (TBD2).
- option-len (16 bits): length in octets of the option-data field as
described in [RFC3315].
- Supported Authentication Methods (16 bits): defines which
authentication methods are supported by the DNS server. See
Section 6.1 for more details.
- Update (8 bits): defines which update mechanisms are supported by o option-len (16 bits): length in octets of the option-data field as
the DNS server. See Section 4.3 for more details. described in [RFC3315].
- Server Port (16 bits): defines the port the Synchronization Server o Server Port (16 bits): defines the port the Synchronization Server
is listening. When multiple transport layers may be used, a is listening. When multiple transport layers may be used, a
single and unique Server Port value applies to all the single and unique Server Port value applies to all the transport
transport layers. In the case of DNS for example, Server Port layers. In the case of DNS for example, Server Port value
value considers DNS exchanges using UDP and TCP. considers DNS exchanges using UDP and TCP.
- Synchronization Server FQDN (variable): the FQDN of the o Synchronization Server FQDN (variable): the FQDN of the
Synchronization Server. Synchronization Server.
6.6. Reverse Synchronization Server Option 4.3. 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.
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_DIST_MASTER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Auth. Methods | Update | Server /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Port | | | Server Port | |
+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Reverse Synchronization Server FQDN / / Reverse DM FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Reverse Synchronization Server Option Figure 1: Reverse Synchronization Server Option
- option-code (16 bits): OPTION_REVERSE_SYNC_SERVER, the option code
for the Reverse Synchronization Server Option (TBD3).
- option-len (16 bits): length in octets of the option-data field as
described in [RFC3315].
- Supported Authentication Methods (16 bits): defines which o option-code (16 bits): OPTION_REVERSE_SYNC_SERVER, the option code
authentication methods are supported by the DNS server. See for the Reverse Synchronization Server Option (TBD3).
Section 6.1 for more details.
- Update (8 bits): defines which update mechanisms are supported by o option-len (16 bits): length in octets of the option-data field as
the DNS server. See Section 4.3 for more details. described in [RFC3315].
- Server Port (16 bits): defines the port the Synchronization Server o Server Port (16 bits): defines the port the Synchronization Server
is listening. is listening.
- Reverse Synchronization Server FQDN (variable): The FQDN of the o Reverse Synchronization Server FQDN (variable): The FQDN of the
Reverse Synchronization Server. Reverse Synchronization Server.
7. DHCP Behavior 5. DHCP Behavior
7.1. DHCPv6 Server Behavior 5.1. DHCPv6 Server Behavior
Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in Sections 17.2.2 and 18.2 of [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.
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 and communicate this credential
this credential to the available DNS Servers like the DNS Template to the available DM and Reverse DM unless not configured to do so.
Server, the Synchronization Server and the Reverse Synchronization
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
Client Public Key Option (OPTION_PUBLIC_KEY) as this document assumes Client Public Key Option (OPTION_PUBLIC_KEY) as this document assumes
the link between the HNA and the DHCP Server is considered the link between the HNA and the DHCP Server is considered
authenticated and trusted. The server SHOULD process received Client authenticated and trusted. The server SHOULD process received Client
Public Key Option sent by the client (see step 2 in Section 4.1), Public Key Option sent by the client unless not configured to do so.
unless not configured to do so.
7.2. DHCPv6 Client Behavior 5.2. DHCPv6 Client Behavior
The DHCPv6 client SHOULD send a Client Public Key Option The DHCPv6 client SHOULD send a Client Public Key Option
(OPTION_PUBLIC_KEY) to the DHCP Server. This Client Public Key (OPTION_PUBLIC_KEY) to the DHCP Server. This Client Public Key
authenticates the HNA. authenticates the HNA.
The DHCPv6 client sends a ORO with the necessary option codes: Zone The DHCPv6 client sends a ORO with the necessary option codes: Zone
Template Option, Synchronization Server Option and Reverse Template Option, Synchronization Server Option and Reverse
Synchronization Server Option. Synchronization Server Option.
Upon receiving a DHCP option described in this document in the Reply Upon receiving a DHCP option described in this document in the Reply
message, the HNA SHOULD retrieve or update DNS zones using the message, the HNA SHOULD publish the zone as described in
associated Supported Authentication Methods and update protocols, as [I-D.ietf-homenet-front-end-naming-delegation].
described in Section 5.
7.3. DHCPv6 Relay Agent Behavior 5.3. DHCPv6 Relay Agent Behavior
There are no additional requirements for the DHCP Relay agents. There are no additional requirements for the DHCP Relay agents.
8. IANA Considerations 6. IANA Considerations
The DHCP options detailed in this document is:
- OPTION_DNS_ZONE_TEMPLATE: TBD1
- OPTION_SYNC_SERVER: TBD2
- OPTION_REVERSE_SYNC_SERVER: TBD3 The DHCP options detailed in this document is: * OPTION_CLIENT_KEY:
TBD1 * OPTION_REGISTERED_DOMAIN: TBD2 * OPTION_SYNC_SERVER: TBD3 *
OPTION_REVERSE_SYNC_SERVER: TBD4
9. Security Considerations 7. Security Considerations"
9.1. DNSSEC is recommended to authenticate DNS hosted data 7.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.
9.2. Channel between the HNA and ISP DHCP Server MUST be secured 7.2. Channel between the HNA and ISP DHCP Server MUST be secured
The channel MUST be secured because the HNA provides authentication The channel MUST be secured because the HNA provides authentication
credentials. Unsecured channel may result in HNA impersonation credentials. Unsecured channel may result in HNA impersonation
attacks. attacks.
The document considers that the channel between the HNA and the ISP The document considers that the channel between the HNA and the ISP
DHCP Server is trusted. More specifically, the HNA is authenticated DHCP Server is trusted. More specifically, the HNA is authenticated
and the exchanged messages are protected. The current document does and the exchanged messages are protected. The current document does
not specify how to secure the channel. [RFC3315] proposes a DHCP not specify how to secure the channel. [RFC3315] proposes a DHCP
authentication and message exchange protection, [RFC4301], [RFC7296] authentication and message exchange protection, [RFC4301], [RFC7296]
propose to secure the channel at the IP layer. propose to secure the channel at the IP layer.
9.3. HNAs are sensitive to DoS 7.3. HNAs are sensitive to DoS
HNA have not been designed for handling heavy load. The HNA are HNA have not been designed for handling heavy load. The HNA are
exposed on the Internet, and their IP address is publicly published exposed on the Internet, and their IP address is publicly published
on the Internet via the DNS. This makes the Home Network sensitive on the Internet via the DNS. This makes the Home Network sensitive
to Deny of Service Attacks. The resulting outsourcing architecture to Deny of Service Attacks. The resulting outsourcing architecture
is described in [I-D.ietf-homenet-front-end-naming-delegation]. This is described in [I-D.ietf-homenet-front-end-naming-delegation]. This
document shows how the outsourcing architecture can be automatically document shows how the outsourcing architecture can be automatically
set. set.
10. Acknowledgments 8. Acknowledgments
We would like to thank Marcin Siodelski and Bernie Volz for their We would like to thank Marcin Siodelski and Bernie Volz for their
comments on the design of the DHCPv6 options. We would also like to comments on the design of the DHCPv6 options. We would also like to
thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their
remarks on the architecture design. The designed solution has been remarks on the architecture design. The designed solution has been
largely been inspired by Mark Andrews's document largely been inspired by Mark Andrews's document
[I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We
also thank Ray Hunter for its reviews, its comments and for also thank Ray Hunter for its reviews, its comments and for
suggesting an appropriated terminology. suggesting an appropriated terminology.
11. References 9. Scenarios and impact on the End User
11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
[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>.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000,
<https://www.rfc-editor.org/info/rfc2930>.
[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>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<https://www.rfc-editor.org/info/rfc3007>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
11.2. Informational References
[I-D.andrews-dnsop-pd-reverse]
Andrews, M., "Automated Delegation of IP6.ARPA reverse
zones with Prefix Delegation", draft-andrews-dnsop-pd-
reverse-02 (work in progress), November 2013.
[I-D.ietf-dhc-sedhcpv6]
Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D.
Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work
in progress), February 2017.
[I-D.ietf-homenet-front-end-naming-delegation]
Migault, D., Weber, R., Hunter, R., Griffiths, C., and W.
Cloetens, "Outsourcing Home Network Authoritative Naming
Service", draft-ietf-homenet-front-end-naming-
delegation-06 (work in progress), October 2017.
[I-D.sury-dnsext-cname-dname]
Sury, O., "CNAME+DNAME Name Redirection", draft-sury-
dnsext-cname-dname-00 (work in progress), April 2010.
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.
A.1. Base Scenario 10. Base Scenario
The base scenario is the one described in Section 4. It is typically The base scenario is the one described in Section 3. It is typically
the one of an ISP that manages the DHCP Server, and all DNS servers. the one of an ISP that manages the DHCP Server, and all DNS servers.
The end user subscribes to the ISP (foo), and at subscription time The end user subscribes to the ISP (foo), and at subscription time
registers for example.foo as its Registered Homenet Domain registers for example.foo as its Registered Homenet Domain
example.foo. Since the ISP knows the Registered Homenet Domain and example.foo.
the Public Authoritative Server(s) the ISP is able to build the
Homenet Zone Template.
The ISP manages the DNS Template Server, so it is able to load the
Homenet Zone Template on the DNS Template Server.
When the HNA is plugged (at least the first time), it provides its When the HNA is plugged (at least the first time), it provides its
Client Public Key to the DHCP Server. In this scenario, the DHCP Client Public Key to the DHCP Server. In this scenario, the DHCP
Server and the DNS Servers are managed by the ISP so the DHCP Server Server and the DNS Servers are managed by the ISP so the DHCP Server
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 with the DM and the Reverse DM.
More specifically, credentials are provided to:
- Synchronization Server
- Reverse Synchronization Server
- DNS Template Server
The HNA can update the zone using DNS update or a primary / secondary
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.
A.2. Third Party Registered Homenet Domain 10.1. Third Party Registered Homenet Domain
This section considers the case when the end user wants its home This section considers the case when the end user wants its home
network to use example.com as a Registered Homenet Domain instead of network to use example.com as a Registered Homenet Domain instead of
example.foo that has been assigned by the ISP. We also suppose that example.foo that has been assigned by the ISP. We also suppose that
example.com is not managed by the ISP. example.com is not managed by the ISP.
This can also be achieved without any configuration. When the end This can also be achieved without any configuration. When the end
user buys the domain name example.com, it may request to redirect the user buys the domain name example.com, it may request to redirect the
name example.com to example.foo using static redirection with CNAME name example.com to example.foo using static redirection with CNAME
[RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME
[I-D.sury-dnsext-cname-dname]. [I-D.sury-dnsext-cname-dname].
This configuration is performed once when the domain name example.com This configuration is performed once when the domain name example.com
is registered. The only information the end user needs to know is is registered. The only information the end user needs to know is
the domain name assigned by the ISP. Once this configuration is done the domain name assigned by the ISP. Once this configuration is done
no additional configuration is needed anymore. More specifically, no additional configuration is needed anymore. More specifically,
the HNA may be changed, the zone can be updated as in Appendix A.1 the HNA may be changed, the zone can be updated as in Section 10
without any additional configuration from the end user. without any additional configuration from the end user.
The main advantage of this scenario is that the end user benefits The main advantage of this scenario is that the end user benefits
from the Zero Configuration of the Base Scenario Appendix A.1. Then, from the Zero Configuration of the Base Scenario Section 10. Then,
the end user is able to register for its home network an unlimited the end user is able to register for its home network an unlimited
number of domain names provided by an unlimited number of different number of domain names provided by an unlimited number of different
third party providers. third party providers.
The drawback of this scenario may be that the end user still rely on The drawback of this scenario may be that the end user still rely on
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 10.2. Third Party DNS Infrastructure
This scenario considers that the end user uses example.com as a This scenario considers that the end user uses example.com as a
Registered Homenet Domain, and does not want to rely on the Registered Homenet Domain, and does not want to rely on the
authoritative servers provided by the ISP. authoritative servers provided by the ISP.
In this section we limit the outsourcing to the Synchronization In this section we limit the outsourcing to the DM and Public
Server and Public Authoritative Server(s) to a third party. All Authoritative Server(s) to a third party. The Reverse Public
other DNS Servers DNS Template Server, Reverse Public Authoritative Authoritative Server(s) and Reverse Synchronization Server remain
Server(s) and Reverse Synchronization Server remain managed by the managed by the ISP as the IP prefix is managed by the ISP.
ISP. The reason we consider that Reverse Public Authoritative
Server(s) and Reverse Synchronization Server remains managed by the
ISP are that the prefix is managed by the ISP, so outsourcing these
resources requires some redirection agreement with the ISP. More
specifically the ISP will need to configure the redirection on one of
its Reverse DNS Servers. That said, outsourcing these resources is
similar as outsourcing Synchronization Server and Public
Authoritative Server(s) to a third party. Similarly, the DNS
Template Server can be easily outsourced as detailed in this section
Outsourcing Synchronization Server and Public Authoritative Server(s)
requires:
- 1) Updating the Homenet Zone Template: this can be easily done as Outsourcing DM and Public Authoritative Server(s) requires:
detailed in Section 4.3 as the DNS Template Server is still
managed by the ISP. Such modification can be performed once by
any HNA. Once this modification has been performed, the HNA
can be changed, the Client Public Key of the HNA may be
changed, this does not need to be done another time. One can
imagine a GUI on the HNA asking the end user to fill the field
with Registered Homenet Domain, optionally Public Authoritative
Server(s), with a button "Configure Homenet Zone Template".
- 2) Updating the DHCP Server Information. In fact the Reverse 1. Updating the DHCP Server Information. One can imagine a GUI
Synchronization Server returned by the ISP is modified. One interface that enables the end user to modify its profile
can imagine a GUI interface that enables the end user to modify parameters. Again, this configuration update is done once-for-
its profile parameters. Again, this configuration update is ever.
done once-for-ever.
- 3) Upload the authentication credential of the HNA, that is the 2. Upload the authentication credential of the HNA, that is the
Client Public Key of the HNA, to the third party. Unless we Client Public Key of the HNA, to the third party. Unless we use
use specific mechanisms, like communication between the DHCP specific mechanisms, like communication between the DHCP Server
Server and the third party, or a specific token that is plugged and the third party, or a specific token that is plugged into the
into the HNA, this operation is likely to be performed every HNA, this operation is likely to be performed every time the HNA
time the HNA is changed, and every time the Client Public Key is changed, and every time the Client Public Key generated by the
generated by the HNA is changed. 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 needs to be configured for every
HNA. Configuration is expected to be HNA live-long. HNA. Configuration is expected to be HNA live-long.
A.4. Multiple ISPs 10.3. 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 Suppose the HNA has been configured each of its interfaces
exposed in Appendix A.1. The HNA has multiple interfaces, one for independently with each ISPS as described in Section 10. Each ISP
each ISP, and each of these interface is configured using DHCP. The provides a different Registered Homenet Domain. The HNA Client
HNA sends to each ISP its Client Public Key Option as well as a Public Key may be shared between the HNA and the multiple ISPs.
request for a Zone Template Option, a Synchronization Server Option
and a Reverse Synchronization Server Option. Each ISP provides the
requested DHCP options, with different values. Note that this
scenario assumes, the home network has a different Registered Homenet
Domain for each ISP as it is managed by the ISP. On the other hand,
the HNA Client Public Key may be shared between the HNA and the
multiple ISPs. The HNA builds the associate DNS(SEC) Homenet Zone,
and proceeds to the various settings as described in Appendix A.1.
The protocol and DHCPv6 options described in this document are fully The protocol and DHCPv6 options described in this document are fully
compatible with a HNA connected to multiple ISPs with multiple compatible with a HNA connected to multiple ISPs with multiple
Registered Homenet Domains. However, the HNA should be able to Registered Homenet Domains. However, the HNA should be able to
handle different Registered Homenet Domains. This is an handle different Registered Homenet Domains. This is an
implementation issue which is outside the scope of the current implementation issue which is outside the scope of the current
document. More specifically, multiple Registered Homenet Domains document.
leads to multiple DNS(SEC) Homenet Zones. A basic implementation may
erase the DNS(SEC) Homenet Zone that exists when it receives DHCPv6
options, and rebuild everything from scratch. This will work for an
initial configuration but comes with a few drawbacks. First, updates
to the DNS(SEC) Homenet Zone may only push to one of the multiple
Registered Homenet Domain, the latest Registered Homenet Domain that
has been set, and this is most likely expected to be almost randomly
chosen as it may depend on the latency on each ISP network at the
boot time. As a results, this leads to unsynchronized Registered
Homenet Domains. Secondly, if the HNA handles in some ways
resolution, only the latest Registered Homenet Domain set may be able
to provide naming resolution in case of network disruption.
Secondly, suppose the HNA is connected to multiple ISP with a single If a HNA is not able to handle multiple Registered Homenet Domains,
Registered Homenet Domain. In this case, the one party is chosen to the HNA may remain connected to multiple ISP with a single Registered
host the Registered Homenet Domain. This entity may be one of the Homenet Domain. In this case, the one party is chosen to host the
ISP or a third party. Note that having multiple ISPs can be Registered Homenet Domain.
motivated for bandwidth aggregation, or connectivity fail-over. In
the case of connectivity fail-over, the fail-over concerns the access This entity may be one of the ISP or a third party. Note that having
network and a failure of the access network may not impact the core multiple ISPs can be motivated for bandwidth aggregation, or
network where the Synchronization Server and Public Authoritative connectivity fail-over. In the case of connectivity fail-over, the
Primaries are hosted. In that sense, choosing one of the ISP even in fail-over concerns the access network and a failure of the access
a scenario of multiple ISPs may make sense. However, for sake of network may not impact the core network where the DM Server and
simplicity, this scenario assumes that a third party has be chosen to Public Authoritative Primaries are hosted. In that sense, choosing
host the Registered Homenet Domain. The DNS settings for each ISP is one of the ISP even in a scenario of multiple ISPs may make sense.
described in Appendix A.2 and Appendix A.3. With the configuration However, for sake of simplicity, this scenario assumes that a third
described in Appendix A.2, the HNA is expect to be able to handle party has be chosen to host the Registered Homenet Domain. The DNS
multiple Homenet Registered Domain, as the third party redirect to settings for each ISP is described in Section 10.1 and Section 10.2.
one of the ISPs Servers. With the configuration described in With the configuration described in Section 10.1, the HNA is expect
Appendix A.3, DNS zone are hosted and maintained by the third party. to be able to handle multiple Homenet Registered Domain, as the third
A single DNS(SEC) Homenet Zone is built and maintained by the HNA. party redirect to one of the ISPs Servers. With the configuration
This latter configuration is likely to match most HNA described in Section 10.2, DNS zone are hosted and maintained by the
third party. A single DNS(SEC) Homenet Zone is built and maintained
by the HNA. This latter configuration is likely to match most HNA
implementations. implementations.
The protocol and DHCPv6 options described in this document are fully The protocol and DHCPv6 options described in this document are fully
compatible with a HNA connected to multiple ISPs. To configure or compatible with a HNA connected to multiple ISPs. To configure or
not and how to configure the HNA depends on the HNA facilities. not and how to configure the HNA depends on the HNA facilities.
Appendix A.1 and Appendix A.2 require the HNA to handle multiple Section 10 and Section 10.1 require the HNA to handle multiple
Registered Homenet Domain, whereas Appendix A.3 does not have such Registered Homenet Domain, whereas Section 10.2 does not have such
requirement. requirement.
Appendix B. Document Change Log 11. References
[RFC Editor: This section is to be removed before publication]
-05: changing Master to Primary, Slave to Secondary
-04: Working Version Major modifications are:
- Re-structuring the draft: description and comparison of update and
authentication methods have been integrated into the Overview
section. a Configuration section has been created to describe
both configuration and corresponding behavior of the HNA.
- Adding Ports parameters: Server Set can configure a port. The
Port Server parameter have been added in the DHCPv6 option
payloads because middle boxes may not be configured to let port
53 packets and it may also be useful to split servers among
different ports, assigning each end user a different port.
- Multiple ISP scenario: In order to address comments, the multiple 11.1. Normative References
ISPs scenario has been described to explicitly show that the
protocol and DHCPv6 options do not prevent a HNA connected to
multiple independent ISPs.
-03: Working Version Major modifications are: [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
- Redesigning options/scope: according to feed backs received from [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
the IETF89 presentation in the dhc WG. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
- Redesigning architecture: according to feed backs received from [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
the IETF89 presentation in the homenet WG, discussion with Mark Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
and Lorenzo. <https://www.rfc-editor.org/info/rfc2181>.
-02: Working Version Major modifications are: [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
- Redesigning options/scope: As suggested by Bernie Volz [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
-01: Working Version Major modifications are: [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
- Remove the DNS Zone file construction: As suggested by Bernie Volz [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>.
- DHCPv6 Client behavior: Following options guide lines [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
- DHCPv6 Server behavior: Following options guide lines [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
-00: version published in the homenet WG. Major modifications are: 11.2. Informative References
- Reformatting of DHCPv6 options: Following options guide lines [I-D.andrews-dnsop-pd-reverse]
Andrews, M., "Automated Delegation of IP6.ARPA reverse
zones with Prefix Delegation", draft-andrews-dnsop-pd-
reverse-02 (work in progress), November 2013.
- DHCPv6 Client behavior: Following options guide lines [I-D.ietf-dhc-sedhcpv6]
Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D.
Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work
in progress), February 2017.
- DHCPv6 Server behavior: Following options guide lines [I-D.ietf-homenet-front-end-naming-delegation]
Migault, D., Weber, R., Richardson, M., Hunter, R.,
Griffiths, C., and W. Cloetens, "Outsourcing Home Network
Authoritative Naming Service", draft-ietf-homenet-front-
end-naming-delegation-10 (work in progress), March 2020.
-00: First version published in dhc WG. [I-D.sury-dnsext-cname-dname]
Sury, O., "CNAME+DNAME Name Redirection", draft-sury-
dnsext-cname-dname-00 (work in progress), April 2010.
Authors' Addresses Authors' Addresses
Daniel Migault Daniel Migault
Ericsson Ericsson
8400 boulevard Decarie 8275 Trans Canada Route
Montreal, QC H4P 2N2 Saint Laurent, QC 4S 0B6
Canada Canada
Email: daniel.migault@ericsson.com EMail: daniel.migault@ericsson.com
Ralf Weber
Akamai
EMail: ralf.weber@nominum.com
Tomek Mrugalski Tomek Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City 94063
USA US
Email: tomasz.mrugalski@gmail.com
URI: http://www.isc.org
EMail: tomasz.mrugalski@gmail.com
Chris Griffiths Chris Griffiths
Email: cgriffiths@gmail.com EMail: cgriffiths@gmail.com
Ralf Weber
Nominum
2000 Seaport Blvd #400
Redwood City, CA 94063
US
Email: ralf.weber@nominum.com
URI: http://www.nominum.com
Wouter Cloetens Wouter Cloetens
SoftAtHome
vaartdijk 3 701
3018 Wijgmaal
Belgium
Email: wouter.cloetens@softathome.com EMail: wouter.cloetens@softathome.com
 End of changes. 113 change blocks. 
958 lines changed or deleted 289 lines changed or added

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