Skip to main content

DHCP Options for Homenet Naming Architecture
draft-mglt-homenet-naming-architecture-dhc-options-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Daniel Migault , Wouter Cloetens , Chris Griffiths , Ralf Weber
Last updated 2014-02-13
Replaced by draft-ietf-homenet-naming-architecture-dhc-options, draft-ietf-homenet-naming-architecture-dhc-options, draft-ietf-homenet-naming-architecture-dhc-options, draft-ietf-homenet-naming-architecture-dhc-options
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-mglt-homenet-naming-architecture-dhc-options-01
HOMENET                                                  D. Migault (Ed)
Internet-Draft                                                    Orange
Intended status: Standards Track                             W. Cloetens
Expires: August 17, 2014                                      SoftAtHome
                                                            C. Griffiths
                                                                     Dyn
                                                                R. Weber
                                                                 Nominum
                                                       February 13, 2014

              DHCP Options for Homenet Naming Architecture
       draft-mglt-homenet-naming-architecture-dhc-options-01.txt

Abstract

   The home network naming architecture requires a complex naming
   configuration on the CPE.  This configuration MAY not be handled
   easily by the average end user.  Furthermore, such misconfiguration
   MAY result in making home network unreachable.

   This document proposes a DHCP options that provide the CPE all
   necessary parameters to set up the home network naming architecture.

   First, this DHCP options provide automatic configuration and avoid
   most end users' misconfiguration.  Most average end users may not
   require specific configuration, and their ISP default configuration
   MAY fully address their needs.  In that case, the naming homenet
   architecture configuration will be completely transparent to the end
   users.  Then, saving naming configuration outside the CPE, makes it
   resilient to change of CPE or CPE upgrades.  Such configuration may
   also be configured by the end user, via the customer area of their
   ISP.

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

Migault (Ed), et al.     Expires August 17, 2014                [Page 1]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

   This Internet-Draft will expire on August 17, 2014.

Copyright Notice

   Copyright (c) 2014 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.1.  DNS Homenet Zone Template Considerations  . . . . . . . .   6
     3.2.  DNS Homenet Zone Considerations . . . . . . . . . . . . .   7
   4.  Payload Description . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  DHCP Zone Template Option . . . . . . . . . . . . . . . .   7
     4.2.  DHCP Public Authoritative Name Server Set Option  . . . .   8
     4.3.  DHCP Reverse Public Authoritative Name Server Set Option    9
     4.4.  DHCP TSIG Public Authoritative Name Server Set Option . .  11
     4.5.  DHCP TSIG Reverse Public Authoritative Name Server Set
           Option  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.  DHCPv6 Server Behavior  . . . . . . . . . . . . . . . . . . .  12
   6.  DHCPv6 Client Behavior  . . . . . . . . . . . . . . . . . . .  12
   7.  DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . . .  13
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     9.1.  DNSSEC is recommended to authenticate DNS hosted data . .  13
     9.2.  Sending TSIG over the network is not recommended  . . . .  13
     9.3.  Channel between the CPE and ISP DHCP Server MUST be
           secured . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.4.  CPEs are sensitive to DoS . . . . . . . . . . . . . . . .  14
   10. Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . .  15
   11. Document Change Log . . . . . . . . . . . . . . . . . . . . .  15
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     12.2.  Informational References . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

Migault (Ed), et al.     Expires August 17, 2014                [Page 2]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

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) is the router providing
         connectivity to the home network.  It is configured and managed
         by the end user.  In this document, the CPE MAY also hosts
         services such as DHCPv6.  This device MAY be provided by the
         ISP.

   - 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 master / slave architecture.  The Public
         Authoritative Server MAY 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 Homenet Reverse Zone:   The reverse zone file associated to the
         DNS Homenet Zone.

   - Public Authoritative Master(s):   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
         master for the zone.

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

   - Reverse Public Authoritative Master(s):   are the visible name
         server hosting the DNS Homenet Reverse Zone.  End users'

Migault (Ed), et al.     Expires August 17, 2014                [Page 3]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

         resolutions for the Homenet Domain are sent to this server, and
         this server is a master 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 slave and the CPE acts as master.  The CPE
         sends information so the DNSSEC zone can be set and served.

