draft-ietf-homenet-naming-architecture-dhc-options-02.txt   draft-ietf-homenet-naming-architecture-dhc-options-03.txt 
HOMENET D. Migault (Ed) HOMENET D. Migault (Ed)
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track W. Cloetens Intended status: Standards Track T. Mrugalski
Expires: November 20, 2015 SoftAtHome Expires: April 21, 2016 ISC
C. Griffiths C. Griffiths
Dyn
R. Weber R. Weber
Nominum Nominum
May 19, 2015 W. Cloetens
SoftAtHome
October 19, 2015
DHCP Options for Homenet Naming Architecture DHCPv6 Options for Homenet Naming Architecture
draft-ietf-homenet-naming-architecture-dhc-options-02.txt draft-ietf-homenet-naming-architecture-dhc-options-03.txt
Abstract Abstract
CPEs are usually constraint devices with reduced network and CPU Customer Premises Equipment (CPE) devices are usually constrained
capacities. As such, a CPE hosting on the Internet the authoritative devices with reduced network and CPU capabilities. As such, a CPE
naming service for its home network may become vulnerable to resource exposing the authoritative naming service for its home network on the
exhaustion attacks. One way to avoid exposing CPE is to outsource Internet may become vulnerable to resource exhaustion attacks. One
the authoritative service to a third party. This third party can be way to avoid exposing CPE is to outsource the authoritative service
the ISP or any other independent third party. to a third party, e.g. ISP. Such an outsource requires setting up
an architecture which may be inappropriate for most end users. This
Outsourcing the authoritative naming service to a third party document defines DHCPv6 options so any agnostic CPE can automatically
requires setting up an architecture which may be unappropriated for proceed to the appropriate configuration and outsource the
most end users. To leverage this issue, this document proposes DHCP authoritative naming service for the home network. In most cases,
Options so any agnostic CPE can automatically proceed to the the outsourcing mechanism is transparent for the end user.
appropriated configuration and outsource the authoritative naming
service for the home network. This document shows that in most
cases, these DHCP Options make outsourcing to a third party (be it
the ISP or any ISP independent service provider) 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 http://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 November 20, 2015.
This Internet-Draft will expire on April 21, 2016.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 (http://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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Architecture and DHCP Options Overview . . . . . . . . . 7 4.1. Architecture and DHCPv6 Options Overview . . . . . . . . 6
4.2. Mechanisms Securing DNS Transactions . . . . . . . . . . 10 4.2. Mechanisms Securing DNS Transactions . . . . . . . . . . 9
4.3. Primary / Secondary Synchronization versus DNS Update . . 11 4.3. Primary / Secondary Synchronization versus DNS Update . . 10
5. CPE Configuration . . . . . . . . . . . . . . . . . . . . . . 11 5. CPE Configuration . . . . . . . . . . . . . . . . . . . . . . 11
5.1. CPE Primary / Secondary Synchronization Configurations . 11 5.1. CPE Primary / Secondary Synchronization Configurations . 11
5.1.1. CPE / Public Authoritative Name Server Set . . . . . 12 5.1.1. CPE / Synchronization Server . . . . . . . . . . . . 11
5.1.2. CPE / Reverse Public Authoritative Name Server Set . 12 5.1.2. CPE / Reverse Synchronization Server . . . . . . . . 11
5.2. CPE DNS Data Handling and Update Policies . . . . . . . . 12 5.2. CPE DNS Data Handling and Update Policies . . . . . . . . 12
5.2.1. DNS Homenet Zone Template . . . . . . . . . . . . . . 12 5.2.1. Homenet Zone Template . . . . . . . . . . . . . . . . 12
5.2.2. DNS (Reverse) Homenet Zone . . . . . . . . . . . . . 13 5.2.2. DNS (Reverse) Homenet Zone . . . . . . . . . . . . . 12
6. Payload Description . . . . . . . . . . . . . . . . . . . . . 13 6. Payload Description . . . . . . . . . . . . . . . . . . . . . 13
6.1. Security Field . . . . . . . . . . . . . . . . . . . . . 14 6.1. Supported Authentication Methods Field . . . . . . . . . 13
6.2. Update Field . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Update Field . . . . . . . . . . . . . . . . . . . . . . 14
6.3. DHCP Public Key Option . . . . . . . . . . . . . . . . . 15 6.3. Client Public Key Option . . . . . . . . . . . . . . . . 14
6.4. DHCP Zone Template Option . . . . . . . . . . . . . . . . 16 6.4. Zone Template Option . . . . . . . . . . . . . . . . . . 14
6.5. DHCP Public Authoritative Name Server Set Option . . . . 16 6.5. Synchronization Server Option . . . . . . . . . . . . . . 15
6.6. DHCP Reverse Public Authoritative Name Server Set Option 17 6.6. Reverse Synchronization Server Option . . . . . . . . . . 16
7. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 18 7. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 18 7.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 17
7.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 19 7.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 18
7.3. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 19 7.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
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 CPE and ISP DHCP Server MUST be 9.2. Channel between the CPE and ISP DHCP Server MUST be
secured . . . . . . . . . . . . . . . . . . . . . . . . . 19 secured . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.3. CPEs are sensitive to DoS . . . . . . . . . . . . . . . . 20 9.3. CPEs are sensitive to DoS . . . . . . . . . . . . . . . . 19
10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informational References . . . . . . . . . . . . . . . . 22 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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Requirements notation 1. Requirements notation
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
- Customer Premises Equipment: (CPE) is the router providing The reader is expected to be familiar with
connectivity to the home network. It is configured and managed [I-D.ietf-homenet-front-end-naming-delegation] and its terminology
by the end user. In this document, the CPE might also hosts section. This section defines terms that have not been defined in
services such as DHCPv6. This device might be provided by the [I-D.ietf-homenet-front-end-naming-delegation]:
ISP.
- Public Key: designates a public Key generated by the CPE. This - Client Public Key: designates a public key generated by the CPE.
key is used as an authentication credential for the CPE. This key is used as an authentication credential for the CPE.
- Registered Homenet Domain: is the Domain Name associated to the - Homenet Zone Template: The template used as a basis to generate
home network. the Homenet Zone.
- DNS Homenet Zone: is the DNS zone associated to the home network. - DNS Template Server: The DNS server that hosts the Homenet Zone
This zone is set by the CPE and essentially contains the Template.
bindings between names and IP addresses of the nodes of the
home network. In this document, the CPE does neither perform
any DNSSEC management operations such as zone signing nor
provide an authoritative service for the zone. Both are
delegated to the Public Authoritative Server. The CPE
synchronizes the DNS Homenet Zone with the Public Authoritative
Server via a hidden primary / secondary architecture. The
Public Authoritative Server might use specific servers for the
synchronization of the DNS Homenet Zone: the Public
Authoritative Name Server Set.
- DNS Homenet Zone Template: The template used as a basis to - Homenet Reverse Zone: The reverse zone file associated to the
generate the DNS Homenet Zone. Homenet Zone.
- DNS Template Server: The DNS server that hosts the DNS Homenet 3. Introduction
Zone Template.
- DNS Homenet Reverse Zone: The reverse zone file associated to the CPEs are usually constrained devices with reduced network and CPU
DNS Homenet Zone. capacities. As such, a CPE 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 CPE to such attacks. This third party can
be the ISP or any other independent third party.
- Public Authoritative Primary(ies): are the visible name server Outsourcing the authoritative naming service to a third party
hosting the DNS Homenet Zone. End users' resolutions for the requires setting up an architecture designated in this document as
Homenet Domain are sent to this server, and this server is a
primary for the zone.
- Public Authoritative Name Server Set: is the server the CPE Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
synchronizes the DNS Homenet Zone. It is configured as a
secondary and the CPE acts as primary. The CPE sends
information so the DNSSEC zone can be set and served.
- Reverse Public Authoritative Primary(ies): are the visible name the Outsourcing Infrastructure. These settings may be inappropriate
server hosting the DNS Homenet Reverse Zone. End users' for most end users that do not have the sufficient knowledge. To
resolutions for the Homenet Domain are sent to this server, and address this issue, this document proposes DHCPv6 options so any
this server is a primary for the zone. agnostic CPE 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.
- Reverse Public Authoritative Name Server Set: is the server the When the CPE is plugged, the DHCPv6 options described in the document
CPE synchronizes the DNS Homenet Reverse Zone. It is enable:
configured as a secondary and the CPE acts as primary. The CPE
sends information so the DNSSEC zone can be set and served.
3. Introduction - 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 CPE 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 CPE. 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 CPE sends a
query of type AXFR [RFC1034], [RFC5936].
CPEs are usually constraint devices with reduced network and CPU - 2. To upload the Homenet Zone to the Synchronization Server, in
capacities. As such, a CPE hosting on the Internet the authoritative charge of publishing the Homenet Zone on the Public
naming service for its home network may become vulnerable to resource Authoritative Server(s). This document describes the
exhaustion attacks. One way to avoid exposing CPE is to outsource Synchronization Server Option that provides the FQDN of the
the authoritative service to a third party. This third party can be appropriated server. Note that, the document does not consider
the ISP or any other independent third party. 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.
Outsourcing the authoritative naming service to a third party - 3. To upload the Homenet Reverse Zone to the Reverse
requires setting up an architecture which may be unappropriated for Synchronization Server in charge of publishing the Homenet
most end users. To leverage this issue, this document proposes DHCP Reverse Zone on the Reverse Public Authoritative Server(s).
Options so any agnostic CPE can automatically proceed to the This document describes the Reverse Synchronization Server
appropriated configuration and outsource the authoritative naming Option that provides the FQDN of the appropriated server.
service for the home network. This document shows that in most Similarly to item 2., we do not consider in this document if
cases, these DHCP Options make outsourcing to a third party (be it the Homenet Reverse Zone is signed or not, and if signed who
the ISP or any ISP independent service provider) transparent for the signs it.
end user.
When the CPE is plugged, the DHCP Options described in the document - 4. To provide authentication credential (a public key) to the DHCP
enable the CPE: Server: Information stored in the Homenet Zone Template, the
- 1. To build the DNS Homenet Zone: Building the DNS Homenet Zone Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
requires filling the zone with appropriated bindings likes name
/ IP addresses of the different devices in the home networks.
Such information can be provided for example by the DHCP Server
hosted on the CPE. On the other hand, it also requires
configuration parameters like the name of the Registered Domain
Name associated to the home network or the Public Authoritative
Primary(ies) the DNS Homenet Zone is outsourced to. These
configuration parameters are stored in the DNS Homenet Zone
Template. This document describes the DHCP Zone Template
Option. This option carries a DNS Homenet Zone Template FQDN.
In order to retrieve the DNS Homenet Zone Template, the CPE
sends a query of type AXFR [RFC1034] [RFC5936]for the DNS
Homenet Zone Template FQDN.
- 2. To upload the DNS(SEC) Homenet Zone to the appropriated server: Homenet Zone and Homenet Reverse Zone belongs to the CPE, and
This server is designated as the Public Authoritative Name only the CPE should be able to update or upload these zones.
Server Set. It is in charge of publishing the DNS(SEC) Homenet To authenticate the CPE, this document defines the Client
Zone on the Public Authoritative Primary(ies). This document Public Key Option. This option is sent by the CPE to the
describes the DHCP Public Authoritative Name Server Set Option DHCPv6 server and provides the Client Public Key the CPE uses
that provides the FQDN of the appropriated server. Note that, to authenticate itself. This document does not describe
in the document we do not consider whether the DNS(SEC) Homenet mechanisms used to transmit the Client Public Key from the
Zone is signed or not and if signed who signs it. Such DHCPv6 server to the appropriate entities. If the DHCPv6
questions are out of the scope of the current document. 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.
- 3. To upload the DNS Homenet Reverse Zone to the appropriated The DHCPv6 options described in this document make possible to
server: This server is designated as the Reverse Public configure an Outsourcing Infrastructure with no or little
Authoritative Name Server Set. It is in charge of publishing configurations from the end user. A zero-config setting is achieved
the DNS Homenet Reverse Zone on the Reverse Public if the the link between the CPE and the DHCPv6 server and the link
Authoritative Primary(ies). This document describes the DHCP between the DHCPv6 server and the various DNS servers (Homenet Zone
Reverse Public Authoritative Name Server Set Option that Server, the Reverse Synchronization Server, Synchronization Server)
provides the FQDN of the appropriated server. Similarly to are trusted. For example, one way to provide a thrustworhy
item 2., we do not consider in this document if the DNS Homenet connection between the CPE and the DHCPv6 server is defined in
Reverse Zone is signed or not, and if signed who signs it. [I-D.ietf-dhc-sedhcpv6]. When both links are trusted, the CPE 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
CPE is able to securely update.
- 4. To provide authentication credential (a public key) to the DHCP If the DHCPv6 server cannot provide the Client Public Key to one of
Server: Information stored in the DNS Homenet Zone Template, these servers (most likely the Synchronization Server) and the CPE
the DNS(SEC) Homenet Zone and DNS Homenet Reverse Zone belongs needs to interact with the server, then, the end user is expected to
to the CPE, and only the CPE should be able to update or upload provide the CPE's Client Public Key to these servers (the Reverse
these zones. To authenticate the CPE, this document defines Synchronization Server or the Synchronization Server) either manually
the DHCP Public Key Option. This option is sent by the CPE to or using other mechanisms. Such mechanisms are outside the scope of
the DHCP Server and provides the Public Key the CPE uses to this document. In that case, the authentication credentials need to
authenticate itself. The DHCP Server is then responsible to be provided every time the key is modified. Appendix A provides more
provide the Public Key to the various DNS servers. details on how different scenarios impact the end users.
As a result, the DHCP Options described in this document enable an The remaining of this document is structured as follows. Section 4
agnostic CPE to outsource its naming infrastructure without any provides an overview of the DHCPv6 options as well as the expected
configuration from the end user. The main reason no configuration is interactions between the CPE and the various involved entities. This
required by the end user is that there are privileged links: first section also provides an overview of available mechanisms to secure
between the CPE and the DHCP Server and then between the DHCP Server DNS transactions and update DNS data. Section 5 describes how the
and the various DNS servers (DNS Homenet Zone Server, the Reverse CPE may securely synchronize and update DNS data. Section 6
Public Authoritative Name Server Set, Public Authoritative Name describes the payload of the DHCPv6 options and Section 7 details how
Server Set). This enables the CPE to send its authentication
credentials (a Public Key) to the DHCP Server that in turn forward it
to the various DNS servers. With the authentication credential on
the DNS servers set, the CPE is able to update the various zones in a
secure way.
If the DHCP Server cannot provide the public key to one of these Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
servers (most likely the Public Authoritative Name Server Set) and
the CPE needs to interact with the server, then, the end user is
expected to provide the CPE's public key to these servers (the
Reverse Public Authoritative Name Server Set or the Public
Authoritative Name Server Set) either manually or using other
mechanisms. Such mechanisms are outside the scope of 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 as follows. Section 4 provides an DHCPv6 client, server and relay agent behave. Section 8 lists the
overview of the DHCP Options as well as the expected interactions new parameters to be registered at the IANA, Section 9 provides
between the CPE and the various involved entities. This section also security considerations. Finally, Appendix A describes how the CPE
provides an overview of available mechanisms to secure DNS may behave and be configured regarding various scenarios.
transactions and update DNS Data. Section 5 describes how the CPE
may securely synchronize and update DNS data. Section 6 describes
the payload of the DHCP Options and Section 7 details how DHCP Client
DHCP Server and DHCP Relay behave. Section 8 lists the new
parameters to be registered at the IANA, Section 9 provides security
considerations. Finally, Appendix A describes how the CPE may behave
and be configured regarding various scenarios.
4. Protocol Overview 4. Protocol Overview
This section provides an overview of the how the CPE is expect to This section provides an overview of the CPE's interactions with the
interact with various entities, as well as how the CPE is expected to Outsourcing Infrastructure in Section 4.1, and so the necessary for
be configured via DHCP Options. Section 4.1 describes the entities its setting. In this document, the configuration is provided via
the CPE is expected to interact with. Interaction with each entities DHCPv6 options. Once configured, the CPE is expected to be able to
is defined via DHCP Options that are expected to configure the CPE. update and publish DNS data on the different components of the
Once configured, the CPE is expected to be able to update some DNS Outsourcing Infrastructure. As a result authenticating and updating
Data hosted by the different entities. As a result security and mechanisms play an important role in the specification. Section 4.2
updating mechanisms play an important role in the specification. provides an overview of the different authentication methods and
Section 4.2 provides an overview of the different security mechanisms Section 4.3 provides an overview of the different update mechanisms
considered for securing the CPE transactions and Section 4.3 considered to update the DNS data.
considers the different update mechanisms considered for the CPE to
update the DNS Data.
4.1. Architecture and DHCP Options Overview 4.1. Architecture and DHCPv6 Options Overview
This section illustrates how a CPE configures its naming This section illustrates how a CPE receives the necessary information
infrastructure to outsource its authoritative naming service. All via DHCPv6 options to outsource its authoritative naming service on
configurations and settings are performed using DHCP Options. This the Outsourcing Infrastructure. For the sake of simplicity, this
section, for the sake of simplicity, assumes that the DHCP Server is section assumes that the DHCPv6 server is able to communicate to the
able to communicate to the various DNS servers and to provide them various DNS servers and to provide them the public key associated
the public key associated to the CPE. Once each server got the with the CPE. Once each server got the public key, the CPE can
public key, the CPE can proceed to updates in a authenticated and proceed to transactions in an authenticated and secure way.
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 that scenarios where
the DHCP Server does not have privileged relations with the Public the DHCP Server does not have privileged relations with the
Authoritative Name Server Set must be considered. These cases are Synchronization Server must be considered. These cases are discussed
discussed latter in Appendix A. Such scenario does not necessarily latter in Appendix A. Such scenario does not necessarily require
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 CPE provides its Public Key to the DHCP Server using a DHCP - 1: The CPE provides its Client Public Key to the DHCP Server using
Public Key Option (OPTION_PUBLIC_KEY) and sends a DHCP Option a Client Public Key Option (OPTION_PUBLIC_KEY) and includes the
Request Option (ORO) for the DHCP Zone Template Option following option codes in its its Option Request Option (ORO):
(OPTION_DNS_ZONE_TEMPLATE), the DHCP Public Authoritative Name Zone Template Option (OPTION_DNS_ZONE_TEMPLATE), the
Server Set Option (OPTION_NAME_SERVER_SET) and the DHCP Reverse Synchronization Server Option (OPTION_SYNC_SERVER) and the
Public Authoritative Name Server Set Option Reverse Synchronization Server Option
(OPTION_REVERSE_NAME_SERVER_SET). (OPTION_REVERSE_SYNC_SERVER).
- 2: The DHCP Server makes the Public Key available to the DNS - 2: The DHCP Server makes the Client Public Key available to the
servers, so the CPE can secure its DNS transactions. Note that DNS servers, so the CPE can secure its DNS transactions. How
the Public Key alone is not sufficient to perform the the Client Public Key is transmitted to the various DNS servers
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
were the DHCP Server forwards the set (Public Key, Zone
Template FQDN) to the DNS Template Server, the set (Public Key,
IPv6 subnet) to the Reverse Public Authoritative Name Server
Set and the set (Public Key, Registered Homenet Domain) to the
Public Authoritative Name Server Set.
- 3.: The DHCP Server responds to the CPE with the requested DHCP Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
Options, i.e. the DHCP Public Key Option (OPTION_PUBLIC_KEY),
DHCP Zone Template Option OPTION_DNS_ZONE_TEMPLATE, DHCP Public
Authoritative Name Server Set Option (OPTION_NAME_SERVER_SET),
DHCP Reverse Public Authoritative Name Server Set Option
(OPTION_REVERSE_NAME_SERVER_SET).
- 4.: Upon receiving the DHCP Zone Template Option is out of scope of this document. Note that the Client Public
(OPTION_DNS_ZONE_TEMPLATE), the CPE performs an AXFR DNS query Key alone is not sufficient to perform the authentication and
for the Zone Template FQDN. The exchange is secured according the key should be, for example, associated with an identifier,
to the security protocols defined in the Security field of the or the concerned domain name. How the binding is performed is
DHCP option. Once the CPE has retrieved the DNS Zone Template, out of scope of the document. It can be a centralized database
the CPE can build the DNS Homenet Zone and the DNS Homenet or various bindings may be sent to the different servers.
Reverse Zone. Eventually the CPE signs these zones. 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.
- 5.: Once the DNS(SEC) Homenet Reverse Zone has been set, the CPE - 3: The DHCP Server responds to the CPE with the requested DHCPv6
uploads the zone to the Reverse Public Authoritative Name options, i.e. the Client Public Key Option (OPTION_PUBLIC_KEY),
Server Set. The DHCP Reverse Public Authoritative Name Server Zone Template Option OPTION_DNS_ZONE_TEMPLATE, Synchronization
Set Option (OPTION_REVERSE_NAME_SERVER_SET) provides the Server Option (OPTION_SYNC_SERVER), Reverse Synchronization
Reverse Public Authoritative Name Server Set FQDN as well as Server Option (OPTION_REVERSE_SYNC_SERVER). Note that this
the upload method, and the security protocol to secure the step may be performed in parallel to step 2, or even before.
upload. In other words, there is no requirements that step 3 is
conducted after step 2.
- 6.: Once the DNS(SEC) Homenet Zone has been set, the CPE uploads - 4: Upon receiving the Zone Template Option
the zone to the Public Authoritative Name Server Set. The DHCP (OPTION_DNS_ZONE_TEMPLATE), the CPE performs an AXFR DNS query
Public Authoritative Name Server Set Option for the Zone Template FQDN. The exchange is authenticated
(OPTION_NAME_SERVER_SET) provides the Public Authoritative Name according to the authentication methods defined in the
Server Set FQDN as well as the upload method and the security Supported Authentication Methods field of the DHCP option.
Once the CPE has retrieved the DNS Zone Template, the CPE can
build the Homenet Zone and the Homenet Reverse Zone.
Eventually the CPE signs these zones.
- 5: Once the Homenet Reverse Zone has been set, the CPE 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. protocol to secure the upload.
+----------------------+ - 6: Once the Homenet Zone has been set, the CPE uploads the zone to
| DHCP Server | 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
| | |2. secure the upload.
1.| |3. |
v v | Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
+---------------------+
| DHCPv6 Server |
+---------------------+
^ ^ ^
| | |
1.| |3. |2.
| | |
v v |
+------+ | +--------------------------------+ +------+ | +--------------------------------+
| | 4. +--->| DNS Template Server | | | 4. +--->| DNS Template Server |
| |<---------->| | | |<---------->| |
| | | +--------------------------------+ | | | +--------------------------------+
| CPE | | | CPE | |
| | | +--------------------------------+ | | | +--------------------------------+
| | 5./6. +--->| Reverse Public Authoritative | | | 5./6. +--->| Reverse Synchronization |
| |<---------->| Name Server Set | | |<---------->| Server |
| | | +--------------------------------+ | | | +--------------------------------+
-------| |-------|-------------------------------------- | | |
| | | +--------------------------------+ | | | +--------------------------------+
+------+ +--->| Public Authoritative | +------+ +--->| Synchronization Server |
| Name Server Set | | |
+--------------------------------+ +--------------------------------+
Figure 1: Protocol Overview Figure 1: Protocol Overview
As described above, the CPE is likely to interact with various DNS As described above, the CPE is likely to interact with various DNS
content. This section is focused on DNS Data the CPE is likely to content. More specifically, the CPE is likely to update the:
update. More specifically, the CPE is likely to update the:
- DNS Homenet Zone Template: may be updated by the CPE if the - Homenet Zone Template: if the configuration of the zone may be
configuration of the zone may be changed. This can include changed. This may include additional Public Authoritative
additional Public Authoritative Primary(ies), a different Server(s), a different Registered Homenet Domain as the one
Registered Homenet Domain as the one initially proposed, or a initially proposed, or a redirection to another domain.
redirection to another domain.
- DNS Homenet Reverse Zone: may be updated every time a new device - Homenet Reverse Zone: every time a new device is connected or
is connected or dis-connected. dis-connected.
- DNS Homenet Zone: may be updated every time a new device is - Homenet Zone: every time a new device is connected, dis-
connected, dis-connected. connected.
In fact, the CPE must be able to perform these updates in a secure Step 2 and step 3 should be considered as independent steps and could
manner. There are multiple ways to secure a DNS transaction and this be re-ordered. In fact, the DHCPv6 server does not have to wait for
document considers two mechanisms to update a DNS Data (nsupdate and a confirmation from the DNS servers the Client Public Key has been
primary/secondary synchronization). Which security mechanism to use properly received, and is operational by the DNS servers. The DHCP
to secure a DNS transaction depends on the expected security Server is expected to reply upon receiving the Client Public Key
(authentication of the authoritative server, mutual authentication, Option. The reply to the message with a Client Public Key Option
confidentiality...). The expected security may also depends on the from the DHCP Server is interpreted by the DHCPv6 client as a
kind of transaction performed by the CPE. Section 4.2 describes the confirmation of the reception of the option by the DHCP Server only.
different security mechanisms considered in the document as well as It does not indicate whether the server had processed the option or
their respective goals. Which mechanism to use to update the DNS
Data depends on the kind of update. Frequency of the update, size of Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
the DNS Data to update may be some useful criteria. Section 4.3
not. Debugging configurations errors or transmission error with one
of the DNS servers is let to the CPE 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 CPE, 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 CPE 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 CPE. The
appropriate authentication methods may, for example, be chosen
according to the level of confidentiality or the level of
authentication requested by the CPE transactions. Section 4.3
positions the nsupdate and primary/secondary synchronization positions the nsupdate and primary/secondary synchronization
mechanisms. 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 4.2. Mechanisms Securing DNS Transactions
Multiple protocols like IPsec [RFC4301] or TLS / DTLS [RFC5246] / Multiple protocols like IPsec [RFC4301] or TLS / DTLS [RFC5246] /
[RFC6347] may be used to secure DNS transactions between the CPE and [RFC6347] may be used to secure DNS transactions between the CPE and
the DNS servers. This document restricts the scope of security the DNS servers. This document limits its scope to authentication
protocols to those that have been designed specifically for DNS. method that have been designed specifically for DNS. This includes
This includes DNSSEC [RFC4033], [RFC4034], [RFC4035] that DNSSEC [RFC4033], [RFC4034], [RFC4035] that authenticates and
authenticates and provides integrity protection of DNS data, TSIG provides integrity protection of DNS data, TSIG [RFC2845], [RFC2930]
[RFC2845], [RFC2930] that use a shared secret to secure a transaction that use a shared secret to secure a transaction between two end
between two end points and SIG(0) [RFC2931] authenticates the DNS points and SIG(0) [RFC2931] authenticates the DNS packet exchanged.
packet exchanged.
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 CPE and the server. On the other hand, TSIG performs between the CPE 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 provides means to distribute shared secret for This document does not provide means to distribute shared secret for
example using a specific DHCP Option. The only assumption made is example using a specific DHCPv6 option. The only assumption made is
that the CPE generates or is assigned a public key. that the CPE generates or is assigned a public key.
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 CPE and the DNS Server have been with TSIG, it means that either the CPE and the DNS server have been
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
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).
Exchange with the DNS Template Server to retrieve the DNS Homenet Exchanges with the DNS Template Server to retrieve the Homenet Zone
Zone Template may be protected by SIG(0), TSIG or DNSSEC. When Template may be protected by SIG(0), TSIG or DNSSEC. When DNSSEC is
DNSSEC is used, it means the DNS Template Server only provides used, it means the DNS Template Server only provides integrity
integrity protection, and does not necessarily prevents someone else protection, and does not necessarily prevent someone else to query
to query the DNS Homenet Zone Template. In addition, DNSSEC is only the Homenet Zone Template. In addition, DNSSEC is only a way to
a way to protect the AXFR queries transaction, in other words, DNSSEC protect the AXFR queries transaction, in other words, DNSSEC cannot
cannot be used to secure updates. If DNSSEC is used to provide be used to secure updates. If DNSSEC is used to provide integrity
integrity protection for the AXFR response, the CPE should proceed to protection for the AXFR response, the CPE should proceed to the
the DNSSEC signature checks. If signature check fails, it MUST DNSSEC signature checks. If signature check fails, it MUST reject
reject the response. If the signature check succeeds, the CPE the response. If the signature check succeeds, the CPE removes all
removes all DNSSEC related RRsets (DNSKEY, RRSIG, NSEC* ...) before DNSSEC related RRsets (DNSKEY, RRSIG, NSEC* ...) before building the
building the DNS Homenet Zone. In fact, these DNSSEC related fields Homenet Zone. In fact, these DNSSEC related fields are associated to
are associated to the DNS Homenet Zone Template and not the DNS the Homenet Zone Template and not the Homenet Zone.
Homenet Zone.
Any update exchange should use SIG(0) or TSIG to authenticate the Any update exchange should use SIG(0) or TSIG to authenticate the
exchange. exchange.
4.3. Primary / Secondary Synchronization versus DNS Update 4.3. Primary / Secondary Synchronization versus DNS Update
As updates only concern DNS zones, this document only considers DNS As updates only concern DNS zones, this document only considers DNS
update mechanisms such as DNS update [RFC2136] [RFC3007] or a update mechanisms such as DNS update [RFC2136] [RFC3007] or a
primary / secondary synchronization. primary / secondary synchronization.
The DNS Homenet Zone Template can only be updated with DNS update. The Homenet Zone Template SHOULD be updated with DNS update as it
The reason is that the DNS Homenet Zone Template contains static contains static configuration data that is not expected to evolve
configuration data that is not expected to evolve over time. over time.
The DNS Homenet Reverse Zone and the DNS Homenet Zone can be updated The Homenet Reverse Zone and the Homenet Zone can be updated either
either with DNS update or using a primary / secondary with DNS update or using a primary / secondary synchronization. As
synchronization. As these zones may be large, with frequent updates, these zones may be large, with frequent updates, we recommend to use
we recommend to use the primary / secondary architecture as described the primary / secondary architecture as described in
in [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 then a NOTIFY, updates can use UDP, packets require more processing than a NOTIFY,
and they do not provide the server the opportunity to post-pone the and they do not provide the server the opportunity to postpone the
update. update.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
5. CPE Configuration 5. CPE Configuration
5.1. CPE Primary / Secondary Synchronization Configurations 5.1. CPE 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 CPE is [I-D.ietf-homenet-front-end-naming-delegation]. The CPE hosts a
configured as a primary whereas the DNS Server is configured as a Hidden Primary that synchronizes with a Synchronization Server or the
secondary. The DNS Server represents the Public Authoritative Name Reverse Synchronization Server.
Server Set or the Reverse Public Authoritative Name Server Set.
When the CPE is plugged its IP address may be unknown to the When the CPE is plugged its IP address may be unknown to the
secondary. The section details how the CPE or primary communicate secondary. The section details how the CPE or primary communicates
the necessary information to set up the secondary. the necessary information to set up the secondary.
In order to set the primary / secondary configuration, both primary In order to set the primary / secondary configuration, both primary
and secondaries must agree on 1) the zone to be synchronized, 2) the and secondaries must agree on 1) the zone to be synchronized, 2) the
IP address and ports used by both primary and secondary. IP address and ports used by both primary and secondary.
5.1.1. CPE / Public Authoritative Name Server Set 5.1.1. CPE / Synchronization Server
The CPE knows the zone to be synchronized by reading the Registered The CPE is aware of the zone to be synchronized by reading the
Homenet Domain in the DNS Homenet Zone Template provided by the DHCP Registered Homenet Domain in the Homenet Zone Template provided by
Zone Template Option (OPTION_DNS_ZONE_TEMPLATE). The IP address of the Zone Template Option (OPTION_DNS_ZONE_TEMPLATE). The IP address
the secondary is provided by the DHCP Public Authoritative Name of the secondary is provided by the Synchronization Server Option
Server Set Option (OPTION_NAME_SERVER_SET). (OPTION_SYNC_SERVER).
The Public Authoritative Name Server Set has been configured with the The Synchronization Server has been configured with the Registered
Registered Homenet Domain and the Public Key that identifies the CPE. Homenet Domain and the Client Public Key that identifies the CPE.
The only thing missing is the IP address of the CPE. This IP address The only missing information is the IP address of the CPE. This IP
is provided by the CPE by sending a NOTIFY [RFC1996]. address is provided by the CPE by sending a NOTIFY [RFC1996].
When the CPE has built its DNS Homenet Zone, it sends a NOTIFY When the CPE has built its Homenet Zone, it sends a NOTIFY message to
message to the Public Authoritative Name Server Sets. Upon receiving the Synchronization Servers. Upon receiving the NOTIFY message, the
the NOTIFY message, the secondary reads the Registered Homenet Domain secondary reads the Registered Homenet Domain and checks the NOTIFY
and checks the NOTIFY is sent by the authorized primary. This can be is sent by the authorized primary. This can be done using the shared
done using the shared secret (TSIG) or the public key (SIG(0)). Once secret (TSIG) or the public key (SIG(0)). Once the NOTIFY has been
the NOTIFY has been authenticated, the Public Authoritative Name authenticated, the Synchronization Servers might consider the source
Server Sets might consider the source IP address of the NOTIFY query IP address of the NOTIFY query to configure the primaries attributes.
to configure the primaries attributes.
5.1.2. CPE / Reverse Public Authoritative Name Server Set 5.1.2. CPE / Reverse Synchronization Server
The CPE knows the zone to be synchronized by looking at its assigned The CPE is aware of the zone to be synchronized by looking at its
prefix. The IP address of the secondary is provided by the DHCP assigned prefix. The IP address of the secondary is provided by the
Reverse Public Authoritative Name Server Set Option Reverse Synchronization Server Option (OPTION_REVERSE_SYNC_SERVER).
(OPTION_REVERSE_NAME_SERVER_SET).
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 2015
5.2. CPE DNS Data Handling and Update Policies 5.2. CPE DNS Data Handling and Update Policies
5.2.1. DNS Homenet Zone Template 5.2.1. Homenet Zone Template
The DNS Homenet Zone Template contains at least the related fields of The Homenet Zone Template contains at least the related fields of the
the Public Authoritative Primary(ies) as well as the Homenet Public Authoritative Server(s) as well as the Homenet Registered
Registered Domain, that is SOA, and NS fields. This template might Domain, that is SOA, and NS fields. This template might be generated
be generated automatically by the owner of the DHCP Server. For automatically by the owner of the DHCP Server. For example, an ISP
example, an ISP might provide a default Homenet Registered Domain as might provide a default Homenet Registered Domain as well as default
well as default Public Authoritative Primary(ies). This default Public Authoritative Server(s). This default settings should provide
settings should provide the CPE the necessary pieces of information the CPE the necessary pieces of information to set the homenet naming
to set the homenet naming architecture. architecture.
If the DNS Homenet Zone Template is not subject to modifications or If the Homenet Zone Template is not subject to modifications or
updates, the owner of the template might only use DNSSEC to enable updates, the owner of the template might only use DNSSEC to enable
integrity check. integrity check.
The DNS Homenet Zone Template might be subject to modification by the On the other hand, the Homenet Zone Template might also be subject to
CPE. The advantage of using the standard DNS zone format is that modification by the CPE. The advantage of using the standard DNS
standard DNS update mechanism can be used to perform updates. These zone format is that standard DNS update mechanism can be used to
updates might be accepted or rejected by the owner of the DNS Homenet perform updates. These updates might be accepted or rejected by the
Zone Template. Policies that defines what is accepted or rejected is owner of the Homenet Zone Template. Policies that defines what is
out of scope of this document. However, in this document we assume accepted or rejected is out of scope of this document. However, this
the Registered Homenet Domain is used as an index by the Public document assumes the Registered Homenet Domain is used as an index by
Authoritative Name Server Set, and SIG(0), TSIG are used to the Synchronization Server, and SIG(0), TSIG are used to authenticate
authenticate the CPE. As a result, the Registered Homenet Domain the CPE. As a result, the Registered Homenet Domain should not be
should not be modified unless the Public Authoritative Name Server modified unless the Synchronization Server can handle with it.
Set can handle with it.
5.2.2. DNS (Reverse) Homenet Zone 5.2.2. DNS (Reverse) Homenet Zone
The DNS Homenet Zone might be generated from the DNS Homenet Zone The Homenet Zone might be generated from the Homenet Zone Template.
Template. How the DNS Homenet Zone is generated is out of scope of How the Homenet Zone is generated is out of scope of this document.
this document. In some cases, the DNS Homenet Zone might be the In some cases, the Homenet Zone might be the exact copy of the
exact copy of the DNS Homenet Zone Template. In other cases, it Homenet Zone Template. In other cases, it might be generated from
might be generated from the DNS Homenet Zone Template with additional the Homenet Zone Template with additional RRsets. In some other
RRsets. In some other cases, the DNS Homenet Zone might be generated cases, the Homenet Zone might be generated without considering the
without considering the DNS Homenet Zone Template, but only Homenet Zone Template, but only considering specific configuration
considering specific configuration rules. rules.
In the current document the CPE only sets a single zone that is In the current document the CPE 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 DNS Homenet Zone Template. might be assigned by the owner of the Homenet Zone Template. This
This constrain does not prevent the CPE to use multiple domain names. constraint does not prevent the CPE 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
static redirections to the DNS 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 2015
6. Payload Description 6. Payload Description
This section details the payload of the DHCP Options. A few DHCP This section details the payload of the DHCPv6 options. A few DHCPv6
Options are used to advertise a server the CPE may be expect to options are used to advertise a server the CPE may be expected to
interact with. Interaction may require to define how the update is interact with. Interaction may require to define update and
expected to be performed as well as how the communication is secured. authentication methods. Update fields are shared by multiple DHCPv6
Security and Update are shared by multiple DHCP Options and are options and are described in separate sections. Section 6.1
described in separate sections. Section 6.1 describes the security describes the Supported Authentication Method field, Section 6.2
field, Section 6.2 describes the update fields, the remaining describes the Update field, the remaining Section 6.3, Section 6.4,
sections Section 6.3, Section 6.4, Section 6.5, Section 6.6 describe Section 6.5, Section 6.6 describe the DHCPv6 options.
the DHCP Options.
6.1. Security Field 6.1. Supported Authentication Methods Field
The Security Field of the DHCP Option is represented in Figure 2. It The Supported Authentication Methods field of the DHCPv6 option
indicates the security mechanism supported by the DNS Server. One of represented in Figure 2 indicates the authentication method supported
these mechanism MUST be chosen by the CPE in order to perform a by the DNS server. One of these mechanism MUST be chosen by the CPE
transaction with the DNS server. See Section 4.2 for more details. in order to perform a transaction with the DNS server. See
Section 4.2 for more details.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security | | Supported Auth. Methods |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Security Field Figure 2: Supported Authentication Methods Filed
- DNS (Bit 0): indicates, when set to 1, that DNS without any - DNS (Bit 0): indicates, when set to 1, that DNS without any
security extension is supported. security extension is supported.
- DNSSEC (Bit 1): indicates, when set to 1, that DNSSEC provides - DNSSEC (Bit 1): indicates, when set to 1, that DNSSEC provides
integrity protection. This can only be used for read integrity protection. This can only be used for read
operations like retrieving the DNS Homenet Zone Template. operations like retrieving the Homenet Zone Template.
- 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.
- 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 ignored by the DHCP Client. and MUST be ignored by the DHCPv6 client.
A Security field with all bits set to zero indicates the operation is A Supported Authentication Methods field with all bits set to zero
not permitted. The Security field may be set to zero when updates indicates the operation is not permitted. The Supported
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
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 DHCP 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.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Update | | Update |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: Update Field Figure 3: Update Field
- Primary / Secondary (Bit 0): indicates, when set to 1, that DNS - Primary / Secondary (Bit 0): indicates, when set to 1, that DNS
Server supports data synchronization using a Primary / Server supports data synchronization using a Primary /
Secondary mechanism. Secondary mechanism.
- DNS Update (Bit 1): indicates, when set to 1, that DNS Server - DNS Update (Bit 1): indicates, when set to 1, that DNS Server
supports data synchronization using DNS Updates. supports data synchronization using DNS Updates.
- Remaining Bits (Bit 2-7): MUST be set to 0 by the DHCP Server and - Remaining Bits (Bit 2-7): MUST be set to 0 by the DHCPv6 server
ignored by the DHCP Client. and MUST be ignored by the DHCPv6 client.
6.3. DHCP Public Key Option
The DHCP Public Key Option (OPTION_PUBLIC_KEY) indicates the Public
Key that is used to authenticate the CPE.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PUBLIC_KEY | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Public Key Data /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DHCP Public Key Option
- OPTION_PUBLIC_KEY (variable): the option code for the DHCP Public 6.3. Client Public Key Option
Key Option.
- option-len (16 bits): length in octets of the option-data field as The Client Public Key Option (OPTION_PUBLIC_KEY) indicates the Client
described in [RFC3315]. Public Key that is used to authenticate the CPE. This option is
defined in [I-D.ietf-dhc-sedhcpv6].
- Public Key Data: contains the Public Key. The format is the DNSKEY 6.4. Zone Template Option
RDATA format as defined in [RFC4034].
6.4. DHCP Zone Template Option The Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option indicates
the CPE how to retrieve the Homenet Zone Template. It provides a
FQDN the CPE 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.
The DHCP Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
indicates the CPE how to retrieve the DNS Homenet Zone Template. It
provides a FQDN the CPE SHOULD query with a DNS query of type AXFR.
The option also specifies which security protocols are available on
the authoritative server. DNS 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_DNS_ZONE_TEMPLATE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security (axfr) | Security | | Supp. Auth. Methods (axfr) | Supp. Auth. Methods (update) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Zone Template FQDN / / Zone Template FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DHCP Zone Template Option Figure 4: Zone Template Option
- OPTION_DNS_ZONE_TEMPLATE (variable): the option code for the DHCP - option-code: (16 bits): OPTION_DNS_ZONE_TEMPLATE, the option code
Zone Template Option. for the Zone Template Option (TBD1).
- option-len (16 bits): length in octets of the option-data field as - option-len (16 bits): length in octets of the option-data field as
described in [RFC3315]. described in [RFC3315].
- Security (axfr) (16 bits): defines which security protocols are - Supported Authentication Methods(axfr) (16 bits): defines which
supported by the DNS server. This field concerns the AXFR and authentication methods are supported by the DNS server. This
consultation queries, not the update queries. See Section 6.1 field concerns the AXFR and consultation queries, not the
for more details. update queries. See Section 6.1 for more details.
- Security (16 bits): defines which security protocols are supported - Supported Authentication Methods (16 bits): defines which
by the DNS server. This field concerns the update. See authentication methods are supported by the DNS server. This
Section 6.1 for more details. field concerns the update. See Section 6.1 for more details.
- Zone Template FQDN FQDN (variable): the FQDN of the DNS server - Zone Template FQDN FQDN (variable): the FQDN of the DNS server
hosting the DNS Homenet Zone Template. hosting the Homenet Zone Template.
6.5. DHCP Public Authoritative Name Server Set Option 6.5. Synchronization Server Option
The DHCP Public Authoritative Name Server Set Option The Synchronization Server Option (OPTION_SYNC_SERVER) provides
(OPTION_NAME_SERVER_SET) provides information so the CPE can upload information necessary for the CPE to upload the Homenet Zone to the
the DNS Homenet Zone to the Public Authoritative Name Server Set. Synchronization Server. Finally, the option provides the
Finally, the option provides the security mechanisms that are authentication methods that are available to perform the upload. The
available to perform the upload. The upload is performed via a DNS upload is performed via a DNS primary / secondary architecture or DNS
primary / secondary architecture or DNS updates. updates.
0 1 2 3 Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
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_NAME_SERVER_SET | option-len | | OPTION_SYNC_SERVER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security | Update | Server / | Supported Auth. Methods | Update | Server /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Port | | / Port | |
+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
/ Public Authoritative Name Server Set FQDN / / Synchronization Server FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: DHCP Public Authoritative Name Server Set Option Figure 5: Synchronization Server Option
- OPTION_NAME_SERVER_SET (16 bits): the option code for the DHCP - option-code (16 bits): OPTION_SYNC_SERVER, the option code for the
Public Authoritative Name Server Set Option. Synchronization Server Option (TBD2).
- option-len (16 bits): length in octets of the option-data field as - option-len (16 bits): length in octets of the option-data field as
described in [RFC3315]. described in [RFC3315].
- Security (16 bits): defines which security protocols are supported - Supported Authentication Methods (16 bits): defines which
by the DNS server. See Section 6.1 for more details. 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 - Update (8 bits): defines which update mechanisms are supported by
the DNS server. See Section 4.3 for more details. the DNS server. See Section 4.3 for more details.
- Server Port (16 bits): defines the port the Public Authoritative - Server Port (16 bits): defines the port the Synchronization Server
Name Server Set is listening. is listening. When multiple transport layers may be used, a
single and unique Server Port value applies to all the
transport layers. In the case of DNS for example, Server Port
value considers DNS exchanges using UDP and TCP.
- Public Authoritative Name Server Set FQDN (variable): the FQDN of - Synchronization Server FQDN (variable): the FQDN of the
the Public Authoritative Name Server Set. Synchronization Server.
6.6. DHCP Reverse Public Authoritative Name Server Set Option 6.6. Reverse Synchronization Server Option
The DHCP Reverse Public Authoritative Name Server Set Option The Reverse Synchronization Server Option
(OPTION_REVERSE_NAME_SERVER_SET) provides information so the CPE can (OPTION_REVERSE_SYNC_SERVER) provides information necessary for the
upload the DNS Homenet Zone to the Public Authoritative Name Server CPE to upload the Homenet Zone to the Synchronization Server. The
Set. The option provides the security mechanisms that are available option provides the authentication methods that are available to
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 October 2015
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_NAME_SERVER_SET| option-len | | OPTION_REVERSE_SYNC_SERVER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security | Update | Server / | Supported Auth. Methods | Update | Server /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Port | | / Port | |
+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+ |
| | | |
/ Reverse Public Authoritative Name Server Set FQDN / / Reverse Synchronization Server FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: DHCP Reverse Public Authoritative Name Server Set Option Figure 6: Reverse Synchronization Server Option
- OPTION_REVERSE_NAME_SERVER_SET (16 bits): the option code for the - option-code (16 bits): OPTION_REVERSE_SYNC_SERVER, the option code
DHCP Reverse Public Authoritative Name Server Set Option. for the Reverse Synchronization Server Option (TBD3).
- option-len (16 bits): length in octets of the option-data field as - option-len (16 bits): length in octets of the option-data field as
described in [RFC3315]. described in [RFC3315].
- Security (16 bits): defines which security protocols are supported - Supported Authentication Methods (16 bits): defines which
by the DNS server. See Section 6.1 for more details. 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 - Update (8 bits): defines which update mechanisms are supported by
the DNS server. See Section 4.3 for more details. the DNS server. See Section 4.3 for more details.
- Server Port (16 bits): defines the port the Public Authoritative - Server Port (16 bits): defines the port the Synchronization Server
Name Server Set is listening. is listening.
- Reverse Public Authoritative Name Server Set FQDN (variable): The - Reverse Synchronization Server FQDN (variable): The FQDN of the
FQDN of the Reverse Public Authoritative Name Server Set. Reverse Synchronization Server.
7. DHCP Behavior 7. DHCP Behavior
7.1. DHCPv6 Server Behavior 7.1. DHCPv6 Server Behavior
The DHCP Server sends the DHCP Zone Template Option Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in
(OPTION_DNS_ZONE_TEMPLATE), DHCP Public Authoritative Name Server Set regards to option assignment. As a convenience to the reader, we
Option (OPTION_NAME_SERVER_SET), DHCP Reverse Public Authoritative mention here that the server will send option foo only if configured
Name Server Set Option (OPTION_REVERSE_NAME_SERVER_SET) upon request with specific values for foo and if the client requested it. In
by the DHCP Client. particular, when configured the DHCP Server sends the Zone Template
Option, Synchronization Server Option, Reverse Synchronization Server
Option when requested by the DHCPv6 client by including necessary
option codes in its ORO.
The DHCP Server MAY receive a DHCP Public Key Option Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
(OPTION_PUBLIC_KEY) from the CPE. Upon receipt of this DHCP Option,
the DHCP Sever is expect to communicate this credential to the
available DNS Servers like the DNS Template Server, the Public
Authoritative Name Server Set and the Reverse Public Authoritative
Name Server Set.
7.2. DHCPv6 Client Behavior The DHCP Server may receive a Client Public Key Option
(OPTION_PUBLIC_KEY) from the CPE. Upon receipt of this DHCPv6
option, the DHCP Server SHOULD acknowledge the reception of the
Client Public Key Option as described in Section 4.1 and communicate
this credential to the available DNS Servers like the DNS Template
Server, the Synchronization Server and the Reverse Synchronization
Server, unless not configured to do so.
The DHCP Client MAY send a DHCP Public Key Option (OPTION_PUBLIC_KEY) A CPE may update its Client Public Key by sending a new value in the
to the DHCP Server. This Public Key authenticates the CPE. Client Public Key Option (OPTION_PUBLIC_KEY) as this document assumes
the link between the CPE and the DHCP Server is considered
authenticated and trusted. The server SHOULD process received Client
Public Key Option sent by the client (see step 2 in Section 4.1),
unless not configured to do so.
The DHCP Client sends a DHCP Option Request Option (ORO) with the 7.2. DHCPv6 Client Behavior
necessary DHCP options.
A CPE SHOULD only send the an ORO request for DHCP Options it needs The DHCPv6 client SHOULD send a Client Public Key Option
or for information that needs to be up-to-date. (OPTION_PUBLIC_KEY) to the DHCP Server. This Client Public Key
authenticates the CPE.
Upon receiving a DHCP option described in this document, the CPE The DHCPv6 client sends a ORO with the necessary option codes: Zone
SHOULD retrieve or update DNS zones using the associated security and Template Option, Synchronization Server Option and Reverse
update protocols. Synchronization Server Option.
7.3. DHCPv6 Relay Behavior Upon receiving a DHCP option described in this document in the Reply
message, the CPE SHOULD retrieve or update DNS zones using the
associated Supported Authentication Methods and update protocols, as
described in Section 5.
DHCP Relay behavior are not modified by this document. 7.3. DHCPv6 Relay Agent Behavior
There are no additional requirements for the DHCP Relay agents.
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: TBD - OPTION_DNS_ZONE_TEMPLATE: TBD1
- OPTION_NAME_SERVER_SET: TBD - OPTION_SYNC_SERVER: TBD2
- OPTION_REVERSE_NAME_SERVER_SET: TBD - OPTION_REVERSE_SYNC_SERVER: TBD3
- OPTION_PUBLIC_KEY: TBD Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
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) DNS Homenet Zone is signed with It is recommended that the (Reverse) Homenet Zone is signed with
DNSSEC. The zone may be signed by the CPE or by a third party. We DNSSEC. The zone may be signed by the CPE or by a third party. We
recommend the zone to be signed by the CPE, and that the signed zone recommend the zone to be signed by the CPE, and that the signed zone
is uploaded. is uploaded.
9.2. Channel between the CPE and ISP DHCP Server MUST be secured 9.2. Channel between the CPE and ISP DHCP Server MUST be secured
The channel MUST be secured because the CPE provides authentication
credentials. Unsecured channel may result in CPE impersonation
attacks.
The document considers that the channel between the CPE and the ISP The document considers that the channel between the CPE and the ISP
DHCP Server is trusted. More specifically, the CPE is authenticated DHCP Server is trusted. More specifically, the CPE 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.
In fact, the channel MUST be secured because the CPE provides
authentication credentials. Unsecured channel may result in CPE
impersonation attacks.
9.3. CPEs are sensitive to DoS 9.3. CPEs are sensitive to DoS
CPE have not been designed for handling heavy load. The CPE are CPE have not been designed for handling heavy load. The CPE 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. Acknowledgment 10. Acknowledgments
We would like to thank Tomasz Mrugalski, Marcin Siodelski and Bernie We would like to thank Marcin Siodelski and Bernie Volz for their
Volz for their comments on the design of the DHCP Options. We would comments on the design of the DHCPv6 options. We would also like to
also like to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their
for their remarks on the architecture design. The designed solution remarks on the architecture design. The designed solution has been
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. [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We
also thank Ray Hunter for its reviews, its comments and for
suggesting an appropriated terminology.
11. References 11. References
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
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, November 1987. STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://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, August 1996. Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <http://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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., 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, April 1997. RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://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, July 1997. Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<http://www.rfc-editor.org/info/rfc2181>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, 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, May 2000. (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<http://www.rfc-editor.org/info/rfc2845>.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000. RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000,
<http://www.rfc-editor.org/info/rfc2930>.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
SIG(0)s)", RFC 2931, September 2000. ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <http://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, November 2000. Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<http://www.rfc-editor.org/info/rfc3007>.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
[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", RFC Rose, "DNS Security Introduction and Requirements",
4033, March 2005. RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://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, March 2005. RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://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, March 2005. Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://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, December 2005. Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://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, August 2008. (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, June 2010. (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<http://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, January 2012. Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://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, June 2012. DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<http://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, October 2014. (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://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 October 2015
[I-D.ietf-dhc-sedhcpv6]
Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure
DHCPv6", draft-ietf-dhc-sedhcpv6-08 (work in progress),
June 2015.
[I-D.ietf-homenet-front-end-naming-delegation] [I-D.ietf-homenet-front-end-naming-delegation]
Migault, D., Cloetens, W., Griffiths, C., and R. Weber, Migault, D., Weber, R., Hunter, R., Griffiths, C., and W.
"Outsourcing Home Network Authoritative Naming Service", Cloetens, "Outsourcing Home Network Authoritative Naming
draft-ietf-homenet-front-end-naming-delegation-02 (work in Service", draft-ietf-homenet-front-end-naming-
progress), May 2015. delegation-04 (work in progress), September 2015.
[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.
A.1. Base Scenario A.1. Base Scenario
The base scenario is the one described in Section 4. It is typically The base scenario is the one described in Section 4. 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. Since the ISP knows the Registered Homenet Domain and
the Public Authoritative Primary(ies) the ISP is able to build the the Public Authoritative Server(s) the ISP is able to build the
DNS Homenet Zone Template. Homenet Zone Template.
The ISP manages the DNS Template Server, so it is able to load the The ISP manages the DNS Template Server, so it is able to load the
DNS Homenet Zone Template on the DNS Template Server. Homenet Zone Template on the DNS Template Server.
When the CPE is plugged (at least the first time), it provides its When the CPE is plugged (at least the first time), it provides its
Public Key to the DHCP Server. In this scenario, the DHCP Server and Client Public Key to the DHCP Server. In this scenario, the DHCP
the DNS Servers are managed by the ISP so the DHCP Server can provide Server and the DNS Servers are managed by the ISP so the DHCP Server
authentication credentials of the CPE to enable secure authenticated can provide authentication credentials of the CPE to enable secure
transaction between the CPE and these DNS servers. More authenticated transaction between the CPE and these DNS servers.
specifically, credentials are provided to: More specifically, credentials are provided to:
- Public Authoritative Name Server Set - Synchronization Server
- Reverse Public Authoritative Name Server Set - Reverse Synchronization Server
- DNS Template Server - DNS Template Server
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
The CPE can update the zone using DNS update or a primary / secondary The CPE 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.
In this section we limit the outsourcing to the Public Authoritative Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
Name Server Set and Public Authoritative Primary(ies) to a third
party. All other DNS Servers DNS Template Server, Reverse Public In this section we limit the outsourcing to the Synchronization
Authoritative Primary(ies) and Reverse Public Authoritative Name Server and Public Authoritative Server(s) to a third party. All
Server Set remain managed by the ISP. The reason we consider that other DNS Servers DNS Template Server, Reverse Public Authoritative
Reverse Public Authoritative Primary(ies) and Reverse Public Server(s) and Reverse Synchronization Server remain managed by the
Authoritative Name Server Set remains managed by the ISP are that the ISP. The reason we consider that Reverse Public Authoritative
prefix is managed by the ISP, so outsourcing these resources requires Server(s) and Reverse Synchronization Server remains managed by the
some redirection agreement with the ISP. More specifically the ISP ISP are that the prefix is managed by the ISP, so outsourcing these
will need to configure the redirection on one of its Reverse DNS resources requires some redirection agreement with the ISP. More
Servers. That said, outsourcing these resources is similar as specifically the ISP will need to configure the redirection on one of
outsourcing Public Authoritative Name Server Set and Public its Reverse DNS Servers. That said, outsourcing these resources is
Authoritative Primary(ies) to a third party. Similarly, the DNS 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 Template Server can be easily outsourced as detailed in this section
Outsourcing Public Authoritative Name Server Set and Public Outsourcing Synchronization Server and Public Authoritative Server(s)
Authoritative Primary(ies) requires: requires:
- 1) Updating the DNS Homenet Zone Template: this can be easily done - 1) Updating the Homenet Zone Template: this can be easily done as
as detailed in Section 4.3 as the DNS Template Server is still detailed in Section 4.3 as the DNS Template Server is still
managed by the ISP. Such modification can be performed once by managed by the ISP. Such modification can be performed once by
any CPE. Once this modification has been performed, the CPE any CPE. Once this modification has been performed, the CPE
can be changed, the Public Key of the CPE may be changed, this can be changed, the Client Public Key of the CPE may be
does not need to be done another time. One can imagine a GUI changed, this does not need to be done another time. One can
on the CPE asking the end user to fill the field with imagine a GUI on the CPE asking the end user to fill the field
Registered Homenet Domain, optionally Public Authoritative with Registered Homenet Domain, optionally Public Authoritative
Primary(ies), with a button "Configure DNS Homenet Zone Server(s), with a button "Configure Homenet Zone Template".
Template".
- 2) Updating the DHCP Server Information. In fact the Reverse - 2) Updating the DHCP Server Information. In fact the Reverse
Public Authoritative Name Server Set returned by the ISP is Synchronization Server returned by the ISP is modified. One
modified. One can imagine a GUI interface that enables the end can imagine a GUI interface that enables the end user to modify
user to modify its profile parameters. Again, this its profile parameters. Again, this configuration update is
configuration update is done once-for-ever. done once-for-ever.
- 3) Upload the authentication credential of the CPE, that is the - 3) Upload the authentication credential of the CPE, that is the
Public Key of the CPE, to the third party. Unless we use Client Public Key of the CPE, to the third party. Unless we
specific mechanisms, like communication between the DHCP Server use specific mechanisms, like communication between the DHCP
and the third party, or a specific token that is plugged into Server and the third party, or a specific token that is plugged
the CPE, this operation is likely to be performed every time into the CPE, this operation is likely to be performed every
the CPE is changed, and every time the Public Key generated by time the CPE is changed, and every time the Client Public Key
the CPE is changed. generated by the CPE 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 Public Key completely outsourced to the third party. Most likely the Client
that authenticate the CPE need to be configured for every CPE. Public Key that authenticate the CPE need to be configured for every
Configuration is expected to be CPE live-long. CPE. Configuration is expected to be CPE live-long.
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
A.4. Multiple ISPs A.4. Multiple ISPs
This scenario considers a CPE connected to multiple ISPs. This scenario considers a CPE connected to multiple ISPs.
Firstly, suppose the CPE has been configured with the based scenarios Firstly, suppose the CPE has been configured with the based scenarios
exposed in Appendix A.1. The CPE has multiple interfaces, one for exposed in Appendix A.1. The CPE 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
CPE sends to each ISP its DHCP Public Key Option as well as a request CPE sends to each ISP its Client Public Key Option as well as a
for a DHCP Zone Template Option, a DHCP Public Authoritative Name request for a Zone Template Option, a Synchronization Server Option
Server Set Option and a DHCP Reverse Public Authoritative Name Server and a Reverse Synchronization Server Option. Each ISP provides the
Set Option. Each ISP provides the requested DHCP options, with requested DHCP options, with different values. Note that this
different values. Note that this scenario assumes, the home network scenario assumes, the home network has a different Registered Homenet
has a different Registered Homenet Domain for each ISP as it is Domain for each ISP as it is managed by the ISP. On the other hand,
managed by the ISP. On the other hand, the CPE Public Key may be the CPE Client Public Key may be shared between the CPE and the
shared between the CPE and the multiple ISPs. The CPE builds the multiple ISPs. The CPE builds the associate DNS(SEC) Homenet Zone,
associate DNS(SEC) Homenet Zone, and proceeds to the various settings and proceeds to the various settings as described in Appendix A.1.
as described in Appendix A.1.
The protocol and DHCP Options described in this document are fully The protocol and DHCPv6 options described in this document are fully
compatible with a CPE connected to multiple ISPs with multiple compatible with a CPE connected to multiple ISPs with multiple
Registered Homenet Domains. However, the CPE should be able to Registered Homenet Domains. However, the CPE 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. More specifically, multiple Registered Homenet Domains
leads to multiple DNS(SEC) Homenet Zones. A basic implementation may leads to multiple DNS(SEC) Homenet Zones. A basic implementation may
erase the DNS(SEC) Homenet Zone that exists when it receives DHCP erase the DNS(SEC) Homenet Zone that exists when it receives DHCPv6
Options, and rebuild everything from scratch. This will work for an options, and rebuild everything from scratch. This will work for an
initial configuration but comes with a few drawbacks. First, updates initial configuration but comes with a few drawbacks. First, updates
to the DNS(SEC) Homenet Zone may only push to one of the multiple to the DNS(SEC) Homenet Zone may only push to one of the multiple
Registered Homenet Domain, the latest Registered Homenet Domain that Registered Homenet Domain, the latest Registered Homenet Domain that
has been set, and this is most likely expected to be almost randomly 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 chosen as it may depend on the latency on each ISP network at the
boot time. As a results, this leads to unsynchronized Registered boot time. As a results, this leads to unsynchronized Registered
Homenet Domains. Secondly, if the CPE handles in some ways Homenet Domains. Secondly, if the CPE handles in some ways
resolution, only the latest Registered Homenet Domain set may be able resolution, only the latest Registered Homenet Domain set may be able
to provide naming resolution in case of network disruption. to provide naming resolution in case of network disruption.
Secondly, suppose the CPE is connected to multiple ISP with a single Secondly, suppose the CPE is connected to multiple ISP with a single
Registered Homenet Domain. In this case, the one party is chosen to Registered Homenet Domain. In this case, the one party is chosen to
host the Registered Homenet Domain. This entity may be one of the host the Registered Homenet Domain. This entity may be one of the
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 Public Authoritative Name Server Set and Public network where the Synchronization Server and Public Authoritative
Authoritative Primaries are hosted. In that sense, choosing one of Primaries are hosted. In that sense, choosing one of the ISP even in
the ISP even in a scenario of multiple ISPs may make sense. However, a scenario of multiple ISPs may make sense. However, for sake of
for sake of simplicity, this scenario assumes that a third party has simplicity, this scenario assumes that a third party has be chosen to
be chosen to host the Registered Homenet Domain. The DNS settings host the Registered Homenet Domain. The DNS settings for each ISP is
for each ISP is described in Appendix A.2 and Appendix A.3. With the
configuration described in Appendix A.2, the CPE is expect to be able Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
to handle multiple Homenet Registered Domain, as the third party
redirect to one of the ISPs Servers. With the configuration described in Appendix A.2 and Appendix A.3. With the configuration
described in Appendix A.3, DNS zone are hosted and maintained by the described in Appendix A.2, the CPE is expect to be able to handle
third party. A single DNS(SEC) Homenet Zone is built and maintained multiple Homenet Registered Domain, as the third party redirect to
by the CPE. This latter configuration is likely to match most CPE one of the ISPs Servers. With the configuration described in
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 CPE.
This latter configuration is likely to match most CPE
implementations. implementations.
The protocol and DHCP Options described in this document are fully The protocol and DHCPv6 options described in this document are fully
compatible with a CPE connected to multiple ISPs. To configure or compatible with a CPE connected to multiple ISPs. To configure or
not and how to configure the CPE depends on the CPE facilities. not and how to configure the CPE depends on the CPE facilities.
Appendix A.1 and Appendix A.2 require the CPE to handle multiple Appendix A.1 and Appendix A.2 require the CPE to handle multiple
Registered Homenet Domain, whereas Appendix A.3 does not have such Registered Homenet Domain, whereas Appendix A.3 does not have such
requirement. requirement.
Appendix B. Document Change Log Appendix B. Document Change Log
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
-05: changing Master to Primary, Slave to Secondary -05: changing Master to Primary, Slave to Secondary
-04: Working Version Major modifications are: -04: Working Version Major modifications are:
- Re-structuring the draft: description and comparison of update and - Re-structuring the draft: description and comparison of update and
security mechanisms have been intergrated into the Overview authentication methods have been integrated into the Overview
section. a Configuration section has been created to describe section. a Configuration section has been created to describe
both configuration and corresponding behavior of the CPE. both configuration and corresponding behavior of the CPE.
- Adding Ports parameters: Server Set can configure a port. The - Adding Ports parameters: Server Set can configure a port. The
Port Server parameter have been added in the DHCP Option Port Server parameter have been added in the DHCPv6 option
payloads because middle boxes may not be configured to let port payloads because middle boxes may not be configured to let port
53 packets and it may also be useful to split servers among 53 packets and it may also be useful to split servers among
different ports, assigning each end user a different port. different ports, assigning each end user a different port.
- Multiple ISP scenario: In order to address comments, the multiple - Multiple ISP scenario: In order to address comments, the multiple
ISPs scenario has been described to explicitly show that the ISPs scenario has been described to explicitly show that the
protocol and DHCP Options do not prevent a CPE connected to protocol and DHCPv6 options do not prevent a CPE connected to
multiple independent ISPs. multiple independent ISPs.
-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 October 2015
-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
- DHCPv6 Server behavior: Following options guide lines - DHCPv6 Server behavior: Following options guide lines
-00: version published in the homenet WG. Major modifications are: -00: version published in the homenet WG. Major modifications are:
- Reformatting of DHCP Options: Following options guide lines - Reformatting of DHCPv6 options: Following options guide lines
- DHCPv6 Client behavior: Following options guide lines - DHCPv6 Client behavior: Following options guide lines
- DHCPv6 Server behavior: Following options guide lines - DHCPv6 Server behavior: Following options guide lines
-00: First version published in dhc WG. -00: First version published in dhc WG.
Authors' Addresses Authors' Addresses
Daniel Migault Daniel Migault
Ericsson Ericsson
8400 boulevard Decarie 8400 boulevard Decarie
Montreal, QC H4P 2N2 Montreal, QC H4P 2N2
Canada Canada
Email: daniel.migault@ericsson.com Email: daniel.migault@ericsson.com
Wouter Cloetens Tomek Mrugalski
SoftAtHome Internet Systems Consortium, Inc.
vaartdijk 3 701 950 Charter Street
3018 Wijgmaal Redwood City, CA 94063
Belgium USA
Email: tomasz.mrugalski@gmail.com
URI: http://www.isc.org
Email: wouter.cloetens@softathome.com
Chris Griffiths Chris Griffiths
Dyn
150 Dow Street
Manchester, NH 03101
US
Email: cgriffiths@dyn.com Email: cgriffiths@gmail.com
URI: http://dyn.com
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015
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
Wouter Cloetens
SoftAtHome
vaartdijk 3 701
3018 Wijgmaal
Belgium
Email: wouter.cloetens@softathome.com
 End of changes. 197 change blocks. 
645 lines changed or deleted 707 lines changed or added

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