Homenet Working Group                                        M. Stenberg
Internet-Draft                                                  S. Barth
Intended status: Standards Track                                S. Barth                             Independent
Expires: January 6, February 7, 2016                                     P. Pfister
                                                           Cisco Systems
                                                            July 5,
                                                          August 6, 2015

                    Home Networking Control Protocol
                       draft-ietf-homenet-hncp-07
                       draft-ietf-homenet-hncp-08

Abstract

   This document describes the Home Networking Control Protocol (HNCP),
   an extensible configuration protocol and a set of requirements for
   home network devices on top devices.  HNCP is described as a profile of and
   extension to the Distributed Node Consensus Protocol (DNCP).  It  HNCP
   enables discovery of network borders, automated configuration of
   addresses,
   naming, network borders name resolution, service discovery, and the seamless use of a any
   routing protocol. protocol which supports routing based on both source and
   destination address.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 6, February 7, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements language . .
     1.1.  Applicability . . . . . . . . . . . . . . . . . .   3
   3.  DNCP Profile  . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . .   3
   4.  Common Links . . . . . .   5
     2.1.  Requirements language . . . . . . . . . . . . . . . . . .   4
   5.  Border Discovery   6
   3.  DNCP Profile  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Autonomic Address Configuration . .   7
   4.  HNCP Versioning and Router Capabilities . . . . . . . . . . .   8
   5.  Interface Classification  . .   7
     6.1.  External Connections . . . . . . . . . . . . . . . .   9
     5.1.  Interface Categories  . .   7
       6.1.1.  External Connection TLV . . . . . . . . . . . . . . .   7
       6.1.2.  Delegated Prefix TLV .   9
     5.2.  DHCP Aided Auto-Detection . . . . . . . . . . . . . . .   8
       6.1.3.  Prefix Domain TLV .  10
     5.3.  Algorithm for Border Discovery  . . . . . . . . . . . . .  10
   6.  Autonomous Address Configuration  . . . .   9
       6.1.4.  DHCP Data TLVs . . . . . . . . . .  11
     6.1.  Common Link . . . . . . . . .  10
     6.2.  Prefix Assignment . . . . . . . . . . . . . .  11
     6.2.  External Connections  . . . . . .  11
       6.2.1.  Prefix Assignment Algorithm Parameters . . . . . . .  11
       6.2.2.  Assigned Prefix TLV . . . . .  12
     6.3.  Prefix Assignment . . . . . . . . . . . .  12
       6.2.3.  Making New Assignments . . . . . . . .  13
       6.3.1.  Prefix Assignment Algorithm Parameters  . . . . . . .  13
       6.2.4.  Applying
       6.3.2.  Making New Assignments  . . . . . . . . . . . . . . . .  14
       6.2.5.  DHCPv6-PD Excluded Prefix Support . . .  15
       6.3.3.  Applying Assignments  . . . . . . .  14
       6.2.6.  Downstream Prefix Delegation Support . . . . . . . .  15
     6.3.  Node Address Assignment .  16
       6.3.4.  DHCPv6 Prefix Delegation  . . . . . . . . . . . . . .  16
     6.4.  Node Address Assignment . .  15
     6.4.  Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . .  16
     6.5.  Special Purpose  Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . .  17
   7.  Configuration of Hosts and non-HNCP Routers . . . . . . . . .  18
     7.1.  DHCPv6 for Addressing or Configuration  . . . . . . . . .  18
     7.2.  Sending Router Advertisements . . . . . . . . . . . . . .  19
     7.3.
     7.2.  DHCPv6 for Prefix Delegation  . . . . . . . . . . . . . .  19
     7.4.
     7.3.  DHCPv4 for Addressing and Configuration . . . . . . . . .  20
     7.5.  19
     7.4.  Multicast DNS Proxy . . . . . . . . . . . . . . . . . . .  20
   8.  Naming and Service Discovery  . . . . . . . . . . . . . . . .  20
     8.1.  DNS Delegated Zone TLV
   9.  Securing Third-Party Protocols  . . . . . . . . . . . . . . .  21
   10. Type-Length-Value Objects . .  21
     8.2.  Domain Name TLV . . . . . . . . . . . . . . . .  22
     10.1.  HNCP Version TLV . . . . .  22
     8.3.  Node Name TLV . . . . . . . . . . . . . . .  22
     10.2.  External Connection TLV  . . . . . . .  23
   9.  Securing Third-Party Protocols . . . . . . . . .  23
       10.2.1.  Delegated Prefix TLV . . . . . . . . . . . . . . . .  23
   10. HNCP Versioning and Capabilities
       10.2.2.  DHCPv6 Data TLV  . . . . . . . . . . . . . .  24 . . . .  25
       10.2.3.  DHCPv4 Data TLV  . . . . . . . . . . . . . . . . . .  26
     10.3.  Assigned Prefix TLV  . . . . . . . . . . . . . . . . . .  26
     10.4.  Node Address TLV . . . . . . . . . . . . . . . . . . . .  27
     10.5.  DNS Delegated Zone TLV . . . . . . . . . . . . . . . . .  27
     10.6.  Domain Name TLV  . . . . . . . . . . . . . . . . . . . .  29
     10.7.  Node Name TLV  . . . . . . . . . . . . . . . . . . . . .  29
     10.8.  Managed PSK TLV  . . . . . . . . . . . . . . . . . . . .  30
   11. General Requirements for HNCP Routers . . . Nodes . . . . . . . . . . . . .  25  30
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  27  32
     12.1.  Border Determination .  Interface Classification . . . . . . . . . . . . . . . . .  27  32
     12.2.  Security of Unicast Traffic  . . . . . . . . . . . . . .  28  33
     12.3.  Other Protocols in the Home  . . . . . . . . . . . . . .  28  33
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29  34
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  29  35
     14.1.  Normative references . . . . . . . . . . . . . . . . . .  29  35
     14.2.  Informative references . . . . . . . . . . . . . . . . .  30  35
   Appendix A.  Changelog [RFC Editor: please remove]  . . . . . . .  31  37
   Appendix B.  Draft source [RFC Editor: please remove] . . . . . .  32  38
   Appendix C.  Implementation [RFC Editor: please remove] . . . . .  32  38
   Appendix D.  Acknowledgements . . . . . . . . . . . . . . . . . .  32  38
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33  38

1.  Introduction

   HNCP synchronizes is designed to facilitate sharing of state across a small site in order among home routers to allow
   automated network configuration.  The protocol enables use
   fulfill the needs of border
   discovery, address prefix distribution
   [I-D.ietf-homenet-prefix-assignment], naming the IPv6 homenet architecture [RFC7368], which
   assumes zero-configuration operation, multiple subnets, multiple home
   routers and other services
   across (potentially) multiple links.

   HNCP provides enough information upstream service providers
   providing (potentially) multiple prefixes to the home network.  While
   RFC7368 sets no requirements for IPv4 support, HNCP aims to support
   dual-stack mode of operation, and therefore the functionality is
   designed with that in mind.  The state is shared as TLVs among the
   routers (and potentially advanced hosts) to enable:

   o  Autonomic discovery of network borders (Section 5.3) based on DNCP
      topology.

   o  Automated portioning of prefixes delegated by the service
      providers as well as assigned prefixes to both HNCP and non-HNCP
      routers (Section 6.3) using [I-D.ietf-homenet-prefix-assignment].
      Prefixes assigned to HNCP routers are used to:

      *  Provide addresses to non-HNCP aware nodes (using SLAAC and
         DHCP).

      *  Provide space in which HNCP nodes assign their own addresses
         (Section 6.4).

   o  Internal and external name resolution, as well as multi-link
      service discovery (Section 8).

   o  Other services not defined in this document, that do need to share
      state among homenet nodes, and do not cause rapid and constant TLV
      changes (see following applicability section).

   HNCP is a routing DNCP [I-D.ietf-homenet-dncp]-based protocol to operate
   without homenet-specific extensions.  In and includes a
   DNCP profile which defines transport and synchronization details for
   sharing state across nodes defined in Section 3.  The rest of the
   document defines behavior of the services noted above, how the
   required TLVs are encoded (Section 10), as well as additional
   requirements on how HNCP nodes should behave (Section 11).

1.1.  Applicability

   While HNCP does not deal with routing protocols directly (except
   potentially informing them about internal and external interfaces if
   classification specified in Section 5.3 is used), in homenet
   environments where multiple IPv6 source-prefixes can be present,
   routing based on source and destination address is necessary
   [RFC7368].

2.  Requirements language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are  Ideally, the routing protocol is also zero-configuration
   (e.g., no need to configure identifiers or metrics) although HNCP can
   be interpreted used also with a manually configured routing protocol.

   As HNCP uses DNCP as described in RFC
   2119 [RFC2119].

3.  DNCP Profile

   HNCP is defined as a profile the actual state synchronization protocol, the
   applicability statement of DNCP [I-D.ietf-homenet-dncp] with the
   following parameters:

   o  HNCP uses UDP datagrams on port HNCP-UDP-PORT can be used here as a transport over
      link-local scoped IPv6, using unicast well; HNCP should
   not be used for any data that changes rapidly and multicast (All-Homenet-
      Routers constantly, and
   locators to find such services should be published using it instead.
   This is why the naming and service discovery (Section 8) TLVs contain
   only DNS server addresses, and no actual per-name or per-service data
   of hosts.

   HNCP group address).  Received datagrams TLVs specified within this document, in steady state, stay
   constant, with an
      IPv6 source one exception: as Delegated Prefix TLVs
   (Section 10.2.1) do contain lifetimes, they force re-publishing of
   that data every time the valid or destination address which preferred lifetimes of prefixes are
   updated (significantly).  Therefore, it is not link-local scoped
      MUST be ignored.  Unicast replies desirable for ISPs to multicast
   provide large enough valid and unicast
      messages MUST be sent preferred lifetimes to avoid
   unnecessary HNCP state churn in homes, but even given non-cooperating
   ISPs, the state churn is proportional only to the IPv6 source address and port number of
   externally received delegated prefixes and not the
      original message.  Each node MUST home network size,
   and should therefore be able to receive (and
      potentially reassemble) UDP datagrams with relatively low.

   HNCP assumes a payload certain level of at least
      4000 bytes.

   o  HNCP operates control over host configuration
   servers (e.g., DHCP [RFC2131]) on multicast-capable interfaces only. links that are managed by its
   routers.  Some HNCP routers
      MUST assign a unique 32-bit endpoint identifier functionality (such as border discovery or some
   aspects of naming) might be affected by existing DHCP servers not
   aware of the HNCP-managed network and thus might need to each interface
      for which be
   reconfigured to not result in unexpected behavior.

   While HNCP is enabled.  The value zero is reserved for
      internal purposes.  Implementations MAY use a value equivalent designed to
      the sin6_scope_id for the given interface.

   o  HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as
      described in DNCP used by (home) routers, it can also be
   used by advanced hosts that want to do, e.g., their own address
   assignment and routing.

   HNCP is link layer agnostic; if exchanged over unsecured links.  UDP a link supports IPv6 (link-local)
   multicast and unicast, HNCP will work on port
      HNCP-DTLS-PORT is it.  Trickle retransmissions
   and keep-alives will handle both packet loss and non-transitive
   connectivity, ensuring eventual convergence.

2.  Terminology

   The following terms are used for this purpose.  A node implementing HNCP
      security MUST support the DNCP Pre-Shared Key method, SHOULD
      support the as they are defined in
   [I-D.ietf-homenet-prefix-assignment]:

   o  Advertised Prefix Priority

   o  Advertised Prefix

   o  Assigned Prefix

   o  Delegated Prefix

   o  Prefix Adoption

   o  Private Link

   o  Published Assigned Prefix

   o  Applied Assigned Prefix

   o  Shared Link

   The following terms are used as they are defined in
   [I-D.ietf-homenet-dncp]:

   o  DNCP Certificate Based Trust Consensus and MAY support
      the PKI-based trust method. profile

   o  HNCP uses opaque 32-bit  Node identifier

   o  Link

   o  Interface
   (HNCP) node identifiers
      (DNCP_NODE_IDENTIFIER_LENGTH = 32).       A node device implementing HNCP
      SHOULD generate this specification.
   (HNCP) router     A device implementing this specification, which
                     forwards traffic on behalf of other devices.
   Border            separation point between administrative domains; in
                     this case, between the home network and use any other
                     network, i.e., usually an ISP network.

   Internal link     a random node identifier.  If using link that does not cross borders.
   Internal          an interface that is connected to an internal link.
   interface

   External          an interface that is connected to a
      random node identifier and there link which is
   interface         not an internal link.

   Interface         a node identifier collision, local configuration denoting the node MUST immediately generate and use of a new random node
      identifier which is not used by any other node.

   o  HNCP nodes MUST ignore all Node State TLVs received via multicast
      on
   category          particular interface.  The interface category
                     determines how a link which has DNCP security enabled in order to prevent
      spoofing of node state changes.

   o HNCP nodes use the following Trickle parameters:

      *  k SHOULD be 1, as node should treat the timer reset when data is updated
                     particular interface.  External and
         further retransmissions should handle packet loss.

      *  Imin SHOULD be 200 milliseconds but MUST NOT be lower.  Note:
         Earliest transmissions may occur at Imin / 2.

      *  Imax SHOULD be 7 doublings of Imin (i.e. 25.6 seconds) but MUST
         NOT be lower.

   o  HNCP nodes MUST use internal
                     category mark the leading 64 bits of MD5 [RFC1321] interface as DNCP
      non-cryptographic hash function H(x).

   o  HNCP nodes MUST use DNCP's keep-alive extension on all endpoints.
      The following parameters are suggested:

      *  Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20
         seconds.

      *  Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1.

