HOMENET
Homenet                                                       D. Migault (Ed)
Internet-Draft                                                  Ericsson
Intended status: Standards Track                                R. Weber
Expires: October 21, 2020                                         Akamai
                                                            T. Mrugalski
Expires: December 27, 2018                                           ISC
                                       Internet Systems Consortium, Inc.
                                                            C. Griffiths

                                                                R. Weber
                                                                 Nominum

                                                             W. Cloetens
                                                              SoftAtHome
                                                           June 25, 2018
                                                          April 19, 2020

      DHCPv6 Options for Homenet Home Network Authoritative Naming Architecture
         draft-ietf-homenet-naming-architecture-dhc-options-06 Service
         draft-ietf-homenet-naming-architecture-dhc-options-07

Abstract

   The Homenet Naming Authority (HNA) is the designated device in charge
   of outsourcing the service to a third party, which requires setting
   up an architecture.

   Such settings may be inappropriate for most end users.

   This document defines DHCPv6 options so any agnostic HNA 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 December 27, 2018. October 21, 2020.

Copyright Notice

   Copyright (c) 2018 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.  Requirements notation . .  Terminology . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . .   3
   3.  Introduction . . . . . .   3
   3.  Protocol Overview . . . . . . . . . . . . . . . . . .   3
   4.  Protocol Overview . . . .   4
   4.  Payload Description . . . . . . . . . . . . . . . . . .   6
     4.1.  Architecture and DHCPv6 Options Overview . . .   4
     4.1.  Client Public Key Option  . . . . .   6
     4.2.  Mechanisms Securing DNS Transactions . . . . . . . . . .   9
     4.3.  Primary / Secondary Synchronization versus DNS Update .   5
     4.2.  Distribution Master Option  .  10
   5.  HNA Configuration . . . . . . . . . . . . . .   5
     4.3.  Reverse Synchronization Server Option . . . . . . . .  11
     5.1.  HNA Primary / Secondary Synchronization Configurations .  11
       5.1.1.  HNA / Synchronization Server .   6
   5.  DHCP Behavior . . . . . . . . . . .  11
       5.1.2.  HNA / Reverse Synchronization Server . . . . . . . .  11
     5.2.  HNA DNS Data Handling and Update Policies . . . . .   7
     5.1.  DHCPv6 Server Behavior  . . .  12
       5.2.1.  Homenet Zone Template . . . . . . . . . . . . . .   7
     5.2.  DHCPv6 Client Behavior  . .  12
       5.2.2.  DNS (Reverse) Homenet Zone . . . . . . . . . . . . .  12
   6.  Payload Description . .   7
     5.3.  DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . .  13
     6.1.  Supported Authentication Methods Field . . . . . . . . .  13
     6.2.  Update Field . . . . . . . .   8
   7.  Security Considerations"  . . . . . . . . . . . . . .  14
     6.3.  Client Public Key Option . . . .   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 . . . . . . . . . .  14
     6.4.  Zone Template Option . . . . . . . . . . . . . . .   8
     7.3.  HNAs are sensitive to DoS . . .  14
     6.5.  Synchronization Server Option . . . . . . . . . . . . .   8
   8.  Acknowledgments .  15
     6.6.  Reverse Synchronization Server Option . . . . . . . . . .  16
   7.  DHCP Behavior . . . . . . . . . . . .   8
   9.  Scenarios and impact on the End User  . . . . . . . . . . . .  17
     7.1.  DHCPv6 Server Behavior   9
   10. Base Scenario . . . . . . . . . . . . . . . . .  17
     7.2.  DHCPv6 Client Behavior . . . . . . .   9
     10.1.  Third Party Registered Homenet Domain  . . . . . . . . . .  18
     7.3.  DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . .  18
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     9.1.  DNSSEC is recommended to authenticate   9
     10.2.  Third Party DNS hosted data . .  19
     9.2.  Channel between the HNA and ISP DHCP Server MUST be
           secured . . . . . . . . . . . . . . . . . . . . . . . . .  19
     9.3.  HNAs are sensitive to DoS . . . . . Infrastructure . . . . . . . . . . .  19

   10. Acknowledgments . .  10
     10.3.  Multiple ISPs  . . . . . . . . . . . . . . . . . . . . .  19  11
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19  12
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  20  12
     11.2.  Informational  Informative References . . . . . . . . . . . . . . . .  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  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27  13

1.  Requirements notation  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 [RFC2119].

2.  Terminology

   The reader is expected to be familiar
   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.
         This key is HNA
      and used as an authentication credential for the HNA.

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

2.  Introduction

   [I-D.ietf-homenet-front-end-naming-delegation] describes how Homenet Zone.

   - DNS Template Server:   The DNS server that hosts
   Naming Authority (HNA) outsources the Public Homenet Zone
         Template.

   - Homenet Reverse Zone:   The reverse zone file associated to an
   Outsourcing Infrastructure.

   In most cases the
         Homenet Zone.

