<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc toc="yes"?>         <!-- generate a table of contents -->
<?rfc symrefs="yes"?>     <!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>   <!-- alphabetize the references -->
<?rfc compact="yes" ?>    <!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>  <!-- but keep a blank line between list items -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
 <!ENTITY rfc2119 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
 <!ENTITY rfc3947 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3947.xml'>
 <!ENTITY rfc3948 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3948.xml'>
 <!ENTITY rfc1035 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
 <!ENTITY rfc4034 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml'>
 <!ENTITY rfc4301 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml'>
 <!ENTITY rfc5996 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml'>
 <!ENTITY rfc3315 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
 <!ENTITY rfc4862 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml'>
 <!ENTITY rfc6672 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6672.xml'>
 <!ENTITY rfc2118 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2118.xml'>
 <!ENTITY rfc3633 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml'>
 <!ENTITY rfc3769 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3769.xml'>
]>


<rfc category="std" ipr="trust200902" docName="draft-mglt-naming-delegation-00.txt">
    <front>
        <title abbrev="IPv6 Home Network Naming Delegation">IPv6 Home Network Naming Delegation Architecture</title>
        <author fullname="Wouter Cloetens" initials="W.C." surname="Cloetens">
            <organization>SoftAtHome</organization>
            <address>
                <postal>
                    <street>vaartdijk 3 701</street><city>3018 Wijgmaal</city><country>Belgium</country>
                </postal>
                <phone></phone><email>wouter.cloetens@softathome.com</email>
            </address>
        </author>
        <author fullname="Philippe Lemordant" initials="P.L." surname="Lemordant">
            <organization>Francetelecom - Orange</organization>
            <address>
                <postal>
                    <street>2, avenue Pierre Marzin</street><city>22300  Lannion</city><country>France</country>
                </postal>
                <phone>+33 2 96 05 35 11</phone><email>philippe.lemordant@orange.com</email>
            </address>
        </author>
        <author fullname="Daniel Migault" initials="D.M." surname="Migault (Ed)">
            <organization>Francetelecom - Orange</organization>
            <address>
                <postal>
                    <street>38, rue du General Leclerc</street><city>92794 Issy-les-Moulineaux Cedex 9</city><country>France</country>
                </postal>
                <phone>+33 1 45 29 60 52</phone><email>mglt.ietf@gmail.com</email>
            </address>
        </author>
        <date month="July" year="2012"></date><area>INTERNET</area><workgroup>HOMENET</workgroup>
        <abstract>
            <t>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.</t>

            <t> 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.</t>

            <t>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.</t>
        </abstract>
    </front>
    <middle>

    <section title="Requirements notation">
        <t>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 <xref target="RFC2119"/>.</t>
    </section>

        <section title="Introduction">
            <t>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.</t>

<t>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".</t>

<t>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.</t>

<t>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.</t>     

<t>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.</t>

<t>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. </t>

<t>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. <xref target="RFC3315"></xref> proposes a DHCP authentication and message exchange protection, <xref target="RFC4301"></xref>, <xref target="RFC5996"></xref> proposes to secure the channel at the IP layer.</t>

<t>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 <xref target="I-D.mglt-front-end-naming-delegation"></xref> which describes the Front End Naming Delegation Architecture. In this architecture, the ISP's infrastructure protects the CPE from heavy load.</t> 

<t>This document only deals with IPv6 IP addresses and DHCPv6 <xref target="RFC3315"></xref>. When we mention DHCP, it MUST be understood as DHCPv6.</t>
        </section>

<section title="Terminology">

