HOMENET                                                  D. Migault (Ed)
Internet-Draft                                                  Ericsson
Intended status: Standards Track                             W. Cloetens                            T. Mrugalski
Expires: November 20, 2015                                    SoftAtHome April 21, 2016                                              ISC
                                                            C. Griffiths
                                                                     Dyn

                                                                R. Weber
                                                                 Nominum
                                                            May
                                                             W. Cloetens
                                                              SoftAtHome
                                                        October 19, 2015

              DHCP

             DHCPv6 Options for Homenet Naming Architecture
       draft-ietf-homenet-naming-architecture-dhc-options-02.txt
       draft-ietf-homenet-naming-architecture-dhc-options-03.txt

Abstract

   CPEs

   Customer Premises Equipment (CPE) devices are usually constraint constrained
   devices with reduced network and CPU
   capacities. capabilities.  As such, a CPE hosting on the Internet
   exposing the authoritative naming service for its home network on the
   Internet may become vulnerable to resource exhaustion attacks.  One
   way to avoid exposing CPE is to outsource the authoritative service
   to a third party.  This third party can be
   the ISP or any other independent third party.

   Outsourcing the authoritative naming service to a third party party, e.g.  ISP.  Such an outsource requires setting up
   an architecture which may be unappropriated inappropriate for most end users.  To leverage this issue, this  This
   document proposes DHCP
   Options defines DHCPv6 options so any agnostic CPE can automatically
   proceed to the
   appropriated appropriate configuration and outsource the
   authoritative naming service for the home network.  This document shows that in  In most cases, these DHCP Options make outsourcing to a third party (be it
   the ISP or any ISP independent service provider) outsourcing mechanism is transparent for the end user.

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
   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 November 20, 2015. April 21, 2016.

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

Copyright Notice

   Copyright (c) 2015 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.

Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4   3
   4.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Architecture and DHCP DHCPv6 Options Overview  . . . . . . . . .   7   6
     4.2.  Mechanisms Securing DNS Transactions  . . . . . . . . . .  10   9
     4.3.  Primary / Secondary Synchronization versus DNS Update . .  11  10
   5.  CPE Configuration . . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  CPE Primary / Secondary Synchronization Configurations  .  11
       5.1.1.  CPE / Public Authoritative Name Synchronization Server Set  . . . . .  12 . . . . . . .  11
       5.1.2.  CPE / Reverse Public Authoritative Name Synchronization Server Set  .  12 . . . . . . .  11
     5.2.  CPE DNS Data Handling and Update Policies . . . . . . . .  12
       5.2.1.  DNS  Homenet Zone Template . . . . . . . . . . . . . . . .  12
       5.2.2.  DNS (Reverse) Homenet Zone  . . . . . . . . . . . . .  13  12
   6.  Payload Description . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  Security  Supported Authentication Methods Field  . . . . . . . . . . . . . . . . . . . . .  14  13
     6.2.  Update Field  . . . . . . . . . . . . . . . . . . . . . .  14
     6.3.  DHCP  Client Public Key Option  . . . . . . . . . . . . . . . . .  15  14
     6.4.  DHCP  Zone Template Option  . . . . . . . . . . . . . . . .  16 . .  14
     6.5.  DHCP Public Authoritative Name  Synchronization Server Set Option . . . .  16 . . . . . . . . . .  15
     6.6.  DHCP  Reverse Public Authoritative Name Synchronization Server Set Option   17 . . . . . . . . . .  16
   7.  DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . .  18  17
     7.1.  DHCPv6 Server Behavior  . . . . . . . . . . . . . . . . .  18  17
     7.2.  DHCPv6 Client Behavior  . . . . . . . . . . . . . . . . .  19  18
     7.3.  DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . . . .  19  18
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19  18
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     9.1.  DNSSEC is recommended to authenticate DNS hosted data . .  19
     9.2.  Channel between the CPE and ISP DHCP Server MUST be
           secured . . . . . . . . . . . . . . . . . . . . . . . . .  19
     9.3.  CPEs are sensitive to DoS . . . . . . . . . . . . . . . .  20  19

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

   10. Acknowledgment Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20  19
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20  19
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     11.2.  Informational References . . . . . . . . . . . . . . . .  22  21
   Appendix A.  Scenarios and impact on the End User . . . . . . . .  22
     A.1.  Base Scenario . . . . . . . . . . . . . . . . . . . . . .  22
     A.2.  Third Party Registered Homenet Domain . . . . . . . . . .  23
     A.3.  Third Party DNS Infrastructure  . . . . . . . . . . . . .  23
     A.4.  Multiple ISPs . . . . . . . . . . . . . . . . . . . . . .  25
   Appendix B.  Document Change Log  . . . . . . . . . . . . . . . .  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

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

   - Customer Premises Equipment:   (CPE)

   The reader is the router providing
         connectivity expected to the home network.  It is configured be familiar with
   [I-D.ietf-homenet-front-end-naming-delegation] and managed
         by the end user.  In this document, the CPE might also hosts
         services such as DHCPv6. its terminology
   section.  This device might be provided by the
         ISP. section defines terms that have not been defined in
   [I-D.ietf-homenet-front-end-naming-delegation]:

   - Client Public Key:   designates a public Key key generated by the CPE.
         This key is used as an authentication credential for the CPE.

   - Registered Homenet Domain:   is the Domain Name associated to the
         home network.

   - DNS Homenet Zone:   is the DNS zone associated to the home network.
         This zone is set by the CPE and essentially contains the
         bindings between names and IP addresses of the nodes of the
         home network.  In this document, the CPE does neither perform
         any DNSSEC management operations such as zone signing nor
         provide an authoritative service for the zone.  Both are
         delegated to the Public Authoritative Server.  The CPE
         synchronizes the DNS Homenet Zone with the Public Authoritative
         Server via a hidden primary / secondary architecture.  The
         Public Authoritative Server might use specific servers for the
         synchronization of the DNS Homenet Zone: the Public
         Authoritative Name Server Set.

   - DNS Homenet Zone Template:   The template used as a basis to generate
         the DNS Homenet Zone.

   - DNS Template Server:   The DNS server that hosts the DNS Homenet Zone
         Template.

   - DNS Homenet Reverse Zone:   The reverse zone file associated to the
         DNS
         Homenet Zone.

   - Public Authoritative Primary(ies):   are the visible name server
         hosting the DNS Homenet Zone.  End users' resolutions for the
         Homenet Domain are sent to this server, and this server is a
         primary for the zone.

   - Public Authoritative Name Server Set:   is the server the CPE
         synchronizes the DNS Homenet Zone.  It is configured as a
         secondary and the CPE acts as primary.  The CPE sends
         information so the DNSSEC zone can be set and served.

   - Reverse Public Authoritative Primary(ies):   are the visible name
         server hosting the DNS Homenet Reverse Zone.  End users'
         resolutions for the Homenet Domain are sent to this server, and
         this server is a primary for the zone.

   - Reverse Public Authoritative Name Server Set:   is the server the
         CPE synchronizes the DNS Homenet Reverse Zone.  It is
         configured as a secondary and the CPE acts as primary.  The CPE
         sends information so the DNSSEC zone can be set and served.