3.  Introduction

   [I-D.mglt-homenet-front-end-naming-delegation] defines a homenet
   naming architecture that enables CPE to outsource their naming
   service to Public Authoritative Masters.  This document describes
   DHCP options that makes possible any CPE to configure automatically
   the homenet naming architecture.

   More specifically, when the CPE is plugged, it downloads the DNS
   Homenet Zone Template.  This template is used to generate the DNS
   Homenet Zone, for according to specific CPE configurations or to
   newly attached devices that need to be accessed from the outside
   Internet.  Finally, the CPE uploads the DNS Homenet Zone file on the
   Public Authoritative Name Server Sets that are in charge of
   publishing the zone on the Internet - on the Public Authoritative
   Master(s).  In the case, the DNS Homenet Zone is static, DNS update
   [RFC2136]  [RFC3007] might be considered.  However,
   [I-D.mglt-homenet-front-end-naming-delegation] recommends uploads is
   performed by setting a master / slave synchronization between the CPE
   and the Public Authoritative Name Server Sets, with a hidden master
   hosted by the CPE.  This is actually the way to do when data MAY be
   subject to change, and this is the alternative we consider in this
   document.

   In order to set the master / slave synchronization between the CPE
   and the Public Authoritative Name Server Sets, the CPE and the Public
   Authoritative Name Server Sets SHOULD agree on the 1) the zone to be
   synchronized, 2) the IP address used by both the CPE for the hidden
   master.  In this document we assume that synchronization is performed
   on both side on port 53.  The zone to be synchronized is the one
   associated to the Registered Homenet Domain and is mentioned in the
   DNS Homenet Zone Template.  This means the Registered Homenet Domain
   provided in the DNS Homenet Zone Template MAY not be modified by the
   CPE and MAY be known by the Public Authoritative Name Server Sets.
   Although this is not mandatory, this document assumes so.  When the
   CPE sends a NOTIFY [RFC1996] message to the Public Authoritative Name
   Server Sets reads the Registered Homenet Domain and check the NOTIFY
   is sent by the authorized master.  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 MAY consider

Migault (Ed), et al.     Expires August 17, 2014                [Page 4]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

   the source IP address of the NOTIFY query to configure the masters
   attributes.

   [QUESTION Do we have to consider different port of port 53 is fine.
   I guess it is fine.]

   Once the DNS Homenet Zone has been generated, the CPE generates the
   DNS Homenet Reverse Zone before uploading it on the Reverse Public
   Authoritative Name Server Sets.  Note that the Reverse Public Master
   can be easily derived from the IP prefix delegated to the CPE.
   However, the DNS Homenet Reverse Zone may not be sent to the Reverse
   Public Master, but instead the Reverse Public Authoritative Name
   Server Sets that are in charge of publishing the zone on the Reverse
   Public Master.

   Similarly, the CPE and the Reverse Public Authoritative Name Server
   Sets configure set a master / slave synchronization.  Note that with
   the reverse zone, the domain name is agreed by both the CPE and the
   Reverse Public Authoritative Name Server Sets.  More specifically,
   the zone is not modified by the CPE and is necessarily the one
   provided by the ISP.

   The DNS Homenet Zone Template, is provided to the CPE by the DHCP
   server via the DHCP Zone Template Option (OPTION_DNS_ZONE_TEMPLATE).
   This option contains a FQDN.  In order to download the DNS Homenet
   Zone Template, the CPE sends a DNS query with type AXFR [RFC5936].
   If this exchange needs to be protected or authenticated, TSIG
   [RFC2845], [RFC2930] or SIG(0) [RFC2931]may be used.  The DHCP Zone
   Template Option indicates which security mechanisms are supported by
   the DNS authoritative server.  Note that integrity protection may be
   performed by DNSSEC [RFC4033], [RFC4034], [RFC4035] only and may not
   require additional protections.

   The DHCP Public Authoritative Name Server Set Option
   (OPTION_NAME_SERVER_SET) provides the Public Authoritative Name
   Server Set the DNS Homenet Zone is uploaded to.  This operation
   SHOULD be done in a secure way, and this option specifies the
   supported security mechanisms used by the Public Authoritative Name
   Server (TSIG or SIG(0) [RFC3007]).

   This document considers that uploading the DNS Homenet Zone is
   performed using a master / slave architecture between the CPE and the
   Public Authoritative Name Server Set. The CPE gets the Registered
   Homenet Domain from the DNS Homenet Zone Template and the IP address
   of the Public Authoritative Name Server Set from the DHCP Public
   Authoritative Name Server Set Option (OPTION_NAME_SERVER_SET).  This
   IP address is used to send a NOTIFY query, protected with TSIG or
   SIG(0).  This identifies the Registered Homenet Domain as well as the