<t>This sections defines terminology specific to IPv6 and DHCP used in this document.
    <list style="hanging" hangIndent="6">
                    <t hangText=" - Home Network: ">Designates the objects and Services that are hosted in the Home Network of the End User.</t>
                    <t hangText=" - Home Network Naming Architecture: ">Designates the Architecture that makes possible to reach a device, an object or a service in the Home Network by using Names like Fully Qualified Domain Names.</t>
                    <t hangText=" - Home Network Naming Delegation Architecture or Naming Delegation Architecture: ">Designates the Naming Architecture Described in this document. The ISP delegates the Naming management of the Home Network to the Delegated DNS Servers. Consistency with the Global Naming Architecture is provided by the ISP. The Delegation occurs between Delegating DNS Servers hosted by the ISP and Delegated DNS Servers hosted in the Home Network.</t>
                    <t hangText=" - Internet Service Provider (ISP): ">The End User has subscribed to the ISP. The ISP is aware of End User credential and the Delegated Domain of the Home Network. The ISP is expected to provide the CPE the required information to properly configure the DNS Zone.</t>
                    <t hangText=" - Delegating DNS Server: ">Designates the Authoritative DNS Server of the ISP. The Home Network is a subzone of the Delegating DNS Server. This subzone is handled by the Delegated DNS Server.</t>
                    <t hangText=" - Customer Premise Equipment (CPE): ">Designates the device that hosts the DNS and DHCP Service in the Home Network. This device sets the IP and Naming interconnection between the ISP Network and Home Network.</t>
                    <t hangText=" - Delegated DNS Server: ">Designates the DNS Authoritative Server that handles the Hosts of the Home Network.</t>
                    <t hangText=" - Delegated Delegation of Signing Option: ">Designates the DHCP Option that makes possible the DNSSEC Delegation between the Delegated DNS Server and the Delegating DNS Server.</t>
                    <t hangText=" - Delegated DNS Addressing Information Option: ">Designates the DHCP Option that makes possible the Delegation between the Delegated DNS Server and the Delegating DNS Server for both DNS and DNSSEC. With this option, the Delegating DNS Server is informed of the IP addressing information - the interface and the subnet identifier - used by the Delegated DNS Server.</t>
                    <t hangText=" - Delegated Domain: ">Designates the domain Name associated to the Home Network. In this document, the Delegated Domain is reserved by the End User to the ISP at the subscription of the Internet Access. It is then communicated to the CPE by the ISP, so the CPE configures properly its Delegated DNS Server.</t>
                    <t hangText=" - Fully Qualified Domain Name (FQDN): ">Name that fits the general DNS requirements.</t>
    </list>
</t>

</section>


        <section title="Home Network Naming Architecture Requirements">

            <t>The Home Network Naming Architecture is defined by two parties the End User and the ISP. Both of them have specific requirements.</t>
            <t>The End User requirements we are considering are the following:
                <list style="hanging" hangIndent="6">
                    <t hangText="- 1: Centralized Naming Configuration:"> Configuring a Network, is most of the time more convenient when done in a centralized way. Home Networks now may have only a few nodes, which makes a per-node configuration possible, for example using DynDNS like service, to assign a FQDN to each node. However, the number of nodes is expected to grow in the next future, and we recommend now to specify a centralized way for configuring the Home Network Naming Architecture.</t>
                    <t hangText="- 2: Automatic Configuration:"> Most End User do not want to configure, their Home Network, and configuration MUST be minimal. The procedure should consider those 90% of End Users</t>
                    <t hangText="- 3: Advanced Configuration enable:"> Some End Users have various specific requirements, and they SHOULD be able to match these requirements. This means that the Automatic Configuration may be disable.</t>
                    <t hangText="- 4: Privacy Protection By Design:"> Most End User does not want to provide anyone, including their ISP, the content of their zone, like network topology, or the devices and services hosted in the Home Network. On the other hand the content of the zone should be publicly published. DNS makes this possible for two reasons.  First, DNS makes the content of the zone public, without publishing the whole zone - at least AXFR queries must be disabled. Then, DNS is a distributed databases with delegation mechanisms, that preserves the privacy of subzones toward upper zones. Note that as explained in <xref target="security-considerations"></xref> the Naming Delegation Architecture described in this document protects the End User's privacy by not providing the complete DNS zone. However, one MUST be aware that using Names exposes their Home Networks to the Internet since names are expected to provide less randomness than the standard IPv6 numbering. Then Names are more associated to an identity than IP addresses are. Thus, allowing PTR DNS queries may also affect the End User's privacy.</t>
                </list>
            </t>
            <t>The ISP requirements, other than fulfilling the End Users' requirements are the following:
                <list style="hanging" hangIndent="6">
                    <t hangText="- 1: Make the Home Network Naming Architecture Scalable:"> ISPs can hardly foresee the evolution of Home Networks, that is to say the number of devices that will belong to them, or the number of requests, updates associated to each FQDN. Architectures that would make the ISP deal with all FQDNs is definitively out of scope. Delegation management of the Zone to CPE makes local management handled locally, and Delegating the zone makes CPE dealing with their zone traffic.</t>
                </list>
            </t>
        </section>

        <section title="Home Network Delegating Architecture Overview">

            <section title="Fulfilling Home Network Naming Architecture Requirements">

            <t>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.</t>

            <t>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.</t>

            <t>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.</t>

            <t>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.</t>

           <t>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.</t>
           </section>

            <section title="Naming Delegation Architecture Description">

