[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

HOMENET                                                      W. Cloetens
Internet-Draft                                                SoftAtHome
Intended status: Standards Track                            P. Lemordant
Expires: January 31, 2013                                D. Migault (Ed)
                                                  Francetelecom - Orange
                                                           July 30, 2012


            IPv6 Home Network Naming Delegation Architecture
              draft-mglt-homenet-naming-delegation-00.txt

Abstract

   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.

Status of this Memo

   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



Cloetens, et al.        Expires January 31, 2013                [Page 1]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


   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 January 31, 2013.

Copyright Notice

   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.































Cloetens, et al.        Expires January 31, 2013                [Page 2]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Home Network Naming Architecture Requirements  . . . . . . . .  7
   5.  Home Network Delegating Architecture Overview  . . . . . . . .  8
     5.1.  Fulfilling Home Network Naming Architecture
           Requirements . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Naming Delegation Architecture Description . . . . . . . .  9
     5.3.  Naming Delegation Configuration Environment Description  . 11
     5.4.  Naming Delegation DHCP Configuration Description . . . . . 13
   6.  Protocol Exchange  . . . . . . . . . . . . . . . . . . . . . . 15
     6.1.  CPE Request Creation and Transmission for Naming
           Delegation Architecture  . . . . . . . . . . . . . . . . . 15
     6.2.  ISP DHCP Server Responding to the CPE Request for
           Naming Delegation Architecture . . . . . . . . . . . . . . 16
       6.2.1.  Case 1: No Delegated DNS Architecture DHCP Option
               in conjunction with  Delegated Address Information
               or Delegated Domain DHCP Option  . . . . . . . . . . . 16
       6.2.2.  Case 2: No Delegated DNS Architecture DHCP Option
               in conjunction with  Option Request DHCP Option
               for a Delegated Domain DHCP Option . . . . . . . . . . 16
       6.2.3.  Case 3: Delegated DNS Architecture DHCP Option . . . . 16
       6.2.4.  Processing the Delegated DNS Address Information
               DHCP Option  . . . . . . . . . . . . . . . . . . . . . 19
       6.2.5.  Processing the Delegation of Signing DHCP Option . . . 19
     6.3.  CPE Receiving the ISP DHCP Response for the Naming
           Delegation Architecture  . . . . . . . . . . . . . . . . . 19
   7.  DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . . 19
     7.1.  Delegated DNS Architecture Option  . . . . . . . . . . . . 20
     7.2.  Delegated Domain Option  . . . . . . . . . . . . . . . . . 22
     7.3.  Delegated DNS Address Information Option . . . . . . . . . 23
     7.4.  Delegated Delegation of Signing Option . . . . . . . . . . 23
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
     9.1.  Names are less secured than IP addresses . . . . . . . . . 24
     9.2.  Names are less volatile than IP address  . . . . . . . . . 25
     9.3.  DNSSEC is recommended to authenticate DNS hosted data  . . 25
     9.4.  Channel between the CPE and ISP DHCP Server MUST be
           secured  . . . . . . . . . . . . . . . . . . . . . . . . . 26
     9.5.  CPEs are sensitive to DoS  . . . . . . . . . . . . . . . . 26
   10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 26
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
     11.2. Informational References . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28




Cloetens, et al.        Expires January 31, 2013                [Page 3]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


1.  Requirements notation

   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].


2.  Introduction

   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



Cloetens, et al.        Expires January 31, 2013                [Page 4]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


   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-homenet-front-end-naming-delegation] which describes the
   Front End Naming Delegation Architecture.  In this architecture, the



Cloetens, et al.        Expires January 31, 2013                [Page 5]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


   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.


3.  Terminology

   This sections defines terminology specific to IPv6 and DHCP used in
   this document.

    - Home Network:   Designates the objects and Services that are
         hosted in the Home Network of the End User.

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

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

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

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

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

    - Delegated DNS Server:   Designates the DNS Authoritative Server
         that handles the Hosts of the Home Network.






Cloetens, et al.        Expires January 31, 2013                [Page 6]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


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

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

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

    - Fully Qualified Domain Name (FQDN):   Name that fits the general
         DNS requirements.


4.  Home Network Naming Architecture Requirements

   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:

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

   - 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

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






Cloetens, et al.        Expires January 31, 2013                [Page 7]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


   - 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 Section 9 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.

   The ISP requirements, other than fulfilling the End Users'
   requirements are the following:

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