Migault (Ed), et al.     Expires August 17, 2014                [Page 5]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

   sender.  Then the Public Authoritative Name Server Set can finalize
   its slave configuration by considering the IP address of the NOTIFY
   query.

   Similarly, the DHCP Reverse Public Authoritative Name Server Set
   Option (OPTION_REVERSE_NAME_SERVER_SET) provides the Reverse Public
   Authoritative Name Server Set the Reverse DNS Homenet Zone is
   uploaded to.  This operation SHOULD be done in a secure way, and this
   option specifies the supported security mechanisms used by the Public
   Authoritative Name Server (TSIG or SIG(0)).

   In case TSIG is used to secure the exchanges between the CPE and the
   Public Authoritative Name Server Sets or the Reverse Public
   Authoritative Name Server Sets.  The CPE MAY request and get this
   shared secret from the DHCP Server via the DHCP TSIG Public
   Authoritative Name Server Set Option (OPTION_TSIG_NAME_SERVER_SET)
   and DHCP TSIG Reverse Public Authoritative Name Server Set Option
   (OPTION_TSIG_REVERSE_NAME_SERVER_SET).  Note that sending this
   information has significant security issues and SHOULD be done in a
   controlled and cautious way.

3.1.  DNS Homenet Zone Template Considerations

   The DNS Homenet Zone Template contains at least the related fields of
   the Public Authoritative Master(s) as well as the Homenet Registered
   Domain, that is SOA, and NS fields.  This template MAY be generated
   automatically by the owner of the DHCP Server.  For example, an ISP
   MAY provide a default Homenet Registered Domain as well as default
   Public Authoritative Master(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 MAY only use DNSSEC to enable
   integrity check.

   The DNS Homenet Zone Template MAY be subject to modification by the
   CPE.  The advantage of using the standard DNS zone format is that
   standard DNS update mechanisms [RFC2136], [RFC3007] can be used to
   perform updates.  This updates MAY 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 the Registered Homenet Domain is used as
   an index by the Public Authoritative Name Server Set, and SIG(0),
   TSIG are used to authenticate the CPE.  As a result, the Registered
   Homenet Domain MUST NOT be modified unless the Public Authoritative
   Name Server Set can handle with it.

Migault (Ed), et al.     Expires August 17, 2014                [Page 6]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

   If updates on the DNS Homenet Zone Template are considered, then they
   SHOULD be performed using an authenticated and secure channel.  This
   document lists TSIG and SIG(0) as mechanisms to secure the
   transactions.  Bootstrap mechanisms as those described in
   [I-D.andrews-dnsop-pd-reverse] for SIG(0) or using the DHCP TSIG
   Public Authoritative Name Server Set Option
   (OPTION_TSIG_NAME_SERVER_SET) as described in this document.

3.2.  DNS Homenet Zone Considerations

   The DNS Homenet Zone is 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 MAY be the exact copy
   of the DNS Homenet Zone Template.  In other cases, it MAY be
   generated from the DNS Homenet Zone Template with additional RRsets.
   In some other cases, the DNS Homenet Zone MAY 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 MAY
   be assigned by the owner of the DNS Homenet Zone Template.  This
   constrain 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].

4.  Payload Description

4.1.  DHCP Zone Template Option

   The DHCP Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option
   provides the FQDN the CPE SHOULD query with a DNS query of type AXFR.
   The option also specifies which security protocols are available on
   the authoritative server.  In addition, in order to limit the number
   of DNS resolutions, the option follows recommendations of Section 8
   of [I-D.ietf-dhc-option-guidelines] and provide an IPv6 address of
   the dns authoritative server.  In case the IPv6 address is not
   compatible with the CPE, or that the IPv6 address happens to be
   unreachable, the CPE SHOULD resolve the Zone Template FQDN using a
   resolver.

