| HOMENET | D. Migault (Ed) |
| Internet-Draft | Francetelecom - Orange |
| Intended status: Standards Track | W. Cloetens |
| Expires: April 23, 2014 | SoftAtHome |
| C. Griffiths | |
| Dyn | |
| R. Weber | |
| Nominum | |
| October 20, 2013 |
DHCP DNS Public Authoritative Server Options
draft-mglt-homenet-naming-architecture-dhc-options-00.txt
The home network naming architecture as described in [I-D.mglt-homenet-front-end-naming-delegation] requires a complex naming configuration on the CPE. This configuration MAY not be handled easily by the average end user. Furthermore, such misconfiguration MAY result in making home network unreachable.
This document proposes a DHCP options that provide the CPE all necessary parameters to set up the home network naming architecture.
First, this DHCP options provide automatic configuration and avoid most end users' misconfiguration. Most average end users may not require specific configuration, and their ISP default configuration MAY fully address their needs. In that case, the naming homenet architecture configuration will be completely transparent to the end users. Then, saving naming configuration outside the CPE, makes it resilient to change of CPE or CPE upgrades. Such configuration may also be configured by the end user, via the customer area of their ISP.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
With IPv6, nodes inside the home network are expected to be globally reachable. CPEs are already providing connectivity to the home network, and most of the time already assigns IP addresses to the nodes of the home network using for example DHCPv6.
This makes CPE good candidate for defining the DNS zone file of the home network. However, CPEs have not been designed to handle heavy traffic, nor heavy operations. As a consequence, CPE SHOULD neither host the authoritative naming service of the home network, nor handle DNSSEC operations such as zone signing. In addition, CPE are usually managed by end users, and the average end user is most likely not mastering DNSSEC to administrate its DNSSEC zone. As a result, CPE SHOULD outsource both the naming authoritative service and its DNSSEC management operations to a third party. This architecture, designated as the homenet naming architecture is described in [I-D.mglt-homenet-front-end-naming-delegation], and the third party is designated as the Public Authoritative Servers.
The home network naming architecture [I-D.mglt-homenet-front-end-naming-delegation] defines how the CPE and the Public Authoritative Servers interact together, to leverage some of the issues related to the CPE, and the DNSSEC understanding of the average end user. Even though most of the DNSSEC issues are outsourced to the Public Authoritative Servers, setting the homenet naming architecture still requires some configurations.
Configuration is fine as it provides the opportunity for advanced end users to make the naming architecture fit their specific needs. However most of the end users do not want to configure the homenet naming architecture. In most cases, the end users wants to subscribe and plug its CPE. The CPE is expected to be configured to set automatically and transparently the appropriated home network naming architecture.
Using DHCP options to provide the necessary parameters for setting the homenet naming architecture provides multiple advantages. Firstly, it makes the network configuration independent of the CPE. Any new plugged CPE configures itself according to the provided configuration parameters. Secondly, it saves the configuration outside the CPE, which prevents re-configuring the CPE when it is replaced or reset. Finally ISPs are likely to propose a default homenet naming architecture that may address most of the end users needs. For these end users, no configuration will be performed at any time. This avoids unnecessary configurations or misconfiguration that could result in isolating the home network. For more advanced end users, the configuration MAY be provided also via the web GUI of the ISP's customer area for example. This configuration MAY enable third party Public Authoritative Servers. By doing so, these end users will also benefit from CPE-indepedent configuration and configuration backup.
This document considers the architecture described in [I-D.mglt-homenet-front-end-naming-delegation]. The DNS(SEC) zone related to the home network is configured and set by the CPE and hosted on a Public Authoritative Server. [I-D.mglt-homenet-front-end-naming-delegation] describes how the synchronization between the CPE and the Public Authoritative Server is performed. This document describes DHCP options that provide the necessary parameters to the CPE to set the architecture described in [I-D.mglt-homenet-front-end-naming-delegation].
Section 4 presents an overview of the DHCP options presented in this document and Section 5 describes the format of this option and Section 6, Section 7 and Section 8 details the behavior of respectively the DHCP Client, the DHCP Server and the DHCP Relay.
This document assumes the reader is familiar with [I-D.mglt-homenet-front-end-naming-delegation].
This document assumes that the communication between the CPE and the ISP DHCP Server is protected. This document does not specify which mechanism should be used. [RFC3315] proposes a DHCP authentication and message exchange protection, [RFC4301], [RFC5996] proposes to secure the channel at the IP layer.
This document only deals with IPv6 IP addresses and DHCPv6 [RFC3315]. When we mention DHCP, it MUST be understood as DHCPv6.
To properly configure the home network naming architecture defined in [I-D.mglt-homenet-front-end-naming-delegation], the CPE MUST:
A common way for the CPE to collect these pieces of information is to send an Option Request DHCP Option (ORO) [RFC3315] for the DHCP DNS Public Authoritative Server Option and for the DNS Public Authoritative Name Server Set Option. If the DHCP Sever understand these options, it MAY send back one or multiple instance for each option. Then, the DHCP Client sets the naming architecture.
Similarly, the DHCP Server MAY provide the DHCP DNS Public Authoritative Server Option and for the DNS Public Authoritative Name Server Set Option without any request from the DHCP Client.
Note that how the CPE manage the multiple DNS Homenet Zones is implementation dependent. It MAY synchronize all DNS Homenet Zone with the Public Authoritative Servers, or use zone redirection mechanisms like like CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME [I-D.sury-dnsext-cname-dname]. In the first case, any update requires to update all zone, whereas redirection MAY require only updating a single DNS Homenet Zone.
The DHCP Zone Public Master Option (OPTION_ZONE_PUBLIC_MASTER) is used by the CPE to set the DNS Homenet Zone with the proper NS RRsets and the associated IP addresses. The DHCP Zone Public Master Option provides bindings between Registered Domain Names and Public Authoritative Master.
Following Section 9 of [I-D.ietf-dhc-option-guidelines], the DHCP Zone Master Option encapsulates the DHCP Registered Domain Name Option (OPTION_REGISTERED_DOMAIN_NAMES) that contains a list of registered domain names and the Public Authoritative DHCP Master Option (OPTION_MASTER) that contains the FQDNs and IP addresses of each Public Authoritative Masters.
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_ZONE_PUBLIC_MASTER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ OPTION_REGISTERED_DOMAIN_NAME /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ OPTION_MASTER /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ OPTION_MASTER /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 1: DHCP Zone Public Master Option
When a DHCP Zone Public Master Option is received by the DHCP Client, if the DHCP Registered Domain Name Option does not exist or is void, the CPE ignores the DHCP Zone Public Master Option. It MAY indicate the DHCP Server supports these options but they are not properly configured. Otherwise, it selects all DNS Homenet Zone designated by the DHCP Registered Domain Name Option and adds the Public Authoritative NS, A and AAA records provided by the DHCP Master Option. If DHCP Master Option are missing, the CPE hosts the DNS Homenet Zone for the Registered Domains.
All DHCP Options are propositions. The CPE MAY chose a subset of these according to its policies.
Section 13 illustrates with pseudo code how this MAY be performed.
The DHCP Server sends a DHCP Zone Public Master Option to bind Registered Domain Names to a list of Public Authoritative Masters. How to collect these pieces of information is implementation dependent, and depends on the data structure that stores the information. However, we can reasonably assume that sending a DHCP Zone Public Master Option is composed of two phases:
Section 13 illustrates with pseudo code how this MAY be performed.
The DHCP Registered Domain Name Option (OPTION_REGISTERED_DOMAIN_NAME) contains a list of DNS domain names. It MAY have multiple FQDNs. This option follows the description of section 5.10 [I-D.ietf-dhc-option-guidelines].
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_REGISTERED_DOMAIN_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ DNS Wire Format Domain Name List /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 2: DHCP Registered Domain Name Option
The DHCP Registered Domain Name Option MAY return one or multiple Registered Domain Names. The DHCP Client MUST remove empty strings from the list.
The DHCP Registered Domain Name Option is build from a list of non-empty strings.
The DHCP Master Option provides the FQDN and associated IP addresses of the Public Authoritative Master. Following Section 9 of [I-D.ietf-dhc-option-guidelines], the DHCP Master Option encapsulates the DHCP Master FQDN Option (OPTION_MASTER_FQDN) that contains a single FQDN followed by a DHCP Master IP4 Option (OPTION_MASTER_IP4) or a DHCP Master IP6 Option (OPTION_MASTER_IP6) that contains the associated IP addresses. Only a single DHCP Master IP6 Option or DHCP Master IP4 Option is expected.
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_MASTER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_MASTER_FQDN |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_MASTER_IP4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| OPTION_MASTER_IP6 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 3: DHCP Master Option
The DHCP Master FQDN Option is mandatory, and a DHCP Master Option that do not encapsulate a DHCP Master FQDN Option MUST be ignored. An empty DHCP Master FQDN Option indicates the CPE and a FQDN MUST be provided by the CPE. DHCP Master IP4 Options and DHCP Master IP6 Options are optional. Following Section 8 of [I-D.ietf-dhc-option-guidelines], providing IP addresses avoids DNS(SEC) resolutions which unnecessarily load the network and delay the configuration. As a result, it is recommended to provide the IP addresses. If at least a single non void DHCP Master IP4 Option or DHCP Master IP6 Option is provide, the DHCP Client MUST NOT perform any DNS(SEC) resolution. Otherwise, the DHCP Client SHOULD perform a DNSSEC resolution.
Section 13 illustrates with pseudo code how this MAY be performed.
DHCP Master Options are built from the master object. If the FQDN of the Public Authoritative Master is empty, the DHCP Master Option MUST NOT be built. If no IP address has been provisioned, the DHCP Server SHOULD perform a DNS(SEC) resolution and provide the IP addresses.
Section 13 illustrates with pseudo code how this MAY be performed.
The DHCP Master FQDN Option (OPTION_MASTER_FQDN) designates the FQDN of the Public Authoritative Server. Only one FQDN is expected. This option follows the description of section 5.10 [I-D.ietf-dhc-option-guidelines].
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_MASTER_FQDN | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ DNS Wire Format Domain Name /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 4: DHCP Master FQDN Option Format
This section defines the IP addresses associated to the master. This option follows the recommendation of section 5.1 and 8 of [I-D.ietf-dhc-option-guidelines].
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_MASTER_IP4 | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ip4-address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ip4-address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 5: DHCP Master IP4 Option Format
This section defines the IP addresses associated to the master. This option follows the recommendation of section 5.1 and 8 of [I-D.ietf-dhc-option-guidelines].
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_MASTER_IP6 | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ip6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ip6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 6: DHCP Master IP6 Option Format
The DHCP Public Master Upload Option (OPTION_PUBLIC_MASTER_UPLOAD) is used to associate a secure channel for each Public Authoritative Master.
More specifically, to publish a DNS Homenet Zone on a given Public Authoritative Master, the CPE establish a secure channel with the Public Authoritative Name Server Set and upload the DNS Homenet Zone using master / slave mechanisms. It is then the responsibility of the Public Authoritative Name Server Set to publish the DNS Homenet Zone to its associated Public Authoritative Masters.
The DHCP Public Master Upload Option enables the CPE to set an address book where the key is the Public Authoritative and the value is a set of Secure Channels. For each DNS(SEC) Homenet Zone, the CPE is expect to list the Public Authoritative Master and for each of them upload the DNS(SEC) Homenet Zone file to the Public Authoritative Name Server Set via a Secure Channel.
Following Section 9 of [I-D.ietf-dhc-option-guidelines], the DHCP Public Master Upload Option encapsulates a DHCP Master FQDN List Option (OPTION_MASTER_FQDN_LIST) that contains the list of the FQDNs of the Public Authoritative Master and a list of DHCP Secure Channel Options (OPTION_SECURE_CHANNEL) that list how the CPE can upload the DNS(SEC) Homenet Zone. For each of the mentioned Public Authoritative Master, the CPE is expected to consider one of the DHCP Secure Channel Options to upload the Zone.
The DHCP Master FQDN List Option is mandatory and MUST be unique. At least one DHCP Secure Channel Options MUST be encapsulated.
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_MASTER_UPLOAD | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ OPTION_MASTER_FQDN_LIST /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ OPTION_SECURE_CHANNEL /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ OPTION_SECURE_CHANNEL /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 7: DHCP Public Master Upload Option Format
When the DHCP Client receives a DHCP Public Master Upload Option, it builds a dictionary between, Public Authoritative Master FQDN and possible Secure Channels. Secure Channel that do not correspond to the CPE policy, MAY be discarded.
This binding will be used latter when the CPE uploads the DNS(SEC) Homenet Zone files. Section 13 illustrates with pseudo code how this MAY be performed.
The DHCP Server SHOULD send at least a Secure Channel for each of the Public Authoritative Master. All Public Authoritative Masters associated to the DHCP Client that are provided in a DHCP Zone Public Master Option MUST be mentioned in an DHCP Public Master Upload Option.
Packing a DHCP Public Master Upload Option is performed in a similar way as the DHCP Zone Public Master Option. A binding between the Public Authoritative Master and the Secure Channels is performed. Then, this dictionary is factorized as described in Section 5.1.2. More specifically, all keys with the same value are grouped.
The DHCP Master FQDN List Option is similar to the DHCP Master FQDN Option except that it can indicate multiple Master FQDNs.
The DHCP Secure Channel Option (OPTION_SECURE_CHANNEL) indicates:
Following Section 9 of [I-D.ietf-dhc-option-guidelines], the DHCP Secure Channel Option encapsulates the DHCP Secure Protocol Option, the DHCP Secure Credential Option and the DHCP Server Set Option. Each of these options is mandatory and MUST appear only once.
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_SECURE_CHANNEL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| OPTION_SECURE_PROTOCOL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | OPTION_SECURE_CREDENTIAL |
+-+-+-+-+-+-+-+-+ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ OPTION_SERVER_SET /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 8: DHCP Secure Channel Option Format
When the DHCP Secure Channel Option is received, the DHCP Client MUST check that DHCP Secure Protocol Option, DHCP Secure Credential Option and DHCP Server Set Option are unique. If not, the DHCP Client MUST ignore the DHCP Secure Channel Option.
The DHCP Client MUST also check proposition match its policies and Secure Credentials match the Secure Protocol.
Section 13 illustrates with pseudo code how this MAY be performed.
Packing the DHCP Secure Channel Option from the Secure_channel object is straight forward.
The DHCP Secure Protocol Option (OPTION_SECURE_PROTOCOL) is a 8-bit integer option that fills recommendation of section 5.6 of [I-D.ietf-dhc-option-guidelines].
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_SECURE_PROTOCOL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol |
+-+-+-+-+-+-+-+-+
Fig 9: DHCP Secure Protocol Option Format
The protocol detailed in this document are:
The DHCP Secure Credential Option encapsulates the necessary element to authenticate and set up the secure channel. Currently, only the DHCP PSK Credential Option (OPTION_PSK_CREDENTIAL) is defined in this document but the use of DHCP Secure Credential Option enables makes possible the use of different credential in the future.
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_SECURE_CREDENTIAL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
/ credential-option /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 10: DHCP Secure Credential Option Format
The DHCP PSK Credential Option (OPTION_PSK_CREDENTIAL) contains the pre-shared key. It can be used with IPsec, TSIG. If SIG(0) is selected as a protocol, the DHCP server MUST NOT provide this option, and it MUST be ignored by the DHCP Client.
Note that PSK MUST NOT be sent by the DHCP Server over an non trusted channel. In addition a DHCP Server SHOULD NOT provide the PSK unless requested explicitly by the DHCP Client. Similarly, the DHCP Client MUST NOT request the PSK if the channel between the DHCP Client and the DHCP Server is not trusted.
This option follows recommendation of section 5.9 of [I-D.ietf-dhc-option-guidelines].
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_PSK_CREDENTIAL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
/ psk /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DHCP Server Set Option (OPTION_SERVER_SET) carries the IP addresses of the Public Authoritative Name Server Set. It is recommended to have one IP address, and eventually two if the Public Authoritative Server is dual stack. In any case no more than one IP address of each family is expected. The use of IP addresses instead of FQDN follows recommendation of [I-D.ietf-dhc-option-guidelines] section 8.
The DHCP Server Set Option encapsulates the DHCP Server Set IP4 Option (OPTION_SERVER_SET_IP4) and the DHCP Server Set IP6 Option (OPTION_SERVER_SET_IP6).
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_SERVER_SET | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SERVER_SET_IP4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| OPTION_SERVER_SET_IP6 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DHCP Server Set IP4 Option (OPTION_SERVER_SET_IP4) carries the IP address of the Public Authoritative Name Server Set. This option follows the recommendation of section 5.1 and 8 of [I-D.ietf-dhc-option-guidelines].
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_SERVER_SET_IP4 | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ip4-address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DHCP Server Set IP6 Option (OPTION_SERVER_SET_IP6) carries the IP address of the Public Authoritative Name Server Set. This option follows the recommendation of section 5.1 and 8 of [I-D.ietf-dhc-option-guidelines].
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_SERVER_SET_IP6 | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ip6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DHCPv6 server MAY send DHCP Zone Public Master Option and/or DHCP Public Master Upload Option upon receiving or not a DHCP Option Request Option (ORO) by the DHCP Client.
The DHCP Server MAY send zero, one or multiple DHCP Zone Public Master Option or DHCP Public Master Upload Option.
The DHCP Server MUST send these option over a trusted channel. The PSK MUST NOT be sent over a non trusted channel.
If the DHCP Server is not provisioned properly, it SHOULD send empty DHCP Zone Public Master Option or DHCP Public Master Upload Option to indicate it supports the options, but they are not provisioned properly.
Although DHCP Zone Public Master Option and DHCP Public Master Upload Option are different options, they MAY be used together by the DHCP Client. Unless there are good reasons, DHCP Servers SHOULD provide in their DHCP Public Master Upload Option a Secure Channel for all Public Authoritative Masters mentioned in the DHCP Zone Public Master Option. In other words, for all Public Authoritative Masters mentioned in the DHCP Zone Public Master Option, the DHCP Server SHOULD send a DHCP Public Master Upload Option that provides a Secure Channel.
The DHCPv6 Client MAY enable different policies to configure the Home Network Naming Architecture. More specifically, it MAY allow an end user to set manually a specific naming configuration, which may disable automatic configuration of the Home Network Naming Architecture. If automatic configuration of the Home Network is not considered, the CPE SHOULD NOT send a DHCP Option Request Option (ORO) from the CPE for a DHCP DNS Public Authoritative Server Option or for a DHCP Public Master Upload Option. This would otherwise unnecessarily load the DHCPv6 Server of the ISP and the network.
The DHCP Client SHOULD NOT send and ORO for a DHCP Zone Public Master Option or a DHCP Public Master Upload Option if the channel between the DHCP Client and the DHCP Server is not trusted.
By sending an DHCP Option Request Option (ORO) for a DHCP Zone Public Master Option or a DHCP Public Master Upload Option, the CPE indicates that the response received from the DHCP Server will define how the Naming Architecture of the CPE is configured. However, this does not necessarily mean that the CPE will automatically configure its Naming Architecture according to according to the elements provided by the DHCPv6 Server. In fact the CPE MAY implement various policies to configure the Naming Architecture. Some policies MAY merge configuration manually provided by the end user and those provided by the DHCPv6 Server, others MAY only accept a subset of Public Authoritative Name Servers provided by the DHCPv6 Server. Defining the selection policies of the CPE is how of scope of this document.
The remaining of the section describes how the DHCPv6 Client handles information received by the DHCPv6 Server to configure the Naming Architecture. We assume that all information are considered. Although this document restricts the description to a single use case, we believe this will be the most common and basic use case. In addition, other uses cases implementing different configuration policies only requires small modifications to the use case considered in this section.
If the DHCPv6 Client does not receive any DHCP Zone Public Master Option or DHCP Public Master Upload Option from the DHCPv6 Server. The DHCPv6 Client assumes the DHCPv6 Server does not support the option. In this case, the Naming Architecture can only be set from local settings.
By receiving empty DHCP Zone Public Master Option or empty DHCP Public Master Upload Option. The DHCP Client assumes the DHCP Server supports these options, but they are not or badly provisioned.
The DHCPv6 Client MAY receive one or multiple DHCP Zone Public Master Option and/or DHCP Public Master Upload Option. From these Option the CPE is expected to :
DHCP Relay behavior are not modified by this document.
The DHCP options detailed in this document is:
The security-protocol detailed in this document are:
The security-credential detailed in this document are:
The document describes how the Secure Delegation can be set between the Delegating DNS Server and the Delegated DNS Server.
Deploying DNSSEC is recommended since in some cases the information stored in the DNS is used by the ISP or an IT department to grant access. For example some Servers may performed a PTR DNS query to grant access based on host names. With the described Delegating Naming Architecture, the ISP or the IT department MUST take into consideration that the CPE is outside its area of control. As such, with DNS, DNS responses may be forged, resulting in isolating a Service, or not enabling a host to access a service. ISPs or IT department may not base their access policies on PTR or any DNS information. DNSSEC fulfills the DNS lack of trust, and we recommend to deploy DNSSEC on CPEs.
In the document we consider that the channel between the CPE and the ISP DHCP Server is trusted. More specifically, we suppose the CPE is authenticated and the exchanged messages are protected. The current document does not specify how to secure the channel. [RFC3315] proposes a DHCP authentication and message exchange protection, [RFC4301], [RFC5996] propose to secure the channel at the IP layer.
In fact, the channel MUST be secured because the CPE provides necessary information for the configuration of the Naming Delegation. Unsecured channel may result in setting the Naming Delegation with an non legitimate CPE. The non legitimate CPE would then be redirected the DNS traffic that is intended for the legitimate CPE. This makes the CPE sensitive to three types of attacks. The first one is the Deny Of Service Attack, if for example DNS traffic for a lot of CPEs are redirected to a single CPE. CPE are even more sensitive to this attack since they have been designed for low traffic. The other type of traffic is the DNS traffic hijacking. A malicious CPE may redirect the DNS traffic of the legitimate CPE to one of its server. In return, the DNS Servers would be able to provide DNS Responses and redirect the End Users on malicious Servers. This is particularly used in Pharming Attacks. A third attack may consists in isolating a Home Network by misconfiguring the Naming Delegation for example to a non-existing DNS Server, or with a bad DS value.
The Naming Delegation Architecture involves the CPE that hosts a DNS Server for the Home Network. CPE have not been designed for handling heavy load. The CPE are exposed on the Internet, and their IP address is publicly published on the Internet via the DNS. This makes the Home Network sensitive to Deny of Service Attacks. The Naming Delegation Architecture described in this document does not address this issue. The issue is addressed by [I-D.mglt-homenet-front-end-naming-delegation].
We would like to thank Tomasz Mrugalski and Bernie Volz for their comments on the design of the DHCP Options.
[RFC Editor: This section is to be removed before publication]
-00: version published in the homenet WG. Major modifications are:
-00: First version published in dhc WG.
This section is informational. It aims at illustrating how options MAY be handled by the DHCP Client or the DHCP Server. Not all the DHCP Options described in the document are considered. This section is not normative and implementation MAY differ.
## We consider the following object for the CPE:
## Class cpe
## self.ip4_list
## self.ip6_list
## self.fqdn
receive_dhcp_zone_public_master_option(OPTION_ZONE_PUBLIC_MASTER):
## Checking existence of Registered Domains
if OPTION_REGISTERED_DOMAIN_NAME is empty or missing:
ignore OPTION_ZONE_PUBLIC_MASTER
## Checking existence of Public Authoritative Masters
if OPTION_ZONE_PUBLIC_MASTER has no OPTION_MASTER options:
build_option_master(cpe.fqdn, cpe.ip4_list, cpe.ip6_list)
## select each DNS Homenet Zone
for zone_name in OPTION_REGISTERED_DOMAIN_NAME:
## adds Public Authoritative Master information to the
## zone_name. Typically this may consists in adding the
## lines:
## zone_name NS master_fqdn
## master_fqdn A ip4
## master_fqdn A ip6
for each OPTION_MASTER:
(fqdn, ip4_list, ip6_list) = \
get_master_option_info(OPTION_MASTER)
add_ns(fqdn, zone_name)
add_a(fqdn, ip4_list, zone_name)
add_aaa(fqdn, ip6_list, zone_name)
Fig 11: Pseudo code for receiving a DHCP Zone
Public Master Option
The pseudo code for sending a DHCP Zone Public Master Option is presented below. It is informational and intedns to illustrates text above. Implementation MAY be different.
## We consider the following objects for Public Authoritative Master
## Class master
## self.ip4_list
## self.ip6_list
## self.fqdn
build_dhcp_zone_public_master_option():
## Collect all Registered Domain and associate the list of
## Public Authoritative Master. One way it to build the
## registered_domain_dict = {registered_domain:[master_list]}
tmp_rd_dict = build_registered_domain_dict()
## Remove void registered domain names,
## Factorize registered_domain_dict and output
rd_dict = factorize_registered_domain_dict(tmp_rd_dict)
## Build DHCP Zone Public Master Option
for registered_domain_list, master_list in rd_dict.items():
## Builds the DHCP Zone Public Master Option Data Payload
data = \
build_registered_domain_name_option(registered_domain_list)
## Concatenation with DHCP Public Authoritative Master
## Options
for master in master_list:
data += build_master_option(master)
## Build the DHCP Zone Public Master Option
return build_header_zone_public_master(data) + data
Fig 12: Pseudo code for sending DHCP Zone
Public Master Option
def get_master_option_info(OPTION_MASTER):
if OPTION_MASTER is empty:
## Consider the CPE for the Public Authoritative Master
## or ignore the option
## build_option_master(cpe.fqdn, cpe.ip4_list, cpe.ip6_list)
ignore OPTION_MASTER
if OPTION_MASTER_FQDN is empty or missing:
ignore OPTION_MASTER
if multiple OPTION_MASTER_IP4 or\
multiple OPTION_MASTER_IP4:
ignore OPTION_MASTER
fqdn = get_fqdn(OPTION_MASTER_FQDN)
ip4_list = []
ip6_list = []
## collect Public Authoritative Master's IP addresses
if OPTION_MASTER_IP4 exists:
append(ip4_list, get_ip4(OPTION_MASTER_IP4))
if OPTION_MASTER_IP6 exists:
append(ip4_list, get_ip4(OPTION_MASTER_IP4))
## if no IP addresses are provided perform a DNSSEC
## resolution
if len(ip4_list) == 0 and len(ip6_list) == 0:
ip4_list = dig(fqdn, A)
ip6_list = dig(fqdn, AAAA)
Fig 13: Pseudo code for Unpacking DHCP Master Option
The pseudo code illustrates how the DHCP Server builds a DHCP Master Option.
def build_master_option(fqdn, ip4_list, ip6_list):
## Do not build the data payload of the DHCP Master Option
## if fqdn is empty or a null string
if fqdn is empty or fqdn has more than one fqdn:
return error
data = build_master_fqdn_option(fqdn)
if ip4_list is empty:
ip4_list = dig(fqdn, A)
if ip6_list is empty:
ip6_list = dig(fqdn, AAAA)
if ip4_list is empty and ip6_list is empty:
return error
if ip4_list is not empty:
data += build_master_ip4_option(ip4_list)
if ip6_list is not empty:
data += build_master_ip6_option(ip6_list)
return build_header_master(data) + data
Fig 14: Pseudo code for Packing DHCP Master Option
The pseudo code for building the binding between Public Authoritative Master and Secure Channel MAY be as follows:
## We consider the master_secure_channel_dict that associates
## for each master a list of Secure Channel
## master_secure_channel_dict = {master: [secure_channel], ..., }
## This function is used to add an entry to the
## master_secure_channel_dict
def get_master_upload_option_info(OPTION_PUBLIC_MASTER_UPLOAD):
if OPTION_MASTER_FQDN_LIST is not unique or\
OPTION_SECURE_CHANNEL does not exist:
ignore OPTION_PUBLIC_MASTER_UPLOAD
secure_channel_list = []
for all OPTION_SECURE_CHANNEL:
sc = get_secure_channel_info(OPTION_SECURE_CHANNEL)
secure_channel_list.append(sc)
for each master in OPTION_MASTER_FQDN_LIST:
master_secure_channel_dict[master] = secure_channel_list
Fig 15: Pseudo code for receiving a DHCP Public
Master Upload Option
## We consider the secure_channel object
## Class Secure_channel:
## self.protocol
## self.credential
## self.server_set_ip4
## self.server_set_ip6
def get_secure_channel_option_info(OPTION_SECURE_CHANNEL):
if OPTION_SECURE_PROTOCOL is not unique or \
OPTION_SECURE_CREDENTIAL is not unique or\
OPTION_SERVER_SET is not unique:
ignore OPTION_SECURE_CHANNEL
protocol = \
get_secure_protocol_option_info(OPTION_SECURE_PROTOCOL)
credential = \
get_secure_credential_option_info(OPTION_SECURE_CREDENTIAL)
ip4, ip6 = \
get_server_set_option_info(OPTION_SERVER_SET)
return(Secure_channel(protocol, credential, ip4, ip6))
Fig 16: Pseudo code for receiving a DHCP
Secure Channel Option
| [RFC1034] | Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2181] | Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. |
| [RFC4301] | Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. |
| [RFC5996] | Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. |
| [RFC3315] | Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. |
| [RFC6672] | Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, June 2012. |
| [I-D.sury-dnsext-cname-dname] | Sury, O., "CNAME+DNAME Name Redirection", Internet-Draft draft-sury-dnsext-cname-dname-00, April 2010. |
| [I-D.mglt-homenet-front-end-naming-delegation] | Migault, D., Cloetens, W., Lemordant, P. and C. Griffiths, "IPv6 Home Network Front End Naming Delegation", Internet-Draft draft-mglt-homenet-front-end-naming-delegation-01, November 2012. |
| [I-D.ietf-dhc-option-guidelines] | Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S. and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", Internet-Draft draft-ietf-dhc-option-guidelines-14, September 2013. |