Homenet                                                       D. Migault
Internet-Draft                                                  Ericsson
Intended status: Standards Track                                R. Weber
Expires: October 21, 2020 April 25, 2021                                           Akamai
                                                            T. Mrugalski
                                       Internet Systems Consortium, Inc.
                                                            C. Griffiths

                                                             W. Cloetens
                                                          April 19,
                                                        Deutsche Telekom
                                                        October 22, 2020

            DHCPv6 Options for Home Network Authoritative Naming Service
         draft-ietf-homenet-naming-architecture-dhc-options-07 Authority
         draft-ietf-homenet-naming-architecture-dhc-options-08

Abstract

   This document defines DHCPv6 options so any agnostic Homnet Naming
   Authority (HNA) can automatically proceed to the appropriate
   configuration and outsource the authoritative naming service for the
   home network.  In most cases, the 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 https://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 October 21, 2020. April 25, 2021.

Copyright Notice

   Copyright (c) 2020 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
   (https://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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Payload Description . . . . . . . . . . . . . . . . . . . . .   4   5
     4.1.  Client Public Key Option  . . . . . . . . . . . . . . . .   5
     4.2.  Distribution Master  Registered Homenet Domain Option  . . . . . . . . . . . . . . .   5
     4.3.  Reverse Synchronization Server  Distribution Master Option  . . . . . . . . . .   6
   5.  DHCP Behavior . . . . . . .   6
       4.3.1.  Supported Transport . . . . . . . . . . . . . . . . .   7
     5.1.  DHCPv6   6
     4.4.  Reverse Distribution Master Server Behavior  . . Option . . . . . . . .   7
   5.  DHCP Behavior . . . . . . .   7
     5.2.  DHCPv6 Client Behavior . . . . . . . . . . . . . . . . .   7
     5.3.   8
     5.1.  DHCPv6 Relay Agent Server Behavior  . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . .   8
     5.2.  DHCPv6 Client Behavior  . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations"  . . . . .
     5.3.  DHCPv6 Relay Agent Behavior . . . . . . . . . . . . .   8
     7.1.  DNSSEC is recommended to authenticate DNS hosted data . .   8
     7.2.  Channel between the HNA and ISP DHCP Server MUST be
           secured . .
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations"  . .   8
     7.3.  HNAs are sensitive to DoS . . . . . . . . . . . . . . . .   8   9
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8   9
   9.  Scenarios and impact on the End User  . .  References  . . . . . . . . . .   9
   10. Base Scenario . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . .   9
     10.1.  Third Party Registered Homenet Domain . . . . . . . . .   9
     10.2.  Third Party DNS Infrastructure . . . . .
     9.2.  Informative References  . . . . . . . .  10
     10.3.  Multiple ISPs . . . . . . . . .  10
   Appendix A.  Scenarios and impact on the End User . . . . . . . .  11
   Appendix B.  Base Scenario  . . . .  11
   11. References . . . . . . . . . . . . . . .  11
     B.1.  Third Party Registered Homenet Domain . . . . . . . . . .  12
     11.1.  Normative References  11
     B.2.  Third Party DNS Infrastructure  . . . . . . . . . . . . .  12
     B.3.  Multiple ISPs . . . . .  12
     11.2.  Informative References . . . . . . . . . . . . . . . . .  13  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The reader is expected to be familiar with
   [I-D.ietf-homenet-front-end-naming-delegation] and its terminology
   section.  This section defines terms that have not been defined in
   [I-D.ietf-homenet-front-end-naming-delegation]:

   o  Client Public Key: designates a public key generated by the HNA
      and used as an authentication credential for the HNA.

2.  Introduction

   [I-D.ietf-homenet-front-end-naming-delegation] describes how Homenet
   Naming Authority (HNA) outsources the Public Homenet Zone to an
   Outsourcing Infrastructure.

   In most cases the setting of the relation between

   This document shows how an ISP can provision automatically the HNA and the
   with an DNS Outsourcing Infrastructure is not fully automated and involves the
   end user.  More specifically, (DOI).  Most likely the Outsourcing Infrastructure needs to DOI
   will be able to authenticate - at least partly be - managed or provided by its ISP, but
   other cases may envision the ISP storing some configuration so the
   homenet becomes resilient to HNA replacement.

   The ISP delegates the home network an IP prefix it owns as well as needs to ensure
   the HNA
   owns associated reverse zone.
   The ISP is well aware of the Registered Homenet Domain.  As owner of that prefix, and as such
   becomes a result, natural candidate for hosting the Outsourcing
   Infrastructure is likely to be provided by a registrar.

   This document describes DHCPv6 options Homenet Reverse Zone -
   that leverage a relation
   between is the ISP Reverse Distribution Master (RDM) and an end user to fully automated these steps.  This
   enables an end user to provide potentially the
   Reverse Public Authoritative Servers.

   In addition, the ISP often identifies the home network configuration to the
   DHCPv6 server, so an HNA can outsource without any configuration. with a name.
   In
   this case, outsourcing most cases, the name is achieved with zero-config used by the ISP for its internal network
   management operations and is resilient
   to HNA change.  This may provide not a name the ability for an home network owner has
   registered to.  The ISP to may thus leverage such infrastructure and
   provide a
   default outsourcing service to its customers, however this service
   can be used by the end user for any homenet a specific domain name designated as per
   [I-D.ietf-homenet-front-end-naming-delegation] a Homenet registered
   domain, not just Registered
   Domain.  Similarly to the ones provided by reverse zone, the ISP is well aware of who
   owns that domain name and as such benefits may become a natural candidate for hosting
   the end user.

   The overall principle is Homenet Zone - that is the HNA advertises Distribution Master (DM) and the DHCPv6 server of
   its
   Public Key. Authoritative Servers.

   This Public Key will be used by document describes DHCPv6 options so the HNA for can advertise the
   authentication during
   ISP its identity via a Client Public Key.  The ISP internally
   associates the TLS Registered Homenet Domains with that key exchange between - that is to
   the HNA DM and RDM.  The ISP provides the
   Distribution Master (DM) of Registered Homenet Domain,
   necessary information on the DM and the RDM so the HNA can manage and
   upload the Public Homenet Zone and the Reverse Public Homenet Zone.  Note that a specific relation between the Zone as
   described in [I-D.ietf-homenet-front-end-naming-delegation].

   The use of DHCPv6
   server and the DM is required.  When the DHCPv6 server is managed by
   the ISP, such relation exist between DHCPv6 server and the DM of options makes the
   Reverse Homenet Zone.  Such relation may also exist - but not
   necessarily - between configuration completely
   transparent to the DHCPv6 server end user and the DM of the Public
   Homenet Zone.  The DHCHv6 server provides the HNA the FQDN and Public
   Keys a similar level of trust as
   the respective DMs.

   This document assumes one used to provide the IP prefix.  The link between the HNA and
   the DHCPv6 server
   is trustworthy may benefit from additional security for example by
   using [I-D.ietf-dhc-sedhcpv6].

3.  Protocol Overview

   This section illustrates how a HNA receives the necessary information
   via DHCPv6 options to outsource its authoritative naming service on to
   the Outsourcing Infrastructure. DOI.  For the sake of simplicity, and similarly to
   [I-D.ietf-homenet-front-end-naming-delegation], this section assumes
   that the HNA and the home network DHCPv6 server client are collocated on the
   CPE.  Note also that this is able to communicate to not mandatory and specific
   communications between the
   various DNS servers HNA and to provide them the public key associated
   with DHCPv6 client only are needed.
   In addition, this section assumes the HNA.  Once each server got responsible entity for the public key,
   DHCPv6 server is able to configure the HNA DM and RDM.  In our case, this
   means a Registered Homenet Domain can
   proceed be associated to transactions in an authenticated and secure way. a Client
   Public Key.

   This scenario has been chosen as it is believed to be the most
   popular scenario.  This document does not ignore scenarios where the
   DHCP Server does not have privileged relations with the DM. DM or RDM.
   These cases are discussed latter in Section 9. Appendix A.  Such scenario does scenarios do
   not necessarily require configuration for the end user and can also
   be zero-config.

   The scenario considered in this section is as follows:

   o  1)

   1.  The HNA provides is willing to outsource the Public Homenet Zone or
       Homenet Reverse Zone and configures its DHCP Client to provide
       its Client Public Key to the DHCP Server using a Client Public
       Key Option (OPTION_PUBLIC_KEY) and includes (OPTION_PUBLIC_KEY).
       In addition, it also requests the
      following option codes DHCP Client to include in its its
       Option Request Option (ORO): (ORO) the Registered Homnet Domain Option
       (OPTION_REGISTERED_DOMAIN), the Distribution Master Option (OPTION_DM)
       (OPTION_DIST_MASTER) and the Reverse Distribution Master Option (OPTION_REVERSE_DM).

   o  2)
       (OPTION_REVERSE_DIST_MASTER) option codes.

   2.  The DHCP Server makes updates as indicated by the Client Public Key available to ORO, the DM
      servers, so and RDM,
       and associate the HNA can secure its DNS transactions.  How Registered Domain with the Client Public Key is transmitted Key.

   3.  The DHCP Server responds to the various DNS servers is out
      of scope of this document.  Note that HNA with the requested DHCPv6
       options, i.e. OPTION_DIST_MASTER) and OPTION_REVERSE_DIST_MASTER.
       The DHCP 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 transmits the binding is performed is out of scope of the
      document.  It can be a centralized database or various bindings
      may be sent information to the different servers.

   o  3) HNA.

   4.  The DHCP Server responds to the HNA with the requested DHCPv6
      options, i.e. is able to get authenticated by the Distribution Master Option (OPTION_DM) DM and the
      Reverse Distribution Master Option (OPTION_REVERSE_DM).

   o  4) Once RDM.  The
       HNA builds the Homenet Zone has been set, the HNA uploads the zone to ( resp. the respective DMs. Homenet Reverse Zone) and
       proceed as described in
       [I-D.ietf-homenet-front-end-naming-delegation].