Migault (Ed), et al.     Expires August 17, 2014                [Page 7]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

    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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /              Authoritative DNS Server IP6                     /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Security      |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   /                    Zone Template FQDN                         /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Fig 1: DHCP Zone Template Option

   -  OPTION_DNS_ZONE_TEMPLATE (variable):  the option code for the DHCP
         Zone Template Option.

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

   - Authoritative DNS Server IP6 (128 bits):  the IP address the AXFR
         DNS query is sent to.

   - Security (8 bits):  defines which security protocols are supported
         by the Authoritative DNS server.  Bit 0 is set to indicate the
         AXFR query can be done with DNS without any additional security
         mechanisms.  Bit 1 is set to mention TSIG is available to
         secure the transaction.  Bit 2 is set to indicate SIG(0) is
         available to secure the DNS transaction.

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

4.2.  DHCP Public Authoritative Name Server Set Option

   The DHCP Public Authoritative Name Server Set Option
   (OPTION_NAME_SERVER_SET) provides information so the CPE can upload
   the DNS Homenet Zone to the Public Authoritative Name Server Set. In
   order to limit the number of DNS resolutions, the option follows
   recommendations of Section 8 of [I-D.ietf-dhc-option-guidelines] and
   provide an IPv6 address of the Public Authoritative Name Server Set.
   If this IPv6 cannot be used by the CPE or is unreachable, the option
   provides the FQDN of the Public Authoritative Name Server Set.
   Finally, the option provides the security mechanisms that are

Migault (Ed), et al.     Expires August 17, 2014                [Page 8]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

   available to perform the upload.  The upload is performed via a DNS
   master / slave architecture or DNS updates.

    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-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /           Public Authoritative Name Server Set IP6            /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Security      |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   /           Public Authoritative Name Server Set FQDN           /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Fig 2: DHCP Public Authoritative Name Server Set Option

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

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

   - Public Authoritative Name Server Set IP6 (128 bits):  the IP
         address of the Public Authoritative Name Server Set. The DNS
         master / slave synchronization or DNS update query is performed
         between the CPE and this IP address.

   - Security (8 bits):  defines which security protocols are supported
         by the Public Authoritative Name Server Set. Bit 0 is set to
         indicate the AXFR query can be done with DNS without any
         additional security mechanisms.  Bit 1 is set to mention TSIG
         is available to secure the transaction.  Bit 2 is set to
         indicate SIG(0) is available to secure the DNS transaction.

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

4.3.  DHCP Reverse Public Authoritative Name Server Set Option

   The DHCP Reverse Public Authoritative Name Server Set Option
   (OPTION_REVERSE_NAME_SERVER_SET) provides information so the CPE can
   upload the DNS Homenet Zone to the Public Authoritative Name Server
   Set. In order to limit the number of DNS resolutions, the option

Migault (Ed), et al.     Expires August 17, 2014                [Page 9]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

   follows recommendations of Section 8 of
   [I-D.ietf-dhc-option-guidelines] and provide an IPv6 address of the
   Public Authoritative Name Server Set. If this IPv6 cannot be used by
   the CPE or is unreachable, the option provides the FQDN of the Public
   Authoritative Name Server Set. Finally, the option provides the
   security mechanisms that are available to perform the upload.  The
   upload is performed via a DNS master / slave architecture or DNS
   updates.

    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-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /      Reverse Public Authoritative Name Server Set IP6         /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Security      |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   /      Reverse Public Authoritative Name Server Set FQDN        /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Fig 3: DHCP Reverse Public Authoritative Name Server Set Option

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

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

   - Reverse Public Authoritative Name Server Set IP6 (128 bits):  the
         IP address of the Reverse Public Authoritative Name Server Set.
         The DNS master / slave synchronization or DNS update query is
         performed between the CPE and this IP address.

   - Security (8 bits):  defines which security protocols are supported
         by the Public Authoritative Name Server Set. Bit 0 is set to
         indicate the AXFR query can be done with DNS without any
         additional security mechanisms.  Bit 1 is set to mention TSIG
         is available to secure the transaction.  Bit 2 is set to
         indicate SIG(0) is available to secure the DNS transaction.

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