<t>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.</t>

<t>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.".</t>
<t>The End User is likely to use alternate names which will require the use of DNAME <xref target="RFC6672"></xref> and CNAME <xref target="RFC2118"></xref> . 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 <xref target="RFC2118"></xref>. 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.</t>

<t>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.</t>

<t>Then, the Resolver sends the DNS(SEC) Query to the Home Network Delegated DNS Server which responds with the requested DNS(SEC) information.</t> 
                <figure>
                    <artwork>
+----------------------------+  DNS Query                        +---+
| ISP DNS Server             |  hots1.my-homenet.example. AAAA   |   |
| Delegating Servers         | &lt;---------------------------------- |   |
| ZONE "example."            |  DNS Response:                    |   |
|                            |  my-homenet.example. NS IP6       | R |  
|                            | [my-homenet.example. DS [...]]    | E |
+----------------------------+ ----------------------------------&gt; | S |
+----------------------------+  DNS Query                          | O |
| CPE DNS Server             |  host1.my-homenet.example. AAAA   | L |
| Delegating Server          | &lt;---------------------------------- | V |
| ZONE "my-homenet.example." |  DNS Response:                      | E |
|                            |  my-homenet.example. NS IP6       | R |
|                            | [my-homenet.example. RRSIG [...]] |   |
+----------------------------+ ----------------------------------&gt; |   |
       |               |                                         |   |
+------------+  +------------+                                   +---+  
|   Host 1   |  |   Host n   |   
+------------+  +------------+  

Figure 1:  DNS Resolution with the Home Network Delegating Architecture
                     </artwork>
                </figure>
            </section>


            <section title="Naming Delegation Configuration Environment Description">

                <t>Figure 2 shows the DHCP exchange between the CPE and the ISP DHCP Server. This exchange sets the  Home Network Naming Delegation Architecture.</t>

                <t>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).
                <list style="hanging" hangIndent="6">
                        <t hangText="- CPE DHCP Client (DHCP_CLT):"> is responsible for getting parameters from the ISP. In figure 2, the CPE DHCP Client requests the ISP an IPv6 Prefix Delegation (IA_PD) <xref target="RFC3633"></xref>. The CPE DHCP Client also requests to set a Naming Delegation Architecture (DELEGATED_DNS_ARCHITECTURE), and provides the necessary pieces of information to set up the Naming Delegation Architecture (DELEGATED_DNS_ADDR_INFO, DELEGATED_DNSSEC_DS). In return, the CPE DHCP Client (DHCP_CLT) is expected to receive from the ISP DHCP Server, the Delegated Domain Name (DELEGATED_DOMAIN) and the IPv6 Prefix Delegation (IA_PD). These pieces of information are useful to configure the Home Network DNS Zone file, of the CPE Delegated DNS Server (DNS_SRV).</t> 
                        <t hangText="- CPE DHCP Server (DHCP_SRV):"> The CPE DHCP server hosted by the CPE is not mandatory for the Naming Delegation Architecture. We mentioned it in Figure 2 as most of the CPEs are responsible for assigning IPv6 Addresses to the Hosts of the Home Network. Figure 2 considers that the IPv6 Address of the Hosts are assigned via DHCP, and that while assigning the IPv6 prefixes, the DHCP Server populates the Home Network DNS Zone file of the CPE Delegated DNS Server (DNS_SRV).</t>
                        <t hangText="- CPE Delegated DNS Server (DNS_SRV):">The CPE Delegated DNS Server hosts the Naming Service of the Home Network. The DNS Server can implement DNS or DNSSEC. This function interacts with the CPE DHCP Client (DHCP_CLT) so the Naming Delegation is properly set with the ISP, and the CPE DHCP Server (DHCP_SRV) which manages names for the hosts of the Home Network.</t>
                </list>
                </t>

                <t>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.</t>

                <t>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 <xref target="RFC3315"></xref> but other protocols like "IPv6 Stateless Address Autoconfiguration" <xref target="RFC4862"></xref> may also be used. This will not affect the Naming Delegation Architecture.</t>

                <figure>
                    <artwork>