3.  Introduction

   CPEs are usually constraint constrained devices with reduced network and CPU
   capacities.  As such, a CPE hosting on the Internet the authoritative
   naming service for its home network may become vulnerable to resource
   exhaustion attacks.  One way to avoid exposing CPE is to outsource  Outsourcing the authoritative service to a third party.
   party avoids exposing the CPE to such attacks.  This third party can
   be the ISP or any other independent third party.

   Outsourcing the authoritative naming service to a third party
   requires setting up an architecture which designated in this document as

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

   the Outsourcing Infrastructure.  These settings may be unappropriated inappropriate
   for most end users. users that do not have the sufficient knowledge.  To leverage
   address this issue, this document proposes DHCP
   Options DHCPv6 options so any
   agnostic CPE can automatically proceed to the
   appropriated configuration and outsource the authoritative naming
   service for the home network.  This document shows that in set the Outsourcing Infrastructure.
   In most cases, these DHCP Options make outsourcing to a third party (be it
   the ISP or DHCPv6 options are sufficient and do not require
   any ISP independent service provider) transparent for additional interaction from the end user. user, thus achieving a zero-
   config settings.  In some other cases, the end user is expected to
   perform some limited manual configuration.

   When the CPE is plugged, the DHCP Options DHCPv6 options described in the document
   enable the CPE:
   enable:

   - 1.  To build the DNS Homenet Zone: Building the DNS Homenet Zone requires
         filling the zone with appropriated bindings likes name
         / such as bindings
         between the names and the IP addresses of the different devices in
         of the home networks.
         Such information can  How the CPE is aware of these binding is
         out of scope of the document.  They may be provided provided, for example
         example, by the DHCP Server DHCPv6 server hosted on the CPE.  On the other
         hand, it building the Homenet Zone also requires configuration
         parameters like the name of the Registered Domain Name
         associated to the home network or the Public Authoritative
         Primary(ies)
         Server(s) the DNS Homenet Zone is outsourced to.  These
         configuration parameters are stored in the DNS Homenet Zone
         Template.  This document describes the DHCP Zone Template
         Option.  This option Option
         which carries a DNS the FQDN associated to the Homenet Zone Template FQDN. Template.
         In order to retrieve the DNS Homenet Zone Template, the CPE sends a
         query of type AXFR [RFC1034] [RFC5936]for the DNS
         Homenet Zone Template FQDN. [RFC1034], [RFC5936].

   - 2.  To upload the DNS(SEC) Homenet Zone to the appropriated server:
         This server is designated as the Public Authoritative Name
         Server Set. It is Synchronization Server, in
         charge of publishing the DNS(SEC) Homenet Zone on the Public
         Authoritative Primary(ies). Server(s).  This document describes the DHCP Public Authoritative Name
         Synchronization Server Set Option that provides the FQDN of the
         appropriated server.  Note that,
         in the document we do does not consider
         whether the DNS(SEC) Homenet Zone is signed or not not, and if signed who signs signed, which
         entity is responsible to sign it.  Such questions are out of
         the scope of the current document.

   - 3.  To upload the DNS Homenet Reverse Zone to the appropriated
         server: This server is designated as the Reverse Public
         Authoritative Name
         Synchronization Server Set. It is in charge of publishing the DNS Homenet
         Reverse Zone on the Reverse Public Authoritative Primary(ies). Server(s).
         This document describes the DHCP Reverse Public Authoritative Name Synchronization Server Set
         Option that provides the FQDN of the appropriated server.
         Similarly to item 2., we do not consider in this document if
         the DNS Homenet Reverse Zone is signed or not, and if signed who
         signs it.

   - 4.  To provide authentication credential (a public key) to the DHCP
         Server: Information stored in the DNS Homenet Zone Template, the DNS(SEC)

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

         Homenet Zone and DNS Homenet Reverse Zone belongs to the CPE, and
         only the CPE should be able to update or upload these zones.
         To authenticate the CPE, this document defines the DHCP Client
         Public Key Option.  This option is sent by the CPE to the DHCP Server
         DHCPv6 server and provides the Client Public Key the CPE uses
         to authenticate itself.  The DHCP Server  This document does not describe
         mechanisms used to transmit the Client Public Key from the
         DHCPv6 server to the appropriate entities.  If the DHCPv6
         server is not able to provide the Client Public Key to the
         appropriated entities, then the end user is likely to provide
         manually the Client Public Key to these entities.  This
         document illustrates two scenarios: one where the DHCPv6 server
         is then responsible to
         provide for distributing the Client Public Key to the various DNS servers.

   As a result,
         Synchronization Servers and Reverse Synchronization Server.  In
         the DHCP Options other scenarios, the Client Public Key is distributed out
         of band.

   The DHCPv6 options described in this document enable an
   agnostic CPE make possible to outsource its naming infrastructure without any
   configuration
   configure an Outsourcing Infrastructure with no or little
   configurations from the end user.  The main reason no configuration  A zero-config setting is
   required by achieved
   if the end user is that there are privileged links: first the link between the CPE and the DHCP Server DHCPv6 server and then the link
   between the DHCP Server DHCPv6 server and the various DNS servers (DNS Homenet (Homenet Zone
   Server, the Reverse
   Public Authoritative Name Server Set, Public Authoritative Name
   Server Set).  This enables Synchronization Server, Synchronization Server)
   are trusted.  For example, one way to provide a thrustworhy
   connection between the CPE and the DHCPv6 server is defined in
   [I-D.ietf-dhc-sedhcpv6].  When both links are trusted, the CPE is
   able to send provide its authentication credentials (a Client Public Key)
   to the DHCP Server DHCPv6 server, that in turn forward forwards it to the various DNS
   servers.  With the authentication credential credentials on the DNS servers set, servers, the
   CPE is able to update the various zones in a
   secure way. securely update.

   If the DHCP Server DHCPv6 server cannot provide the public key Client Public Key to one of
   these servers (most likely the Public Authoritative Name Server Set) Synchronization Server) and the CPE
   needs to interact with the server, then, the end user is expected to
   provide the CPE's public key Client Public Key to these servers (the Reverse Public Authoritative Name
   Synchronization Server Set or the Public
   Authoritative Name Server Set) Synchronization Server) either manually
   or using other mechanisms.  Such mechanisms are outside the scope of
   this document.  In that case, the authentication credentials need to
   be provided every time the key is modified.  Appendix A provides more
   details on how different scenarios impact the end users.

   The remaining of this document is structured as follows.  Section 4
   provides an overview of the DHCP Options DHCPv6 options as well as the expected
   interactions between the CPE and the various involved entities.  This
   section also provides an overview of available mechanisms to secure
   DNS transactions and update DNS Data. data.  Section 5 describes how the
   CPE may securely synchronize and update DNS data.  Section 6
   describes the payload of the DHCP Options DHCPv6 options and Section 7 details how DHCP Client
   DHCP Server

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

   DHCPv6 client, server and DHCP Relay relay agent behave.  Section 8 lists the
   new parameters to be registered at the IANA, Section 9 provides
   security considerations.  Finally, Appendix A describes how the CPE
   may behave and be configured regarding various scenarios.

4.  Protocol Overview

   This section provides an overview of the how the CPE is expect to
   interact CPE's interactions with various entities, as well as how the CPE is expected to
   be configured via DHCP Options.
   Outsourcing Infrastructure in Section 4.1 describes the entities 4.1, and so the CPE is expected to interact with.  Interaction with each entities
   is defined via DHCP Options that are expected to configure necessary for
   its setting.  In this document, the CPE. configuration is provided via
   DHCPv6 options.  Once configured, the CPE is expected to be able to
   update some and publish DNS
   Data hosted by data on the different entities. components of the
   Outsourcing Infrastructure.  As a result security authenticating and updating
   mechanisms play an important role in the specification.  Section 4.2
   provides an overview of the different security mechanisms
   considered for securing the CPE transactions authentication methods and
   Section 4.3
   considers provides an overview of the different update mechanisms
   considered for the CPE to update the DNS Data. data.