4.  Common Links

   HNCP uses out of or within the concept
                     network border; there are also a number of Common Links sub-
                     categories to internal that further affect local
                     node behavior.  See Section 5.1 for some a list of its applications.
   A
                     interface categories and how they behave.  The
                     internal or external categories may also be auto-
                     detected (Section 5.3).

   Border router     a router announcing external connectivity and
                     forwarding traffic across the network border.

   Common Link usually refers to       a set of nodes on a link layer broadcast domain with
   certain properties and is used, e.g., to determine where prefixes
   should be assigned or which neighboring nodes participate in the
   election of share a DHCP(v6) server.  The Common Link is computed
   separately for common view
                     of it, i.e., they see each local interface, other's traffic and it always contains the local
   interface.  Additionally, if the local interface
                     same set of hosts.  Unless configured otherwise
                     transitive connectivity is not assumed.

   DHCPv4            refers to Dynamic Host Configuration Protocol
                     [RFC2131] in ad-hoc
   mode, it also contains this document.
   DHCPv6            refers to Dynamic Host Configuration Protocol for
                     IPv6 (DHCPv6) [RFC3315] in this document.
   DHCP              refers to cases which apply to both DHCPv4 and
                     DHCPv6 in this document.

2.1.  Requirements language

   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 RFC
   2119 [RFC2119].

3.  DNCP Profile

   The DNCP profile of HNCP is defined as follows:

   o  HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport over
      link-local scoped IPv6, using unicast and multicast (All-Homenet-
      Nodes is the set HNCP group address).  Received datagrams where either
      or both of interfaces that are bidirectionally
   reachable from the given IPv6 source or destination address is not link-
      local interface, i.e. every remote interface scoped MUST be ignored.  Replies to multicast and unicast
      messages MUST be sent to the IPv6 source address and port of a remote the
      original message.  Each node meeting all MUST be able to receive (and
      potentially reassemble) UDP datagrams with a payload of the following requirements: at least
      4000 bytes.

   o  The local node publishes  HNCP operates on multicast-capable interfaces only.  HNCP nodes
      MUST assign a Neighbor TLV with:

      *  Neighbor Node Identifier = remote node's node identifier

      *  Neighbor Endpoint Identifier = remote interface's endpoint
         identifier

      *  Endpoint Identifier = local interface's locally unique non-zero 32-bit endpoint identifier

   o
      to each interface for which HNCP is enabled.  The remote node publishes value zero it is
      not used in DNCP TLVs, but it has a Neighbor TLV with:

      *  Neighbor Node Identifier = local node's node identifier

      *  Neighbor Endpoint Identifier = local interface's endpoint
         identifier

      *  Endpoint Identifier = remote interface's endpoint identifier

   A node MUST be able to detect whether two of its local interfaces are
   connected, e.g. by detecting an identical remote interface being part
   of the Common Links of both local interfaces.

5.  Border Discovery special meaning in HNCP router's interfaces are either internal, external or of TLVs
      (see Section 10.3 and Section 6.4).  Implementations MAY use a
   different category derived from the internal one.  This section
   defines
      value equivalent to the border discovery algorithm.  It is suitable for both IPv4
   and IPv6 (single or dual-stack) and determines whether an link-local scope identifier for the
      given interface.

   o  HNCP
   interface is internal, external, or uses another fixed category.  The
   algorithm opaque 32-bit node identifiers
      (DNCP_NODE_IDENTIFIER_LENGTH = 32).  A node implementing HNCP
      SHOULD use a random node identifier.  If there is derived from the edge router interactions described a node
      identifier collision (as specified in the Basic Requirements for IPv6 Customer Edge Routers [RFC7084].
   This algorithm Node State TLV handling
      of Section 4.4 of [I-D.ietf-homenet-dncp]), the node MUST be implemented
      immediately generate and use a new random node identifier which is
      not used by any router implementing HNCP.

   The border discovery auto-detection algorithm works as follows, with
   evaluation stopping other node at first match:

   1.  If a fixed category is configured for the interface, it MUST be
       used.

   2.  If a delegated prefix could be acquired by running a DHCPv6
       client time, based on the interface, it current DNCP
      network state.

   o  HNCP nodes MUST be considered external.

   3.  If an IPv4 address could be acquired by running a DHCPv4 client
       on the interface it MUST be considered external.

   4.  Otherwise use the interface MUST be considered internal.

   In order to avoid conflicts between border discovery and leading 64 bits of MD5 [RFC1321] as DNCP
      non-cryptographic hash function H(x).

   o  HNCP routers
   running DHCPv4 [RFC2131] or DHCPv6-PD [RFC3633] servers, each router nodes MUST implement the following mechanism based use DNCP's per-endpoint keep-alive extension on
      all endpoints.  The User Class Option following parameters are suggested:

      *  Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20
         seconds.

      *  Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1 on virtually
         lossless links works fine as it allows for DHCPv4 [RFC3004] and its DHCPv6 counterpart [RFC3315]:

   o  An HNCP router running a DHCP client one lost keep-alive.
         If used on an HNCP interface MUST
      include a DHCP User-Class consisting of the ASCII-String
      "HOMENET".

   o  An HNCP router running a DHCP server on lossy link, considerably higher multiplier, such
         as 15, should be used instead.  In that case, an HNCP interface MUST
      ignore or reject DHCP-Requests containing a DHCP User-Class
      consisting of the ASCII-String "HOMENET".

   A router MUST allow setting a category of either auto-detected,
   internal or external for each interface implementation
         might prefer shorter keep-alive intervals on that link as well
         to ensure that DNCP_KEEPALIVE_INTERVAL *
         DNCP_KEEPALIVE_MULTIPLIER timeout after which (entirely) lost
         nodes time out is suitable for both
   internal and external connections.  In addition low enough.

   o  HNCP nodes use the following
   specializations of the internal category are defined to modify Trickle parameters for the
   local router behavior:

   Leaf category:  This declares an interface used by client devices
      only.  Such an interface acts as an internal per-
      interface with the
      exception that HNCP or routing protocol traffic MUST NOT Trickle instances:

      *  k SHOULD be sent
      on 1, as the interface, timer reset when data is updated and all such traffic received
         further retransmissions should handle packet loss.  Even on a
         non-transitive lossy link, the interface eventual per-endpoint keep-
         alives should ensure status synchronization occurs.

      *  Imin SHOULD be 200 milliseconds but MUST NOT be ignored.  This category lower.  Note:
         Earliest transmissions may occur at Imin / 2.

      *  Imax SHOULD be supported.

   Guest category:  This declares an interface used by untrusted client
      devices only.  In addition to the restrictions 7 doublings of the Leaf
      category, HNCP routers Imin (i.e., 25.6 seconds) but
         MUST enable firewalling rules such that
      connected devices are unable to reach other devices inside the NOT be lower.

   o  HNCP network or query services advertised by them unless
      explicitly allowed.  This category unicast traffic SHOULD be supported.

   Ad-hoc category:  This configures an interface to be ad-hoc
      (Section 4).  Ad-hoc interfaces are considered internal but no
      assumption is made secured using DTLS [RFC6347] as
      described in DNCP if exchanged over unsecured links.  UDP on the the link transitivity properties.
      Support port
      HNCP-DTLS-PORT is used for this category is OPTIONAL.

   Hybrid category:  This declares an interface to be internal while
      still running DHCPv4 purpose.  A node implementing HNCP
      security MUST support the DNCP Pre-Shared Key method, SHOULD
      support the DNCP Certificate Based Trust Consensus and DHCPv6-PD clients on it.  It is assumed
      that MAY support
      the link is under control of PKI-based trust method.

   o  HNCP nodes MUST ignore all Node State TLVs received via multicast
      on a legacy, trustworthy non-HNCP
      router, still within the same network.  Detection of this category
      automatically link which has DNCP security enabled in addition order to manual configuration is out prevent
      spoofing of scope node state changes.

4.  HNCP Versioning and Router Capabilities

   Multiple versions of this document.  Support for this category is OPTIONAL.

   Each router MUST continuously scan each active interface that does
   not have a fixed category HNCP based on compatible DNCP profiles may be
   present in order to dynamically reclassify it if
   necessary.  The router therefore runs an appropriately configured
   DHCPv4 and DHCPv6 client as long as the interface is active including
   states where same network when transitioning between HNCP versions
   and for troubleshooting purposes it considers the interface to might be internal.  The router
   SHOULD wait for a reasonable time period (5 seconds as a default),
   during which beneficial to identify
   the DHCP clients can acquire a lease, before treating HNCP agent version running.  Therefore each node MUST include an
   HNCP-Version TLV (Section 10.1) in its Node Data and MUST ignore
   (except for DNCP synchronization purposes) any TLVs with a
   newly activated type
   greater than 32 published by nodes not also publishing an HNCP-
   Version TLV or previously external interface as internal.  Once
   it treats publishing such a certain interface as internal it MUST start forwarding
   traffic TLV with appropriate source addresses between its internal
   interfaces a different Version.

   HNCP routers may also have different capabilities regarding
   interactions with hosts, e.g., for configuration or service
   discovery.  These are indicated by M, P, H and allow internal traffic to reach external networks
   according to the routes it publishes.  Once L values.  The
   combined "capability value" is a router detects metric indicated by interpreting the
   bits as an
   interface transitioning integer, i.e., (M << 12 | P << 8 | H << 4 | L).  These
   values are used to external it elect certain servers on a Common Link, as
   described in Section 7.  Nodes that are not routers MUST stop any previously
   enabled internal forwarding.  In addition it SHOULD announce the
   acquired information
   value 0 for use all capabilities and therefore do not take part in these
   elections.

5.  Interface Classification

5.1.  Interface Categories

   HNCP specifies the following categories interfaces can be configured
   to be in:

   Internal category:  This declares an interfaces to be internal, i.e.,
      within the borders of the HNCP network.  HNCP traffic MUST be sent
      and received.  Routers MUST forward traffic with appropriate
      source addresses between their internal interfaces and allow
      internal traffic to reach external networks.  All nodes MUST
      implement this category and nodes not implementing any other
      category implicitly use it as a fixed default.

   External category:  This declares an interface to be external, i.e.,
      not within the borders of the HNCP network.  HNCP traffic MUST
      neither be sent nor received.  HNCP routers SHOULD announce
      acquired configuration information for use in the network as
      described in later
   sections of this draft Section 6.2, if the interface appears to be connected
      to an external network.

6.  Autonomic Address Configuration

   This section specifies how  HNCP routers configure host and router
   addresses.  At first border routers share information obtained from
   service providers or local configuration by publishing one or more
   External Connection TLVs.  These contain other TLVs such as Delegated
   Prefix TLVs which are then MUST implement this
      category.

   Leaf category:  This declares an interface used for prefix assignment.  Finally, by client devices
      only.  Such an interface uses the Internal category with the
      exception that HNCP
   routers obtain addresses either statelessly or using a specific
   stateful mechanism and hosts traffic MUST NOT be sent on the interface, and legacy routers are configured using
   SLAAC or DHCP.

   In
      all TLVs specified in this section which include a prefix, IPv4
   prefixes are encoded using the IPv4-mapped IPv6 addresses format
   [RFC4291].  The prefix length of such IPv4 prefix is set to 96 plus traffic received on the IPv4 prefix length.

6.1.  External Connections

   Each interface MUST be ignored.  This
      category SHOULD be supported by HNCP router MAY obtain external connection information routers.

   Guest category:  This declares an interface used by untrusted client
      devices only.  In addition to the restrictions of the Leaf
      category, HNCP routers MUST filter traffic from one
   or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] and to the
      interface such that connected devices are unable to reach other
      devices inside the HNCP network or
   static configuration. query services advertised by
      them unless explicitly allowed.  This section specifies how such information category SHOULD be supported
      by HNCP routers.

   Ad-hoc category:  This configures an interface to use the Internal
      category but no assumption is
   encoded and advertised.