&lt;--------- Home Network ----------&gt;     &lt;--------- ISP ---------&gt;
+--------+  +---------------------+     +-----------------------+
| Host 1 +--+    CPE              |     |       ISP DHCP        |
+--------+  +----------+----------+     +-----------------------+
     .      | DHCP_SRV | DHCP_CLT |     |                       |
     .      |     v    |          |     |                       |
     .      |     v    | DHCP Request  ----------------------&gt;  |
     .      |     v    |   DELEGATED_DNS_ARCHITECTURE,          |
     .      +----------|   DELEGATED_DNS_ADDR_INFO,             |
     .      | DNS_SRV  |   ORO(IA_PD)                           |
     .      +----------|   [DS, ORO(DELEGATED_DOMAIN)]          |
     .      |     ^    |          |     |                       |
     .      |     ^    |   &lt;----------------------  DHCP Reply  |
     .      |     ^    |         DELEGATED_DNS_ARCHITECTURE,    |
            |     ^    |         DELEGATED_DOMAIN,              |
+--------+  |     ^    |         IA_PD                          |
| Host n +--|      &lt; &lt; &lt; DHCP_CLT |     |                       |
+--------+  +----------+--------- +     +-----------------------+


Figure 2:  Naming Delegation Architecture
                    </artwork>
                </figure>

            </section>
            <section title="Naming Delegation DHCP Configuration Description">
            
            <t>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. </t>

            <t>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 <xref target="RFC3633"></xref>, <xref target="RFC3769"></xref>. To Request the Option from the ISP DHCP Server, the CPE uses the Option Request DHCP Option (ORO) <xref target="RFC3315"></xref>. </t>

            <t>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.</t>

            <t>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.</t>

             <t>The calculation of the CPE IPv6 address used for the delegated DNS server is done as follows: </t>
 
                <figure>
                    <artwork>
0                           63|64                             127 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix  | subnet-ID    |           interface-ID          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
subnet-ID length = 64 – IPv6 prefix length

Figure 3:  CPE IP address Format
                    </artwork>
                </figure>


           <t>If DNSSEC is used, the CPE MUST also provide the Delegation of Signing (DS) Information <xref target="RFC4034"></xref>. This is done using the Delegation of Signing DHCP Option (OPTION_DS) </t>

           <t>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).</t> 

           <t>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.</t>

           <t>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.</t>
            </section>

</section>

<section title="Protocol Exchange">

            <t>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.</t>

           <t>For clarity, we designated the CPE DHCP Client by the CPE.</t> 

            <section title="CPE Request Creation and Transmission for Naming Delegation Architecture">
            
            <t>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. </t>

           <t>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.</t>

           <t>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).</t>

           <t>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).</t>

           <t>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).</t> 
            </section> 

            <section title="ISP DHCP Server Responding to the CPE Request for Naming Delegation Architecture">

            <section title="Case 1: No Delegated DNS Architecture DHCP Option in conjunction with  Delegated Address Information or Delegated Domain DHCP Option">           
            <t>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.</t>
            </section>

            <section title="Case 2: No Delegated DNS Architecture DHCP Option in conjunction with  Option Request DHCP Option for a Delegated Domain DHCP Option">
<t>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.</t>

<t>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.</t> 

<t>In case of success the DHCP Server does not return Delegated DNS Architecture DHCP Option or Status Code.</t>
            </section>

            <section title="Case 3: Delegated DNS Architecture DHCP Option"> 

            <t>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.</t>

            <t>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.</t>
 
<t>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.</t>  

<t>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.</t>

<t>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.</t>

<t>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.</t>

<t>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.</t>

<t> 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.</t>   

<t>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.</t>
 
<t>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.</t> 

<t>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 <xref target="RFC3633"></xref>. Then, the DHCP Server sends  back the Delegated DNS Architecture DHCP Option with a Status Code set to Success.</t>
            </section>

            <section title="Processing the Delegated DNS Address Information DHCP Option">
            <t>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.</t>

            <t>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.</t>  

            <t>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.</t> 
            </section>

            <section title="Processing the Delegation of Signing DHCP Option">
            <t>The Format of the DS RDATA is defined in <xref target="RFC4034"></xref>.</t> 
            </section>
            </section>

            <section title="CPE Receiving the ISP DHCP Response for the Naming Delegation Architecture">
            <t>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.</t>