4.1.  Architecture and DHCP DHCPv6 Options Overview

   This section illustrates how a CPE configures its naming
   infrastructure receives the necessary information
   via DHCPv6 options to outsource its authoritative naming service.  All
   configurations and settings are performed using DHCP Options.  This
   section, for service on
   the Outsourcing Infrastructure.  For the sake of simplicity, this
   section assumes that the DHCP Server DHCPv6 server is able to communicate to the
   various DNS servers and to provide them the public key associated to
   with the CPE.  Once each server got the public key, the CPE can
   proceed to updates transactions in a an authenticated and secure way.

   This scenario has been chosen as it is believed to be the most
   popular scenario.  This document does not ignore that scenarios where
   the DHCP Server does not have privileged relations with the Public
   Authoritative Name
   Synchronization Server Set must be considered.  These cases are discussed
   latter in Appendix A.  Such scenario does not necessarily require
   configuration for the end user and can also be Zero Config. zero-config.

   The scenario is represented in Figure 1.

   - 1:  The CPE provides its Client Public Key to the DHCP Server using
         a DHCP Client Public Key Option (OPTION_PUBLIC_KEY) and sends a DHCP includes the
         following option codes in its its Option Request Option (ORO) for the DHCP (ORO):
         Zone Template Option (OPTION_DNS_ZONE_TEMPLATE), the DHCP Public Authoritative Name
         Synchronization Server Set Option (OPTION_NAME_SERVER_SET) (OPTION_SYNC_SERVER) and the DHCP
         Reverse
         Public Authoritative Name Synchronization Server Set Option
         (OPTION_REVERSE_NAME_SERVER_SET).
         (OPTION_REVERSE_SYNC_SERVER).

   - 2:  The DHCP Server makes the Client Public Key available to the
         DNS servers, so the CPE can secure its DNS transactions.  How
         the Client Public Key is transmitted to the various DNS servers

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

         is out of scope of this document.  Note that the Client Public
         Key alone is not sufficient to perform the authentication and
         the key should be, for example, associated with an identifier,
         or the concerned domain name.  How the binding is performed is
         out of scope of the document.  It can be a centralized database
         or various bindings may be sent to the different servers.
         Figure 1 represents the specific case
         were where the DHCP Server
         forwards the set (Public (Client Public Key, Zone Template FQDN) to the
         DNS Template Server, the set (Public (Client Public Key, IPv6 subnet)
         to the Reverse Public Authoritative Name Synchronization Server
         Set and the set (Public (Client
         Public Key, Registered Homenet Domain) to the
         Public Authoritative Name Server Set. Synchronization
         Server.

   - 3.: 3:  The DHCP Server responds to the CPE with the requested DHCP
         Options, DHCPv6
         options, i.e. the DHCP Client Public Key Option (OPTION_PUBLIC_KEY),
         DHCP
         Zone Template Option OPTION_DNS_ZONE_TEMPLATE, DHCP Public
         Authoritative Name Synchronization
         Server Set Option (OPTION_NAME_SERVER_SET),
         DHCP (OPTION_SYNC_SERVER), Reverse Public Authoritative Name Synchronization
         Server Set Option
         (OPTION_REVERSE_NAME_SERVER_SET). (OPTION_REVERSE_SYNC_SERVER).  Note that this
         step may be performed in parallel to step 2, or even before.
         In other words, there is no requirements that step 3 is
         conducted after step 2.

   - 4.: 4:  Upon receiving the DHCP Zone Template Option
         (OPTION_DNS_ZONE_TEMPLATE), the CPE performs an AXFR DNS query
         for the Zone Template FQDN.  The exchange is secured authenticated
         according to the security protocols authentication methods defined in the Security
         Supported Authentication Methods field of the DHCP option.
         Once the CPE has retrieved the DNS Zone Template, the CPE can
         build the DNS Homenet Zone and the DNS Homenet Reverse Zone.
         Eventually the CPE signs these zones.

   - 5.: 5:  Once the DNS(SEC) Homenet Reverse Zone has been set, the CPE uploads the
         zone to the Reverse Public Authoritative Name
         Server Set. Synchronization Server.  The DHCP Reverse Public Authoritative Name
         Synchronization Server
         Set Option (OPTION_REVERSE_NAME_SERVER_SET) (OPTION_REVERSE_SYNC_SERVER)
         provides the Reverse Public Authoritative Name Synchronization Server Set FQDN as well as the
         upload method, and the security Supported Authentication Methods
         protocol to secure the upload.

   - 6.: 6:  Once the DNS(SEC) Homenet Zone has been set, the CPE uploads the zone to
         the Public Authoritative Name Server Set. Synchronization Server.  The DHCP
         Public Authoritative Name Synchronization Server Set Option
         (OPTION_NAME_SERVER_SET)
         (OPTION_SYNC_SERVER) provides the Public Authoritative Name Synchronization Server Set FQDN
         as well as the upload method and the security
         protocol authentication method to
         secure the upload.

      +----------------------+

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

        +---------------------+
        |     DHCP    DHCPv6 Server    |
      +----------------------+
        +---------------------+
             ^  ^         ^
             |  |         |2.         |
           1.|  |3.       |2.
             |  |         |
             v  v         |
           +------+       |    +--------------------------------+
           |      |  4.   +--->|  DNS Template Server           |
           |      |<---------->|                                |
           |      |       |    +--------------------------------+
           | CPE  |       |
           |      |       |    +--------------------------------+
           |      | 5./6. +--->|  Reverse Public Authoritative Synchronization       |
           |      |<---------->|  Name  Server Set                        |
           |      |       |    +--------------------------------+
    -------|      |-------|--------------------------------------
           |      |       |
           |      |       |    +--------------------------------+
           +------+       +--->|  Public Authoritative  Synchronization Server        |
                               |  Name Server Set                                |
                               +--------------------------------+

                        Figure 1: Protocol Overview

   As described above, the CPE is likely to interact with various DNS
   content.  This section is focused on DNS Data the CPE is likely to
   update.  More specifically, the CPE is likely to update the:

   - DNS Homenet Zone Template:   may be updated by the CPE   if the configuration of the zone may be
         changed.  This can may include additional Public Authoritative Primary(ies),
         Server(s), a different Registered Homenet Domain as the one
         initially proposed, or a redirection to another domain.

   - DNS Homenet Reverse Zone:   may be updated   every time a new device is connected or
         dis-connected.

   - DNS Homenet Zone:   may be updated   every time a new device is connected, dis-connected. dis-
         connected.

   Step 2 and step 3 should be considered as independent steps and could
   be re-ordered.  In fact, the CPE must be able to perform these updates in a secure
   manner.  There are multiple ways DHCPv6 server does not have to secure wait for
   a confirmation from the DNS transaction servers the Client Public Key has been
   properly received, and this
   document considers two mechanisms is operational by the DNS servers.  The DHCP
   Server is expected to update reply upon receiving the Client Public Key
   Option.  The reply to the message with a Client Public Key Option
   from the DHCP Server is interpreted by the DHCPv6 client as a
   confirmation of the reception of the option by the DHCP Server only.
   It does not indicate whether the server had processed the option or

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

   not.  Debugging configurations errors or transmission error with one
   of the DNS Data (nsupdate servers is let to the CPE and
   primary/secondary synchronization).  Which security mechanism thus is outside of the scope
   of the DHCPv6.  First, it is unlikely a DNS server can validate that
   the Client Public Key will be operational for the CPE, as multiple
   causes of errors could occur.  For example, the Client Public Key may
   have been changed during the transmission or by the DHCP Server, or
   the DNS server may be misconfigured.  Second, the number of error
   codes would be too complex.  In addition to use multiple causes of
   errors, multiple architectures and multiple DNS servers may be
   involved.  Third, this may cause significant DHCP Server performance
   degradation.

   In fact, the CPE performs these updates in a secure manner.  There
   are multiple ways to secure a DNS transaction depends on the expected security
   (authentication of the authoritative server, mutual authentication,
   confidentiality...).  The expected security may also depends on the
   kind of transaction performed by the CPE. and this document
   considers two mechanisms: nsupdate and primary/secondary
   synchronization.  Section 4.2 describes the
   different security mechanisms considered in the document as well as
   their respective goals.  Which mechanism to authentication method
   that may be use to update secure the DNS
   Data depends on the kind transactions of update.  Frequency the CPE.  The
   appropriate authentication methods may, for example, be chosen
   according to the level of confidentiality or the update, size level of
   authentication requested by the DNS Data to update may be some useful criteria. CPE transactions.  Section 4.3
   positions the nsupdate and primary/secondary synchronization
   mechanisms.  The update appropriate update mechanism may depend on
   the for example on the update frequency or the size of the DNS data
   to update.

4.2.  Mechanisms Securing DNS Transactions

   Multiple protocols like IPsec [RFC4301] or TLS / DTLS [RFC5246] /
   [RFC6347] may be used to secure DNS transactions between the CPE and
   the DNS servers.  This document restricts the limits its scope of security
   protocols to those authentication
   method that have been designed specifically for DNS.  This includes
   DNSSEC [RFC4033], [RFC4034], [RFC4035] that authenticates and
   provides integrity protection of DNS data, TSIG [RFC2845], [RFC2930]
   that use a shared secret to secure a transaction between two end
   points and SIG(0) [RFC2931] authenticates the DNS packet exchanged.

   The key issue with TSIG is that a shared secret must be negotiated
   between the CPE and the server.  On the other hand, TSIG performs
   symmetric cryptography which is light in comparison with asymmetric
   cryptography used by SIG(0).  As a result, over large zone transfer,
   TSIG may be preferred to SIG(0).

   This document does not provides provide means to distribute shared secret for
   example using a specific DHCP Option. DHCPv6 option.  The only assumption made is
   that the CPE generates or is assigned a public key.

   As a result, when the document specifies the transaction is secured
   with TSIG, it means that either the CPE and the DNS Server server have been

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

   manually configured with a shared secret, or the shared secret has
   been negotiated using TKEY [RFC2930], and the TKEY exchanged are
   secured with SIG(0).

   Exchange

   Exchanges with the DNS Template Server to retrieve the DNS Homenet Zone
   Template may be protected by SIG(0), TSIG or DNSSEC.  When DNSSEC is
   used, it means the DNS Template Server only provides integrity
   protection, and does not necessarily prevents prevent someone else to query
   the DNS Homenet Zone Template.  In addition, DNSSEC is only a way to
   protect the AXFR queries transaction, in other words, DNSSEC cannot
   be used to secure updates.  If DNSSEC is used to provide integrity
   protection for the AXFR response, the CPE should proceed to the
   DNSSEC signature checks.  If signature check fails, it MUST reject
   the response.  If the signature check succeeds, the CPE removes all
   DNSSEC related RRsets (DNSKEY, RRSIG, NSEC* ...) before building the DNS
   Homenet Zone.  In fact, these DNSSEC related fields are associated to
   the DNS Homenet Zone Template and not the DNS Homenet Zone.

   Any update exchange should use SIG(0) or TSIG to authenticate the
   exchange.

4.3.  Primary / Secondary Synchronization versus DNS Update

   As updates only concern DNS zones, this document only considers DNS
   update mechanisms such as DNS update [RFC2136]  [RFC3007] or a
   primary / secondary synchronization.

   The DNS Homenet Zone Template can only SHOULD be updated with DNS update.
   The reason is that the DNS Homenet Zone Template update as it
   contains static configuration data that is not expected to evolve
   over time.

   The DNS Homenet Reverse Zone and the DNS Homenet Zone can be updated either
   with DNS update or using a primary / secondary synchronization.  As
   these zones may be large, with frequent updates, we recommend to use
   the primary / secondary architecture as described in
   [I-D.ietf-homenet-front-end-naming-delegation].  The primary /
   secondary mechanism is preferred as it better scales and avoids DoS
   attacks: First the primary notifies the secondary the zone must be
   updated, and leaves the secondary to proceed to the update when
   possible.  Then, the NOTIFY message sent by the primary is a small
   packet that is less likely to load the secondary.  At last, the AXFR
   query performed by the secondary is a small packet sent over TCP
   (section 4.2 [RFC5936]) which makes unlikely the secondary to perform
   reflection attacks with a forged NOTIFY.  On the other hand, DNS
   updates can use UDP, packets require more processing then than a NOTIFY,
   and they do not provide the server the opportunity to post-pone postpone the
   update.

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

5.  CPE Configuration

5.1.  CPE Primary / Secondary Synchronization Configurations

   The primary / secondary architecture is described in
   [I-D.ietf-homenet-front-end-naming-delegation].  The CPE is
   configured as hosts a primary whereas the DNS Server is configured as
   Hidden Primary that synchronizes with a
   secondary.  The DNS Server represents the Public Authoritative Name Synchronization Server Set or the
   Reverse Public Authoritative Name Server Set. Synchronization Server.

   When the CPE is plugged its IP address may be unknown to the
   secondary.  The section details how the CPE or primary communicate communicates
   the necessary information to set up the secondary.

   In order to set the primary / secondary configuration, both primary
   and secondaries must agree on 1) the zone to be synchronized, 2) the
   IP address and ports used by both primary and secondary.

5.1.1.  CPE / Public Authoritative Name Synchronization Server Set

   The CPE knows is aware of the zone to be synchronized by reading the
   Registered Homenet Domain in the DNS Homenet Zone Template provided by
   the DHCP Zone Template Option (OPTION_DNS_ZONE_TEMPLATE).  The IP address
   of the secondary is provided by the DHCP Public Authoritative Name Synchronization Server Set Option (OPTION_NAME_SERVER_SET).
   (OPTION_SYNC_SERVER).

   The Public Authoritative Name Synchronization Server Set has been configured with the Registered
   Homenet Domain and the Client Public Key that identifies the CPE.
   The only thing missing information is the IP address of the CPE.  This IP
   address is provided by the CPE by sending a NOTIFY [RFC1996].

   When the CPE has built its DNS Homenet Zone, it sends a NOTIFY message to
   the Public Authoritative Name Server Sets. Synchronization Servers.  Upon receiving the NOTIFY message, the
   secondary reads the Registered Homenet Domain and checks the NOTIFY
   is sent by the authorized primary.  This can be done using the shared
   secret (TSIG) or the public key (SIG(0)).  Once the NOTIFY has been
   authenticated, the Public Authoritative Name
   Server Sets Synchronization Servers might consider the source
   IP address of the NOTIFY query to configure the primaries attributes.

5.1.2.  CPE / Reverse Public Authoritative Name Synchronization Server Set

   The CPE knows is aware of the zone to be synchronized by looking at its
   assigned prefix.  The IP address of the secondary is provided by the DHCP
   Reverse Public Authoritative Name Synchronization Server Set Option
   (OPTION_REVERSE_NAME_SERVER_SET). (OPTION_REVERSE_SYNC_SERVER).

   Configuration of the secondary is performed as illustrated in
   Section 5.1.1.

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

5.2.  CPE DNS Data Handling and Update Policies

5.2.1.  DNS  Homenet Zone Template

   The DNS Homenet Zone Template contains at least the related fields of the
   Public Authoritative Primary(ies) Server(s) as well as the Homenet Registered
   Domain, that is SOA, and NS fields.  This template might be generated
   automatically by the owner of the DHCP Server.  For example, an ISP
   might provide a default Homenet Registered Domain as well as default
   Public Authoritative Primary(ies). Server(s).  This default settings should provide
   the CPE the necessary pieces of information to set the homenet naming
   architecture.

   If the DNS Homenet Zone Template is not subject to modifications or
   updates, the owner of the template might only use DNSSEC to enable
   integrity check.

   The DNS

   On the other hand, the Homenet Zone Template might also be subject to
   modification by the CPE.  The advantage of using the standard DNS
   zone format is that standard DNS update mechanism can be used to
   perform updates.  These updates might be accepted or rejected by the
   owner of the DNS Homenet Zone Template.  Policies that defines what is
   accepted or rejected is out of scope of this document.  However, in this
   document we assume assumes the Registered Homenet Domain is used as an index by
   the Public
   Authoritative Name Server Set, Synchronization Server, and SIG(0), TSIG are used to authenticate
   the CPE.  As a result, the Registered Homenet Domain should not be
   modified unless the Public Authoritative Name Synchronization Server
   Set can handle with it.

5.2.2.  DNS (Reverse) Homenet Zone

   The DNS Homenet Zone might be generated from the DNS Homenet Zone Template.
   How the DNS Homenet Zone is generated is out of scope of this document.
   In some cases, the DNS Homenet Zone might be the exact copy of the DNS
   Homenet Zone Template.  In other cases, it might be generated from
   the DNS Homenet Zone Template with additional RRsets.  In some other
   cases, the DNS Homenet Zone might be generated without considering the DNS
   Homenet Zone Template, but only considering specific configuration
   rules.

   In the current document the CPE only sets a single zone that is
   associated with one single Homenet Registered Domain.  The domain
   might be assigned by the owner of the DNS Homenet Zone Template.  This constrain
   constraint does not prevent the CPE to use multiple domain names.
   How additional domains are considered is out of scope of this
   document.  One way to handle these additional zones is to configure
   static redirections to the DNS Homenet Zone using CNAME [RFC2181],
   [RFC1034], DNAME [RFC6672] or CNAME+DNAME
   [I-D.sury-dnsext-cname-dname].

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

6.  Payload Description

   This section details the payload of the DHCP Options. DHCPv6 options.  A few DHCP
   Options DHCPv6
   options are used to advertise a server the CPE may be expect expected to
   interact with.  Interaction may require to define how the update is
   expected to be performed as well as how the communication is secured.
   Security and
   authentication methods.  Update fields are shared by multiple DHCP Options DHCPv6
   options and are described in separate sections.  Section 6.1
   describes the security Supported Authentication Method field, Section 6.2
   describes the update fields, Update field, the remaining
   sections Section 6.3, Section 6.4,
   Section 6.5, Section 6.6 describe the DHCP Options. DHCPv6 options.

6.1.  Security  Supported Authentication Methods Field

   The Security Field Supported Authentication Methods field of the DHCP Option is DHCPv6 option
   represented in Figure 2.  It 2 indicates the security mechanism authentication method supported
   by the DNS Server. server.  One of these mechanism MUST be chosen by the CPE
   in order to perform a transaction with the DNS server.  See
   Section 4.2 for more details.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Security    Supported Auth. Methods    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 2: Security Field Supported Authentication Methods Filed

   - DNS (Bit 0):   indicates, when set to 1, that DNS without any
         security extension is supported.

   - DNSSEC (Bit 1):   indicates, when set to 1, that DNSSEC provides
         integrity protection.  This can only be used for read
         operations like retrieving the DNS Homenet Zone Template.

   - SIG(0) (Bit 2):   indicates, when set to 1, that transaction
         protected by SIG(0) are supported.

   - TSIG (Bit 3):   indicates, when set to 1, that transaction using
         TSIG is supported.  Note that if a shared secret has not been
         previously negotiated between the two party, it should be
         negotiated using TKEY.  The TKEY exchanges MUST be protected
         with SIG(0) even though SIG(0) is not supported.

   - Remaining Bits (Bit 4-15):   MUST be set to 0 by the DHCP Server
         and MUST be ignored by the DHCP Client. DHCPv6 client.

   A Security Supported Authentication Methods field with all bits set to zero
   indicates the operation is not permitted.  The Security Supported

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

   Authentication Methods field may be set to zero when updates
   operations are not permitted for the DNS Homenet Template.  In any
   other case this is an error.

6.2.  Update Field

   The Update Field of the DHCP Option DHCPv6 option is represented in Figure 3.  It
   indicates the update mechanism supported by the DNS server.  See
   Section 4.3 for more details.

    0
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |    Update     |
   +-+-+-+-+-+-+-+-+

                          Figure 3: Update Field

   - Primary / Secondary (Bit 0):   indicates, when set to 1, that DNS
         Server supports data synchronization using a Primary /
         Secondary mechanism.

   - DNS Update (Bit 1):   indicates, when set to 1, that DNS Server
         supports data synchronization using DNS Updates.

   - Remaining Bits (Bit 2-7):   MUST be set to 0 by the DHCP Server DHCPv6 server
         and MUST be ignored by the DHCP Client. DHCPv6 client.

6.3.  DHCP  Client Public Key Option

   The DHCP Client Public Key Option (OPTION_PUBLIC_KEY) indicates the Client
   Public Key that is used to authenticate the CPE.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OPTION_PUBLIC_KEY       |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                      Public Key Data                          /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 4: DHCP Public Key Option

   - OPTION_PUBLIC_KEY (variable):  the  This option code for the DHCP Public
         Key Option.

   - option-len (16 bits):  length in octets of the option-data field as
         described in [RFC3315].

   - Public Key Data:  contains the Public Key. The format is the DNSKEY
         RDATA format as
   defined in [RFC4034]. [I-D.ietf-dhc-sedhcpv6].

6.4.  DHCP  Zone Template Option

   The DHCP Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option indicates
   the CPE how to retrieve the DNS Homenet Zone Template.  It provides a
   FQDN the CPE SHOULD query with a DNS query of type AXFR.
   The option also specifies which security protocols are available on AXFR as well as
   the authentication methods associated to the authoritative server.  DNS AXFR query or the
   nsupdate queries.  Homenet Zone Template update, if permitted MUST
   use the DNS Update mechanism.

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    OPTION_DNS_ZONE_TEMPLATE   |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Security Supp. Auth. Methods (axfr)    |            Security Supp. Auth. Methods (update)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                        Zone Template FQDN                     /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 5: DHCP 4: Zone Template Option

   - OPTION_DNS_ZONE_TEMPLATE (variable): option-code: (16 bits):  OPTION_DNS_ZONE_TEMPLATE, the option code
         for the DHCP Zone Template Option. Option (TBD1).

   - option-len (16 bits):  length in octets of the option-data field as
         described in [RFC3315].

   - Security (axfr) Supported Authentication Methods(axfr) (16 bits):  defines which security protocols
         authentication methods are supported by the DNS server.  This
         field concerns the AXFR and consultation queries, not the
         update queries.  See Section 6.1 for more details.

   - Security Supported Authentication Methods (16 bits):  defines which security protocols
         authentication methods are supported by the DNS server.  This
         field concerns the update.  See Section 6.1 for more details.

   - Zone Template FQDN FQDN (variable):  the FQDN of the DNS server
         hosting the DNS Homenet Zone Template.

6.5.  DHCP Public Authoritative Name  Synchronization Server Set Option

   The DHCP Public Authoritative Name Synchronization Server Set Option
   (OPTION_NAME_SERVER_SET) (OPTION_SYNC_SERVER) provides
   information so necessary for the CPE can to upload the DNS Homenet Zone to the Public Authoritative Name Server Set.
   Synchronization Server.  Finally, the option provides the security mechanisms
   authentication methods that are available to perform the upload.  The
   upload is performed via a DNS primary / secondary architecture or DNS
   updates.

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

    0                   1                        2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    OPTION_NAME_SERVER_SET        OPTION_SYNC_SERVER     |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Security Supported Auth. Methods       |    Update     |     Server    /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /     Port      |                                               |
   +-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   /           Public Authoritative Name                    Synchronization Server Set FQDN                /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 6: DHCP Public Authoritative Name 5: Synchronization Server Set Option

   - OPTION_NAME_SERVER_SET option-code (16 bits):  OPTION_SYNC_SERVER, the option code for the DHCP
         Public Authoritative Name
         Synchronization Server Set Option. Option (TBD2).

   - option-len (16 bits):  length in octets of the option-data field as
         described in [RFC3315].

   - Security Supported Authentication Methods (16 bits):  defines which security protocols
         authentication methods are supported by the DNS server.  See
         Section 6.1 for more details.

   - Update (8 bits):  defines which update mechanisms are supported by
         the DNS server.  See Section 4.3 for more details.

   - Server Port (16 bits):  defines the port the Public Authoritative
         Name Synchronization Server Set
         is listening.  When multiple transport layers may be used, a
         single and unique Server Port value applies to all the
         transport layers.  In the case of DNS for example, Server Port
         value considers DNS exchanges using UDP and TCP.

   - Public Authoritative Name Synchronization Server Set FQDN (variable):  the FQDN of the Public Authoritative Name Server Set.
         Synchronization Server.

6.6.  DHCP  Reverse Public Authoritative Name Synchronization Server Set Option

   The DHCP Reverse Public Authoritative Name Synchronization Server Set Option
   (OPTION_REVERSE_NAME_SERVER_SET)
   (OPTION_REVERSE_SYNC_SERVER) provides information so necessary for the
   CPE can to upload the DNS Homenet Zone to the Public Authoritative Name Server
   Set. Synchronization Server.  The
   option provides the security mechanisms authentication methods that are available to
   perform the upload.  The upload is performed via a DNS primary /
   secondary architecture or DNS updates.

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OPTION_REVERSE_NAME_SERVER_SET|  OPTION_REVERSE_SYNC_SERVER   |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Security Supported Auth. Methods       |     Update    |   Server      /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /         Port    |                                             |
   +-+-+-+-+-+-+-+-+-+                                             |
   |                                                               |
   /                Reverse Public Authoritative Name Synchronization Server Set FQDN            /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 7: DHCP 6: Reverse Public Authoritative Name Synchronization Server Set Option

   - OPTION_REVERSE_NAME_SERVER_SET option-code (16 bits):  OPTION_REVERSE_SYNC_SERVER, the option code
         for the
         DHCP Reverse Public Authoritative Name Synchronization Server Set Option. Option (TBD3).

   - option-len (16 bits):  length in octets of the option-data field as
         described in [RFC3315].

   - Security Supported Authentication Methods (16 bits):  defines which security protocols
         authentication methods are supported by the DNS server.  See
         Section 6.1 for more details.

   - Update (8 bits):  defines which update mechanisms are supported by
         the DNS server.  See Section 4.3 for more details.

   - Server Port (16 bits):  defines the port the Public Authoritative
         Name Synchronization Server Set
         is listening.

   - Reverse Public Authoritative Name Synchronization Server Set FQDN (variable):  The FQDN of the Reverse Public Authoritative Name Server Set.

7.  DHCP Behavior

7.1.  DHCPv6 Server Behavior

   The
         Reverse Synchronization Server.

7.  DHCP Behavior

7.1.  DHCPv6 Server Behavior

   Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in
   regards to option assignment.  As a convenience to the reader, we
   mention here that the server will send option foo only if configured
   with specific values for foo and if the client requested it.  In
   particular, when configured the DHCP Server sends the DHCP Zone Template Option
   (OPTION_DNS_ZONE_TEMPLATE), DHCP Public Authoritative Name
   Option, Synchronization Server Set
   Option (OPTION_NAME_SERVER_SET), DHCP Option, Reverse Public Authoritative
   Name Synchronization Server Set
   Option (OPTION_REVERSE_NAME_SERVER_SET) upon request when requested by the DHCP Client. DHCPv6 client by including necessary
   option codes in its ORO.

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

   The DHCP Server MAY may receive a DHCP Client Public Key Option
   (OPTION_PUBLIC_KEY) from the CPE.  Upon receipt of this DHCP Option, DHCPv6
   option, the DHCP Sever is expect to Server SHOULD acknowledge the reception of the
   Client Public Key Option as described in Section 4.1 and communicate
   this credential to the available DNS Servers like the DNS Template
   Server, the Public
   Authoritative Name Synchronization Server Set and the Reverse Synchronization
   Server, unless not configured to do so.

   A CPE may update its Client Public Authoritative
   Name Key by sending a new value in the
   Client Public Key Option (OPTION_PUBLIC_KEY) as this document assumes
   the link between the CPE and the DHCP Server Set. is considered
   authenticated and trusted.  The server SHOULD process received Client
   Public Key Option sent by the client (see step 2 in Section 4.1),
   unless not configured to do so.

7.2.  DHCPv6 Client Behavior

   The DHCP Client MAY DHCPv6 client SHOULD send a DHCP Client Public Key Option
   (OPTION_PUBLIC_KEY) to the DHCP Server.  This Client Public Key
   authenticates the CPE.

   The DHCP Client DHCPv6 client sends a DHCP Option Request Option (ORO) ORO with the necessary DHCP options.

   A CPE SHOULD only send the an ORO request for DHCP Options it needs
   or for information that needs to be up-to-date. option codes: Zone
   Template Option, Synchronization Server Option and Reverse
   Synchronization Server Option.

   Upon receiving a DHCP option described in this document, document in the Reply
   message, the CPE SHOULD retrieve or update DNS zones using the
   associated security Supported Authentication Methods and update protocols. protocols, as
   described in Section 5.

7.3.  DHCPv6 Relay Agent Behavior

   There are no additional requirements for the DHCP Relay behavior are not modified by this document. agents.

8.  IANA Considerations

   The DHCP options detailed in this document is:

   - OPTION_DNS_ZONE_TEMPLATE:  TBD  TBD1

   - OPTION_NAME_SERVER_SET:  TBD OPTION_SYNC_SERVER:  TBD2

   - OPTION_REVERSE_NAME_SERVER_SET:  TBD

   - OPTION_PUBLIC_KEY:  TBD OPTION_REVERSE_SYNC_SERVER:  TBD3

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

9.  Security Considerations

9.1.  DNSSEC is recommended to authenticate DNS hosted data

   It is recommended that the (Reverse) DNS Homenet Zone is signed with
   DNSSEC.  The zone may be signed by the CPE or by a third party.  We
   recommend the zone to be signed by the CPE, and that the signed zone
   is uploaded.

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

   The channel MUST be secured because the CPE provides authentication
   credentials.  Unsecured channel may result in CPE impersonation
   attacks.

   The document considers that the channel between the CPE and the ISP
   DHCP Server is trusted.  More specifically, 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], [RFC7296]
   propose to secure the channel at the IP layer.

   In fact, the channel MUST be secured because the CPE provides
   authentication credentials.  Unsecured channel may result in CPE
   impersonation attacks.