6.1.1.  External Connection TLV

   An External Connection TLV made about the the link's
      transitivity.  All other interface categories assume transitive
      connectivity.  This affects the Common Link (Section 6.1)
      definition.  Support for this category is a container-TLV used OPTIONAL.

   Hybrid category:  This declares an interface to gather network use the Internal
      category while still trying to acquire (external) configuration
      information associated on it, e.g., by running DHCP clients.  This is useful,
      e.g., if the link is shared with a single external
   connection.  A node MAY publish an arbitrary number non-HNCP router under control
      and still within the borders of instances the same network.  Detection of
      this TLV.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type: EXTERNAL-CONNECTION (33)|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Nested TLVs                          |

   The External Connection TLV category automatically in addition to manual configuration is a container which:

   o  MAY contain an arbitrary number
      out of Delegated Prefix TLVs. scope of this document.  Support for this category is
      OPTIONAL.

5.2.  DHCP Aided Auto-Detection

   Auto-detection of interface categories is possible based on
   interaction with DHCPv4 [RFC2131] and DHCPv6-PD [RFC3633] servers on
   connected links.  HNCP defines special DHCP behavior to differentiate
   its internal servers from external ones in order to achieve this.
   Therefore all internal devices (including HNCP nodes) running DHCP
   servers on links where auto-detection is used by any HNCP node MUST
   use the following mechanism based on The User Class Option for DHCPv4
   [RFC3004] and its DHCPv6 counterpart [RFC3315]:

   o  The device MUST NOT contain multiple Delegated Prefix TLVs with identical ignore or
      overlapping prefixes.  In such reject DHCP-Requests containing a situation, DHCP
      User-Class consisting of the External
      Connection TLV MUST ASCII-String "HOMENET".

   Not following this rule (e.g., running unmodified DHCP servers) might
   lead to false positives when auto-detection is used, i.e., HNCP nodes
   assume an interface to not be ignored.

   o  MAY contain at most one DHCPv6 Data TLV internal, even though it was intended
   to be.

5.3.  Algorithm for Border Discovery

   This section defines the interface classification algorithm.  It is
   suitable for both IPv4 and at most one DHCPv4
      Data TLV encoding options associated with IPv6 (single or dual-stack) and detects
   the External Connection
      but MUST NOT contain more than one category of each otherwise an interface either automatically or based on a fixed
   configuration.  By determining the External
      Connection TLV MUST be ignored.

   o  MAY contain other TLVs category for future use.  Such additional TLVs MUST
      be ignored.

6.1.2.  Delegated Prefix TLV

   The Delegated Prefix TLV is used by HNCP routers to advertise
   prefixes which all interfaces, the
   network borders are allocated implicitly defined, i.e., all interfaces not
   belonging to the whole network and will External category are considered to be used
   for prefix assignment.  Any Delegated Prefix TLV MUST be nested in an
   External Connection TLV.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type: DELEGATED-PREFIX (34)  |          Length: >= 9         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Valid Lifetime                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Preferred Lifetime                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |                                               |
   +-+-+-+-+-+-+-+-+            Prefix [+ nested TLVs]             +
   |                                                               |

   Valid Lifetime:   The time in seconds the delegated prefix is valid.
      The value is relative to within the point in time
   borders of the Node-Data TLV was
      last published.  It network, all others are not.

   The following algorithm MUST be updated whenever implemented by any node implementing
   HNCP.  However, if the node republishes
      its Node-Data TLV.

   Preferred Lifetime:   The time in seconds does not implement auto-detection, only
   the first step is required.  The algorithm works as follows, with
   evaluation stopping at first match:

   1.  If a fixed category is configured for an interface, it is used.

   2.  If a delegated prefix could be acquired by running a DHCPv6
       client, it is
      preferred. considered external.  The value is relative to DHCPv6 client MUST have
       included a DHCPv6 User-Class consisting of the point ASCII-String
       "HOMENET" in time the Node-
      Data TLV was last published.  It MUST all of its requests.

   3.  If an IPv4 address could be updated whenever acquired by running a DHCPv4 client
       on the node
      republishes its Node-Data TLV.

   Prefix Length: interface, it is considered external.  The number DHCPv4 client
       MUST have included a DHCP User-Class consisting of significant bits in the Prefix.

   Prefix:   Significant bits ASCII-
       String "HOMENET" in all of its requests.

   4.  The interface is considered internal.

   Note that as other HNCP nodes will ignore the prefix padded with zeroes up to the
      next byte boundary.

   Nested TLVs:  Other TLVs included in the Delegated Prefix TLV and
      starting at the next 32-bit boundary following the end of client due to the
      encoded prefix:

      *  Zero or more Prefix Domain TLVs.  In absence of user
   class option, any such TLV
         the prefix server that replies is assumed to clearly external (or a
   malicious internal node).

   An HNCP router SHOULD allow setting the fixed category for each
   interface which may be generated by connected to either an HNCP-router and for internal use only.

      *  If the encoded prefix represents or external
   device (e.g., an IPv6 prefix, at most one
         DHCPv6 Data TLV MAY Ethernet port that can be included, and any included DHCPv4 Data
         TLV connected to a modem,
   another HNCP router or a client).

   An HNCP router using auto-detection on an interface MUST be ignored.

      *  If run the prefix represents an IPv4 prefix (encoded
   appropriately configured DHCP clients as long as an
         IPv4-mapped IPv6 prefix), at most one DHCPv4 Data TLV MAY be
         included, and any included DHCPv6 Data TLV MUST be ignored.

      *  It MAY contain other TLVs for future use.  Such additional TLVs
         MUST be ignored.

6.1.3.  Prefix Domain TLV

   The Prefix Domain TLV contains information about the origin and
   applicability of interface
   without a delegated prefix.  This information can be used fixed category is active (including states where auto-
   detection considers it to
   determine whether prefixes for a certain domain (e.g. local
   reachability, internet connectivity) do exist or should be acquired internal) and rerun the algorithm above
   to make decisions about assigning prefixes to certain links or react to
   fine-tune border firewalls.  See Section 6.5 conditions resulting in a different interface category.
   The router SHOULD wait for a more in-depth
   discussion.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: PREFIX-DOMAIN (43)   |          Length: >= 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Domain Type  |                                               |
   +-+-+-+-+-+-+-+-+                    Value                      +
   |                                                               |
   Domain Type:   The type of the domain identifier.

      0      :  Internet connectivity (no Value).

      1-128  :  Explicit destination prefix with the Domain Type being
         the actual length of the prefix (Value contains significant
         bits of the destination prefix padded with zeroes up to the
         next byte boundary).

      129    :  DNS Zone (Value contains an RFC 1035 [RFC1035] encoded
         DNS label sequence).

      130    :  Opaque UTF-8 string (e.g. for administrative purposes).

      131-255:  Reserved for future additions.

   Value:   A variable length identifier of the given type.

6.1.4.  DHCP Data TLVs

   Auxiliary connectivity information is encoded reasonable time period (5 seconds as a stream of
   default), during which the DHCP
   options.  Such TLVs MUST only be present in an External Connection
   TLV or clients can acquire a Delegated Prefix TLV.  When included in an lease, before
   treating a newly activated or previously external interface as
   internal.

6.  Autonomous Address Configuration

   This section specifies how HNCP nodes configure host and node
   addresses.  At first border routers share information obtained from
   service providers or local configuration by publishing one or more
   External Connection TLV, they MUST TLVs (Section 10.2).  These contain DHCP options which are relevant to
   the whole External Connection.  When included in a other TLVs
   such as Delegated Prefix,
   they MUST contain DHCP options Prefix TLVs (Section 10.2.1) which are specific to the Delegated
   Prefix. then used
   for prefix assignment.  Finally, HNCP nodes obtain addresses either
   statelessly or using a specific stateful mechanism (Section 6.4).
   Hosts and non-HNCP routers are configured using SLAAC, DHCP or
   DHCPv6-PD.

6.1.  Common Link

   HNCP uses the concept of Common Link both in autonomic address
   configuration and naming and service discovery (Section 8).  A Common
   Link refers to the set of interfaces of nodes that see each other's
   traffic and presumably also the traffic of all hosts that may use the
   nodes to, e.g., forward traffic.  Common Links are used, e.g., to
   determine where prefixes should be assigned or which peers
   participate in the election of a DHCP server.  The Common Link is
   computed separately for each local internal interface, and it always
   contains the local interface.  Additionally, if the local interface
   is not set to ad-hoc category (see Section 5.1), it also contains the
   set of interfaces that are bidirectionally reachable from the given
   local interface, that is, every remote interface of a remote node
   meeting all of the following requirements:

   o  The local node publishes a Peer TLV with:

      *  Peer Node Identifier = remote node's node identifier

      *  Peer Endpoint Identifier = remote interface's endpoint
         identifier

      *  Endpoint Identifier = local interface's endpoint identifier

   o  The remote node publishes a Peer TLV with:

      *  Peer Node Identifier = local node's node identifier

      *  Peer Endpoint Identifier = local interface's endpoint
         identifier

      *  Endpoint Identifier = remote interface's endpoint identifier

   A node MUST be able to detect whether two of its local internal
   interfaces are connected, e.g., by detecting an identical remote
   interface being part of the Common Links of both local interfaces.

6.2.  External Connections

   Each HNCP router MAY obtain external connection information such as
   address prefixes, DNS server addresses and DNS search paths from one
   or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or
   static configuration.  Each individual external connection to be
   shared in the network is represented by one External Connection TLV
   (Section 10.2).

   Announcements of individual external connections may consist of the
   following components:

   Delegated Prefixes:   address space available for assignment to
      internal links announced using Delegated Prefix TLVs
      (Section 10.2.1).  Some address spaces might have special
      properties which are necessary to understand in order to handle
      them (e.g., information similar to [RFC6603]).  This information
      is encoded using DHCPv6 Data TLVs (Section 10.2.2) inside the
      respective Delegated Prefix TLVs.

   Auxiliary Information:   information about services such as DNS or
      time synchronization regularly used by hosts in addition to
      addressing and routing information.  This information is encoded
      using DHCPv6 Data TLVs (Section 10.2.2) and DHCPv4 Data TLVs
      (Section 10.2.3).

   Whenever information about reserved parts (e.g., as specified in
   [RFC6603]) is received for a delegated prefix, the reserved parts
   MUST be advertised using Assigned Prefix TLVs (Section 10.3) with the
   highest priority (i.e., 15), as if they were assigned to a Private
   Link.

   Some connections or delegated prefixes may have a special meaning and
   are not regularly used for internal or internet connectivity, instead
   they may provide access to special services like VPNs, sensor
   networks, VoIP, IPTV, etc.  Care must be taken that these prefixes
   are properly integrated and dealt with in the network, in order to
   avoid breaking connectivity for devices who are not aware of their
   special characteristics or to only selectively allow certain devices
   to use them.  Such prefixes are distinguished using Prefix Policy
   TLVs (Section 10.2.1.1).  Their contents MAY be partly opaque to HNCP
   nodes, and their identification and usage depends on local policy.
   However the following general rules MUST be adhered to:

      Special rules apply when making address assignments for prefixes
      with Prefix Policy TLVs with type 131, as described in
      Section 6.3.2

      In presence of any type 1 to 128 Prefix Policy TLV the prefix is
      specialized to reach destinations denoted by any such Prefix
      Policy TLV, i.e., in absence of a type 0 Prefix Policy TLV it is
      not usable for general internet connectivity.  An HNCP router MAY
      enforce this restriction with appropriate packet filter rules.

6.3.  Prefix Assignment

   HNCP uses the Prefix Assignment Algorithm
   [I-D.ietf-homenet-prefix-assignment] in order to assign prefixes to
   HNCP internal links and uses some of the terminology (Section 2)
   defined there.  HNCP furthermore defines the Assigned Prefix TLV
   (Section 10.3) which MUST be used to announce Published Assigned
   Prefixes.