Migault (Ed), et al.     Expires August 17, 2014               [Page 10]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

4.4.  DHCP TSIG Public Authoritative Name Server Set Option

   The DHCP TSIG Public Authoritative Name Server Set Option carries the
   shared secret used for TSIG with the Public Authoritative Name Server
   Set.

    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_TSIG_NAME_SERVER_SET  |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                         Shared Secret                         /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Fig 4: DHCP TSIG Public Authoritative Name Server Set Option

   - OPTION_TSIG_NAME_SERVER_SET (16 bits):  the option code for the
         DHCP TSIG Public Authoritative Name Server Set Option.

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

   - Shared Secret (variable):  the Shared Secret used for TSIG.

4.5.  DHCP TSIG Reverse Public Authoritative Name Server Set Option

   The DHCP TSIG Reverse Public Authoritative Name Server Set Option
   carries the shared secret used for TSIG with the Reverse Public
   Authoritative Name Server Set.

    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_R._TSIG_NAME_SERVER_SET|          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                         Shared Secret                         /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Fig 5: DHCP TSIG Reverse Public Authoritative Name Server
               Set Option

   - OPTION_TSIG_REVERSE_NAME_SERVER_SET (16 bits):  the option code for
         the DHCP TSIG Reverse Public Authoritative Name Server Set
         Option.

Migault (Ed), et al.     Expires August 17, 2014               [Page 11]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

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

   - Shared Secret (variable):  the Shared Secret used for TSIG.

5.  DHCPv6 Server Behavior

   The DHCP Server sends the DHCP Zone Template Option
   (OPTION_DNS_ZONE_TEMPLATE), DHCP Public Authoritative Name Server Set
   Option (OPTION_NAME_SERVER_SET), DHCP Reverse Public Authoritative
   Name Server Set Option (OPTION_REVERSE_NAME_SERVER_SET), DHCP TSIG
   Public Authoritative Name Server Set Option
   (OPTION_TSIG_NAME_SERVER_SET), DHCP TSIG Reverse Public Authoritative
   Name Server Set Option (OPTION_TSIG_REVERSE_NAME_SERVER_SET) upon
   request by the DHCP Client.

   The DHCP Server MUST NOT send DHCP a TSIG Public Authoritative Name
   Server Set Option (OPTION_TSIG_NAME_SERVER_SET) or a DHCP TSIG
   Reverse Public Authoritative Name Server Set Option
   (OPTION_TSIG_REVERSE_NAME_SERVER_SET) over a channel that is not
   trusted.

6.  DHCPv6 Client Behavior

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

   A CPE that does not use information provided by the network SHOULD
   NOT send any ORO for options described in this document.  It MAY be
   for example a CPE that uses alternate Public Authoritative Name
   Server Set. In that case it SHOULD only send the an ORO request for
   the necessary options related to the Reverse Public Authoritative
   Name Server Set. Another example is when the CPE has already up-to
   date information.

   A CPE that uses TSIG and has the Shared Secret stored on the device
   SHOULD NOT request any of the DHCP TSIG Public Authoritative Name
   Server Set Option (OPTION_TSIG_NAME_SERVER_SET) or the DHCP TSIG
   Reverse Public Authoritative Name Server Set Option
   (OPTION_TSIG_REVERSE_NAME_SERVER_SET).

   Once the CPE has the necessary information to generate the DNS
   Homenet Zone and DNS Homenet Reverse Zone, as recommended by
   [I-D.mglt-homenet-front-end-naming-delegation], it MAY set the hidden
   master that synchronizes with the Public Authoritative Name Server
   Sets and Reverse Public Authoritative Name Server Sets.
   Alternatively, for very static zones, the CPE MAY use DNS update.

Migault (Ed), et al.     Expires August 17, 2014               [Page 12]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

7.  DHCPv6 Relay Behavior

   DHCP Relay behavior are not modified by this document.