3.  Introduction

   HNAs are usually constrained devices with reduced network and CPU
   capacities.  As such, a HNA hosting on setting of the Internet relation between the HNA and the authoritative
   naming service for its home network may become vulnerable to resource
   exhaustion attacks.
   Outsourcing Infrastructure is not fully automated and involves the authoritative service
   end user.  More specifically, the Outsourcing Infrastructure needs to a third
   party avoids exposing
   be able to authenticate the HNA as well as needs to such attacks.  This third party can
   be ensure the ISP or any other independent third party.

   Outsourcing HNA
   owns the authoritative naming service to Registered Homenet Domain.  As a third party
   requires setting up an architecture designated in this document as result, the Outsourcing Infrastructure.  These settings may
   Infrastructure is likely to be inappropriate
   for most end users that do not have the sufficient knowledge.  To
   address this issue, this provided by a registrar.

   This document proposes describes DHCPv6 options so any
   agnostic HNA can automatically set that leverage a relation
   between the Outsourcing Infrastructure.
   In most cases, these DHCPv6 options are sufficient ISP and do not require
   any additional interaction from the an end user, thus achieving a zero-
   config settings.  In some other cases, the user to fully automated these steps.  This
   enables an end user is expected to
   perform some limited manual configuration.

   When provide the home network configuration to the
   DHCPv6 server, so an HNA can outsource without any configuration.  In
   this case, outsourcing is achieved with zero-config and is plugged, resilient
   to HNA change.  This may provide the DHCPv6 options described in the document
   enable:

   - 1.  To build the Homenet Zone: Building ability for an ISP to provide a
   default outsourcing service to its customers, however this service
   can be used by the end user for any specific Homenet Zone requires
         filling registered
   domain, not just the zone with appropriated bindings such as bindings
         between ones provided by the names ISP and as such benefits
   the IP addresses of the different devices
         of the home networks.  How end user.

   The overall principle is that the HNA is aware of these binding is
         out of scope of advertises the document.  They may DHCPv6 server of
   its Public Key.  This Public Key will be provided, for
         example, used by the DHCPv6 server hosted on HNA for the HNA.  On
   authentication during the other
         hand, building TLS key exchange between the Homenet Zone also requires configuration
         parameters like HNA and the name
   Distribution Master (DM) of the Registered Domain Name
         associated to the home network or the Public Authoritative
         Server(s) the Homenet Zone is outsourced to.  These
         configuration parameters are stored in and the Reverse
   Homenet Zone
         Template.  This document describes Zone.  Note that a specific relation between the Zone Template Option
         which carries DHCPv6
   server and the FQDN associated to DM is required.  When the Homenet Zone Template.
         In order to retrieve DHCPv6 server is managed by
   the Homenet Zone Template, ISP, such relation exist between DHCPv6 server and the HNA sends a
         query DM of type AXFR [RFC1034], [RFC5936].

   - 2.  To upload the
   Reverse Homenet Zone to Zone.  Such relation may also exist - but not
   necessarily - between the Synchronization Server, in
         charge of publishing DHCPv6 server and the Homenet Zone on DM of the Public
         Authoritative Server(s).  This document describes the
         Synchronization Server Option that
   Homenet Zone.  The DHCHv6 server provides the HNA the FQDN and Public
   Keys of the
         appropriated server.  Note that, the respective DMs.

   This document does not consider
         whether assumes the Homenet Zone is signed or not, and if signed, which
         entity is responsible to sign it.  Such questions are out of link between the scope of HNA and the current document.

   - DHCPv6 server
   is trustworthy for example using [I-D.ietf-dhc-sedhcpv6].