6.3.1.  Prefix Assignment Algorithm Parameters

   All HNCP nodes running the prefix assignment algorithm use the
   following values for its parameters:

   Node IDs:   HNCP node identifiers are used.  The comparison operation
      is defined as bit-wise comparison.

   Set of Delegated Prefixes:   The set of prefixes encoded in Delegated
      Prefix TLVs which are not strictly included in prefixes encoded in
      other Delegated Prefix TLVs.  Note that Delegated Prefix TLVs
      included in ignored External Connection TLVs are not considered.
      It is dynamically updated as Delegated Prefix TLVs are added or
      removed.

   Set of Shared Links:   The set of Common Links associated with
      interfaces with internal, leaf, guest or ad-hoc category.  It is
      dynamically updated as interfaces are added, removed, or switch
      from one category to another.  When multiple interfaces are
      detected as belonging to the same Common Link, prefix assignment
      is disabled on all of these interfaces except one.

   Set of Private Links:   This document defines Private Links
      representing DHCPv6-PD clients or as a mean to advertise prefixes
      included in the DHCPv6 Data TLV uses Exclude Prefix option.  Other
      implementation-specific Private Links may be defined whenever a
      prefix needs to be assigned for a purpose that does not require a
      consensus with other HNCP nodes.

   Set of Advertised Prefixes:   The set of prefixes included in
      Assigned Prefix TLVs advertised by other HNCP nodes (Prefixes
      advertised by the local node are not in this set).  The associated
      Advertised Prefix Priority is the following format:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: DHCPV6-DATA (37)     |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      DHCPv6 option stream                     |

   DHCPv6 option stream:   DHCPv6 options encoded as priority specified in
      [RFC3315]. the TLV.
      The DHCPv4 Data TLV uses associated Shared Link is determined as follows:

      *  If the following format:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 Link Identifier is zero, the Advertised Prefix is not
         assigned on a Shared Link.

      *  If the other node's interface identified by the Link Identifier
         is included in one of the Common Links used for prefix
         assignment, it is considered as assigned on the given Common
         Link.

      *  Otherwise, the Advertised Prefix is not assigned on a Shared
         Link.

      Advertised Prefixes as well as their associated priorities and
      associated Shared Links MUST be updated as Assigned Prefix TLVs
      are added, updated or removed, and as Common Links are modified.

   ADOPT_MAX_DELAY:   The default value is 0 1 2 3 seconds (i.e., prefix
      adoption MAY be done instantly).

   BACKOFF_MAX_DELAY:   The default value is 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: DHCPV4-DATA (38)    |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DHCPv4 option stream                    |
   DHCPv4 option stream:   DHCPv4 options encoded seconds.

   RANDOM_SET_SIZE:   The default value is 64.

   Flooding Delay:   The default value is 5 seconds.

   Default Advertised Prefix Priority:   When a new assignment is
      created or an assignment is adopted - as specified in
      [RFC2131].

6.2. the prefix
      assignment algorithm routine - the default Advertised Prefix
      Priority to be used is 2.

6.3.2.  Making New Assignments

   Whenever the prefix assignment algorithm subroutine (Section 4.1 of
   [I-D.ietf-homenet-prefix-assignment]) is run on a Common Link and
   whenever a new prefix may be assigned (case 1 of the subroutine: no
   Best Assignment and no Current Assignment), the decision of whether
   the assignment of a new prefix is desired MUST follow these rules in
   order:

      If the Delegated Prefix TLV contains a DHCPv6 Data TLV, and the
      meaning of one of the DHCP options is not understood by the HNCP uses
      node, the creation of a new prefix is not desired.  This rule
      applies to TLVs inside Delegated Prefix TLVs but not to those
      inside External Connection TLVs.

      If the remaining preferred lifetime of the prefix is 0 and there
      is another delegated prefix of the same IP version used for prefix
      assignment with a non-zero preferred lifetime, the creation of a
      new prefix is not desired.

      If the Delegated Prefix does not include a Prefix Policy TLV
      indicating restrictive assignment (type 131) or if local policy
      exists to identify it based on, e.g., other Prefix Policy TLV
      values and allows assignment, the creation of a new prefix is
      desired.

      Otherwise, the creation of a new prefix is not desired.

   If the considered delegated prefix is an IPv6 prefix, and whenever
   there is at least one available prefix of length 64, a prefix of
   length 64 MUST be selected unless configured otherwise.  In case no
   prefix of length 64 would be available, a longer prefix MAY be
   selected even without configuration.

   If the Distributed Prefix Assignment Algorithm specified in
   [I-D.ietf-homenet-prefix-assignment] in order to assign considered delegated prefix is an IPv4 prefix (Section 6.5
   details how IPv4 delegated prefixes to are generated), a prefix of
   length 24 SHOULD be preferred.

   In any case, an HNCP internal links and uses router making an assignment MUST support a
   mechanism suitable to distribute addresses from the terminology defined there.

6.2.1.  Prefix Assignment Algorithm Parameters

   All HNCP nodes running considered prefix
   if the link is intended to be used by clients.  In this case a router
   assigning an IPv4 prefix assignment algorithm MUST use announce the
   following parameters:

   Node IDs:   HNCP node identifiers are used.  The comparison operation
      is defined L-capability and a router
   assigning an IPv6 prefix with a length greater than 64 MUST announce
   the H-capability as bit-wise comparison.

   Set of Delegated Prefixes:   The set of prefixes encoded in Delegated
      Prefix TLVs which are not strictly included in prefixes encoded in
      other Delegated Prefix TLVs.  Note that Delegated Prefix TLVs
      included defined in ignored External Connection TLVs are not considered.
      It is dynamically updated as Delegated Prefix TLVs are added or
      removed.

   Set of Shared Links: Section 4.

6.3.3.  Applying Assignments

   The set of Common Links associated with
      internal, leaf, guest or ad-hoc interfaces.  It prefix assignment algorithm indicates when a prefix is dynamically
      updated as HNCP interfaces are added, removed, or switch from one
      category applied to another.
   the respective Common Link.  When multiple interfaces are detected as
      belonging that happens each router connected
   to said link:

      MUST forward traffic destined to the same Common Link, said prefix assignment is disabled
      on all of these interfaces except one.

   Set of Private Links:   This document defines Private Links
      representing DHCPv6-PD clients or as a mean to advertise prefixes
      included the respective
      link.

      MUST participate in the DHCPv6 Exclude Prefix option.  Other
      implementation-specific Private Links may client configuration election as described
      in Section 7, if the link is intended to be defined whenever a used by clients.

      MAY add an address from said prefix needs to the respective network
      interface as described in Section 6.4, e.g., if it is to be assigned used
      as source for locally originating traffic.

6.3.4.  DHCPv6 Prefix Delegation

   When an HNCP router announcing the P-Capability (Section 4) receives
   a purpose that does not require DHCPv6-PD request from a
      consensus with other HNCP routers.

   Set of Advertised Prefixes:   The client, it SHOULD assign one prefix per
   delegated prefix in the network.  This set of assigned prefixes included in
      Assigned Prefix TLVs advertised by other HNCP routers (Prefixes
      advertised by the local node are not in this set).  The associated
      Advertised Prefix Priority is
   then delegated to the priority specified client, after it has been applied as described
   in the TLV.
      The associated Shared Link is determined prefix assignment algorithm.  Each DHCPv6-PD client MUST be
   considered as follows:

      *  If the an independent Private Link Identifier is zero, the Advertised Prefix is not
         assigned and delegation MUST be
   based on a Shared Link.

      *  If the other node's interface identified by same set of Delegated Prefixes as the one used for
   Common Link Identifier
         is included prefix assignments, however the prefix length to be
   delegated MAY be smaller than 64.

   The assigned prefixes MUST NOT be given to DHCPv6-PD clients before
   they are applied, and MUST be withdrawn whenever they are destroyed.
   As an exception to this rule, in one order to shorten delays of the Common Links used for processed
   requests, a router MAY prematurely give out a prefix
         assignment, it is considered as assigned on the given Common
         Link.

      *  Otherwise, the Advertised Prefix which is
   advertised but not assigned on yet applied if it does so with a Shared
         Link.

      Advertised Prefixes valid lifetime of
   not more than 30 seconds and ensures removal or correction of
   lifetimes as well soon as possible.

6.4.  Node Address Assignment

   This section specifies how HNCP nodes reserve addresses for their associated priorities own
   use.  Nodes MAY, at any time, try to reserve a new address from any
   Applied Assigned Prefix.  Each HNCP node SHOULD announce an IPv6
   address and
      associated Shared Links - if it supports IPv4 - MUST be updated as Assigned Prefix TLVs announce an IPv4 address,
   whenever matching prefixes are added, updated or removed, and as assigned to at least one of its Common Links
   Links.  These addresses are modified.

   ADOPT_MAX_DELAY:   The default value is 0 seconds (i.e. prefix
      adoption MAY be done instantly).

   BACKOFF_MAX_DELAY:   The default value is 4 seconds.

   RANDOM_SET_SIZE:   The default value is 64.

   Flooding Delay:   The default value is 5 seconds.

   Default Advertised Prefix Priority:   When published using Node Address TLVs and
   used to locally reach HNCP nodes for other services.  Nodes SHOULD
   NOT create and announce more than one assignment per IP version to
   avoid cluttering the node data with redundant information unless a new
   special use case requires it.

   Stateless assignment is
      created or an based on Semantically Opaque Interface
   Identifiers [RFC7217] SHOULD be used for address assignment whenever
   possible (e.g., the prefix length is adopted - as specified in 64), otherwise (e.g., for IPv4
   if supported) the following method MUST be used instead: For any
   assigned prefix for which stateless assignment algorithm routine - is not used, the default Advertised Prefix
      Priority first
   quarter of the addresses are reserved for HNCP based address
   assignments, whereas the last three quarters are left to be used the DHCP
   elected router (Section 4 specifies the DHCP server election
   process).  For example, if the prefix 192.0.2.0/24 is 2.

6.2.2.  Assigned Prefix TLV

   Published Assigned Prefixes MUST be advertised assigned and
   applied to a Common Link, addresses included in 192.0.2.0/26 are
   reserved for HNCP nodes and the remaining addresses are reserved for
   the elected DHCPv4 server.

   HNCP nodes assign themselves addresses, and then (to ensure eventual
   lack of conflicting assignments) publish the assignments using the Assigned
   Prefix TLV:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type: ASSIGNED-PREFIX (35)   |          Length: >= 6         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Endpoint Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Rsv. | Prty. | Prefix Length |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            Prefix             +
   |                                                               |

   Endpoint Identifier:
   Node Address TLV (Section 10.4).

   The endpoint identifier process of obtaining addresses is specified as follows:

   o  A node MUST NOT start advertising an address if it is already
      advertised by another node.

   o  An assigned address MUST be part of an assigned prefix currently
      applied on a Common Link which includes the local interface
      that belongs to specified by
      the Common Link endpoint identifier.

   o  An address MUST NOT be used unless it has been advertised for at
      least ADDRESS_APPLY_DELAY consecutive seconds, and is still
      currently being advertised.  The default value for
      ADDRESS_APPLY_DELAY is 3 seconds.

   o  Whenever the prefix same address is assigned to, advertised by more than one node, all
      but the one advertised by the node with the highest node
      identifier MUST be removed.

6.5.  Local IPv4 and ULA Prefixes

   HNCP routers can create a ULA or 0 private IPv4 prefix to enable
   connectivity between local devices.  These prefixes are inserted in
   HNCP as if
      the Common Link is they were delegated prefixes of a Private Link (e.g., when the (virtual) external
   connection (Section 6.2).  The following rules apply:

      An HNCP router SHOULD create a ULA prefix if there is
      assigned for downstream no other
      IPv6 prefix delegation).

   Rsv.:   Bits are reserved for future use.  They MUST be set to zero
      when creating this TLV, and their value MUST be ignored when
      processing with a preferred time greater than 0 in the TLV.

   Prty:   The Advertised network.
      It MAY also do so, if there are other delegated IPv6 prefixes, but
      none of which is locally generated (i.e., without any Prefix Priority from 0 to 15.

      0-1  :  Low priorities.

      2    :  Default priority.

      3-7  :  High priorities.

      8-11 :  Administrative priorities.
      Policy TLV) and has a preferred time greater than 0.  However, it
      MUST NOT be used unless
         configured do so otherwise.

      12-14:  Reserved for future use.

      15   :  Provider priorities.  MAY  In case multiple locally generated ULA
      prefixes are present, only be used the one published by the router
         advertising node with the corresponding delegated prefix and based on
         static or dynamic configuration (e.g., for excluding
      highest node identifier is kept among those with a preferred time
      greater than 0 - if there is any.

      An HNCP router MUST create a private IPv4 prefix
         based on DHCPv6-PD Prefix Exclude Option [RFC6603]).

   Prefix Length:   The number of significant bits in the Prefix field.

   Prefix:   The significant bits of the prefix padded with zeroes up [RFC1918]
      whenever it wishes to provide IPv4 internet connectivity to the next byte boundary.