<!-- 
            <t>If the CPE has not received all expected DHCP Options, or cannot proceed to the configuration of the Naming Delegation Architecture, it MUST either clear the Naming Delegation settings or proceed to the appropriated settings. Clearing the Naming Delegation settings is performed by sending a Delegated DNS Architecture DHCP Option (OPTION_DELEGATED_DNS_ARCHITECTURE) with the delegation-naming-action set to CLEAR. A renegotiation is performed with any other naming-delegation-action other than CLEAR or NONE.</t>
-->
            </section>

</section>



<section title="DHCP Options">
            <t>The options detailed in this section are
                <list style="hanging" hangIndent="6">
                    <t hangText="- Delegated DNS Architecture (OPTION_DELEGATED_DNS_ARCHITECTURE):">is used by the DHCP Client on the CPE to inform how the Naming Delegation Architecture should be configured. In return, it is used by the ISP DHCP Server to report the Status Code.</t>
                    <t hangText="- Delegated Domain (OPTION_DELEGATED_DOMAIN):">is used by the DHCP Server to advertise the CPE the Delegated Domain of the Home Network. This Delegated Domain has been reserved and assigned by the End User during the subscription. This option is used to configure properly the DNS zone file of the CPE.</t>
                    <t hangText="- Delegated DNS Address Information (OPTION_DELEGATED_DNS_ADDR_INFO):">is used by the CPE to advertise the DHCP Server which interface and subnet identifier is used by the CPE to build the IPv6 address using the delegated IPv6 prefix to host the DNS Server. This option is used so the DELEGATING_SERVERS can properly fix the delegation.</t>
                    <t hangText="- Delegated Delegation of Signing (OPTION_DELEGATED_DNSSEC_DS):">is used by the CPE so the DELEGATING_SERVERS can properly fix the DNSSEC Naming Delegation.</t>
                </list>
            </t>

            <section title="Delegated DNS Architecture Option">
                <figure>
                    <artwork>
 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                          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             </artwork>
                 </figure>
 <t>
                <list style="hanging" hangIndent="6">
                    <t hangText="- option-code:">OPTION_DELEGATED_DNS_ARCHITECTURE.</t>
                    <t hangText="- option-len:">Length of the  delegated-naming-action-list field, the  status-code and the status-message in octets.</t>
                    <t hangText="- naming-delegation-action-list:">The list of the actions the CPE is ready to accept.</t>
                    <t hangText="- status-code:">The Status Code of the operation as specified in <xref target="RFC3315"></xref>. This option may be absent if operation is successful. </t>
                 </list>
            </t>

            <t>The naming-delegation-action-list is encoded as follows:</t>
                <figure>
                     <artwork>
 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                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     </artwork>
                 </figure>
 <t>
                <list style="hanging" hangIndent="6">
                    <t hangText="- list length:">Length of the 'naming-delegation-action-list' field in octets</t>
                    <t hangText="- naming-delegation-action-list:">List of proposed actions by the CPE to the ISP DHCP Server.</t>
                 </list>
            </t>
<t>The naming-delegation-actions are 1 octet length, and the following values are considered in this document:
                <list style="hanging" hangIndent="6">
                    <t hangText="- NONE - 0 - :">Indicates that the DHCP Server MUST remove the Naming Delegation Architecture Configuration settings on the Delegating DNS Server.</t>
                    <t hangText="- CLEAR - 1 - :">Indicates that the DHCP Server MUST remove the Naming Delegation Architecture Configuration settings on the Delegating DNS Server.</t>
                    <t hangText="- SET_NAMING_DELEGATION_WITH_DNS - 2 - :">Indicates that the DHCP Server MUST set the Naming Delegation Architecture with only DNS, and MUST NOT consider DNSSEC Delegation.</t>
                    <t hangText="- SET_NAMING_DELEGATION_WITH_DNSSEC - 3 - :">Indicates that the DHCP Server MUST set the Naming Delegation Architecture with DNSSEC.</t>
                 </list>
</t> 