3.  To upload  Protocol Overview

   This section illustrates how a HNA receives the Homenet Reverse Zone necessary information
   via DHCPv6 options to the Reverse
         Synchronization Server in charge of publishing the Homenet
         Reverse Zone outsource its authoritative naming service on
   the Reverse Public Authoritative Server(s).
         This document describes the Reverse Synchronization Server
         Option that provides Outsourcing Infrastructure.  For the FQDN sake of the appropriated server.
         Similarly to item 2., we do not consider in simplicity, this document if
   section assumes that the Homenet Reverse Zone DHCPv6 server is signed or not, and if signed who
         signs it.

   - 4.  To provide authentication credential (a public key) able to the DHCP
         Server: Information stored in the Homenet Zone Template, the
         Homenet Zone and Homenet Reverse Zone belongs communicate to the HNA,
   various DNS servers and
         only the HNA should be able to update or upload these zones.
         To authenticate the HNA, this document defines the Client
         Public Key Option.  This option is sent by provide them the HNA to public key associated
   with the
         DHCPv6 HNA.  Once each server and provides got the Client Public Key public key, the HNA uses can
   proceed to authenticate itself. transactions in an authenticated and secure way.

   This scenario has been chosen as it is believed to be the most
   popular scenario.  This document does not describe
         mechanisms used to transmit the Client Public Key from the
         DHCPv6 server to the appropriate entities.  If ignore scenarios where the DHCPv6
         server is
   DHCP Server does not able to provide the Client Public Key to have privileged relations with the
         appropriated entities, then DM.

   These cases are discussed latter in Section 9.  Such scenario does
   not necessarily require configuration for the end user and can also
   be zero-config.

   The scenario is likely to provide
         manually the as follows:

   o  1) The HNA provides its Client Public Key to these entities.  This
         document illustrates two scenarios: one where the DHCPv6 server
         is responsible for distributing the Client DHCP Server using
      a Client Public Key to Option (OPTION_PUBLIC_KEY) and includes the
         Synchronization Servers
      following option codes in its its Option Request Option (ORO): the
      Distribution Master Option (OPTION_DM) and the Reverse Synchronization Server.  In
      Distribution Master Option (OPTION_REVERSE_DM).

   o  2) The DHCP Server makes the other scenarios, Client Public Key available to the DM
      servers, so the HNA can secure its DNS transactions.  How the
      Client Public Key is distributed transmitted to the various DNS servers is out
      of band.

   The DHCPv6 options described in scope of this document make possible document.  Note that the Client Public Key alone
      is not sufficient to
   configure an Outsourcing Infrastructure perform the authentication and the key should
      be, for example, associated with no an identifier, or little
   configurations from the end user.  A zero-config setting concerned
      domain name.  How the binding is achieved
   if performed is out of scope of the
      document.  It can be a centralized database or various bindings
      may be sent to the link between different servers.

   o  3) The DHCP Server responds to the HNA and with the requested DHCPv6 server and the link
   between
      options, i.e. the DHCPv6 server Distribution Master Option (OPTION_DM) and the various DNS servers (Homenet Zone
   Server, the
      Reverse Synchronization Server, Synchronization Server)
   are trusted.  For example, one way to provide a thrustworhy
   connection between the HNA and Distribution Master Option (OPTION_REVERSE_DM).

   o  4) Once the DHCPv6 server is defined in
   [I-D.ietf-dhc-sedhcpv6].  When both links are trusted, Homenet Zone has been set, the HNA is
   able to provide its authentication credentials (a Client Public Key)
   to uploads the DHCPv6 server, that in turn forwards it zone to
      the various DNS
   servers.  With the authentication credentials on the DNS servers, respective DMs.

4.  Payload Description

   This section details the
   HNA is able to securely update.

   If payload of the DHCPv6 server cannot provide options.