6.2.3.  Making New Assignments

   Whenever the Prefix Assignment Algorithm subroutine is run on a
   Common Link
      network and whenever no other private IPv4 prefix with internet
      connectivity currently exists.  It MAY also enable local IPv4
      connectivity by creating a new private IPv4 prefix may be assigned (case 1 of if no IPv4 prefix
      exists but MUST NOT do so otherwise.  In case multiple IPv4
      prefixes are announced, only the
   subroutine), one published by the decision of whether node with
      the assignment highest node identifier is kept among those with a Prefix
      Policy of type 0 - if there is any.  The router publishing a new
      prefix
   is desired with internet connectivity MUST follow these rules:

      If forward IPv4 traffic to the Delegated Prefix TLV contains a DHCPv4 or DHCPv6 Data TLV,
      internet and the meaning of one perform NAT on behalf of the DHCP options is not understood by
      the HNCP router, network as long as it
      publishes the creation of a new prefix is not desired.
      This rule applies to TLVs inside Delegated Prefix TLVs but not to
      those inside External Connection TLVs.

      If prefix, other routers in the remaining preferred lifetime network MAY choose not
      to.

   Creation of the prefix is such ULA and IPv4 prefixes MUST be delayed by a random
   timespan between 0 and there
      is another delegated prefix of 10 seconds in which the same IP version used router MUST scan for prefix
      assignment with a non-null preferred lifetime,
   others trying to do the creation of same.

   When a new ULA prefix is not desired.

      Otherwise, created, the creation of a new prefix is desired, if selected based on the
      Delegated Prefix is either locally
   configuration, using the last non-deprecated ULA prefix, or generated (does not
   based on [RFC4193].

7.  Configuration of Hosts and non-HNCP Routers

   HNCP routers need to ensure that hosts and non-HNCP downstream
   routers on internal links are configured with addresses and routes.
   Since DHCP clients can usually only bind to one server at a time, a
   per-link and per-service election takes place.

   HNCP routers may have any
      Prefix Domain TLVs) or intended different capabilities for internet access (has configuring
   downstream devices and providing naming services.  Each router MUST
   therefore indicate its capabilities as specified in Section 4 in
   order to participate as a Prefix
      Domain TLV of type 0).  Local desirability policies MAY override candidate in the election.

7.1.  DHCPv6 for Addressing or provide additional desirability rules Configuration

   In general Stateless Address Autoconfiguration is used for delegated prefixes,
      e.g., client
   configuration for its low overhead and fast renumbering capabilities,
   however stateful DHCPv6 can be used in addition by matching different Prefix Domain TLV values.

   If the considered delegated prefix administrative
   choice, to, e.g., collect hostnames and use them to provide naming
   services or whenever stateless configuration is not applicable.

   The designated stateful DHCPv6 server for a Common Link (Section 6.1)
   is an IPv6 prefix, and whenever
   there elected based on the capabilities described in Section 4.  The
   winner is at least one available prefix of length 64, a prefix of
   length 64 MUST be selected unless configured otherwise. the router (connected to the Common Link) advertising the
   greatest H-capability.  In case no
   prefix of length 64 would be available, a longer prefix MAY be
   selected even without configuration.

   If tie, Capability Values are
   compared, and router with the considered delegated prefix greatest value is an IPv4 prefix (Section 6.4
   details how IPv4 delegated prefixes are generated), a prefix elected.  In case of
   length 24
   another tie, the router with the highest node identifier is elected
   among the routers with tied Capability Values.

   The elected router MUST serve stateful DHCPv6 and SHOULD provide
   naming services for acquired hostnames as outlined in Section 8.
   Stateful addresses SHOULD be preferred.

   In any case, assigned in a router MUST way not hindering fast
   renumbering even if the DHCPv6 server or client do not support a mechanism suitable to distribute
   addresses from the considered prefix if
   DHCPv6 reconfigure mechanism.  In case no router was elected,
   stateful DHCPv6 is not provided.

7.2.  DHCPv6 for Prefix Delegation

   The designated DHCPv6 server for prefix-delegation on a Common Link
   is elected based on the link capabilities described in Section 4.  The
   winner is intended the router (connected to be
   used by clients. the Common Link) advertising the
   greatest P-capability.  In this case of a router assigning an IPv4 prefix MUST
   support the L-capability tie, Capability Values are
   compared, and a router assigning an IPv6 prefix MUST
   support serving router advertisements.  In addition if an assigned
   IPv6 prefix router with the greatest value is not suitable for Stateless Address Autoconfiguration elected.  In case of
   another tie, the router MUST also support with the H-capability as defined in
   Section 10.

6.2.4.  Applying Assignments

   The prefix assignment algorithm indicates when a prefix highest node identifier is applied to elected
   among the respective Common Link.  When that happens each routers with tied Capability Values.

   The elected router connected
   to said link: MUST create an appropriate route for said prefix, indicating it is
      directly reachable provide prefix-delegation services [RFC3633]
   on the respective given link and advertise said route
      using the chosen routing protocol.

      MUST participate in follow the client configuration election as described rules in Section 7, if the link 6.3.4.

7.3.  DHCPv4 for Addressing and Configuration

   The designated DHCPv4 server on a Common Link (Section 6.1) is intended to be used by clients.

      MAY add an address from said prefix to
   elected based on the respective network
      interface as capabilities described in Section 6.3, e.g., if it 4.  The winner
   is the router (connected to be used
      as source for locally originating traffic.

6.2.5.  DHCPv6-PD Excluded Prefix Support

   Whenever the Common Link) advertising the greatest
   L-capability.  In case of a DHCPv6 Prefix Exclude option [RFC6603] is received tie, Capability Values are compared, and
   router with a
   delegated prefix, the excluded prefix MUST be advertised as assigned
   to a Private Link greatest value is elected.  In case of another tie,
   the router with the maximum priority (i.e. 15). highest node identifier is elected among the
   routers with tied Capability Values.

   The same procedure MAY be applied in order to exclude prefixes
   obtained by other means of configuration.

6.2.6.  Downstream Prefix Delegation Support

   When an HNCP elected router MUST provide DHCPv4 services on the given link.
   It MUST announce itself as router receives a request for prefix delegation, it
   SHOULD assign one prefix per delegated prefix [RFC2132] to clients if and only if
   there is an IPv4 default route known in the network.  This
   set of assigned prefix  If there is then delegated to no
   default route, the client, after it has
   been applied as described elected router MUST announce a Classless Static
   Route Option [RFC3442] for the IPv4 prefix announced in the Delegated
   Prefix Assignment Algorithm.  Each
   client MUST be considered as an independent Private Link TLV and
   delegation MUST MAY announce such an option for known reachable IPv4
   destinations not within any local delegated prefix.

   DHCPv4 lease times SHOULD be based short (i.e., not longer than 5 minutes)
   in order to provide reasonable response times to changes.

7.4.  Multicast DNS Proxy

   The designated MDNS [RFC6762] proxy on the same set of Delegated Prefixes as the
   one used for a Common Link prefix assignments. is elected based
   on the capabilities described in Section 4.  The assigned prefixes MUST NOT be given winner is the router
   (connected to clients before they the Common Link) advertising the greatest M-capability.
   In case of a tie, Capability Values are
   applied, compared, and MUST be withdrawn whenever they are destroyed.  As an
   exception to this rule, in order to shorten delays router with the
   greatest value is elected.  In case of processed
   requests, a another tie, the router MAY prematurely give out a prefix which with
   the highest node identifier is
   advertised but not yet applied if it does so elected among the routers with a valid lifetime of
   not more than 30 seconds tied
   Capability Values.

   The elected router MUST provide an MDNS-proxy on the given link and ensures removal or correction of
   lifetimes as soon
   announce it as possible.

6.3.  Node Address Assignment

   This section specifies how HNCP nodes reserve addresses for their own
   use.  Nodes MAY, at any time, try to reserve described in Section 8.

8.  Naming and Service Discovery

   Network-wide naming and service discovery can greatly improve the
   user-friendliness of a new address from any
   applied Assigned Prefix. network.  The following mechanism provides
   means to setup and delegate naming and service discovery across
   multiple HNCP routers.

   Each HNCP router MUST announce at least one
   IPv6 address SHOULD provide a recursive name resolution server
   which honors the announcements made in Delegated Zone TLVs
   (Section 10.5), Domain Name TLVs (Section 10.6) and - if it supports IPv4 - at least one IPv4 address,
   whenever matching prefixes are assigned to at least one if its Common
   Links.  These addresses are published using Node Address Name TLVs
   (Section 10.7), i.e., delegate queries to the designated name servers
   and
   used hand out appropriate A, AAAA and PTR records according to locally reach the
   mentioned TLVs.

   Each HNCP nodes for other services.  Nodes router SHOULD
   NOT create provide and announce more than one assignment per IP version to
   avoid cluttering the node data with redundant information unless a
   special use case requires it.

   Stateless assignment based on Modified EUI64 interface identifiers
   [RFC4291] SHOULD be used an auto-generated or
   user-configured name for address assignment whenever possible,
   otherwise (e.g., each internal Common Link (Section 6.1) for IPv4)
   which it is the following method MUST be used instead:
   For any assigned prefix designated DHCPv4, stateful DHCPv6 server, MDNS
   proxy, or for which SLAAC cannot it provides forward or reverse DNS services on
   behalf of connected devices.  This announcement is done using
   Delegated Zone TLVs (Section 10.5) and MUST be used, unique in the first
   quarter whole
   network.  In case of a conflict the addresses are reserved for routers HNCP based address
   assignments, whereas announcement of the last three quarters are left node with the
   highest node identifier takes precedence and all other nodes MUST
   cease to announce the DHCPv6
   (resp.  DHCPv4) elected router (Section 10 specifies conflicting TLV.  HNCP routers providing name
   resolving services MUST use the DHCP included DNS server
   election process).  For instance, if address within
   the prefix 192.0.2.0/24 is
   assigned and applied TLV to resolve names belonging to the zone as if there was an NS
   record.

   Each HNCP node SHOULD announce a Common Link, addresses included in
   192.0.2.0/26 are reserved node name for HNCP nodes itself to be easily
   reachable and the remaining addresses MAY do so on behalf of other devices.  Announcements
   are reserved for the elected DHCPv4 server.

   HNCP routers assign themselves addresses made using the Node Address TLV:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: NODE-ADDRESS (36)    |           Length: 20          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Endpoint Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           IP Address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Endpoint Identifier:   The endpoint identifier Name TLVs (Section 10.7) and MUST be unique in
   the whole network.  In case of a conflict the local interface
      that belongs to announcement of the Common Link
   node with the prefix is assigned to, or 0 highest node identifier takes precedence and all other
   nodes MUST cease to announce the conflicting TLV.  HNCP routers
   providing name resolving services MUST resolve these names to their
   respective IP addresses as if
      it is not assigned on there were corresponding A/AAAA
   records.

   Names and unqualified zones are used in an HNCP enabled link.

   IP Address:   The globally scoped IPv6 address, network to provide
   naming and service discovery with local significance.  A network-wide
   zone is appended to all single labels or unqualified zones in order
   to qualify them. ".home" is the IPv4 address
      encoded as default, however an IPv4-mapped IPv6 address [RFC4291]. administrator MAY
   configure announcing of a Domain Name TLV (Section 10.6) for the
   network to use a different one.  In case multiple are announced, the
   domain of the node with the greatest node identifier takes
   precedence.

9.  Securing Third-Party Protocols

   Pre-shared keys (PSKs) are often required to secure (for example)
   IGPs and other protocols which lack support for asymmetric security.
   The process following mechanism manages PSKs using HNCP to enable
   bootstrapping of obtaining addresses is specified as follows:

   o  A router MUST NOT start advertising an address if it is already
      advertised by another router.

   o  An assigned address MUST such third-party protocols.  The scheme SHOULD be
   used only in conjunction with secured HNCP unicast transport (=DTLS),
   as transferring the first quarter PSK in plain-text anywhere in the network is a
   potential risk, especially as the originator may not know about
   security (and use of an assigned
      prefix currently applied DNCP security) on all links.  The following
   rules define how such a Common Link which includes the
      interface specified by the endpoint identifier. PSK is managed and used:

   o  An address  If no Managed PSK TLV (Section 10.8) is currently being announced,
      an HNCP node using this mechanism MUST NOT be used unless it has been advertised for at
      least ADDRESS_APPLY_DELAY consecutive seconds, create one after a random
      delay of 0 to 10 seconds with a 32 bytes long random key and is still
      currently being advertised.  The default value for
      ADDRESS_APPLY_DELAY is 3 seconds. add
      it to its node data.

   o  Whenever  In case multiple nodes announce such a TLV at the same address is advertised by more than one node, time, all
      but the one advertised by the node with the highest greatest node identifier MUST be removed.

6.4.  Local IPv4 stop advertising it
      and ULA Prefixes

   HNCP routers can create adopt the remaining one.

   o  The node currently advertising the Managed PSK TLV must generate
      and advertise a new random one whenever an ULA or private IPv4 prefix to enable
   connectivity between local devices.  These prefixes are inserted in
   HNCP unreachable node is
      removed from the DNCP topology as if they were delegated prefixes.  The following rules apply:

      An HNCP router described in the Section 4.6 of
      [I-D.ietf-homenet-dncp].

   PSKs for individual protocols SHOULD create be derived from the random PSK
   using a ULA prefix if there is no other
      IPv6 prefix suitable one-way hashing algorithm (e.g., by using HMAC-
   SHA256 [RFC6234] with a preferred time greater than 0 in the network.
      It MAY also do so, if there are other delegated IPv6 prefixes, but
      none per-protocol HMAC-key) so that disclosure of which is locally generated (i.e., without
   any Prefix
      Domain TLV) and has a preferred time greater than 0.  However, it derived key does not impact other users of the managed PSK.
   Furthermore derived PSKs MUST NOT do so otherwise.  In case multiple locally generated ULA
      prefixes be updated whenever the managed PSK
   changes.