<t>The Status code  1 octet length and this section considers the following values:
                <list style="hanging" hangIndent="6">
                    <t hangText="- Success - 0 - :"></t>
                    <t hangText="- UnspecFail - 1 - :"></t>
                    <t hangText="- MissingPrefixDelegationRequest - TBD - :"></t>
                    <t hangText="- NamingDelegationUnavailable - TBD - :"></t>
                    <t hangText="- UnauthorizedRequester - TBD - :"></t>
                    <t hangText="- UnprovisionedDelegatedDomain - TBD - :"></t>
                    <t hangText="- TooManyNamingDelegationActions - TBD - :"></t>
                    <t hangText="- VoidNamindDelegationActionList - TBD - :"></t>
                    <t hangText="- NoApplicableNamingDelegationAction - TBD - :"></t>
                    <t hangText="- SubnetIDNonMatchingISPDelegatedPrefixLength - TBD - :"></t>
                    <t hangText="- DelegatedIPAddressConflict - TBD - :"></t>
                    <t hangText="- MissingDNSSECDelegationOfSigning - TBD - :"></t>
                 </list>
</t> 




            
            </section>
            <section title="Delegated Domain Option">
                <figure>
                    <artwork>
 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                           |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             </artwork>
                 </figure>
 <t>
                <list style="hanging" hangIndent="6">
                    <t hangText="- option-code:">OPTION_DELEGATED_DOMAIN</t>
                    <t hangText="- option-len:">Length of the 'Delegated Domain' field in octets.</t>
                    <t hangText="- delegated-domain:">The Delegated Domain encoded as specified in <xref target="RFC1035"></xref></t>
                  </list>
            </t>
<!--
 <t>The format of the delegated-domain-list is encoded as follows:</t>
                <figure>
                     <artwork>
 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              |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|                                                               |
|                        delegated-domain-list                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     </artwork>
                 </figure>
 <t>
                <list style="hanging" hangIndent="6">
                    <t hangText="- list length:">Length of the 'delegated-domain-list' field in octets</t>
                    <t hangText="- delegated-domain-list:">The specification of the list of domain names in the
                 Delegated Domain List. This list may be empty is the status code is not successful.

The list of domain names in the ' delegated-domain-list ' MUST be encoded as specified in section "Representation and use of domain names" of <xref target="RFC3315"></xref>.</t>
</list>
</t>
-->

            </section>
          
            <section title="Delegated DNS Address Information Option">
                <figure>
                    <artwork>
 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)                   |      
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                </artwork>
                    </figure>

 <t>
                <list style="hanging" hangIndent="6">
                    <t hangText="- option-code:">OPTION_DELEGATED_DNS_ADDR_INFO</t>
                    <t hangText="- option-len:">Length (16) of the Delegated DNS addressing information.</t>
                    <t hangText="- subnet-ID:">The identifier of a subnet used by the authoritative DNS server for the delegated domain name. Only the last 'm' bits are significant. The 'm' value is equal to (64 - 'n') where 'n' is the delegated prefix length. The subnet-ID may be dynamically truncated by the DHCP server and client to match the 'm' size (depending on the delegated prefix length).</t>

                    <t hangText="- interface-ID:">The interface-ID of the IPv6 address used by the authoritative DNS server for the delegated domain name.</t> 
                  </list>
            </t>
            </section>

            <section title="Delegated Delegation of Signing Option">
                <figure>
                    <artwork>
 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                |
|                               ...                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                </artwork>
                    </figure>
 <t>
                <list style="hanging" hangIndent="6">
                    <t hangText="- option-code:">OPTION_DELEGATED_DNSSEC_DS</t>
                    <t hangText="- option-len:">Length of the 'Delegated Domain' field in octets.</t>
<t hangText="- DS Resource Record:">The DS Resource Record as defined in <xref target="RFC4034"></xref>, Section 5.</t>
                  </list>
            </t>

            </section>

</section>

<section title="IANA Considerations">