4.1.  Client Public Key Option

   The Client Public Key Option (OPTION_PUBLIC_KEY) indicates the Client
   Public Key that is used to one of
   these servers (most likely the Synchronization Server) and the HNA
   needs to interact with the server, then, authenticate the end user HNA.  This option is expected to
   provide the HNA's Client
   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 to these servers (the Reverse
   Synchronization Server or Data                        /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   { #fig-public-key title="Client Public Key Option"}

   o  option-code (16 bits): OPTION_PUBLIC_KEY, the Synchronization Server) either manually
   or using other mechanisms.  Such mechanisms are outside option code for the scope
      Client Public Key Option (TBD1).

   o  option-len (16 bits): length in octets 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 option-data field as
      described in [RFC3315].

   o  Client Public Key Data: contains the end users. Client Public Key. The remaining of this document format
      is structured the DNSKEY RDATA format as follows.  Section 4 defined in [RFC4034].

4.2.  Distribution Master Option

   The Synchronization Server Option (OPTION_SYNC_SERVER) provides an overview of
   information necessary for the DHCPv6 options as well as HNA to upload the expected
   interactions between Homenet Zone to the HNA and
   Synchronization Server.  Finally, the various involved entities.  This
   section also option provides an overview of the
   authentication methods that are available mechanisms to secure perform the upload.  The
   upload is performed via a DNS transactions and update primary / secondary architecture or DNS data.  Section
   updates.

    0                   1                        2                   3
    0 1 2 3 4 5 describes how the
   HNA may securely synchronize and update DNS data.  Section 6
   describes the payload of the DHCPv6 options and Section 7 details how
   DHCPv6 client, server and 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 HNA
   may behave and be configured regarding various scenarios.

4.  Protocol Overview

   This section provides an overview of 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            |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   /                             DM FQDN                           /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   { #fig-name-srv-set title="Synchronization Server Option"}

   o  option-code (16 bits): OPTION_SYNC_SERVER, the HNA's interactions with option code for the
   Outsourcing Infrastructure
      Synchronization Server Option (TBD2).

   o  option-len (16 bits): length in Section 4.1, and so octets of the necessary for
   its setting.  In this document, option-data field as
      described in [RFC3315].

   o  Server Port (16 bits): defines the configuration is provided via
   DHCPv6 options.  Once configured, port the HNA Synchronization Server
      is expected to listening.  When multiple transport layers may be able to
   update used, a
      single and publish DNS data on unique Server Port value applies to all the different components of transport
      layers.  In the
   Outsourcing Infrastructure.  As a result authenticating case of DNS for example, Server Port value
      considers DNS exchanges using UDP and updating
   mechanisms play an important role in TCP.

   o  Synchronization Server FQDN (variable): the specification.  Section 4.2
   provides an overview FQDN of the different authentication methods and
   Section 4.3
      Synchronization Server.

4.3.  Reverse Synchronization Server Option

   The Reverse Synchronization Server Option
   (OPTION_REVERSE_SYNC_SERVER) provides an overview of the different update mechanisms
   considered to update information necessary for the DNS data.

4.1.  Architecture and DHCPv6 Options Overview

   This section illustrates how a
   HNA receives to upload the necessary information
   via DHCPv6 options Homenet Zone to outsource its authoritative naming service on the Outsourcing Infrastructure.  For Synchronization Server.  The
   option provides the sake of simplicity, this
   section assumes authentication methods that the DHCPv6 server is able are available to communicate to the
   various DNS servers and to provide them the public key associated
   with the HNA.  Once each server got the public key, the HNA can
   proceed to transactions in 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
   Synchronization Server must be considered.  These cases are discussed
   latter in Appendix A.  Such scenario does not necessarily require
   configuration for
   perform the end user and can also be zero-config. upload.  The scenario upload is represented in performed via a DNS primary /
   secondary 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_DIST_MASTER       |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Server    Port            |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   /                         Reverse DM FQDN                       /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1.

   - 1:  The HNA provides its Client Public Key to the DHCP Reverse Synchronization Server using
         a Client Public Key Option (OPTION_PUBLIC_KEY) and includes

   o  option-code (16 bits): OPTION_REVERSE_SYNC_SERVER, the
         following option codes in its its Option Request Option (ORO):
         Zone Template Option (OPTION_DNS_ZONE_TEMPLATE), code
      for the Reverse Synchronization Server Option (OPTION_SYNC_SERVER) and (TBD3).

   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.

   o  Reverse Synchronization Server Option
         (OPTION_REVERSE_SYNC_SERVER).

   - 2: FQDN (variable): The FQDN of the
      Reverse Synchronization Server.

5.  DHCP Behavior

5.1.  DHCPv6 Server makes the Client Public Key available to the
         DNS servers, so the HNA can secure its DNS transactions.  How
         the Client Public Key is transmitted to the various DNS servers
         is out of scope of this document.  Note that the Client Public
         Key alone is not sufficient to perform the authentication Behavior

   Sections 17.2.2 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 18.2 of the document.  It can be [RFC3315] govern server operation in
   regards to option assignment.  As a centralized database
         or various bindings may be sent convenience to the different servers.
         Figure 1 represents reader, we
   mention here that the server will send option foo only if configured
   with specific case where values for foo and if the client requested it.  In
   particular, when configured the DHCP Server
         forwards sends the set (Client Public Key, Zone Template FQDN) to the
         DNS Template Server, the set (Client Public Key, IPv6 subnet)
         to the
   Option, Synchronization Server Option, Reverse Synchronization Server and the set (Client
         Public Key, Registered Homenet Domain) to
   Option when requested by the Synchronization
         Server.

   - 3: DHCPv6 client by including necessary
   option codes in its ORO.

   The DHCP Server responds to the HNA with may receive a Client Public Key Option
   (OPTION_PUBLIC_KEY) from the requested HNA.  Upon receipt of this DHCPv6
         options, i.e.
   option, the DHCP Server SHOULD acknowledge the reception of the
   Client Public Key Option (OPTION_PUBLIC_KEY),
         Zone Template Option OPTION_DNS_ZONE_TEMPLATE, Synchronization
         Server Option (OPTION_SYNC_SERVER), Reverse Synchronization
         Server Option (OPTION_REVERSE_SYNC_SERVER).  Note that as described and communicate this
         step may be performed in parallel credential
   to step 2, or even before.
         In other words, there is no requirements that step 3 is
         conducted after step 2.

   - 4:  Upon receiving the Zone Template Option
         (OPTION_DNS_ZONE_TEMPLATE), the available DM and Reverse DM unless not configured to do so.

   A HNA performs an AXFR DNS query
         for the Zone Template FQDN.  The exchange is authenticated
         according to the authentication methods defined may update its Client Public Key by sending a new value in the
         Supported Authentication Methods field of the DHCP option.
         Once the HNA has retrieved
   Client Public Key Option (OPTION_PUBLIC_KEY) as this document assumes
   the DNS Zone Template, link between the HNA can
         build the Homenet Zone and the Homenet Reverse Zone.
         Eventually the HNA signs these zones.

   - 5:  Once the Homenet Reverse Zone has been set, the HNA uploads DHCP Server is considered
   authenticated and trusted.  The server SHOULD process received Client
   Public Key Option sent by the
         zone 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 Reverse Synchronization DHCP Server.  This Client Public Key
   authenticates the HNA.

   The Reverse DHCPv6 client sends a ORO with the necessary option codes: Zone
   Template Option, Synchronization Server Option (OPTION_REVERSE_SYNC_SERVER)
         provides the and Reverse
   Synchronization Server FQDN as well as Option.

   Upon receiving a DHCP option described in this document in the
         upload method, and Reply
   message, the Supported Authentication Methods
         protocol to secure HNA SHOULD publish the upload.

   - 6:  Once zone 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: * OPTION_CLIENT_KEY:
   TBD1 * OPTION_REGISTERED_DOMAIN: TBD2 * OPTION_SYNC_SERVER: TBD3 *
   OPTION_REVERSE_SYNC_SERVER: TBD4

7.  Security Considerations"

7.1.  DNSSEC is recommended to authenticate DNS hosted data

   It is recommended that the (Reverse) Homenet Zone has been set, is signed with
   DNSSEC.  The zone may be signed by the HNA uploads or by a third party.  We
   recommend the zone to be signed by the Synchronization Server.  The Synchronization Server Option
         (OPTION_SYNC_SERVER) provides the Synchronization Server FQDN
         as well as the upload method HNA, and that the authentication method to
         secure signed zone
   is uploaded.

7.2.  Channel between the upload.

        +---------------------+
        |    DHCPv6 Server    |
        +---------------------+
             ^  ^         ^
             |  |         |
           1.|  |3.       |2.
             |  |         |
             v  v         |
           +------+       |    +--------------------------------+
           |      |  4.   +--->|  DNS Template Server           |
           |      |<---------->|                                |
           |      |       |    +--------------------------------+
           | HNA  |       |
           |      |       |    +--------------------------------+
           |      | 5./6. +--->|  Reverse Synchronization       |
           |      |<---------->|  Server                        |
           |      |       |    +--------------------------------+
           |      |       |
           |      |       |    +--------------------------------+
           +------+       +--->|  Synchronization and ISP DHCP Server        |
                               |                                |
                               +--------------------------------+

                        Figure 1: Protocol Overview

   As described above, MUST be secured

   The channel MUST be secured because the HNA is likely to interact with various DNS
   content.  More specifically, the provides authentication
   credentials.  Unsecured channel may result in HNA is likely to update the:

   - Homenet Zone Template:   if impersonation
   attacks.

   The document considers that the configuration of channel between the zone may be
         changed.  This may include additional Public Authoritative
         Server(s), a different Registered Homenet Domain as HNA and the one
         initially proposed, or a redirection to another domain.

   - Homenet Reverse Zone:   every time a new device ISP
   DHCP Server is connected or
         dis-connected.

   - Homenet Zone:   every time a new device trusted.  More specifically, the HNA is connected, dis-
         connected.

   Step 2 and step 3 should be considered as independent steps authenticated
   and could
   be re-ordered.  In fact, the DHCPv6 server exchanged messages are protected.  The current document does
   not have specify how to wait for secure the channel.  [RFC3315] proposes a confirmation from DHCP
   authentication and message exchange protection, [RFC4301], [RFC7296]
   propose to secure the DNS servers channel at the Client Public Key has IP layer.

7.3.  HNAs are sensitive to DoS

   HNA have not been
   properly received, and is operational by the DNS servers. designed for handling heavy load.  The DHCP
   Server HNA are
   exposed on the Internet, and their IP address is expected to reply upon receiving publicly published
   on the Client Public Key
   Option.  The reply to Internet via 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
   not.  Debugging configurations errors or transmission error with one
   of the DNS servers is let to the HNA and 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 HNA, 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 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 HNA performs these updates in a secure manner.  There
   are multiple ways to secure a DNS transaction and this document
   considers two mechanisms: nsupdate and primary/secondary
   synchronization.  Section 4.2 describes the authentication method
   that may be use to secure the DNS transactions of the HNA.  The
   appropriate authentication methods may, for example, be chosen
   according to the level of confidentiality or the level of
   authentication requested by the HNA 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 HNA and
   the DNS servers.  This document limits its scope to 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 makes the DNS packet exchanged.

   The key issue with TSIG is that a shared secret must be negotiated
   between the HNA 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 provide means to distribute shared secret for
   example using a specific DHCPv6 option.  The only assumption made is
   that the HNA 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 HNA and the DNS server have been
   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).

   Exchanges with the DNS Template Server to retrieve the 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 prevent someone else to query
   the 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 HNA should proceed to the
   DNSSEC signature checks.  If signature check fails, it MUST reject
   the response.  If the signature check succeeds, the HNA removes all
   DNSSEC related RRsets (DNSKEY, RRSIG, NSEC* ...) before building the
   Homenet Zone.  In fact, these DNSSEC related fields are associated to
   the Homenet Zone Template and not the 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 Homenet Zone Template SHOULD be updated with DNS update as it
   contains static configuration data that is not expected to evolve
   over time.

   The Homenet Reverse Zone and the 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 than a NOTIFY,
   and they do not provide the server the opportunity to postpone the
   update.

5.  HNA Configuration

5.1.  HNA Primary / Secondary Synchronization Configurations

   The primary / secondary architecture is described in
   [I-D.ietf-homenet-front-end-naming-delegation].  The HNA hosts a
   Hidden Primary that synchronizes with a Synchronization Server or the
   Reverse Synchronization Server.

   When the HNA is plugged its IP address may be unknown to the
   secondary.  The section details how the HNA or primary 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.  HNA / Synchronization Server

   The HNA is aware of the zone to be synchronized by reading the
   Registered Homenet Domain in the Homenet Zone Template provided by
   the Zone Template Option (OPTION_DNS_ZONE_TEMPLATE).  The IP address
   of the secondary is provided by the Synchronization Server Option
   (OPTION_SYNC_SERVER).

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

   When the HNA has built its Homenet Zone, it sends a NOTIFY message to
   the 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 Synchronization Servers might consider the source
   IP address of the NOTIFY query to configure the primaries attributes.

5.1.2.  HNA / Reverse Synchronization Server

   The HNA is aware of the zone to be synchronized by looking at its
   assigned prefix.  The IP address of the secondary is provided by the
   Reverse Synchronization Server Option (OPTION_REVERSE_SYNC_SERVER).

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

5.2.  HNA DNS Data Handling and Update Policies

5.2.1.  Homenet Zone Template

   The Homenet Zone Template contains at least the related fields of the
   Public Authoritative 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 Server(s).  This default settings should provide
   the HNA the necessary pieces of information to set the homenet naming
   architecture.

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

   On the other hand, the Homenet Zone Template might also be subject to
   modification by the HNA.  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 Homenet Zone Template.  Policies that defines what is
   accepted or rejected is out of scope of this document.  However, this
   document assumes the Registered Homenet Domain is used as an index by
   the Synchronization Server, and SIG(0), TSIG are used to authenticate
   the HNA.  As a result, the Registered Homenet Domain should not be
   modified unless the Synchronization Server can handle with it.

5.2.2.  DNS (Reverse) Homenet Zone

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

   In the current document the HNA only sets a single zone that is
   associated with one single Homenet Registered Domain.  The domain
   might be assigned by the owner of the Homenet Zone Template.  This
   constraint does not prevent the HNA 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 Homenet Zone using CNAME [RFC2181],
   [RFC1034], DNAME [RFC6672] or CNAME+DNAME
   [I-D.sury-dnsext-cname-dname].

6.  Payload Description

   This section details the payload of the DHCPv6 options.  A few DHCPv6
   options are used to advertise a server the HNA may be expected to
   interact with.  Interaction may require to define update and
   authentication methods.  Update fields are shared by multiple DHCPv6
   options and are described in separate sections.  Section 6.1
   describes the Supported Authentication Method field, Section 6.2
   describes the Update field, the remaining Section 6.3, Section 6.4,
   Section 6.5, Section 6.6 describe the DHCPv6 options.

6.1.  Supported Authentication Methods Field

   The Supported Authentication Methods field of the DHCPv6 option
   represented in Figure 2 indicates the authentication method supported
   by the DNS server.  One of these mechanism MUST be chosen by the HNA
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Supported Auth. Methods    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 2: 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 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 DHCPv6 client.

   A Supported Authentication Methods field with all bits set to zero
   indicates the operation is not permitted.  The Supported
   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 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 DHCPv6 server
         and MUST be ignored by the DHCPv6 client.

6.3.  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
   defined in [I-D.ietf-dhc-sedhcpv6].

6.4.  Zone Template Option

   The Zone Template Option (OPTION_DNS_ZONE_TEMPLATE) Option indicates
   the HNA how to retrieve the Homenet Zone Template.  It provides a
   FQDN the HNA SHOULD query with a DNS query of type AXFR as well as
   the authentication methods associated to the AXFR query or the
   nsupdate queries.  Homenet Zone Template update, if permitted MUST
   use the DNS Update mechanism.

    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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Supp. Auth. Methods (axfr)    | Supp. Auth. Methods (update)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                        Zone Template FQDN                     /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 4: Zone Template Option

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

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

   - Supported Authentication Methods(axfr) (16 bits):  defines which
         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.

   - Supported Authentication Methods (16 bits):  defines which
         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 Homenet Zone Template.

6.5.  Synchronization Server Option

   The Synchronization Server Option (OPTION_SYNC_SERVER) provides
   information necessary for the HNA to upload the Homenet Zone to the
   Synchronization Server.  Finally, the option provides the
   authentication methods that are available to perform the upload.  The
   upload is performed via a DNS primary / secondary 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_SYNC_SERVER     |          option-len           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Supported Auth. Methods       |    Update     |     Server    /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /     Port      |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   /                    Synchronization Server FQDN                /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 5: Synchronization Server Option

   - option-code (16 bits):  OPTION_SYNC_SERVER, the option code for the
         Synchronization Server Option (TBD2).

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

   - Supported Authentication Methods (16 bits):  defines which
         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 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.

   - Synchronization Server FQDN (variable):  the FQDN of the
         Synchronization Server.

6.6.  Reverse Synchronization Server Option

   The Reverse Synchronization Server Option
   (OPTION_REVERSE_SYNC_SERVER) provides information necessary for the
   HNA to upload the Homenet Zone to the Synchronization Server.  The
   option provides the authentication methods that are available to
   perform the upload.  The upload is performed via a DNS primary /
   secondary 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_SYNC_SERVER   |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Supported Auth. Methods       |     Update    |   Server      /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /         Port    |                                             |
   +-+-+-+-+-+-+-+-+-+                                             |
   |                                                               |
   /                Reverse Synchronization Server FQDN            /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 6: Reverse Synchronization Server Option

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

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

   - Supported Authentication Methods (16 bits):  defines which
         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 Synchronization Server
         is listening.

   - Reverse Synchronization Server FQDN (variable):  The FQDN of 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 Zone Template
   Option, Synchronization Server Option, Reverse Synchronization Server
   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 in Section 4.1 and communicate
   this credential to the available DNS Servers like the DNS Template
   Server, the Synchronization Server and the Reverse Synchronization
   Server, 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 (see step 2 in Section 4.1),
   unless not configured to do so.

7.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 Option, Synchronization Server Option and Reverse
   Synchronization Server Option.

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

7.3.  DHCPv6 Relay Agent Behavior

   There are no additional requirements for the DHCP Relay agents.

8.  IANA Considerations

   The DHCP options detailed in this document is:

   - OPTION_DNS_ZONE_TEMPLATE:  TBD1

   - OPTION_SYNC_SERVER:  TBD2

   - OPTION_REVERSE_SYNC_SERVER:  TBD3

9.  Security Considerations

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

9.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 a DHCP
   authentication and message exchange protection, [RFC4301], [RFC7296]
   propose to secure the channel at the IP layer.

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

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

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

   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
              August 1996, <https://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,
              <https://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,
              <https://www.rfc-editor.org/info/rfc2136>.

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

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

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

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

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
              <https://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, <https://www.rfc-editor.org/info/rfc3315>.

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

   [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection Deny of Service Attacks.  The resulting outsourcing architecture
   is described in [I-D.ietf-homenet-front-end-naming-delegation].  This
   document shows how 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., outsourcing architecture can be automatically
   set.

8.  Acknowledgments

   We would like to thank Marcin Siodelski 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>.

11.2.  Informational References

   [I-D.andrews-dnsop-pd-reverse]
              Andrews, M., "Automated Delegation Bernie Volz for their
   comments on the design 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., the DHCPv6 options.  We would also like to
   thank Mark Andrews, Andrew Sullivan 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., Hunter, R., Griffiths, C., 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 W.
              Cloetens, "Outsourcing Home Network Authoritative Naming
              Service", draft-ietf-homenet-front-end-naming-
              delegation-06 (work in progress), October 2017.

   [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. for
   suggesting an appropriated terminology.

9.  Scenarios and impact on the End User

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

A.1.

10.  Base Scenario

   The base scenario is the one described in Section 4. 3.  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 Server(s) the ISP is able to build the
   Homenet Zone Template.

   The ISP manages the DNS Template Server, so it is able to load the ISP (foo), and at subscription time
   registers for example.foo as its Registered Homenet Zone Template on the DNS Template Server. 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 and the DNS Servers are managed by the ISP so the DHCP Server
   can provide authentication credentials of the HNA to enable secure
   authenticated transaction between with the HNA DM and these DNS servers.
   More specifically, credentials are provided to:

   -     Synchronization Server

   -     Reverse Synchronization Server

   -     DNS Template Server
   The HNA can update the zone using DNS update or a primary / secondary
   configuration in a secure way. 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.

A.2.

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

10.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 Synchronization
   Server and Public Authoritative Server(s) to a third party.  All
   other DNS Servers DNS Template Server, Reverse Public Authoritative
   Server(s) and Reverse Synchronization Server remain managed by the
   ISP.  The reason we consider that Reverse Public Authoritative
   Server(s) and Reverse Synchronization Server 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 Synchronization Server and Public
   Authoritative Server(s) to a third party.  Similarly, the DNS
   Template Server can be easily outsourced as detailed in this section

   Outsourcing Synchronization Server and Public Authoritative Server(s)
   requires:

   - 1)  Updating the 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 HNA.  Once this modification has been performed, the HNA
         can be changed, the Client Public Key of the HNA may be
         changed, this
   Registered Homenet Domain, and does not need want to be done another time.  One can
         imagine a GUI rely on the HNA asking
   authoritative servers provided by the end user ISP.

   In this section we limit the outsourcing to fill the field
         with Registered Homenet Domain, optionally DM and Public
   Authoritative
         Server(s), with Server(s) to a button "Configure Homenet Zone Template".

   - 2)  Updating the DHCP Server Information.  In fact the third party.  The Reverse Public
   Authoritative Server(s) and Reverse Synchronization Server returned remain
   managed by the ISP as the IP prefix is modified. managed by the ISP.

   Outsourcing DM and Public Authoritative Server(s) requires:

   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.

   - 3) once-for-
       ever.

   2.  Upload the authentication credential of the HNA, that is the
       Client Public Key of the HNA, 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
       HNA, this operation is likely to be performed every time the HNA
       is changed, and every time the Client Public Key generated by the
       HNA 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 HNA need needs to be configured for every
   HNA.  Configuration is expected to be HNA live-long.