10.  Type-Length-Value Objects

   HNCP defines the following TLVs in addition to those defined by DNCP.
   The same general rules and defaults for encoding as noted in
   Section 7 of [I-D.ietf-homenet-dncp] apply.

   TLVs defined here are present, only valid when appearing in their designated
   context, i.e., only directly within container TLVs mentioned in their
   definition, or - absent any mentions - only as top-level TLVs within
   the one published by the node with the
      highest node identifier is kept among those with a preferred time
      greater than 0 - if there is any.

      An HNCP router data set.  TLVs appearing outside their designated context
   MUST create a private IPv4 prefix [RFC1918]
      whenever it wishes to provide IPv4 internet connectivity to the
      network be ignored.

   Unless specified otherwise, TLVs encoding IP addresses or prefixes
   allow encoding both IPv6 and no other private IPv4 prefix with internet
      connectivity currently exists.  It MAY also enable local IPv4
      connectivity by creating a private addresses and prefixes.  IPv6
   information is encoded as is, whereas for IPv4 IPv4-mapped IPv6
   addresses format [RFC4291] is used and prefix if no lengths are encoded as
   original IPv4 prefix
      exists but MUST NOT do so otherwise.  In case multiple IPv4
      prefixes are announced, only the one published length increased by the node with
      the highest node identifier is kept among those with a Prefix
      Domain of type 96.

10.1.  HNCP Version TLV

   0 - if there                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: HNCP-VERSION (32)    |         Length: >= 5          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |   Reserved    |   M   |   P   |   H   |   L   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          User-agent                           |

   This TLV is any.  The router publishing a
      prefix with internet connectivity MUST announce an IPv4 default
      route using used to indicate the routing protocol supported version and perform NAT on behalf router
   capabilities of the
      network as long an HNCP node as it publishes the prefix, other routers described in the
      network MAY choose not to.

   Creation Section 4.

   Version:  Indicates which version of such ULA and IPv4 prefixes MUST be delayed by a random
   timespan between 0 and 10 seconds HNCP is currently in which the router use by this
      particular node.  It MUST scan be set to 1.  Nodes with different
      versions are considered incompatible.

   Reserved:  Bits are reserved for
   other nodes trying future use.  They MUST be set to do
      zero when creating this TLV, and their value MUST be ignored when
      processing the same.

   When a new ULA prefix is created, TLV.

   M-capability:  Priority value used for electing the prefix on-link MDNS
      [RFC6762] proxy.  It MUST be set to some value between 1 and 7
      included (4 is selected based on the
   configuration, using default) if the last non-deprecated ULA prefix, or generated
   based on [RFC4193].

6.5.  Special Purpose Prefixes

   Some prefixes may have a special meaning router is capable of proxying
      MDNS and 0 otherwise.  The values 8-15 are not regularly reserved for future
      use.

   P-capability:  Priority value used for internal or internet connectivity, instead they may provide
   access to special services like VPNs, sensor networks, VoIP, IPTV,
   etc.  Care must electing the on-link DHCPv6-PD
      server.  It MUST be taken that these prefixes are properly integrated set to some value between 1 and dealt with in 7 included (4
      is the network, in order to avoid breaking
   connectivity for devices who are not aware of their special
   characteristics.

   Special purpose default) if the router is capable of providing prefixes are distinguished using Prefix Domain TLVs
      through DHCPv6-PD (Section 6.1.3).  Their contents MAY 6.3.4) and 0 otherwise.  The values
      8-15 are reserved for future use.

   H-capability:  Priority value used for electing the on-link DHCPv6
      server offering non-temporary addresses.  It MUST be partly opaque set to HNCP nodes, some
      value between 1 and their identification 7 included (4 is the default) if the router is
      capable of providing such addresses and usage depends on local policy.  However 0 otherwise.  The values
      8-15 are reserved for future use.

   L-capability:  Priority value used for electing the following general rules on-link DHCPv4
      server.  It MUST be adhered to:

      Special rules apply when making address assignments for prefixes
      with Prefix Domain TLVs other than type 0, as described in
      Section 6.2.3
      In presence of any type 1 set to 128 Prefix Domain TLV some value between 1 and 7 included (4
      is the prefix default) if the router is
      specialized to reach destinations denoted by any such Prefix
      Domain TLV, i.e. in abscence capable of running a type legacy
      DHCPv4 server offering IPv4 addresses to clients and 0 Prefix Domain TLV it is
      not usable otherwise.
      The values 8-15 are reserved for general internet connectivity.  An HNCP router MAY
      enforce this restriction with appropriate packet filtering rules
      to provide increased security. future use.

   User-Agent:  The presence user-agent is a human-readable UTF-8 string that
      describes the name and version of the current HNCP implementation.

10.2.  External Connection TLV

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type: EXTERNAL-CONNECTION (33)|             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Nested TLVs                          |

   An External Connection TLV is a type 129 (DNS zone) Prefix Domain container TLV indicates
      that the delegated prefix or its used to gather network
   configuration information associated with a single external
   connection is
      specialized (Section 6.2) to reach destinations within be shared across the given DNS zone.  An HNCP router providing name resolving services SHOULD prefer DNS
      servers listed in the associated external connection's DHCPv4 or
      DHCPv6 Data TLVs when resolving domains from that zone.

7.  Configuration network.  A
   node MAY publish an arbitrary number of Hosts and non-HNCP Routers

   HNCP routers need to ensure that hosts and non-HNCP downstream
   routers on internal links are configured with addresses and routes.
   Since DHCP-clients can usually only bind to one server at a time, a
   per-link and per-service election takes place.

   HNCP routers may have different capabilities for configuring
   downstream devices and providing naming services.  Each router MUST
   therefore indicate its capabilities as specified in Section 10 in
   order instances of this TLV to participate as a candidate in
   share the election.

7.1.  DHCPv6 for Addressing or Configuration

   In general Stateless Address Autoconfiguration desired number of external connections.

10.2.1.  Delegated Prefix TLV
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type: DELEGATED-PREFIX (34)  |          Length: >= 9         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Valid Lifetime Since Origination               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Preferred Lifetime Since Origination             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |                                               |
   +-+-+-+-+-+-+-+-+            Prefix [+ nested TLVs]             +
   |                                                               |

   The Delegated Prefix TLV is used for client
   configuration for its low overhead and fast renumbering capabilities,
   however stateful DHCPv6 can be used in addition by administrative
   choice, to e.g. collect hostnames and use them HNCP routers to provide naming
   services or whenever stateless configuration is not applicable.

   The designated stateful DHCPv6 server for a Common Link (Section 4)
   is elected based on the capabilities described in Section 10.  The
   winner is the router (connected advertise
   prefixes which are allocated to the Common Link) advertising the
   greatest H-capability.  In case of a tie, Capability Values whole network and node
   identifiers can be used for
   prefix assignment.  Delegated Prefix TLVs are considered (greatest value is elected).  The elected
   router MUST serve stateful DHCPv6 only valid inside
   External Connection TLVs and their prefixes MUST provide naming services
   for acquired hostnames as outlined in Section 8.  Stateful addresses
   SHOULD be assigned NOT overlap with
   those of other such TLVs in a way not hindering fast renumbering even if the DHCPv6 server or client do not support same container.

   Valid Lifetime Since Origination:   The time in seconds the DHCPv6 reconfigure
   mechanism.  In case no router delegated
      prefix was elected, stateful DHCPv6 is not
   provided and each router assigning IPv6-prefixes on said link MUST
   provide stateless DHCPv6 service.

7.2.  Sending Router Advertisements

   All HNCP routers MUST send Router Advertisements periodically via
   multicast and via unicast in response to Router Solicitations.

   o  The "Managed address configuration" flag MUST be set whenever a
      router connected to valid for at the link is advertising a non-null
      H-capability and MUST NOT be set otherwise.  The "Other
      configuration" flag MUST always be set.

   o origination time of the node data
      containing this TLV.  The default Router Lifetime value MUST be set to an appropriate non-null
      value updated whenever an IPv6 default route is known the node
      republishes its Node State TLV.

   Preferred Lifetime Since Origination:   The time in seconds the HNCP network
      and MUST be set to zero otherwise.

   o  A Prefix Information Option MUST be added for each assigned and
      applied IPv6
      delegated prefix on was preferred for at the given link. origination time of the
      node data containing this TLV.  The autonomous address-
      configuration flag value MUST be set updated whenever
      the prefix is suitable for
      stateless configuration. node republishes its Node State TLV.

   Prefix Length:   The preferred and valid lifetimes MUST
      be smaller than number of significant bits in the preferred and valid lifetimes Prefix.

   Prefix:   Significant bits of the delegated prefix padded with zeroes up to the prefix is from.  When a prefix is removed, it MUST be
      deprecated as specified in [RFC7084].

   o  A Route Information Option [RFC4191] MUST be added for each
      delegated IPv6 prefix known
      next byte boundary.

   Nested TLVs:  Other TLVs included in the HNCP network.  Additional ones
      SHOULD be added for each non-default IPv6 route with an external
      destination prefix advertised by Delegated Prefix TLV
      starting at the routing protocol.

   o  A Recursive DNS Server Option and a DNS Search List Option MUST next 32-bit boundary following the end of the
      encoded prefix.

10.2.1.1.  Prefix Policy TLV

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: PREFIX-POLICY (43)   |          Length: >= 1         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Policy Type  |                                               |
   +-+-+-+-+-+-+-+-+                    Value                      +
   |                                                               |
   The Prefix Policy TLV contains information about the policy or
   applicability of a delegated prefix.  This information can be
      included with appropriate contents.

   o  To allow for optimized routing decisions used to
   determine whether prefixes for clients on the a certain usecase (e.g., local
      link routers SHOULD adjust their Default Router Preference
   reachability, internet connectivity) do exist or should be acquired
   and
      Route Preferences [RFC4191] so that the priority is set to low if
      the next hop of the default make decisions about assigning prefixes to certain links or to
   fine-tune border firewalls.  See Section 6.2 for a more specific route in-depth
   discussion.  This TLV is on only valid inside a Delegated Prefix TLV.

   Policy Type:   The type of the same
      interface as policy identifier.

      0      :  Internet connectivity (no Value).

      1-128  :  Explicit destination prefix with the Route Advertisement Policy Type being sent on.  Similarly the
      router MAY use the high priority if it is certain it has
         the best
      metric actual length of all routers on the link for all routes known in prefix (Value contains significant
         bits of the
      network destination prefix padded with zeroes up to the respective destination.

   Every router sending Router Advertisements MUST immediately send
         next byte boundary).

      129    :  DNS Zone (Value contains an
   updated Router Advertisement via multicast as soon RFC 1035 [RFC1035] encoded
         DNS label sequence).

      130    :  Opaque UTF-8 string (e.g., for administrative purposes).

      131    :  Restrictive Assignment (no Value).

      132-255:  Reserved for future additions.

   Value:   A variable length identifier of the given type.

10.2.2.  DHCPv6 Data TLV

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: DHCPV6-DATA (37)     |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      DHCPv6 option stream                     |

   This TLV is used to encode auxiliary IPv6 configuration information
   (e.g., recursive DNS servers) encoded as it notices a
   condition resulting in a change stream of any advertised information.

7.3.  DHCPv6 for Prefix Delegation

   The designated DHCPv6 server for prefix-delegation on a Common Link options.
   It is elected based on the capabilities described only valid in Section 10.  The
   winner is the router (connected to the Common Link) advertising the
   greatest P-capability.  In case of an External Connection TLV or a tie, Capability Values are
   compared, Delegated Prefix
   TLV encoding an IPv6 prefix and router with the greatest value is elected.  In case of
   another tie, the router with the highest node identifier is elected
   among the routers with tied Capability Values.  The elected router MUST provide prefix-delegation services [RFC3633] on the given link
   and follow the rules NOT occur more than once in Section 6.2.6.

7.4.  DHCPv4 for Addressing and Configuration

   The designated DHCPv4 server on a Common Link (Section 4) is elected
   based on the capabilities described any
   single container.  When included in Section 10.  The winner is the
   router (connected an External Connection TLV, it
   contains DHCPv6 options relevant to the Common Link) advertising the greatest
   L-capability.  In case of External Connection as a tie, Capability Values are compared, and
   router with the greatest value is elected.  In case of another tie,
   the router with the highest node identifier is elected among the
   routers with tied Capability Values.  The elected router MUST provide
   whole.  When included in a Delegated Prefix, it contains options
   mandatory to handle said prefix.

   DHCPv6 option stream:   DHCPv6 options encoded as specified in
      [RFC3315].