8.  IANA Considerations

   The DHCP options detailed in this document is:

   - OPTION_DNS_ZONE_TEMPLATE:  TBD

   - OPTION_NAME_SERVER_SET:  TBD

   - OPTION_REVERSE_NAME_SERVER_SET:  TBD

   - OPTION_TSIG_NAME_SERVER_SET:  TBD

   - OPTION_TSIG_REVERSE_NAME_SERVER_SET:  TBD

9.  Security Considerations

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

9.2.  Sending TSIG over the network is not recommended

   Sending a DHCP TSIG Public Authoritative Name Server Set Option
   (OPTION_TSIG_NAME_SERVER_SET) or a DHCP TSIG Reverse Public
   Authoritative Name Server Set Option
   (OPTION_TSIG_REVERSE_NAME_SERVER_SET) is generally not recommended.

   In non trusted environments, sending DHCP TSIG Options MUST NOT be
   performed.

Migault (Ed), et al.     Expires August 17, 2014               [Page 13]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

   If the DHCP Server identify the request from a device that is not
   expected to manage the DNS Homenet Zone, the DHCP TSIG Options MUST
   NOT be sent back.

   In any case, sending these options MUST NOT be systematic.  It MAY be
   performed at first boot, and then stored in the CPE.  This would
   enable to perform a leaf-of-faith security.

9.3.  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.
   Unsecured channel may result in setting the Naming Delegation with an
   non legitimate CPE.  The non legitimate CPE would then be redirected
   the DNS traffic that is intended for the legitimate CPE.  This makes
   the CPE sensitive to three types of attacks.  The first one is the
   Deny Of Service Attack, if for example DNS traffic for a lot of CPEs
   are redirected to a single CPE.  CPE are even more sensitive to this
   attack since they have been designed for low traffic.  The other type
   of traffic is the DNS traffic hijacking.  A malicious CPE may
   redirect the DNS traffic of the legitimate CPE to one of its server.
   In return, the DNS Servers would be able to provide DNS Responses and
   redirect the End Users on malicious Servers.  This is particularly
   used in Pharming Attacks.  A third attack may consists in isolating a
   Home Network by misconfiguring the Naming Delegation for example to a
   non-existing DNS Server, or with a bad DS value.

9.4.  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 by
   [I-D.mglt-homenet-front-end-naming-delegation].

Migault (Ed), et al.     Expires August 17, 2014               [Page 14]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

10.  Acknowledgment

   We would like to thank Tomasz Mrugalski, Marcin Siodelski and Bernie
   Volz for their comments on the design of the DHCP Options.

11.  Document Change Log

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

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

12.  References

12.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, August 1996.

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

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

Migault (Ed), et al.     Expires August 17, 2014               [Page 15]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, May 2000.

   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
              RR)", RFC 2930, September 2000.

   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
              SIG(0)s)", RFC 2931, September 2000.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, November 2000.

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

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

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

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

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

   [RFC5936]  Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol
              (AXFR)", RFC 5936, June 2010.

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

Migault (Ed), et al.     Expires August 17, 2014               [Page 16]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

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

   [I-D.ietf-dhc-option-guidelines]
              Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
              S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
              draft-ietf-dhc-option-guidelines-17 (work in progress),
              January 2014.

   [I-D.mglt-homenet-front-end-naming-delegation]
              Migault, D., Cloetens, W., Griffiths, C., and R. Weber,
              "IPv6 Home Network Naming Delegation", draft-mglt-homenet-
              front-end-naming-delegation-03 (work in progress), October
              2013.

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

Authors' Addresses

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

   Phone: +33 1 45 29 60 52
   Email: daniel.migault@orange.com

   Wouter Cloetens
   SoftAtHome
   vaartdijk 3 701
   3018 Wijgmaal
   Belgium

   Email: wouter.cloetens@softathome.com

Migault (Ed), et al.     Expires August 17, 2014               [Page 17]
Internet-DraftDHCP Options for Homenet Naming Architecture February 2014

   Chris Griffiths
   Dyn
   150 Dow Street
   Manchester, NH  03101
   US

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

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

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

Migault (Ed), et al.     Expires August 17, 2014               [Page 18]