5.  Home Network Delegating Architecture Overview

5.1.  Fulfilling Home Network Naming Architecture Requirements

   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.



Cloetens, et al.        Expires January 31, 2013                [Page 8]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


   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.

5.2.  Naming Delegation Architecture Description

   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"



Cloetens, et al.        Expires January 31, 2013                [Page 9]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


   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.



















Cloetens, et al.        Expires January 31, 2013               [Page 10]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


+----------------------------+  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

5.3.  Naming Delegation Configuration Environment Description

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

   - 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) [RFC3633].  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).

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



Cloetens, et al.        Expires January 31, 2013               [Page 11]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


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

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

   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.























Cloetens, et al.        Expires January 31, 2013               [Page 12]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


   <--------- 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

5.4.  Naming Delegation DHCP Configuration Description

   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.



Cloetens, et al.        Expires January 31, 2013               [Page 13]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


   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.




Cloetens, et al.        Expires January 31, 2013               [Page 14]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


6.  Protocol Exchange

   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.

6.1.  CPE Request Creation and Transmission for Naming Delegation
      Architecture

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



Cloetens, et al.        Expires January 31, 2013               [Page 15]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


6.2.  ISP DHCP Server Responding to the CPE Request for Naming
      Delegation Architecture

6.2.1.  Case 1: No Delegated DNS Architecture DHCP Option in conjunction
        with  Delegated Address Information or Delegated Domain DHCP
        Option

   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.

6.2.2.  Case 2: No Delegated DNS Architecture DHCP Option in conjunction
        with  Option Request DHCP Option for a Delegated Domain DHCP
        Option

   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.

6.2.3.  Case 3: Delegated DNS Architecture DHCP Option

   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



Cloetens, et al.        Expires January 31, 2013               [Page 16]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


   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-



Cloetens, et al.        Expires January 31, 2013               [Page 17]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


   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.



Cloetens, et al.        Expires January 31, 2013               [Page 18]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


6.2.4.  Processing the Delegated DNS Address Information DHCP Option

   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.

6.2.5.  Processing the Delegation of Signing DHCP Option

   The Format of the DS RDATA is defined in [RFC4034].

6.3.  CPE Receiving the ISP DHCP Response for the Naming Delegation
      Architecture

   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.


7.  DHCP Options

   The options detailed in this section are

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





Cloetens, et al.        Expires January 31, 2013               [Page 19]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


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

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

   - Delegated Delegation of Signing (OPTION_DELEGATED_DNSSEC_DS):  is
         used by the CPE so the DELEGATING_SERVERS can properly fix the
         DNSSEC Naming Delegation.

7.1.  Delegated DNS Architecture Option

    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                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   - option-code:  OPTION_DELEGATED_DNS_ARCHITECTURE.

   - option-len:  Length of the delegated-naming-action-list field, the
         status-code and the status-message in octets.

   - naming-delegation-action-list:  The list of the actions the CPE is
         ready to accept.

   - status-code:  The Status Code of the operation as specified in
         [RFC3315].  This option may be absent if operation is
         successful.

   The naming-delegation-action-list is encoded as follows:





Cloetens, et al.        Expires January 31, 2013               [Page 20]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


    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                |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   - list length:  Length of the 'naming-delegation-action-list' field
         in octets

   - naming-delegation-action-list:  List of proposed actions by the CPE
         to the ISP DHCP Server.

   The naming-delegation-actions are 1 octet length, and the following
   values are considered in this document:

   - NONE - 0 - :  Indicates that the DHCP Server MUST remove the Naming
         Delegation Architecture Configuration settings on the
         Delegating DNS Server.

   - CLEAR - 1 - :  Indicates that the DHCP Server MUST remove the
         Naming Delegation Architecture Configuration settings on the
         Delegating DNS Server.

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

   - SET_NAMING_DELEGATION_WITH_DNSSEC - 3 - :  Indicates that the DHCP
         Server MUST set the Naming Delegation Architecture with DNSSEC.

   The Status code 1 octet length and this section considers the
   following values:

   - Success - 0 - :

   - UnspecFail - 1 - :

   - MissingPrefixDelegationRequest - TBD - :

   - NamingDelegationUnavailable - TBD - :