10.2.3.  DHCPv4 services on the given link.

   The Data TLV

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: DHCPV4-DATA (38)    |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DHCPv4 serving router MUST announce itself as router [RFC2132] to
   clients if and only if there option stream                    |

   This TLV is an used to encode auxiliary IPv4 default route known in the
   network.  In addition, the router SHOULD announce configuration information
   (e.g., recursive DNS servers) encoded as a Classless Static
   Route Option [RFC3442] for each non-default IPv4 route advertised stream of DHCPv4 options.
   It is only valid in
   the routing protocol with an external destination.

   DHCPv4 lease times SHOULD be short (i.e. not longer External Connection TLV and MUST NOT occur
   more than 5 minutes) once in order to provide reasonable response times any single container.  It contains DHCPv4 options
   relevant to changes.

7.5.  Multicast DNS Proxy

   The designated MDNS [RFC6762] proxy on a Common Link is elected based
   on the capabilities described External Connection as a whole.

   DHCPv4 option stream:   DHCPv4 options encoded as specified in Section 10.  The winner
      [RFC2131].

10.3.  Assigned Prefix TLV

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type: ASSIGNED-PREFIX (35)   |          Length: >= 6         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Endpoint Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Rsv. | Prty. | Prefix Length |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            Prefix             +
   |                                                               |

   This TLV is the
   router (connected used to announce Published Assigned Prefixes for the Common Link) advertising the greatest
   M-capability.  In case
   purposes of a tie, Capability Values are compared, and
   router with the greatest value is elected.  In case prefix assignment (Section 6.3).

   Endpoint Identifier:   The endpoint identifier of another tie, the router with local interface
      the highest node identifier prefix is elected among the
   routers with tied Capability Values.  The elected router MUST provide
   an MDNS-proxy on the given link and announce it as described in
   Section 8.

8.  Naming and Service Discovery

   Network-wide naming and service discovery can greatly improve the
   user-friendliness of a network.  The following mechanism provides
   means to setup and delegate naming and service discovery across
   multiple HNCP routers.

   Each HNCP router SHOULD provide and announce an auto-generated assigned to, or
   user-configured name for each internal Common Link (Section 4) for
   which 0 if it is the designated DHCPv4, stateful DHCPv6 server, MDNS
   proxy, or for which it provides forward or reverse DNS services on
   behalf of connected devices.  HNCP routers providing name resolving
   services MUST use the included DNS server address to resolve names
   belonging assigned to the zone.

   Each HNCP router SHOULD announce a node name Private
      Link (e.g., when the prefix is assigned for itself to be easily
   reachable and MAY do so on behalf of other devices.  HNCP routers
   providing name resolving services downstream prefix
      delegation).

   Rsv.:   Bits are reserved for future use.  They MUST resolve these names be set to zero
      when creating this TLV, and their
   respective IP addresses. value MUST be ignored when
      processing the TLV.

   Prty:   The following TLVs are defined and Advertised Prefix Priority from 0 to 15.

      0-1  :  Low priorities.

      2    :  Default priority.

      3-7  :  High priorities.

      8-11 :  Administrative priorities.  MUST NOT be supported used unless
         configured otherwise.

      12-14:  Reserved for future use.

      15   :  Provider priorities.  MAY only be used by all nodes
   implementing naming the router
         advertising the corresponding delegated prefix and service discovery:

8.1.  DNS Delegated Zone based on
         static or dynamic configuration (e.g., for excluding a prefix
         based on DHCPv6-PD Prefix Exclude Option [RFC6603]).

   Prefix Length:   The number of significant bits in the Prefix field.

   Prefix:   The significant bits of the prefix padded with zeroes up to
      the next byte boundary.

10.4.  Node Address TLV

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: NODE-ADDRESS (36)    |           Length: 20          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Endpoint Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           IP Address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This TLV is used to announce a forward or reverse DNS zone delegation
   in the HNCP network.  Its meaning is roughly equivalent addresses assigned to specifying an NS and A/AAAA record for said zone.  There MUST NOT be more than
   one delegation for the same zone HNCP node as
   described in the whole DNCP network.  In case
   of a conflict the announcement Section 6.4.

   Endpoint Identifier:   The endpoint identifier of the node with local interface
      the highest node
   identifier takes precedence and all other nodes MUST cease to
   announce prefix is assigned to, or 0 if it is not assigned on an HNCP
      enabled link.

   IP Address:   The globally scoped IPv6 address, or the conflicting TLV. IPv4 address
      encoded as an IPv4-mapped IPv6 address [RFC4291].

10.5.  DNS Delegated Zone TLV
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type: DNS-DELEGATED-ZONE (39) |        Length: >= 17          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           IP Address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Reserved |L|B|S|                                               |
   +-+-+-+-+-+-+-+-+  Zone (DNS label sequence - variable length)  |
   |                                                               |

   This TLV is used to announce a forward or reverse DNS zone delegation
   in the HNCP network.  Its meaning is roughly equivalent to specifying
   an NS and A/AAAA record for said zone.  Details are specified in
   Section 8.

   IP Address :  The IPv6 address of the authoritative DNS server for
      the zone; IPv4 addresses are represented as IPv4-mapped addresses
      [RFC4291].  The special value of :: (all-zero) means the
      delegation is available in the global DNS-hierarchy.

   Reserved :  Those bits MUST be set to zero when creating the TLV and
      ignored when parsing it unless defined in a later specification.

   L-bit :  DNS-SD [RFC6763] Legacy-Browse, indicates that this
      delegated zone should be included in the network's DNS-SD legacy
      browse list of domains at lb._dns- sd._udp.(DOMAIN-NAME).  Local
      forward zones SHOULD have this bit set, reverse zones SHOULD NOT.

   B-bit :  (DNS-SD [RFC6763] Browse) indicates that this delegated zone
      should be included in the network's DNS-SD browse list of domains
      at b._dns-sd._udp.  (DOMAIN-NAME).  Local forward zones SHOULD
      have this bit set, reverse zones SHOULD NOT.

   S-bit :  (fully-qualified DNS-SD [RFC6763] domain) indicates that
      this delegated zone consists of a fully-qualified DNS-SD domain,
      which should be used as base for DNS-SD domain enumeration, i.e. i.e.,
      _dns-sd._udp.(Zone) exists.  Forward zones MAY have this bit set,
      reverse zones MUST NOT.  This can be used to provision DNS search
      path to hosts for non-local services (such as those provided by an
      ISP, or other manually configured service providers).  Zones with
      this flag SHOULD be added to the search domains advertised to
      clients.

   Zone :  The label sequence of the zone, encoded as the domain names
      are encoded DNS messages as specified in [RFC1035].  The last
      label in the zone MUST be empty.

8.2.  Domain Name TLV

   This TLV is used to indicate the base domain name for the network.
   It is the zone used as a base for all non fully-qualified delegated
   zones and node names.  In case of conflicts the announced domain of
   the node with the greatest node identifier takes precedence.  By
   default, i.e., if no node advertises such a TLV., ".home" is used.
   This TLV MUST NOT be announced unless the domain name was explicitly
   configured by an administrator.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: DOMAIN-NAME (40)     |         Length: > 0           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Domain (DNS label sequence - variable length)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Domain:   The label sequence encoded according to [RFC1035].
      Compression MUST NOT be used.  The zone MUST end with an empty
      label.

8.3.  Node Name TLV

   This TLV is used to assign the name of a node in the network to a
   certain IP address.  In case  The label sequence of conflicts the announcement of zone, encoded as the
   node with domain names
      are encoded DNS messages as specified in [RFC1035].  The last
      label in the greatest node identifier for a name takes precedence
   and all other nodes zone MUST cease to announce the conflicting TLV. be empty.

10.6.  Domain Name TLV

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: NODE-NAME (41) DOMAIN-NAME (40)     |         Length: > 16          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           IP Address                          |
   |                                                               |
   | 0           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Name (not null-terminated        Domain (DNS label sequence - variable length)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP Address:   The IP address associated with

   This TLV is used to indicate the name.  IPv4
      addresses are encoded using IPv4-mapped IPv6 addresses.

   Name:   The base domain name of for the node network as a single DNS label (up to 63
      characters, no leading length byte).

9.  Securing Third-Party Protocols

   Pre-shared keys (PSKs) are often required to secure IGPs and other
   protocols which lack support for asymmetric security.  The following
   mechanism manages PSKs using HNCP to enable bootstrapping of such
   third-party protocols and SHOULD therefore be used if such a need
   arises.  The following rules define how such a PSK is managed and
   used:

   o  If no Managed-PSK-TLV is currently being announced, an HNCP router
      MUST create one after a random delay of 0 to 10 seconds with a 32
      bytes long random key and add it to its node data.

   o  In case multiple routers announce such a
   specified in Section 8.  This TLV at the same time, all
      but the one with the greatest node identifier stop advertising it
      and adopt MUST NOT be announced unless the remaining one.

   o
   domain name was explicitly configured by an administrator.

   Domain:   The router currently advertising the Managed-PSK-TLV must generate
      and advertise a new random one whenever label sequence encoded according to [RFC1035].
      Compression MUST NOT be used.  The zone MUST end with an unreachable node is
      purged as described in DNCP. empty
      label.

10.7.  Node Name TLV

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: Managed-PSK (42) NODE-NAME (41)      |         Length: 32 > 16          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                                                               |
   |                           Random PSK                          |
   |                           IP Address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Name (not null-terminated - variable length)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PSKs for individual protocols are derived from the random PSK through
   the use of HMAC-SHA256 [RFC6234] with a pre-defined per-protocol
   HMAC-key in ASCII-format.  The following HMAC-keys are currently
   defined

   This TLV is used to derive PSKs for assign the respective protocols:

      "ROUTING": to be used for IGPs

10.  HNCP Versioning and Capabilities

   Multiple versions name of HNCP based on compatible DNCP profiles may be
   present a node in the same network when transitioning between HNCP versions
   and HNCP routers may have different capabilities to support clients.
   The following mechanism describes a way to announce the currently
   active version and User-agent of a node.  Each node MUST include an
   HNCP-Version-TLV
   certain IP address as specified in its Node Data and MUST ignore (except for DNCP
   synchronization purposes) any TLVs with a type greater than 32
   published by nodes not also publishing an HNCP-Version TLV or
   publishing such a TLV Section 8.

   IP Address:   The IP address associated with a different Version number.

   Capabilities are indicated by setting M, P, H and L fields in the
   TLV. name.  IPv4
      addresses are encoded using IPv4-mapped IPv6 addresses.

   Name:   The "capability value" is a metric indicated by interpreting name of the bits node as an integer, i.e.  (M << 12 | P << 8 | H << 4 | L). a single DNS label (up to 63
      characters, no leading length byte).

10.8.  Managed PSK TLV

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: HNCP-VERSION (32) MANAGED-PSK (42)     |          Length: >= 5 32           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |   Reserved    |   M   |   P                                                               |   H
   |   L                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          User-agent                                                               |
   Version:  Indicates which version of HNCP is currently in use by this
      particular node.  It MUST be set to 1.  Nodes with different
      versions are considered incompatible.

   Reserved:  Bits are reserved for future use.  They MUST be set to
      zero when creating this TLV, and their value MUST be ignored when
      processing the TLV.

   M-capability:  Priority value used for electing the on-link MDNS
      [RFC6762] proxy.  It MUST be set to some value between 1 and 7
      included (4 is the default) if the router is capable of proxying
      MDNS and 0 otherwise.  The values 8-15 are reserved for future
      use.

   P-capability:  Priority value used for electing the on-link DHCPv6-PD
      server.  It MUST be set to some value between 1 and 7 included (4
      is the default) if the router is capable of providing prefixes
      through DHCPv6-PD (Section 6.2.6) and 0 otherwise.  The values
      8-15 are reserved for future use.

   H-capability:  Priority value used for electing the on-link DHCPv6
      server offering non-temporary addresses.  It MUST be set to some
      value between 1 and 7 included (4 is the default) if the router is
      capable of providing such addresses and 0 otherwise.  The values
      8-15 are reserved for future use.

   L-capability:  Priority value used for electing the on-link DHCPv4
      server.  It MUST be set to some value between 1 and 7 included (4
      is the default) if the router
   |                      Random 256-bit PSK                       |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This TLV is capable of running a legacy
      DHCPv4 server offering IPv4 addresses used to clients and 0 otherwise.
      The values 8-15 are reserved for future use.

   User-Agent:  The user-agent is announce a human-readable UTF-8 string that
      describes the name and version of the current HNCP implementation. PSK for securing third-party protocols
   exclusively supporting symmetric cryptography as specified in
   Section 9.

11.  General Requirements for HNCP Routers Nodes

   Each router node implementing HNCP is subject to the following requirements:

   o  It MUST implement HNCP-Versioning, Border Discovery, Prefix
      Assignment and Configuration of hosts HNCP-Versioning (Section 4) and non-HNCP routers as
      defined in this document. Interface
      Classification (Section 5).

   o  It MUST implement and run the method for securing third-party
      protocols (Section 9) whenever it uses the security mechanism of
      HNCP.

   If the node is acting as a router, then the following requirements
   apply in addition:

   o  It MUST support Autonomous Address Configuration (Section 6) and
      Configuration of Hosts and non-HNCP Routers (Section 7).

   o  It SHOULD implement support for the Service Discovery and Naming
      TLVs
      (Section 8) as defined in this document.

   o  It MUST implement and run a routing protocol appropriate for the
      given link type on all of the interfaces it sends and receives
      HNCP traffic on.  The protocol MUST support source-specific routes
      and MUST correctly propagate those also for the external
      destinations that may have only implicit source-specific
      information, such as a combination of a DHCPv6 PD-derived prefix
      and a non-source-specific default route.

   o  It MUST use adequate security mechanisms for the routing protocol
      on any interface where it also uses the security mechanisms of
      HNCP.  If the security mechanism is based on a PSK it MUST use a
      PSK derived from the Managed-PSK to secure the IGP.

   o  It MAY be able to provide connectivity to IPv4-devices using
      DHCPv4.

   o  It SHOULD be able to delegate prefixes to legacy IPv6 routers
      using DHCPv6-PD. DHCPv6-PD (Section 6.3.4).

   o  In addition, normative language of Basic Requirements for IPv6
      Customer Edge Routers [RFC7084] applies with the following
      adjustments:

      *  The generic requirements G-4 and G-5 are relaxed such that any
         known default router on any interface is sufficient for a
         router to announce itself as default router, similarly only the
         loss of all such default routers results in self-invalidation.

      *  The section "WAN-Side Configuration" applies to HNCP interfaces
         classified as external.

      *  If the CE sends a size-hint as indicated in WPD-2, the hint
         MUST NOT be determined by the number of LAN-interfaces of the
         CE, but SHOULD instead be large enough to at least accommodate
         prefix assignments announced for existing delegated or ULA-
         prefixes, if such prefixes exist and unless explicitly
         configured otherwise.

      *  The dropping of packets with a destination address belonging to
         a delegated prefix mandated in WPD-5 MUST NOT be applied to
         destinations that are part of any prefix announced using an
         ASSIGNED-PREFIX
         Assigned Prefix TLV by any HNCP router in the network.

      *  The section "LAN-Side Configuration" applies to HNCP interfaces not
         classified as internal. external.

      *  The requirement L-2 to assign a separate /64 to each LAN
         interface is replaced by the participation in the prefix
         assignment mechanism (Section 6.2) 6.3) for each such interface.

      *  The requirement L-9 is modified, in that the M flag MUST be set
         if and only if a router connected to the respective Common Link
         is advertising a non-zero H-capability.

      *  The requirement L-12 to make DHCPv6 options available is
         adapted, in that a CER SHOULD publish the subset of options
         using the DHCPv6 Data TLV in an External Connection TLV.
         Similarly it SHOULD do the same for DHCPv4 options in a DHCPv4
         Data TLV.  DHCPv6 options received inside an OPTION_IAPREFIX
         [RFC3633] MUST be published using a DHCPv6 Data TLV inside the
         respective Delegated Prefix TLV.  HNCP routers SHOULD make
         relevant DHCPv6 and DHCPv4 options available to clients, i.e. i.e.,
         options contained in External Connection TLVs that also include
         delegated prefixes from which a subset is assigned to the
         respective link.

      *  The requirement L-13 to deprecate prefixes is applied to all
         delegated prefixes in the network from which assignments have
         been made on the respective interface.  Furthermore the Prefix
         Information Options indicating deprecation MUST be included in
         Router Advertisements for the remainder of the prefixes'
         respective valid lifetime, but MAY be omitted after at least 2
         hours have passed.

