| HOMENET | W.C. Cloetens |
| Internet-Draft | SoftAtHome |
| Intended status: Standards Track | P.L. Lemordant |
| Expires: December 31, 2012 | D.M. Migault (Ed) |
| Francetelecom - Orange | |
| July 2012 |
IPv6 Home Network Naming Delegation Architecture
draft-mglt-naming-delegation-00.txt
This document describes the Naming Delegation Architecture that makes IPv6 Home Network globally reachable with Names or Fully Qualified Domain Names (FQDN). In this architecture, the Customer Premise Equipment (CPE) acts as the DNS Authoritative Server of the Home Network also called the Delegated DNS Server. The Naming Delegation is configured between the Delegated DNS Server and the Delegating DNS Server managed by the ISP.
The use case considered in this document is an End User that subscribes its ISP a specific Delegated Domain for its Home Network. This document describes how the CPE automatically sets the Naming Delegation between the Delegating and Delegated DNS Server.
The Naming Delegation is requested by the CPE. The CPE DHCP Client and the ISP DHCP Server exchange DHCP Options to properly set the Naming Delegation. More specifically, the CPE DHCP Client (resp. the ISP DHCP Server) configures the DNS(SEC) Zones of the Delegated DNS Server (resp. Delegating DNS Server). For the Delegating DNS Server, the necessary pieces of information required to set the Naming Delegation are the IP address of the Delegated DNS Server, and if DNSSEC is used, the Delegation of Signing Information. For the Delegated DNS Server, the necessary information is the Delegated Domain associated to the Home Network.
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 December 31, 2012.
Copyright (c) 2012 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].
Home Networks used to be composed of a single or a set of PCs connected to a CPE to access the Internet. Now they have evolved to a large set of applications and objects or devices managed by the CPE. Among these applications are Media applications like Video, Music and Photos Stations, Backup applications, File sharing applications with FTP and Web Stations, Access applications with VPN Stations, and others like Surveillance Station, Printing Stations. With the Internet of Things (IoT) the number of objects attached to the CPE is expected to increase in the coming years.
Then, services and objects in the Home Networks should be made reachable from anywhere on the Internet. IPv6 removes the need for NAT and makes this possible with a global reachability. But IPv6 addresses remain inconvenient. In fact, most End Users prefer using Names to access these services. Furthermore Names make communications independent from IP renumbering, or changes of IP addresses. Then, if IP addresses plan remains opaque for End Users, on the other hand, they easily understand the Naming hierarchical model. More specifically, if "my-homenet" is the Delegated Domain associated to my Home Network, it makes sense that "my-service.my-homenet" is the "my-service" in "my-homenet".
To assign Names to objects and services of the Home Network, the Home Network should be provided a Naming Architecture. For most End Users, the CPE manages the Home Network, that is to say, it provides access to the Internet, discovers the devices, and interconnects them between each other. As a result, the CPE is the natural device to centralize the Naming service of the Home Network.
Home Networks should be operational with the least configuration. End Users, expect to subscribe to an ISP, plug with minimum configuration the CPE and access to the Internet and to their services from anywhere on the Internet. The CPE interconnects the Home Network to the ISP's Network, and the CPE gets from the ISP all the necessary pieces of information to set up the connectivity. In some cases, the CPE is even provided by the ISP. In order to make services and objects of the Home Network reachable with Names, the ISP is likely to provide the CPE the Delegated Domain associated to the Home Network, and set up the necessary delegation to make the Home Network DNS Zone reachable from the Internet. More specifically, the End User subscribes its ISP an Internet connectivity, and registered its Home Network Delegated Domain "my-homenet". When the CPE is plugged, as it requests an IP prefix, it also requests the Delegated Domain - like "my-homenet.example.". From then, all devices requesting IP addresses via DHCP or using alternative protocols are registered by the CPE in the zone "my-homenet.example.". When a communication is initiated with "a-device.my-homenet.example.", a DNS query is sent to the ISP authoritative DNS server of the zone "example.". This server is called the Delegating DNS Server and delegates the query to the CPE which acts as the authoritative server of "my-homenet.example." and sends back the response.
This architecture is called the "Home Network Naming Delegation Architecture" because, the ISP is not hosting the DNS zone of the Home Network but is delegating the Home Network zone to the CPE. There are multiple motivations for this delegation architecture. First delegation preserves the Home Network privacy, by avoiding ISPs to know the Home Network hosts. Furthermore, ISP are unlikely to be able to scale their Naming infrastructure for all services and devices of the Home Networks. As a result, ISPs are looking to distribute the Naming service between the CPEs, and delegate to each CPE their associated Home Network zone.
The purpose of this document is to describe an architecture that automatically configures the Naming architecture of the Home Network. More specifically, when the End User plugs its CPE, the CPE is being assigned by the ISP a Delegated Domain that has been pre-registered by the End User to the ISP. This Delegated Domain designates the Home Network, and the CPE is expected to act as an authoritative DNS server of this Zone. When a node of the Home Network is requesting using DHCP an IP address, the CPE can provide the node the IP address and updates the zone file of the Home Network.
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 does not provide any mechanism that protects the CPE from being exposed on the Internet. In fact, CPE are low power devices, and the Naming Delegation described in this document exposes the CPE on the Internet by publishing its IP address and making the DNS Service hosted on the CPE. This issue is addressed in [I-D.mglt-front-end-naming-delegation] which describes the Front End Naming Delegation Architecture. In this architecture, the ISP's infrastructure protects the CPE from heavy load.
This document only deals with IPv6 IP addresses and DHCPv6 [RFC3315]. When we mention DHCP, it MUST be understood as DHCPv6.
This sections defines terminology specific to IPv6 and DHCP used in this document.
The Home Network Naming Architecture is defined by two parties the End User and the ISP. Both of them have specific requirements.
The End User requirements we are considering are the following:
The ISP requirements, other than fulfilling the End Users' requirements are the following:
The CPE is designed to provide connectivity to the Home Network, to discover and connect all Hosts of the Home Network. As such, it is a good candidate to bind FQDNs and IP addresses. In this document, we consider the CPE as the device that centralizes the configuration of the Delegation Home Network Naming Architecture. This fulfills the End User Requirement 1.
The CPE should not be configured, and should get the necessary information to properly configure the Delegation Home Network Naming Architecture. These pieces of information, like the Delegated Domain assigned to the Home Network are provided by the ISP. On the other hand, the CPE may also be able to provide information to the ISP. For example, the CPE may provide the ISP the Delegated DNS IP Address Information, that is to say the Interface and Subnet Identifier of the Home Network Authoritative DNS, or the Delegated Delegation of Signing which is the hash of public key of the Home Network Authoritative DNS server. In this document, we call the Home Network Authoritative DNS server the Delegated DNS Server. These pieces of information are device related and local information. They are not related to the configuration of the Delegation Home Network Naming Architecture. This fulfills the End User Requirement 2.
The CPE should set the Naming Delegation Architecture by requesting for it. The CPE can be configured to not request these pieces of information so the Home Network can have a specific Naming configuration. A specific Naming configuration could be for example, that the FQDN assigned to the Home Network is different from the one attributed by the ISP. This fulfills the End User Requirement 3.
The CPE acts as an authoritative DNS server for the Home Network. This prevents communication of the DNS zone to any third party. As a result, this makes the DNS zone publicly available, while protecting the privacy of the Home Network. This fulfills the End User Requirement 4.
The CPE provides the Home Network Authoritative DNS server or Delegated DNS Server. This function is an added function to the service/device discovery, routing service, DHCP service, Naming resolution service, provided by the CPE. The CPE seems to be the most adapted device, for most End Users cases, to host the Delegated DNS Server. This service includes handling with the DNS queries concerning the Home Network and updating the zone for the various devices. The load generated by the Delegated DNS Server is expected to be handled by the CPE, and CPE may be designed to handle such traffic. On the other hand, it is hardly possible ISPs can handle with this traffic for all Home Networks. The Delegation Home Network Naming Architecture is adopted for its scalability. This fulfills the ISP Requirement 1.
Figure 1 describes a DNS resolution with the Naming Delegation Architecture. The resolution can be done using DNS or DNSSEC. In the Architecture described in figure 1, the IPv6 address MUST be global.
In the example below, the Zone of the ISP is called "example.". The End User of the CPE has registered to the ISP the Delegated Domain "my-homenet", and the Home Network can be globally reachable under the name "my-homenet.example.". A host in the Home Network "host1" has been assigned an IPv6, and has been registered in the Home Network with the name "host1.my-homenet.example.". Note that the architecture makes host1 globally reachable under the name "host1.my-homenet.example.".
The End User is likely to use alternate names which will require the use of DNAME [RFC6672] and CNAME [RFC2118] . In other words, the Naming Delegation Architecture described in this document does not prevent the End User to register a service or a host under an alternative name such as "host1-alternative-name.example.net". For that purpose, the End User may redirect manually "host1-alternative-name.example.net" to "host1.my-homenet.example." using CNAME [RFC2118]. Similarly, the Home Network can also be registered under an alternate domain name such as "my-alternate-homenet.net". Redirecting the zone requires to use DNAME. In both case, the configuration is performed by the End User, and is independent to the configuration between the ISP and the End User.
In figure 1, the Resolver is getting the IP address of "host1.my-homenet.example.". A DNS(SEC) Query is sent to the Delegating DNS Server responsible of "example.". Then "example." responds with the delegating information, so the resolver can send the DNS Query to the Delegated DNS Server responsible of "my-homenet.example.". The delegating pieces of information are, the Name and IP address of the Delegated DNS Server, and if DNSSEC is available and requested the Delegation of Signing. These pieces of information may have been provided by the Delegated DNS Address Information and Delegated Delegation of Signing DHCP Options.
Then, the Resolver sends the DNS(SEC) Query to the Home Network Delegated DNS Server which responds with the requested DNS(SEC) information.
+----------------------------+ DNS Query +---+
| ISP DNS Server | hots1.my-homenet.example. AAAA | |
| Delegating Servers | <---------------------------------- | |
| ZONE "example." | DNS Response: | |
| | my-homenet.example. NS IP6 | R |
| | [my-homenet.example. DS [...]] | E |
+----------------------------+ ----------------------------------> | S |
+----------------------------+ DNS Query | O |
| CPE DNS Server | host1.my-homenet.example. AAAA | L |
| Delegating Server | <---------------------------------- | V |
| ZONE "my-homenet.example." | DNS Response: | E |
| | my-homenet.example. NS IP6 | R |
| | [my-homenet.example. RRSIG [...]] | |
+----------------------------+ ----------------------------------> | |
| | | |
+------------+ +------------+ +---+
| Host 1 | | Host n |
+------------+ +------------+
Figure 1: DNS Resolution with the Home Network Delegating Architecture
Figure 2 shows the DHCP exchange between the CPE and the ISP DHCP Server. This exchange sets the Home Network Naming Delegation Architecture.
As mentioned in figure 2, the CPE is in the Home Network and implements three functions: the DHCP Client (DHCP_CLT), the DHCP Server (DHCP_SRV) and the Delegated DNS Server (DNS_SRV).
The ISP DHCP Server is in the ISP Network and is the counter part of the CPE DHCP Client (DHCP_CLT). As the CPE DHCP Client (DHCP_CLT) interacts with the Delegated DNS Server, the ISP DHCP Server also interact with the ISP Delegating DNS Server. In fact the ISP DHCP Server is in charge of setting the Naming Delegation upon request of the CPE DHCP Client (DHCP_CLT). Furthermore, when the Home Network Prefix Delegation is not any more active, the ISP DHCP Server MUST remove the Naming Delegation settings.
Hosts are the devices of the Home Network. Figure 2, illustrates the case, where these hosts have been assigned an IPv6 prefix from the DHCP Server of the CPE. We use the "stateful address autoconfiguration protocol", as defined in [RFC3315] but other protocols like "IPv6 Stateless Address Autoconfiguration" [RFC4862] may also be used. This will not affect the Naming Delegation Architecture.
<--------- Home Network ----------> <--------- ISP --------->
+--------+ +---------------------+ +-----------------------+
| Host 1 +--+ CPE | | ISP DHCP |
+--------+ +----------+----------+ +-----------------------+
. | DHCP_SRV | DHCP_CLT | | |
. | v | | | |
. | v | DHCP Request ----------------------> |
. | v | DELEGATED_DNS_ARCHITECTURE, |
. +----------| DELEGATED_DNS_ADDR_INFO, |
. | DNS_SRV | ORO(IA_PD) |
. +----------| [DS, ORO(DELEGATED_DOMAIN)] |
. | ^ | | | |
. | ^ | <---------------------- DHCP Reply |
. | ^ | DELEGATED_DNS_ARCHITECTURE, |
| ^ | DELEGATED_DOMAIN, |
+--------+ | ^ | IA_PD |
| Host n +--| < < < DHCP_CLT | | |
+--------+ +----------+--------- + +-----------------------+
Figure 2: Naming Delegation Architecture
Figure 2 illustrates how the CPE provides and get the necessary information to set the Naming Delegation. In this document, all parameters are provided and received using DHCP Options.
First of all, in order to set the Home Network Naming Delegation, the CPE MUST have a Delegated Prefix. In our case, the CPE is requesting the Delegated Prefix to the ISP DHCP Server with the Identity Association Prefix Delegation DHCP Option (IA_PD), as defined in [RFC3633], [RFC3769]. To Request the Option from the ISP DHCP Server, the CPE uses the Option Request DHCP Option (ORO) [RFC3315].
The CPE uses the Delegated DNS Architecture DHCP Option (OPTION_DELEGATED_DNS_ARCHITECTURE) to specify the naming-delegation-action to perform. The CPE provides a ordered list of alternative naming-delegation-actions. One of these actions will be chosen by the ISP DHCP Server. The naming-delegation-actions considered in this document are Clear the Naming Delegation Settings, Set it with DNS or Set is with DNSSEC. Figure 2 illustrates the case where the CPE Sets the Naming Delegation Architecture with DNS or with DNSSEC.
In order to set the Naming Delegation Architecture between the Delegating DNS Server and the Delegated DNS Server, the CPE MUST provide some pieces of information. First the Delegating DNS Server MUST be aware of the IP address used for the Delegated DNS Server. Since the CPE is requesting a Prefix Delegation, it is not aware of the IP address. That is why, the CPE MUST provide pieces of information that enables the ISP DHCP Server to derive the IP address. In fact the CPE provides the Subnet Identifier and the Interface Identifier using the Delegated Address Information DHCP Option (OPTION_DELEGATED_DNS_ADDR_INFO). The ISP DHCP Server is aware of the assigned prefix, and thus can derive the IP address of the Delegated DNS Server.
The calculation of the CPE IPv6 address used for the delegated DNS server is done as follows:
0 63|64 127
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix | subnet-ID | interface-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
subnet-ID length = 64 – IPv6 prefix length
Figure 3: CPE IP address Format
If DNSSEC is used, the CPE MUST also provide the Delegation of Signing (DS) Information [RFC4034]. This is done using the Delegation of Signing DHCP Option (OPTION_DS)
In figure 2, we mentioned the Delegated Domain DHCP Option that can optionally be requested. In fact, with Delegated DNS Architecture DHCP Option requesting the ISP to Set the Naming Delegation Architecture, the ISP is expected to send back the Delegated Domain. However, in some cases, for example if the CPE wants to checks the ISP has provisioned a Delegated Domain, the CPE may request the Delegated Domain without setting the Naming Delegation Architecture. In that case, the CPE, MUST request the Delegated Domain DHCP Option (OPTION_DELEGATED_DOMAIN).
The ISP DHCP Server processes the various DHCP Options, and provides the Prefix Delegation, the Delegated DNS Architecture, and the Delegated Domain DHCP Options. The Prefix Delegation Option provides the IPv6 Prefix assigned to the Home Network. The Delegated DNS Architecture DHCP Option indicates the Naming Delegation set by the ISP, as well as Status Code. The Delegated Domain DHCP Option provides the Domain the owner of the CPE has registered.
The ISP DHCP Server MUST keep the Naming Delegation Architecture coherent with the Prefix Delegation. If the Prefix Delegation is using DHCP, then, the ISP DHCP Server MUST unset the Naming Delegation Architecture when the Prefix Delegation expires. How the DHCP Server should proceed is out of scope of this document.
In this document, we do not consider the CPE and the ISP have pre-agreed on some parameters. In other words, all necessary information for configuring the Home Network Naming Delegation Architecture are sent via DHCP Options. The ISP is in charge of identifying the CPE owner - that is to say the End User - and is aware of the Delegated Domain the End User has subscribed for.
For clarity, we designated the CPE DHCP Client by the CPE.
The CPE provides the ISP DHCP Server an ordered list of naming-delegation-actions which starts with the most most preferred action. The ISP DHCP Server can chose one of these actions and process it. Theses naming-delegation-actions are carried by the Delegated DNS Architecture DHCP Option (OPTION_DELEGATED_DNS_ARCHITECTURE). If the CPE wants to remove the Naming Delegation Architecture, it sets the action to CLEAR. Otherwise, it sets the action to SET_NAMING_DELEGATION_WITH_DNS or SET_NAMING_DELEGATION_WITH_DNSSEC.
The Naming Delegation cannot be set if the CPE has not been provided a Prefix Delegation. So, if the CPE has not been assigned a Prefix, it MUST either get first a prefix before setting the Naming Delegation Architecture. If the Prefix Delegation is provided via the ISP DHCP Server, then the CPE can simultaneously send a DHCP Request for a Prefix Delegation with the Identity Association Prefix Delegation DHCP Option and for setting the Naming Delegation Architecture.
If SET_NAMING_DELEGATION_WITH_DNS or SET_NAMING_DELEGATION_WITH_DNSSEC is one of the naming-delegation-action carried by the Delegated DNS Architecture DHCP Option, then the CPE MUST provide the Delegated Address Information DHCP Option (OPTION_DELEGATED_DNS_ADDR_INFO).
If SET_NAMING_DELEGATION_WITH_DNSSEC is one of the naming-delegation-action carried by the Delegated DNS Architecture DHCP Option, then the CPE MUST provide the Delegation of Signing DHCP Option (OPTION_DS).
If the CPE does not want to set the Naming Delegation Architecture, but wants to known the Delegated Domain, then, the CPE MUST send a Delegated Domain DHCP Option (OPTION_DELEGATED_DOMAIN) with no Delegated DNS Architecture DHCP Option (OPTION_DELEGATED_DNS_ARCHITECTURE).
When the DHCP Server receives a Delegated Address Information DHCP Option or a Delegated Domain DHCP Option it MUST check if there is a Delegated DNS Architecture DHCP Option. If not, these DHCP Options MUST be discarded.
If the DHCP Server receives an Option Request DHCP Option for a Delegated Domain DHCP Option, but no Delegated DNS Architecture DHCP Option. The DHCP Server MUST NOT proceed to any configuration settings. The ISP DHCP Server returns the Delegated Domain DHCP Option. Otherwise, it MUST return a Delegated DNS Architecture DHCP Option with a single action set to NONE and the Status Code indicating the reason of failure.
Possible failure reasons are: If the DHCP Server understands the Delegated Domain DHCP Option but does not provide the Naming Delegation Service, the DHCP Server MUST return a Status Code set to NamingDelegationUnavailable. Then, if the Naming Delegation Service is Available, the DHCP MUST check if the CPE has been identified or authenticated according to local policies. If that is not the case, the DHCP Server MUST return a Status Code set to UnauthorizedRequester. If the CPE is authorized to request a Delegated Domain DHCP Option, the DHCP Server MUST check the Delegated Domain has been provisioned, and if that is not the case, if MUST send a Status Code set to UnprovisionedDelegatedDomain. For any other failure, the DHCP Server MUST send a Status Code UnspecFail.
In case of success the DHCP Server does not return Delegated DNS Architecture DHCP Option or Status Code.
When a Delegated DNS Architecture DHCP Option is received, the DHCP Server MUST check an Option Request for Identity Association Prefix Delegation (IA_PD) has not been provided. If that is the case, the DHCP Server MUST proceed first to this Option. Then, the Delegated DNS Architecture DHCP Option should only be processed, if the Identity Association Prefix Delegation has been processed successfully. If no Identity Association Prefix Delegation has been requested the DHCP Server may consider the CPE has no Prefix and send a Delegated DNS Architecture DHCP Option with the status code MissingPrefixDelegationRequest. On the other hand, the DHCP Server may also assume the CPE got a Prefix from another way and proceeds to the Delegated DNS Architecture DHCP Option.
When a Delegated DNS Architecture DHCP Option is received and the Naming Delegation is already set. If the naming-delegation-action is set to NONE, the packet do not proceed to any change. For all other naming-delegation-action, the ISP DHCP Server MUST process the DHCP Option. In case of success, the Naming Delegation MUST be updated. In any other case, the ISP DHCP Server MUST clear the Naming Delegation settings.
From now, the DHCP processes the Delegated DNS Architecture DHCP Option. Preliminary checks are performed in case of failure, the DHCP Server sends a Delegated DNS Architecture DHCP Option with a single naming-delegation-action set to NONE and the Status Code indicating the reason of failure. If the DHCP Server understands this Option, but does not provide the Naming Delegation Service, the DHCP Server MUST return a Status Code set to NamingDelegationUnavailable. Then the DHCP MUST check the CPE is authorized for this Option. If not, the DHCP Server sends a Status Code set to UnauthorizedRequester. At last, it MUST check if Delegated Domain has been provisioned otherwise the DHCP Server MUST send a Status Code set to UnprovisionedDelegatedDomain. For any other reasons, a Status Code set to UnspecFail MUST be sent.
The DHCP Server then looks at the naming-delegation-actions mentioned by the CPE. The CPE has ordered these actions according to their preference, and the most preferred naming-delegation-action is put first. Naming-delegation-actions are proposed by the CPE, thus the DHCP Server MUST skip any naming-delegation-action it does not understand or its local policies prevent to apply for the CPE. Note that the ordered list is only used to chose a naming-delegation-action to be applied. If the chosen naming-delegation-action fails, the DHCP Server does not have to try other naming-delegation-action with lower preference.
To prevent long proposition lists of naming-delegation-actions, the DHCP Server may send a Status Code TooManyNamingDelegationActions. If the naming-delegation-actions list is void, the DHCP MUST send a Status Code set to VoidNamindDelegationActionList. If none of the naming-delegation-action is acceptable, the DHCP Server MUST send a Status Code of NoApplicableNamingDelegationAction. These Status Code are reported in a Delegated DNS Architecture DHCP Option with naming-delegation-action set to NONE.
In this document, the naming-delegation-action considered can be CLEAR, SET_NAMING_DELEGATION_WITH_DNS, SET_NAMING_DELEGATION_WITH_DNSSEC. Any other proposition is skipped by the DHCP Server.
If CLEAR is the chosen naming-delegation-action, there not reason the DHCP Server cannot remove the configurations settings. In response, the DHCP Server MUST send a Delegated DNS Architecture with a single naming-delegation-action set CLEAR. In case of success, the Status Code MUST be set to Success, otherwise, it MUST be set to UnspecFail.
For both SET_NAMING_DELEGATION_WITH_DNS and SET_NAMING_DELEGATION_WITH_DNSSEC naming-delegation-actions, the DHCP MUST have an IP address for the Delegated DNS Server. This IP address can be pre-agreed. In this document we consider that this IP address can be derived from the parameters provided by the Delegated DNS Address Information DHCP Option. It is up to the DHCP Server to define how to proceed between the pre-agreed IP address and the one derived from the Delegated DNS Address Information DHCP Option. There may be multiple Delegated DNS Address Information DHCP Options, and the DHCP Server may chose to consider all of these IP Addresses. On the other hand, the DHCP Server may also chose to send a Status Code set to DelegatedIPAddressConflict. This Status Code is sent in a Delegated DNS Architecture DHCP Option with naming-delegation-action set to the corresponding naming-delegation-action.
The DHCP Server accepts the Delegated DNS Address Information DHCP Options it should first proceed to it. If there are multiple Delegated DNS Address Information DHCP Options, the DHCP Server may process to all of them. It may proceed to the Naming Delegation Architecture Configuration if at least one IP address is valid or if all IP addresses are valid.
For the SET_NAMING_DELEGATION_WITH_DNSSEC naming-delegation-action, the DHCP Server MUST check a Delegation of Signing DHCP Option has been provided. If not a Status Code set to MissingDNSSECDelegationOfSigning.
If the Delegated DNS Address Information and the Delegation of Signing DHCP Options have been processed successfully, the DHCP Server MUST configure the Delegating Server, with the IP address(es) and DS record in its zone. Values for the TTL are defined according to the DHCP Timer. The TTL value MUST NOT be greater than the valid-lifetime of the Prefix [RFC3633]. Then, the DHCP Server sends back the Delegated DNS Architecture DHCP Option with a Status Code set to Success.
Global Unicast IPv6 Addresses are composed of the ISP assigned prefix, that is usually composed of 56 bits, followed by the subnet-ID, typically composed of 8 bits and the interface-ID composed of 64 bits.
In order to set properly the Naming delegation, one MUST make sure the DHCP Server and the CPE agree on the IP address of the Delegated DNS Server. The CPE may not be aware of its ISP assigned prefix and has requested an Identity Association Prefix Delegation DHCP Option for it. The CPE may also have pre-agreed a ISP assigned prefix. In both cases, the CPE and the DHCP Server MUST make sure they agree on the same subnet-ID, that is to say with the same length. The subnet-ID is defined by setting all unknown bits of the ISP assigned prefix to zero. If the number of zeros does not match the size of the ISP assigned prefix, the DHCP Server MUST send a Delegated DNS Architecture DHCP Option with a Status Code set to SubnetIDNonMatchingISPDelegatedPrefixLength Status Code.
For clarification on the agreed IP address of the Delegated DNS Server, the DHCP Server may send in the DHCP Reply the Delegated DNS Address Information DHCP Option with the complete information. In that case, the DHCP Server MUST add a Status Code set to Success.
The Format of the DS RDATA is defined in [RFC4034].
The Delegated DNS Architecture DHCP Option (OPTION_DELEGATED_DNS_ARCHITECTURE) informs the CPE whether the Naming Delegation Architecture has been set as well as the configuration used by the ISP.
The options detailed in this section are
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_DELEGATED_DNS_ARCH. | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ naming-delegation-action-list /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| status-code |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The naming-delegation-action-list is encoded as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| list length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| naming-delegation-action-list |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The naming-delegation-actions are 1 octet length, and the following values are considered in this document:
The Status code 1 octet length and this section considers the following values:
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_DELEGATED_DOMAIN | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| delegated-domain |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_DELEGATED_DNS_ADDR_INFO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| subnet-ID (8 octets) |
| |
|+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| interface-ID (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_DELEGATED_DNSSEC_DS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Delegation of Signing Resource Record |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document introduces Status Code that are carried in the DHCP Options defined in this document. The Status Code detailed in this document are:
The DHCP options detailed in this document are:
This document describes how an End User can make its services and devices from its Home Network reachable on the Internet with Names rather than IP addresses. This exposes the Home Network to attacker since names are expected to provide less randomness than IP addresses. The naming delegation protects the End User's privacy by not providing the complete zone of the Home Network to the ISP. However, using the DNS with names for the Home Network exposes the Home Network and its components to dictionary attacks. In fact, with IP addresses, the Interface Identifier is 64 bit length leading to 2^64 possibilities for a given subnetwork. This is not to mention that the subnet prefix is also of 64 bit length, thus providing another 2^64 possibilities. On the other hand, names use either for the Home Network domain or for the devices presents less randomness (livebox, router, printer, nicolas, jennifer, ...) and thus exposes the devices to dictionary attacks.
IP addresses may be used to locate a device, a host or a Service. However, Home Network are not expected to be assigned the same Prefix over time. As a result observing IP addresses provides some ephemeral information about who is accessing the service. On the other hand, Names are not expected to be has volatile as IP addresses. As a result, logging Names, over time, may be more valuable that logging IP addresses, especially to profile End User's characteristics.
PTR provides a way to bind an IP address to a Name. In that sense responding to PTR DNS Queries may affect the End User's Privacy. For that reason we recommend that End Users may choose to respond or not to PTR DNS queries
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. Unsecure 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 in the Front End Naming Delegation Architecture described in [I-D.mglt-front-end-naming-delegation].
The authors wish to thank Ole Troan for pointing out issues with the IPv6 routed home concept and placing the scope of this document in a wider picture, Mark Townsley for encouragement and injecting a healthy debate on the merits of the idea, Ulrik de Bie for providing alternative solutions, Paul Mockapetris for pointing out issues of the trustworthiness of a reverse lookup, and Christian Jacquenet for seeing the value from a Service Provider point of view.
| [RFC2118] | Pall, G.S., "Microsoft Point-To-Point Compression (MPPC) Protocol", RFC 2118, March 1997. |
| [RFC3769] | Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, June 2004. |
| [I-D.mglt-front-end-naming-delegation] | Cloetens, C.W, Lemordant, P.L and D.M Migault (Ed), "IPv6 Home Network Front End Naming Delegation", Internet-Draft draft-mglt-front-end-naming-delegation-00, June 2012. |