4.  Payload Description

   This section details the payload of the DHCPv6 options.

4.1.  Client Public Key Option

   The Client Public Key Option (OPTION_PUBLIC_KEY) indicates the Client
   Public Key that is used to authenticate the HNA.  This option is also
   defined in [I-D.ietf-dhc-sedhcpv6].

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

   { #fig-public-key title="Client

                    Figure 1: Client Public Key Option"} Option

   o  option-code (16 bits): OPTION_PUBLIC_KEY, the option code for the
      Client Public Key Option (TBD1).

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

   o  Client Public Key Data: contains the Client Public Key. The format
      is the DNSKEY RDATA format as defined in [RFC4034].

4.2.  Distribution Master  Registered Homenet Domain Option

   The Synchronization Server Registered Domain Option (OPTION_SYNC_SERVER) provides
   information necessary for the HNA to upload the Homenet Zone to the
   Synchronization Server.  Finally, the option provides (OPTION_REGISTERED_DOMAIN) indicates the
   authentication methods that are available
   FQDN associated to perform the upload.  The
   upload is performed via a DNS primary / secondary architecture or DNS
   updates. home network.

    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_DIST_MASTER   OPTION_REGISTERED_DOMAIN    |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Server    Port            |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   /                             DM FQDN                   Registered Homenet Domain                   /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   { #fig-name-srv-set title="Synchronization Server Option"}

                    Figure 2: Client Public Key Option

   o  option-code (16 bits): OPTION_SYNC_SERVER, OPTION_REGISTERED_DOMAIN, the option code
      for the
      Synchronization Server Option Registered Homenet Domain (TBD2).

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

   o  Server Port (16 bits): defines the port the Synchronization Server
      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.

   o  Synchronization Server FQDN (variable):  Registered Homenet Domain (varaiable): the FQDN of registered for the
      Synchronization Server.
      homenet

4.3.  Reverse Synchronization Server  Distribution Master Option

   The Reverse Synchronization Server Distributed Master Option
   (OPTION_REVERSE_SYNC_SERVER) (OPTION_DIST_MASTER) provides information necessary for the HNA
   to upload FQDN of the Homenet Zone to DM as well as the Synchronization Server.  The
   option provides transport protocol for the authentication methods that are available to
   perform
   transaction between the upload.  The upload is performed via a DNS primary /
   secondary architecture or DNS updates. HNA and the DM.

    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_DIST_MASTER       |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Server    Port     Supported Transport       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   /                         Reverse DM                   Distribution Master  FQDN                   /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: Reverse Synchronization Server 3: Distribution Master Option

   o  option-code (16 bits): OPTION_REVERSE_SYNC_SERVER, OPTION_DIST_MASTER, the option code for the Reverse Synchronization Server
      DM Option (TBD3).

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

   o  Server Port  Supported Transport (16 bits): defines the port supported transport by
      the Synchronization Server
      is listening. DM.  Each bit represents a supported transport, and a DM MAY
      indicate the support of multiple modes.  The bit for DoT MUST be
      set.

   o  Reverse Synchronization Server  Distribution Master FQDN (variable): the FQDN of the DM.

4.3.1.  Supported Transport

   The Supported Transport filed of the DHCPv6 option indicates the
   supported transport protocol.  Each bit represents a specific
   transport mechanism.  The bit sets to 1 indicates the associated
   transport protocol is supported.  The corresponding bits are assigned
   as described in Figure 4.

   Bit | Transport Protocol | Reference
   ----+--------------------+-----------
    0  | DNS over TLS       |
    1  | DNS over HTTPS     |
   2-7 | unallocated        |

                       Figure 4: Supported Protocols

4.4.  Reverse Distribution Master Server Option

   The Reverse Distribution Master Server Option
   (OPTION_REVERSE_DIST_MASTER) provides the HNA to FQDN of the DM as
   well as the transport protocol for the transaction between the HNA
   and the DM.

    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_DIST_MASTER    |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Supported Transport       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   /               Reverse Distribution Master FQDN                /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 5: Reverse Distribution Master Option

   o  option-code (16 bits): OPTION_REVERSE_DIST_MASTER, the option code
      for the Reverse Distribution Master Option (TBD4).

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

   o  Supported Transport (16 bits): defines the supported transport by
      the DM.  Each bit represents a supported transport, and a DM MAY
      indicate the support of multiple modes.  The bit for DoT MUST be
      set.

   o  Reverse Synchronization Server. Distribution Master FQDN (variable): the FQDN of the RDM.

5.  DHCP Behavior

5.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 Zone Template Registered
   Homenet Domain Option, Synchronization Server Distribution Master Option, the Reverse Synchronization Server
   Distribution Master Option when requested by the DHCPv6 client by
   including necessary option codes in its ORO.

   The DHCP Server may receive a Client Public Key Option
   (OPTION_PUBLIC_KEY) from the HNA.  Upon receipt of this DHCPv6
   option, the DHCP Server SHOULD acknowledge the reception of the
   Client Public Key Option as described and communicate this credential
   to the available DM and Reverse DM RDM unless not configured to do so.

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

5.2.  DHCPv6 Client Behavior

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

   The DHCPv6 client sends a ORO with the necessary option codes: Zone
   Template
   Registered Homenet Domain Option, Synchronization Server Option and Distribution Master Option, the
   Reverse
   Synchronization Server Distribution Master Option.

   Upon receiving a DHCP option described in this document in the Reply
   message, the HNA SHOULD publish the zone proceed as described in
   [I-D.ietf-homenet-front-end-naming-delegation].

5.3.  DHCPv6 Relay Agent Behavior

   There are no additional requirements for the DHCP Relay agents.

6.  IANA Considerations

   The DHCP options detailed in this document is: are: * OPTION_CLIENT_KEY:
   TBD1 * OPTION_REGISTERED_DOMAIN: TBD2 * OPTION_SYNC_SERVER: OPTION_DIST_MASTER: TBD3 *
   OPTION_REVERSE_SYNC_SERVER:
   OPTION_REVERSE_DIST_MASTER: TBD4

7.  Security Considerations"

7.1.  DNSSEC is recommended to authenticate DNS hosted data

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

7.2.  Channel between the HNA and ISP DHCP Server MUST be secured

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

   The document considers that the channel between the HNA and the ISP
   DHCP Server is trusted.  More specifically, the HNA is authenticated
   and the exchanged messages are protected.
   The current document does
   not specify how to secure the channel.  [RFC3315] proposes also requests a DHCP
   authentication and message exchange protection, [RFC4301], [RFC7296]
   propose to secure the channel at the IP layer.

7.3.  HNAs are sensitive to DoS

   HNA have not been designed for handling heavy load.  The HNA 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. Supported Transport Registry:

   Bit | Transport Protocol | Reference
   ----+--------------------+-----------
    0  | DNS over TLS       |
    1  | DNS over HTTPS     |
   2-7 | unallocated        |

7.  Security Considerations"

8.  Acknowledgments

   We would like to thank Marcin Siodelski and Bernie Volz for their
   comments on the design of the 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.

9.  Scenarios and impact on the End User

   This section details various scenarios  References

9.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and discuss their impact on
   the end user.

10.  Base Scenario

   The base scenario is the one described facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC2119]  Bradner, S., "Key words for use in Section 3.  It is typically
   the one of an ISP that manages the DHCP Server, and all DNS servers.

   The end user subscribes RFCs to the ISP (foo), and at subscription time
   registers for example.foo as Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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

   [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, <https://www.rfc-editor.org/info/rfc3315>.

   [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,
              <https://www.rfc-editor.org/info/rfc4034>.

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative 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-sedhcpv6]
              Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D.
              Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work
              in progress), February 2017.

   [I-D.ietf-homenet-front-end-naming-delegation]
              Migault, D., Weber, R., Richardson, M., Hunter, R.,
              Griffiths, C., and W. Cloetens, "Outsourcing Home Network
              Authoritative Naming Service", draft-ietf-homenet-front-
              end-naming-delegation-11 (work in progress), April 2020.

   [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.  This section is not normative and limits the
   description of a limited scope of scenarios that are assumed to be
   representative.  Many other scenarios may be derived from these.

Appendix B.  Base Scenario

   The base scenario is the one described in Section 3 in which an ISP
   manages the DHCP Server, the DM and RDM.

   The end user subscribes to the ISP (foo), and at subscription time
   registers for example.foo as its Registered Homenet Domain
   example.foo.

   When the HNA is plugged (at least the first time), it provides its
   Client Public Key to the DHCP Server.  In this scenario, the DHCP
   Server
   Server, DM and the DNS Servers RDM are managed by the ISP so the DHCP Server and as
   such can provide authentication credentials of the HNA to enable
   secure authenticated transaction with the DM and the Reverse DM.

   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.

10.1.

B.1.  Third Party Registered Homenet Domain

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

   This can also be achieved without any configuration. home network and
   still provides example.foo as a Registered Homenet Domain.

   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 HNA may be changed, the zone can be updated as in Section 10 Appendix B
   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 Section 10. Appendix B.  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.

10.2.

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

   In this section we limit the outsourcing to the DM and Public
   Authoritative Server(s) to a third party.  The Reverse Public
   Authoritative Server(s) and Reverse Synchronization Server the RDM remain managed by the ISP as the
   IP prefix is managed by the ISP.

   Outsourcing to a third party DM and Public Authoritative Server(s) requires: can be performed in the following
   ways:

   1.  Updating the DHCP Server Information.  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.

   2.  Upload the authentication credential configuration of the HNA, that is DM to the
       Client Public Key HNA.  In some cases,
       the provider of the HNA, to CPE hosting the third party.  Unless we use
       specific mechanisms, like communication between HNA may be the DHCP Server registrar and
       provide the third party, or a specific token that is plugged into CPE already configured.  In other cases, the
       HNA, this operation is likely to be performed every time CPE may
       request the HNA
       is changed, and every time end user to log into the Client Public Key generated by registrar to validate the
       HNA is changed.

   The main advantage
       ownership of this scenario is that the DNS infrastructure is
   completely outsourced to Registered Homenet Domain and agree on the third party.  Most likely
       necessary credentials to secure the Client
   Public Key that authenticate communication between the HNA needs to be configured for every
   HNA.  Configuration is expected to
       and the DM.  As described in
       [I-D.ietf-homenet-front-end-naming-delegation], such settings
       could be HNA live-long.

10.3. performed in an almost automatic way as to limit the
       necessary interactions with the end user.

B.3.  Multiple ISPs

   This scenario considers a HNA connected to multiple ISPs.

   Suppose the HNA has been configured each of its interfaces
   independently with each ISPS as described in Section 10. Appendix B.  Each ISP
   provides a different Registered Homenet Domain.  The HNA Client
   Public Key may be shared between the HNA and the multiple ISPs.

   The protocol and DHCPv6 options described in this document are fully
   compatible with a HNA connected to multiple ISPs with multiple
   Registered Homenet Domains.  However, the HNA should be able to
   handle different Registered Homenet Domains.  This is an
   implementation issue which is outside the scope of the current
   document.

   If a HNA is not able to handle multiple Registered Homenet Domains,
   the HNA may remain connected to multiple ISP with a single Registered
   Homenet Domain.  In this case, the one party entity 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 DM Server 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 been chosen to host the Registered
   Homenet Domain.  The DNS
   settings for each ISP is described in Section 10.1 and Section 10.2.
   With the configuration described in Section 10.1, the HNA 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 Section 10.2, DNS zone are hosted and maintained by the
   third party.  A single DNS(SEC) Homenet Zone is built and maintained
   by the HNA.  This latter configuration is likely to match most HNA
   implementations.

   The protocol and DHCPv6 options described in this document are fully
   compatible with a HNA connected to multiple ISPs.  To configure or
   not and how to configure the HNA depends on the HNA facilities.
   Section 10 and Section 10.1 require the HNA to handle multiple
   Registered Homenet Domain, whereas Section 10.2 does not have such
   requirement.

11.  References

11.1.  Normative References

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

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

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

   [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, <https://www.rfc-editor.org/info/rfc3315>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., is performed as described in
   Appendix B.1 and S.
              Rose, "Resource Records for Appendix B.2.

   With the configuration described in Appendix B.1, the HNA 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 B.2, DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.

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

   [RFC6672]  Rose, S.
   third party.  A single DNS(SEC) Homenet Zone is built and W. Wijngaards, "DNAME Redirection in maintained
   by the
              DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
              <https://www.rfc-editor.org/info/rfc6672>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., HNA.  This latter configuration is likely to match most HNA
   implementations.

   The protocol and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase DHCPv6 options described in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

11.2.  Informative References

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

   [I-D.ietf-dhc-sedhcpv6]
              Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., a HNA connected to multiple ISPs.  To configure or
   not and D.
              Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work
              in progress), February 2017.

   [I-D.ietf-homenet-front-end-naming-delegation]
              Migault, D., Weber, R., Richardson, M., Hunter, R.,
              Griffiths, C., how to configure the HNA depends on the HNA facilities.
   Appendix B and W. Cloetens, "Outsourcing Home Network
              Authoritative Naming Service", draft-ietf-homenet-front-
              end-naming-delegation-10 (work in progress), March 2020.

   [I-D.sury-dnsext-cname-dname]
              Sury, O., "CNAME+DNAME Name Redirection", draft-sury-
              dnsext-cname-dname-00 (work in progress), April 2010. Appendix B.1 require the HNA to handle multiple
   Registered Homenet Domain, whereas Appendix B.2 does not have such
   requirement.

Authors' Addresses

   Daniel Migault
   Ericsson
   8275 Trans Canada Route
   Saint Laurent, QC  4S 0B6
   Canada

   EMail: daniel.migault@ericsson.com
   Ralf Weber
   Akamai

   EMail: ralf.weber@nominum.com ralf.weber@akamai.com

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

   EMail: tomasz.mrugalski@gmail.com

   Chris Griffiths

   EMail: cgriffiths@gmail.com

   Wouter Cloetens
   Deutsche Telekom

   EMail: wouter.cloetens@softathome.com wouter.cloetens@external.telekom.de