12.  Security Considerations

   HNCP enables self-configuring networks, requiring as little user
   intervention as possible.  However this zero-configuration goal
   usually conflicts with security goals and introduces a number of
   threats.

   General security issues for existing home networks are discussed in
   [RFC7368].  The protocols used to set up addresses and routes in such
   networks to this day rarely have security enabled within the
   configuration protocol itself.  However these issues are out of scope
   for the security of HNCP itself.

   HNCP is a DNCP-based state synchronization mechanism carrying
   information with varying threat potential.  For this consideration
   the payloads defined in DNCP and this document are reviewed:

   o  Network topology information such as HNCP nodes and their common
      links.

   o  Address assignment information such as delegated and assigned
      prefixes for individual links.

   o  Naming and service discovery information such as auto-generated or
      customized names for individual links and routers. nodes.

12.1.  Border Determination  Interface Classification

   As described in Section 5, 5.3, an HNCP router node determines the internal or
   external state on a per-link per-interface basis.  A firewall perimeter is set
   up for the external links, interfaces, and for internal links, interfaces, HNCP and IGP
   traffic is allowed. allowed, with the exception of leaf and guest sub-
   categories.

   Threats concerning automatic border discovery interface classification cannot be
   mitigated by encrypting or authenticating HNCP traffic itself since
   external routers do not participate in the protocol and often cannot
   be authenticated by other means.  These threats include propagation
   of forged uplinks in the homenet in order to e.g. to, e.g., redirect traffic
   destined to external locations and forged internal status by external
   routers to e.g. to, e.g., circumvent the perimeter firewall.

   It is therefore imperative to either secure individual links on the
   physical or link-layer or preconfigure the adjacent interfaces of
   HNCP routers to an adequate fixed-category appropriate fixed category in order to secure the
   homenet border.  Depending on the security of the external link
   eavesdropping, man-in-the-middle and similar attacks on external
   traffic can still happen between a homenet border router and the ISP,
   however these cannot be mitigated from inside the homenet.  For
   example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4
   messages, but this is very rarely implemented in large or small
   networks.  Further, while PPP can provide secure authentication of
   both sides of a point to point link, it is most often deployed with
   one-way authentication of the subscriber to the ISP, not the ISP to
   the subscriber.

12.2.  Security of Unicast Traffic

   Once the homenet border has been established there are several ways
   to secure HNCP against internal threats like manipulation or
   eavesdropping by compromised devices on a link which is enabled for
   HNCP traffic.  If left unsecured, attackers may perform arbitrary
   eavesdropping, spoofing or denial of service attacks on HNCP services
   such as address assignment or service discovery.

   Detailed interface categories like "leaf" or "guest" can be used to
   integrate not fully trusted devices to various degrees into the
   homenet by not exposing them to HNCP and IGP traffic or by using firewall
   rules to prevent them from reaching homenet-internal resources.

   On links where this is not practical and lower layers do not provide
   adequate protection from attackers, DNCP secure mode MUST be used to
   secure traffic.

12.3.  Other Protocols in the Home

   IGPs and other protocols are usually run alongside HNCP therefore the
   individual security aspects of the respective protocols must be
   considered.  It can however be summarized that many protocols to be
   run in the home (like IGPs) provide - to a certain extent - similar
   security mechanisms.  Most of these protocols do not support
   encryption and only support authentication based on pre-shared keys
   natively.  This influences the effectiveness of any encryption-based
   security mechanism deployed by HNCP as homenet routing information is
   thus usually not encrypted.

13.  IANA Considerations

   IANA is requested to maintain should set up a registry for HNCP TLV-Types.  This
   registry inherits TLV-Types and allocation policy defined in DNCP
   [I-D.ietf-homenet-dncp], but is independent with regard to all TLV-
   Types not specified or reserved by DNCP.  Particularly, other DNCP
   profile may have there own registries, using same the (decimal values within range
   0-1023) "HNCP DNCP-profile TLV numbers.

   The Types" under "Distributed Node
   Consensus Protocol (DNCP)", with the following TLV-Types are defined initial contents: [TO
   BE REMOVED BY RFC-EDITOR: Ideally as http://www.iana.org/assignments/
   hncp-registry]

      0-31: Reserved - specified in this document: the DNCP registry

      32: HNCP-Version

      33: External-Connection

      34: Delegated-Prefix

      35: Assigned-Prefix

      36: Node-Address

      37: DHCPv4-Data

      38: DHCPv6-Data

      39: DNS-Delegated-Zone

      40: Domain-Name

      41: Node-Name

      42: Managed-PSK

      43: Prefix-Policy

      44-512: Free - policy of 'standards action' should be used.

      512-767: Reserved - specified in the DNCP registry

      768-1023: Reserved - to be used for per-implementation
      experimentation.  How collision is avoided is out of scope of this
      document.

   HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP-
   DTLS-PORT, as well as an IPv6 link-local multicast address All-
   Homenet-Routers.
   Homenet-Nodes.

14.  References

14.1.  Normative references

   [I-D.ietf-homenet-dncp]
              Stenberg, M. and S. Barth, "Distributed Node Consensus
              Protocol", draft-ietf-homenet-dncp-07 draft-ietf-homenet-dncp-09 (work in progress),
              July
              August 2015.

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

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC6603]  Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
              "Prefix Exclude Option for DHCPv6-based Prefix
              Delegation", RFC 6603, May 2012.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, November 2005.

   [I-D.ietf-homenet-prefix-assignment]
              Pfister, P., Paterson, B., and J. Arkko, "Distributed
              Prefix Assignment Algorithm", draft-ietf-homenet-prefix-
              assignment-07 (work in progress), June 2015.

14.2.  Informative references

   [RFC7084]  Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
              Requirements for IPv6 Customer Edge Routers", RFC 7084,
              November 2013.

   [RFC3004]  Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
              A., Beser, B., and J. Privat, "The User Class Option for
              DHCP", RFC 3004, November 2000.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
              2131, March 1997.

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

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

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets", BCP
              5, RFC 1918, February 1996.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC7368]  Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
              "IPv6 Home Networking Architecture Principles", RFC 7368,
              October 2014.

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

   [RFC6234]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              February 2013.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, February 2013.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC3442]  Lemon, T., Cheshire, S., and B. Volz, "The Classless
              Static Route Option for Dynamic Host Configuration
              Protocol (DHCP) version 4", RFC 3442, December 2002.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC7084]  Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
              Requirements for IPv6 Customer Edge Routers", RFC 7084,
              November 2013.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217, April 2014.

14.3.  URIs

   [3] http://www.openwrt.org

   [4] http://www.homewrt.org/doku.php?id=run-conf

Appendix A.  Changelog [RFC Editor: please remove]

   draft-ietf-homenet-hncp-08: Editorial reorganization.

   draft-ietf-homenet-hncp-07: Using version 1 instead of version 0, as
   existing implementations already use it.

   draft-ietf-homenet-hncp-06: Various edits based on feedback,
   hopefully without functional delta.

   draft-ietf-homenet-hncp-05: Renamed "Adjacent Link" to "Common Link".
   Changed single IPv4 uplink election from MUST to MAY.  Added explicit
   indication to distinguish (IPv4)-PDs for local connectivity and ones
   with uplink connectivity allowing e.g. allowing, e.g., better local-only
   IPv4-connectivity.

   draft-ietf-homenet-hncp-04: Change the responsibility for sending RAs
   to the router assigning the prefix.

   draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP
   (homenet profile).

   draft-ietf-homenet-hncp-02: Removed any built-in security.  Relying
   on IPsec.  Reorganized interface categories, added requirements
   languages, made manual border configuration a MUST-support.
   Redesigned routing protocol election to consider non-router devices.

   draft-ietf-homenet-hncp-01: Added (MAY) guest, ad-hoc, hybrid
   categories for interfaces.  Removed old hnetv2 reference, and now
   pointing just to OpenWrt + github.  Fixed synchronization algorithm
   to spread also same update number, but different data hash case.
   Made purge step require bidirectional connectivity between nodes when
   traversing the graph.  Edited few other things to be hopefully
   slightly clearer without changing their meaning.

   draft-ietf-homenet-hncp-00: Added version TLV to allow for TLV
   content changes pre-RFC without changing IDs.  Added link id to
   assigned address TLV.

Appendix B.  Draft source [RFC Editor: please remove]

   This draft is available at https://github.com/fingon/ietf-drafts/ in
   source format.  Issues and pull requests are welcome.

Appendix C.  Implementation [RFC Editor: please remove]

   A GPLv2-licensed implementation of HNCP is currently under
   development at https://github.com/sbyx/hnetd/ and binaries are
   available in the OpenWrt [3] package repositories.  See [4] for more
   information.  Feedback and contributions are welcome.

Appendix D.  Acknowledgements

   Thanks to Ole Troan, Mark Baugher, Mark Townsley and Townsley, Juliusz Chroboczek
   and Thomas Clausen for their contributions to the draft.

   Thanks to Eric Kline for the original border discovery work.

Authors' Addresses

   Markus Stenberg
   Independent
   Helsinki  00930
   Finland

   Email: markus.stenberg@iki.fi

   Steven Barth
   Independent
   Halle  06114
   Germany

   Email: cyrus@openwrt.org

   Pierre Pfister
   Cisco Systems
   Paris
   France

   Email: pierre.pfister@darou.fr