<t>This document introduces Status Code that are carried in the DHCP Options defined in this document. The Status Code detailed in this document are:
    <list style="hanging" hangIndent="6">
         <t hangText="- NamingDelegationServiceNotProvided">TBD</t>
         <t hangText="- UnauthorizedForNamingDelegationService">TBD</t>
         <t hangText="- NoDelegatedDomainProvisionned">TBD</t>
         <t hangText="- NoDelegatedDnsAddrInfo">TBD</t>
         <t hangText="- DelegationSetWithDns">TBD</t>
         <t hangText="- DelegationSetWithDnssec">TBD</t>
         <t hangText="- AcceptingOnlyDnssecNamingDelegation">TBD</t>
         <t hangText="- UnableToSetNamingDelegation">TBD</t>
         <t hangText="- SubnetIDNonMatchingISPDelegatedPrefixLength">TBD</t>

    </list>
</t>

<t>The DHCP options detailed in this document are:
    <list style="hanging" hangIndent="6">
        <t hangText="- OPTION_DELEGATED_DNS_ARCHITECTURE:">TBD</t>
        <t hangText="- OPTION_DELEGATED_DOMAIN:">TBD</t>
        <t hangText="- OPTION_DELEGATED_DNS_ADDR_INFO:">TBD</t>
        <t hangText="- OPTION_DELEGATED_DNSSEC_DS:">TBD</t>
    </list>
</t>
</section>

<section title="Security Considerations" anchor="security-considerations">

    <section title="Names are less secured than IP addresses">
    <t>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.</t>
    </section>

    <section title="Names are less volatile than IP address">
    <t>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.</t>

    <t>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</t>
    </section>

    <section title="DNSSEC is recommended to authenticate DNS hosted data">
    <t>The document describes how the Secure Delegation can be set between the Delegating DNS Server and the Delegated DNS Server.</t>

    <t>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.</t>     
    </section>


    <section title="Channel between the CPE and ISP DHCP Server MUST be secured">
    <t>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.  <xref target="RFC3315"></xref> proposes a DHCP authentication and message exchange protection, <xref target="RFC4301"></xref>, <xref target="RFC5996"></xref> propose to secure the channel at the IP layer.</t> 
    <t>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.</t>
    </section>

   <section title="CPEs are sensitive to DoS"> 
<t>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 <xref target="I-D.mglt-front-end-naming-delegation"></xref>.</t>
   </section>

</section>

<section title="Acknowledgment">
    <t>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.</t>
</section>
</middle>
    <back>
        <references title="Normative References">
             &rfc2119;
             &rfc1035;
             &rfc4034;
             &rfc4301;
             &rfc5996;
             &rfc3315;
             &rfc4862;
             &rfc6672;
             &rfc3633;
        </references>
        <references title="Informational References">
             &rfc2118;
             &rfc3769;
             <reference anchor="I-D.mglt-front-end-naming-delegation">
                 <front>
                     <title>IPv6 Home Network Front End Naming Delegation</title>
                     <author fullname="Wouter Cloetens" initials="C.W" surname="Cloetens">
                         <organization>SoftAtHome</organization>
                         <address>
                             <postal>
                                 <street>vaartdijk 3 701</street><city>3018 Wijgmaal</city><country>Belgium</country>
                             </postal>
                             <phone></phone><email>wouter.cloetens@softathome.com</email>
                         </address>
                     </author>
                     <author fullname="Philippe Lemordant" initials="P.L" surname="Lemordant">
                         <organization>Francetelecom - Orange</organization>
                         <address>
                             <postal>
                                 <street>2, avenue Pierre Marzin</street><city>22300  Lannion</city><country>France</country>
                             </postal>
                             <phone>+33 2 96 05 35 11</phone><email></email>
                         </address>
                     </author>
                     <author fullname="Daniel Migault" initials="D.M" surname="Migault (Ed)">
                         <organization>Francetelecom - Orange</organization>
                         <address>
                             <postal>
                                 <street>38, rue du General Leclerc</street><city>92794 Issy-les-Moulineaux Cedex 9</city><country>France</country>
                             </postal>
                             <phone>+33 1 45 29 60 52</phone><email>mglt.ietf@gmail.com</email>
                         </address>
                     </author>

                     <date month="June" year="2012"/>
                     <abstract>
                         <t>
                         </t>
                     </abstract>
                 </front>
                 <seriesInfo name="Internet-Draft" value="draft-mglt-front-end-naming-delegation-00"/><format type="TXT" target="http://www.ietf.org/internet-drafts/draft-mglt-front-end-naming-delegation-00.txt"/></reference>
        </references>
    </back>
</rfc>