Cloetens, et al.        Expires January 31, 2013               [Page 21]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


   - UnauthorizedRequester - TBD - :

   - UnprovisionedDelegatedDomain - TBD - :

   - TooManyNamingDelegationActions - TBD - :

   - VoidNamindDelegationActionList - TBD - :

   - NoApplicableNamingDelegationAction - TBD - :

   - SubnetIDNonMatchingISPDelegatedPrefixLength - TBD - :

   - DelegatedIPAddressConflict - TBD - :

   - MissingDNSSECDelegationOfSigning - TBD - :

7.2.  Delegated Domain Option

    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                           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   - option-code:  OPTION_DELEGATED_DOMAIN

   - option-len:  Length of the 'Delegated Domain' field in octets.

   - delegated-domain:  The Delegated Domain encoded as specified in
         [RFC1035]

















Cloetens, et al.        Expires January 31, 2013               [Page 22]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


7.3.  Delegated DNS Address Information Option

    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)                   |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   - option-code:  OPTION_DELEGATED_DNS_ADDR_INFO

   - option-len:  Length (16) of the Delegated DNS addressing
         information.

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

   - interface-ID:  The interface-ID of the IPv6 address used by the
         authoritative DNS server for the delegated domain name.

7.4.  Delegated Delegation of Signing Option

    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                |
   |                               ...                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   - option-code:  OPTION_DELEGATED_DNSSEC_DS







Cloetens, et al.        Expires January 31, 2013               [Page 23]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


   - option-len:  Length of the 'Delegated Domain' field in octets.

   - DS Resource Record:  The DS Resource Record as defined in
         [RFC4034], Section 5.


8.  IANA Considerations

   This document introduces Status Code that are carried in the DHCP
   Options defined in this document.  The Status Code detailed in this
   document are:

   - NamingDelegationServiceNotProvided  TBD

   - UnauthorizedForNamingDelegationService  TBD

   - NoDelegatedDomainProvisionned  TBD

   - NoDelegatedDnsAddrInfo  TBD

   - DelegationSetWithDns  TBD

   - DelegationSetWithDnssec  TBD

   - AcceptingOnlyDnssecNamingDelegation  TBD

   - UnableToSetNamingDelegation  TBD

   - SubnetIDNonMatchingISPDelegatedPrefixLength  TBD

   The DHCP options detailed in this document are:

   - OPTION_DELEGATED_DNS_ARCHITECTURE:  TBD

   - OPTION_DELEGATED_DOMAIN:  TBD

   - OPTION_DELEGATED_DNS_ADDR_INFO:  TBD

   - OPTION_DELEGATED_DNSSEC_DS:  TBD


9.  Security Considerations

9.1.  Names are less secured than IP addresses

   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



Cloetens, et al.        Expires January 31, 2013               [Page 24]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


   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.

9.2.  Names are less volatile than IP address

   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

9.3.  DNSSEC is recommended to authenticate DNS hosted data

   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.






Cloetens, et al.        Expires January 31, 2013               [Page 25]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


9.4.  Channel between the CPE and ISP DHCP Server MUST be secured

   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.

9.5.  CPEs are sensitive to DoS

   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-homenet-front-end-naming-delegation].


10.  Acknowledgment

   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.



Cloetens, et al.        Expires January 31, 2013               [Page 26]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


11.  References

11.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

   [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the
              DNS", RFC 6672, June 2012.

11.2.  Informational References

   [I-D.mglt-homenet-front-end-naming-delegation]
              Cloetens, C., Lemordant, P., and D. Migault (Ed), "IPv6
              Home Network Front End Naming Delegation",
              draft-mglt-homenet-front-end-naming-delegation-00 (work in
              progress), July 2012.

   [RFC2118]  Pall, G., "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.



Cloetens, et al.        Expires January 31, 2013               [Page 27]


Internet-Draft     IPv6 Home Network Naming Delegation         July 2012


Authors' Addresses

   Wouter Cloetens
   SoftAtHome
   vaartdijk 3 701
   3018 Wijgmaal
   Belgium

   Phone:
   Email: wouter.cloetens@softathome.com


   Philippe Lemordant
   Francetelecom - Orange
   2, avenue Pierre Marzin
   22300  Lannion
   France

   Phone: +33 2 96 05 35 11
   Email: philippe.lemordant@orange.com


   Daniel Migault
   Francetelecom - Orange
   38, rue du General Leclerc
   92794 Issy-les-Moulineaux Cedex 9
   France

   Phone: +33 1 45 29 60 52
   Email: mglt.ietf@gmail.com





















Cloetens, et al.        Expires January 31, 2013               [Page 28]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/