9.3.  CPEs are sensitive to DoS

   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 resulting outsourcing architecture
   is described in [I-D.ietf-homenet-front-end-naming-delegation].  This
   document shows how the outsourcing architecture can be automatically
   set.

10.  Acknowledgment  Acknowledgments

   We would like to thank Tomasz Mrugalski, Marcin Siodelski and Bernie Volz for their
   comments on the design of the DHCP Options. DHCPv6 options.  We would also like to
   thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their
   remarks on the architecture design.  The designed solution has been
   largely been inspired by Mark Andrews's document
   [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark.  We
   also thank Ray Hunter for its reviews, its comments and for
   suggesting an appropriated terminology.

11.  References
Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

11.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987. 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
              August 1996. 1996, <http://www.rfc-editor.org/info/rfc1996>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997. 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997. 1997,
              <http://www.rfc-editor.org/info/rfc2136>.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997. 1997,
              <http://www.rfc-editor.org/info/rfc2181>.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, Eastlake 3rd, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000. 2000,
              <http://www.rfc-editor.org/info/rfc2845>.

   [RFC2930]  Eastlake,  Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
              RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000. 2000,
              <http://www.rfc-editor.org/info/rfc2930>.

   [RFC2931]  Eastlake,  Eastlake 3rd, D., "DNS Request and Transaction Signatures
              (
              SIG(0)s)", SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 2000.
              2000, <http://www.rfc-editor.org/info/rfc2931>.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, DOI 10.17487/RFC3007, November 2000. 2000,
              <http://www.rfc-editor.org/info/rfc3007>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003.
              2003, <http://www.rfc-editor.org/info/rfc3315>.

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005. 2005,
              <http://www.rfc-editor.org/info/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005. 2005,
              <http://www.rfc-editor.org/info/rfc4034>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005. 2005,
              <http://www.rfc-editor.org/info/rfc4035>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005. 2005, <http://www.rfc-editor.org/info/rfc4301>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008. 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
              (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010. 2010,
              <http://www.rfc-editor.org/info/rfc5936>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012. 2012, <http://www.rfc-editor.org/info/rfc6347>.

   [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the
              DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012. 2012,
              <http://www.rfc-editor.org/info/rfc6672>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014.
              2014, <http://www.rfc-editor.org/info/rfc7296>.

11.2.  Informational References

   [I-D.andrews-dnsop-pd-reverse]
              Andrews, M., "Automated Delegation of IP6.ARPA reverse
              zones with Prefix Delegation", draft-andrews-dnsop-pd-
              reverse-02 (work in progress), November 2013.

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

   [I-D.ietf-dhc-sedhcpv6]
              Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure
              DHCPv6", draft-ietf-dhc-sedhcpv6-08 (work in progress),
              June 2015.

   [I-D.ietf-homenet-front-end-naming-delegation]
              Migault, D., Cloetens, W., Weber, R., Hunter, R., Griffiths, C., and R. Weber, W.
              Cloetens, "Outsourcing Home Network Authoritative Naming
              Service",
              draft-ietf-homenet-front-end-naming-delegation-02 draft-ietf-homenet-front-end-naming-
              delegation-04 (work in progress), May September 2015.

   [I-D.sury-dnsext-cname-dname]
              Sury, O., "CNAME+DNAME Name Redirection", draft-sury-
              dnsext-cname-dname-00 (work in progress), April 2010.

Appendix A.  Scenarios and impact on the End User

   This section details various scenarios and discuss their impact on
   the end user.

A.1.  Base Scenario

   The base scenario is the one described in Section 4.  It is typically
   the one of an ISP that manages the DHCP Server, and all DNS servers.

   The end user subscribes to the ISP (foo), and at subscription time
   registers for example.foo as its Registered Homenet Domain
   example.foo.  Since the ISP knows the Registered Homenet Domain and
   the Public Authoritative Primary(ies) Server(s) the ISP is able to build the
   DNS
   Homenet Zone Template.

   The ISP manages the DNS Template Server, so it is able to load the
   DNS
   Homenet Zone Template on the DNS Template Server.

   When the CPE is plugged (at least the first time), it provides its
   Client Public Key to the DHCP Server.  In this scenario, the DHCP
   Server and the DNS Servers are managed by the ISP so the DHCP Server
   can provide authentication credentials of the CPE to enable secure
   authenticated transaction between the CPE and these DNS servers.
   More specifically, credentials are provided to:

   -     Public Authoritative Name     Synchronization Server Set

   -     Reverse Public Authoritative Name Synchronization Server Set

   -     DNS Template Server

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

   The CPE can update the zone using DNS update or a primary / secondary
   configuration in a secure way.

   The main advantage of this scenario is that the naming architecture
   is configured automatically and transparently for the end user.

   The drawbacks are that the end user uses a Registered Homenet Domain
   managed by the ISP and that it relies on the ISP naming
   infrastructure.

A.2.  Third Party Registered Homenet Domain

   This section considers the case when the end user wants its home
   network to use example.com as a Registered Homenet Domain instead of
   example.foo that has been assigned by the ISP.  We also suppose that
   example.com is not managed by the ISP.

   This can also be achieved without any configuration.  When the end
   user buys the domain name example.com, it may request to redirect the
   name example.com to example.foo using static redirection with CNAME
   [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME
   [I-D.sury-dnsext-cname-dname].

   This configuration is performed once when the domain name example.com
   is registered.  The only information the end user needs to know is
   the domain name assigned by the ISP.  Once this configuration is done
   no additional configuration is needed anymore.  More specifically,
   the CPE may be changed, the zone can be updated as in Appendix A.1
   without any additional configuration from the end user.

   The main advantage of this scenario is that the end user benefits
   from the Zero Configuration of the Base Scenario Appendix A.1.  Then,
   the end user is able to register for its home network an unlimited
   number of domain names provided by an unlimited number of different
   third party providers.

   The drawback of this scenario may be that the end user still rely on
   the ISP naming infrastructure.  Note that the only case this may be
   inconvenient is when the DNS Servers provided by the ISPs results in
   high latency.

A.3.  Third Party DNS Infrastructure

   This scenario considers that the end user uses example.com as a
   Registered Homenet Domain, and does not want to rely on the
   authoritative servers provided by the ISP.

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

   In this section we limit the outsourcing to the Public Authoritative
   Name Synchronization
   Server Set and Public Authoritative Primary(ies) Server(s) to a third party.  All
   other DNS Servers DNS Template Server, Reverse Public Authoritative Primary(ies)
   Server(s) and Reverse Public Authoritative Name Synchronization Server Set remain managed by the
   ISP.  The reason we consider that Reverse Public Authoritative Primary(ies)
   Server(s) and Reverse Public
   Authoritative Name Synchronization Server Set remains managed by the
   ISP are that the prefix is managed by the ISP, so outsourcing these
   resources requires some redirection agreement with the ISP.  More
   specifically the ISP will need to configure the redirection on one of
   its Reverse DNS Servers.  That said, outsourcing these resources is
   similar as outsourcing Public Authoritative Name Synchronization Server Set and Public
   Authoritative Primary(ies) Server(s) to a third party.  Similarly, the DNS
   Template Server can be easily outsourced as detailed in this section

   Outsourcing Public Authoritative Name Synchronization Server Set and Public Authoritative Primary(ies) Server(s)
   requires:

   - 1)  Updating the DNS Homenet Zone Template: this can be easily done as
         detailed in Section 4.3 as the DNS Template Server is still
         managed by the ISP.  Such modification can be performed once by
         any CPE.  Once this modification has been performed, the CPE
         can be changed, the Client Public Key of the CPE may be
         changed, this does not need to be done another time.  One can
         imagine a GUI on the CPE asking the end user to fill the field
         with Registered Homenet Domain, optionally Public Authoritative
         Primary(ies),
         Server(s), with a button "Configure DNS Homenet Zone Template".

   - 2)  Updating the DHCP Server Information.  In fact the Reverse
         Public Authoritative Name
         Synchronization Server Set returned by the ISP is modified.  One
         can imagine a GUI interface that enables the end user to modify
         its profile parameters.  Again, this configuration update is
         done once-for-ever.

   - 3)  Upload the authentication credential of the CPE, that is the
         Client Public Key of the CPE, to the third party.  Unless we
         use specific mechanisms, like communication between the DHCP
         Server and the third party, or a specific token that is plugged
         into the CPE, this operation is likely to be performed every
         time the CPE is changed, and every time the Client Public Key
         generated by the CPE is changed.

   The main advantage of this scenario is that the DNS infrastructure is
   completely outsourced to the third party.  Most likely the Client
   Public Key that authenticate the CPE need to be configured for every
   CPE.  Configuration is expected to be CPE live-long.

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

A.4.  Multiple ISPs

   This scenario considers a CPE connected to multiple ISPs.

   Firstly, suppose the CPE has been configured with the based scenarios
   exposed in Appendix A.1.  The CPE has multiple interfaces, one for
   each ISP, and each of these interface is configured using DHCP.  The
   CPE sends to each ISP its DHCP Client Public Key Option as well as a
   request for a DHCP Zone Template Option, a DHCP Public Authoritative Name Synchronization Server Set Option
   and a DHCP Reverse Public Authoritative Name Synchronization Server
   Set Option.  Each ISP provides the
   requested DHCP options, with different values.  Note that this
   scenario assumes, the home network has a different Registered Homenet
   Domain for each ISP as it is managed by the ISP.  On the other hand,
   the CPE Client Public Key may be shared between the CPE and the
   multiple ISPs.  The CPE builds the associate DNS(SEC) Homenet Zone,
   and proceeds to the various settings as described in Appendix A.1.

   The protocol and DHCP Options DHCPv6 options described in this document are fully
   compatible with a CPE connected to multiple ISPs with multiple
   Registered Homenet Domains.  However, the CPE should be able to
   handle different Registered Homenet Domains.  This is an
   implementation issue which is outside the scope of the current
   document.  More specifically, multiple Registered Homenet Domains
   leads to multiple DNS(SEC) Homenet Zones.  A basic implementation may
   erase the DNS(SEC) Homenet Zone that exists when it receives DHCP
   Options, DHCPv6
   options, and rebuild everything from scratch.  This will work for an
   initial configuration but comes with a few drawbacks.  First, updates
   to the DNS(SEC) Homenet Zone may only push to one of the multiple
   Registered Homenet Domain, the latest Registered Homenet Domain that
   has been set, and this is most likely expected to be almost randomly
   chosen as it may depend on the latency on each ISP network at the
   boot time.  As a results, this leads to unsynchronized Registered
   Homenet Domains.  Secondly, if the CPE handles in some ways
   resolution, only the latest Registered Homenet Domain set may be able
   to provide naming resolution in case of network disruption.

   Secondly, suppose the CPE is connected to multiple ISP with a single
   Registered Homenet Domain.  In this case, the one party is chosen to
   host the Registered Homenet Domain.  This entity may be one of the
   ISP or a third party.  Note that having multiple ISPs can be
   motivated for bandwidth aggregation, or connectivity fail-over.  In
   the case of connectivity fail-over, the fail-over concerns the access
   network and a failure of the access network may not impact the core
   network where the Public Authoritative Name Synchronization Server Set and Public Authoritative
   Primaries are hosted.  In that sense, choosing one of the ISP even in
   a scenario of multiple ISPs may make sense.  However, for sake of
   simplicity, this scenario assumes that a third party has be chosen to
   host the Registered Homenet Domain.  The DNS settings for each ISP is

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

   described in Appendix A.2 and Appendix A.3.  With the configuration
   described in Appendix A.2, the CPE is expect to be able to handle
   multiple Homenet Registered Domain, as the third party redirect to
   one of the ISPs Servers.  With the configuration described in
   Appendix A.3, DNS zone are hosted and maintained by the third party.
   A single DNS(SEC) Homenet Zone is built and maintained by the CPE.
   This latter configuration is likely to match most CPE
   implementations.

   The protocol and DHCP Options DHCPv6 options described in this document are fully
   compatible with a CPE connected to multiple ISPs.  To configure or
   not and how to configure the CPE depends on the CPE facilities.
   Appendix A.1 and Appendix A.2 require the CPE to handle multiple
   Registered Homenet Domain, whereas Appendix A.3 does not have such
   requirement.

Appendix B.  Document Change Log

   [RFC Editor: This section is to be removed before publication]

   -05: changing Master to Primary, Slave to Secondary

   -04: Working Version Major modifications are:

   - Re-structuring the draft:  description and comparison of update and
         security mechanisms
         authentication methods have been intergrated integrated into the Overview
         section. a Configuration section has been created to describe
         both configuration and corresponding behavior of the CPE.

   - Adding Ports parameters:  Server Set can configure a port.  The
         Port Server parameter have been added in the DHCP Option DHCPv6 option
         payloads because middle boxes may not be configured to let port
         53 packets and it may also be useful to split servers among
         different ports, assigning each end user a different port.

   - Multiple ISP scenario:  In order to address comments, the multiple
         ISPs scenario has been described to explicitly show that the
         protocol and DHCP Options DHCPv6 options do not prevent a CPE connected to
         multiple independent ISPs.

   -03: Working Version Major modifications are:

   - Redesigning options/scope:  according to feed backs received from
         the IETF89 presentation in the dhc WG.

   - Redesigning architecture:  according to feed backs received from
         the IETF89 presentation in the homenet WG, discussion with Mark
         and Lorenzo.

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

   -02: Working Version Major modifications are:

   - Redesigning options/scope:  As suggested by Bernie Volz

   -01: Working Version Major modifications are:

   - Remove the DNS Zone file construction:  As suggested by Bernie Volz

   - DHCPv6 Client behavior:  Following options guide lines

   - DHCPv6 Server behavior:  Following options guide lines

   -00: version published in the homenet WG.  Major modifications are:

   - Reformatting of DHCP Options: DHCPv6 options:  Following options guide lines

   - DHCPv6 Client behavior:  Following options guide lines

   - DHCPv6 Server behavior:  Following options guide lines

   -00: First version published in dhc WG.

Authors' Addresses

   Daniel Migault
   Ericsson
   8400 boulevard Decarie
   Montreal, QC H4P 2N2
   Canada

   Email: daniel.migault@ericsson.com

   Wouter Cloetens
   SoftAtHome
   vaartdijk 3 701
   3018 Wijgmaal
   Belgium

   Tomek Mrugalski
   Internet Systems Consortium, Inc.
   950 Charter Street
   Redwood City, CA  94063
   USA

   Email: wouter.cloetens@softathome.com tomasz.mrugalski@gmail.com
   URI:   http://www.isc.org

   Chris Griffiths
   Dyn
   150 Dow Street
   Manchester, NH  03101
   US

   Email: cgriffiths@dyn.com
   URI:   http://dyn.com cgriffiths@gmail.com

Internet-DrafDHCPv6 Options for Homenet Naming Architecture October 2015

   Ralf Weber
   Nominum
   2000 Seaport Blvd #400
   Redwood City, CA  94063
   US

   Email: ralf.weber@nominum.com
   URI:   http://www.nominum.com

   Wouter Cloetens
   SoftAtHome
   vaartdijk 3 701
   3018 Wijgmaal
   Belgium

   Email: wouter.cloetens@softathome.com