A.4.

10.3.  Multiple ISPs

   This scenario considers a HNA connected to multiple ISPs.

   Firstly, suppose

   Suppose the HNA has been configured with the based scenarios
   exposed in Appendix A.1.  The HNA has multiple interfaces, one for
   each ISP, and each of these interface is configured using DHCP.  The
   HNA sends to each ISP its Client Public Key Option as well interfaces
   independently with each ISPS as a
   request for a Zone Template Option, a Synchronization Server Option
   and a Reverse Synchronization Server Option. described in Section 10.  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 Domain.  The HNA Client
   Public Key may be shared between the HNA and the multiple ISPs.

   The HNA builds the associate DNS(SEC) Homenet Zone,
   and proceeds to the various settings as described in Appendix A.1.

   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.  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 DHCPv6
   options, and rebuild everything from scratch.  This will work for an
   initial configuration but comes described in this document are fully
   compatible with a few drawbacks.  First, updates
   to the DNS(SEC) Homenet Zone may only push HNA connected to one of the multiple ISPs with multiple
   Registered Homenet Domain, Domains.  However, the latest HNA should be able to
   handle different Registered Homenet Domain that
   has been set, and this Domains.  This is most likely expected to be almost randomly
   chosen as it may depend on an
   implementation issue which is outside the latency on each ISP network at scope of the
   boot time.  As current
   document.

   If a results, this leads HNA is not able to unsynchronized handle multiple Registered Homenet Domains.  Secondly, if Domains,
   the HNA 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 HNA is remain 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 Synchronization 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 chosen to host the Registered Homenet Domain.  The DNS
   settings for each ISP is described in Appendix A.2 Section 10.1 and Appendix A.3. Section 10.2.
   With the configuration described in Appendix A.2, 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
   Appendix A.3, 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.
   Appendix A.1
   Section 10 and Appendix A.2 Section 10.1 require the HNA to handle multiple
   Registered Homenet Domain, whereas Appendix A.3 Section 10.2 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:

11.  References

11.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - Re-structuring the draft:  description and comparison of update and
         authentication methods have been integrated into the Overview
         section. a Configuration section has been created to describe
         both configuration concepts and corresponding behavior of the HNA.

   - Adding Ports parameters:  Server Set can configure a port.  The
         Port Server parameter have been added 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 the DHCPv6 option
         payloads because middle boxes may not be configured RFCs to let port
         53 packets Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2181]  Elz, R. 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 R. Bush, "Clarifications to explicitly show that the
         protocol 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 DHCPv6 options do not prevent a HNA connected to
         multiple independent ISPs.

   -03: Working Version Major modifications are:

   - Redesigning options/scope:  according to feed backs received from
         the IETF89 presentation in S.
              Rose, "Resource Records for the dhc WG.

   - Redesigning architecture:  according to feed backs received from DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.

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

   [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the homenet WG, discussion with Mark
              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., and Lorenzo.

   -02: Working Version Major modifications are:

   - Redesigning options/scope:  As suggested by Bernie Volz

   -01: Working T.
              Kivinen, "Internet Key Exchange Protocol 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 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 in the homenet WG.  Major modifications are:

   - Reformatting 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 DHCPv6 options:  Following options guide lines

   - DHCPv6 Client behavior:  Following options guide lines

   - DHCPv6 Server behavior:  Following options guide lines

   -00: First version published 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-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 dhc WG. progress), April 2010.

Authors' Addresses

   Daniel Migault
   Ericsson
   8400 boulevard Decarie
   Montreal,
   8275 Trans Canada Route
   Saint Laurent, QC H4P 2N2  4S 0B6
   Canada

   Email:

   EMail: daniel.migault@ericsson.com

   Ralf Weber
   Akamai

   EMail: ralf.weber@nominum.com

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

   Email:
   US

   EMail: tomasz.mrugalski@gmail.com
   URI:   http://www.isc.org
   Chris Griffiths

   Email:

   EMail: cgriffiths@gmail.com
   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:

   EMail: wouter.cloetens@softathome.com