Homenet Working Group                                        M. Stenberg
Internet-Draft
Intended status: Standards Track                                S. Barth
Expires: April 30, July 10, 2015
                                                              P. Pfister
                                                           Cisco Systems
                                                         January 6, 2015
                                                        October 27, 2014

                    Home Networking Control Protocol
                       draft-ietf-homenet-hncp-02
                       draft-ietf-homenet-hncp-03

Abstract

   This document describes the Home Networking Control Protocol (HNCP),
   a minimalist state synchronization
   an extensible configuration protocol and a set of requirements for homenet routers.
   home network devices on top of the Distributed Node Consensus
   Protocol (DNCP).  It enables automated configuration of addresses,
   naming, network borders and the seamless use of a routing protocol.

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 April 30, July 10, 2015.

Copyright Notice

   Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . .   3
   3.  Data model  .  DNCP Profile  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Operation  Adjacent Links  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Border Discovery  . . .   4
     4.1.  Trickle-Driven Status Updates . . . . . . . . . . . . . .   4
     4.2.  Protocol Messages . . . . .   5
   6.  Autonomic Address Configuration . . . . . . . . . . . . . . .   4
       4.2.1.  Network State Update (NetState)   6
     6.1.  External Connections  . . . . . . . . . . .   5
       4.2.2.  Network State Request, (NetState-Req) . . . . . . .   7
       6.1.1.  External Connection TLV . .   5
       4.2.3.  Node Data Request (Node-Req) . . . . . . . . . . . .   5
       4.2.4.  Network and Node State Reply (NetNode-Reply) .   7
       6.1.2.  Delegated Prefix TLV  . . .   6
     4.3.  HNCP Protocol Message Processing . . . . . . . . . . . .   6
     4.4.  Adding and Removing Neighbors .   7
       6.1.3.  DHCP Data TLVs  . . . . . . . . . . . . .   7
     4.5.  Purging Unreachable Nodes . . . . . .   8
     6.2.  Prefix Assignment . . . . . . . . . .   8
   5.  Type-Length-Value objects . . . . . . . . . .   9
       6.2.1.  Assigned Prefix TLV . . . . . . . .   8
     5.1.  Request TLVs (for use within unicast requests) . . . . .   8
       5.1.1.  Request Network State TLV . . . .   9
       6.2.2.  Prefix Assignment Algorithm Parameters  . . . . . . .  10
       6.2.3.  Making New Assignments  . . .   9
       5.1.2.  Request Node Data TLV . . . . . . . . . . . .  12
       6.2.4.  Applying Assignments  . . . .   9
     5.2.  Data TLVs (for use in both multi- and unicast data) . . .   9
       5.2.1.  Node Link TLV . . . . . . . . .  12
       6.2.5.  DHCPv6-PD Excluded Prefix Support . . . . . . . . . .  13
       6.2.6.  Downstream Prefix Delegation Support  .   9
       5.2.2.  Network State TLV . . . . . . .  13
     6.3.  Node Address Assignment . . . . . . . . . . .   9
       5.2.3.  Node State TLV . . . . . .  13
     6.4.  Local IPv4 and ULA Prefixes . . . . . . . . . . . . .  10
       5.2.4.  Node Data TLV . .  14
   7.  Configuration of Hosts and non-HNCP Routers . . . . . . . . .  15
     7.1.  DHCPv6 for Addressing or Configuration  . . . . . . . . .  11
       5.2.5.  Neighbor TLV (within Node Data TLV)  15
     7.2.  Sending Router Advertisements . . . . . . . . .  11
     5.3.  Custom TLV (within/without Node Data TLV) . . . . .  16
     7.3.  DHCPv6 for Prefix Delegation  . . .  11
     5.4.  Version TLV (within Node Data TLV) . . . . . . . . . . .  12
   6.  Border Discovery  17
     7.4.  DHCPv4 for Adressing and Prefix Assignment Configuration  . . . . . . . . .  17
     7.5.  Multicast DNS Proxy . . .  12
   7.  DNS-based . . . . . . . . . . . . . . . .  17
   8.  Naming and Service Discovery  . . . . . . . . . . . . . . . . .  17
     7.1.  18
     8.1.  DNS Delegated Zone TLV  . . . . . . . . . . . . . . . . .  17
     7.2.  18
     8.2.  Domain Name TLV . . . . . . . . . . . . . . . . . . . . .  18
     7.3.  Router  19
     8.3.  Node Name TLV . . . . . . . . . . . . . . . . . . . . .  18
   8.  Routing support .  20
   9.  Securing Third-Party Protocols  . . . . . . . . . . . . . . .  20
   10. HNCP Versioning and Capabilities  . . . . . . .  18
     8.1.  Protocol Requirements . . . . . . .  21
   11. Requirements for HNCP Routers . . . . . . . . . . .  18
     8.2.  Announcement . . . . .  22
   12. Security Considerations . . . . . . . . . . . . . . . . .  18
     8.3.  Protocol Selection  . . . . . . . . . . .  23
     12.1.  Border Determination . . . . . . . .  19
     8.4.  Fallback Mechanism . . . . . . . . . .  24
     12.2.  Security of Unicast Traffic  . . . . . . . . .  20
   9.  Security Considerations . . . . .  24
     12.3.  Other Protocols in the Home  . . . . . . . . . . . . . .  21
   10.  25
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   11.  25
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     11.1.  26
     14.1.  Normative references . . . . . . . . . . . . . . . . . .  22
     11.2.  26
     14.2.  Informative references . . . . . . . . . . . . . . . . .  23
     11.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  24  26
   Appendix A.  Some Outstanding Issues  . .  Changelog  . . . . . . . . . . . .  24
   Appendix B.  Some Obvious Questions and Answers . . . . . . . . .  24  28
   Appendix C.  Changelog  . B.  Draft source . . . . . . . . . . . . . . . . . . . .  25  28
   Appendix D.  Draft source . C.  Implementation . . . . . . . . . . . . . . . . . . .  26  28
   Appendix E. D.  Acknowledgements . . . . . . . . . . . . . . . . . .  26  28
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26  29

1.  Introduction

   HNCP is designed to synchronize synchronizes state across a homenet (or other small site) site in order to facilitate allow
   automated configuration within the
   site. network configuration.  The design supports protocol enables use of border
   discovery, IP address prefix distribution
   [I-D.ietf-homenet-prefix-assignment], naming and service discovery other services
   across multiple links[I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf]. links.

   HNCP is designed to provide provides enough information for a routing protocol to operate
   without homenet-specific extensions.  In homenet environments where
   multiple IPv6 prefixes are source-prefixes can be present, routing based on source
   and destination address is necessary
   [I-D.troan-homenet-sadr].  Routing protocol requirements for source
   and destination routing are described in section 3 of
   [I-D.baker-rtgwg-src-dst-routing-use-cases].

   A GPLv2-licensed implementation of the HNCP protocol is currently
   under development at https://github.com/sbyx/hnetd/ and the binaries
   are available in the routing feed of OpenWrt [2] trunk release.  Some
   information how to get started with it is available at [3].  Comments
   and/or pull requests are welcome. [RFC7368].

2.  Requirements language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Data model

   The data model  DNCP Profile

   HNCP is defined as a profile of DNCP [I-D.ietf-homenet-dncp] with the
   following parameters:

   o  HNCP protocol is simple: Every participating
   node has (and also knows for every other participating node):

      A unique node identifier.  It may be uses UDP datagrams on port HNCP-UDP-PORT as a public key, unique hardware
      ID, transport over
      link-local scoped IPv6, using unicast and multicast (group All-
      Homenet-Routers).  Received datagrams with an IPv6 source or some other unique blob of binary data
      destination address which is not link-local scoped MUST be
      ignored.

   o  HNCP can run a
      hash upon operates on multicast-capable interfaces only, thus every
      DNCP Connection Identifier MUST refer to obtain a node identifier that is very likely unique
      among the set of routers in one, except for the homenet.

      A set of Type-Length-Value (TLV) data it wants to share with other
      routers.  The set of TLVs have a well-defined order based on
      ascending binary content that value
      0 which is reserved for internal purposes and MUST NOT be used for
      connection enumeration.  Implementations MAY use a value
      equivalent to quickly identify changes
      in the set as they occur.

      Latest update sequence number.  A 32 bit number that is
      incremented anytime TLV data changes are detected.

      Relative time, in milliseconds, since last publishing of the
      current TLV data set.  It is also 32 bit number on sin6_scope_id for the wire.

4.  Operation given interface.

   o  HNCP is designed to run on UDP port IANA-UDP-PORT, using both link-
   local scoped IPv6 unicast and link-local scoped IPv6 multicast
   messages to address IANA-MULTICAST-ADDRESS for transport.  The
   protocol consists of Trickle [RFC6206] driven multicast status messages to indicate changes SHOULD be secured using DTLS [RFC6347] as
      described in shared TLV data, and unicast state
   synchronization message exchanges when the Trickle state DNCP if exchanged over unsecured links.  UDP on port
      HNCP-DTLS-PORT is found to
   be inconsistent.

4.1.  Trickle-Driven Status Updates

   Each used for this purpose.  A node implementing the
      security mechanism MUST send link-local multicast NetState Messages
   (Section 4.2.1) each time support the Trickle algorithm [RFC6206] indicates
   they should on each link DNCP Pre-Shared Key method,
      SHOULD support the protocol is active on.  When DNCP Certificate Based Trust Consensus and MAY
      support the locally
   stored network state hash changes (either by PKI-based trust method.

   o  HNCP uses opaque 32-bit node identifiers
      (DNCP_NODE_IDENTIFIER_LENGTH = 32).  A node implementing HNCP
      SHOULD generate and use a local random node event that
   affects the identifier.  If it receives
      a Node State TLV data, or upon receipt of more recent data from
   another node), all Trickle instances MUST be reset.  Trickle state
   MUST be maintained separately for each link.

   Trickle algorithm has 3 parameters; Imin, Imax and k.  Imin with the same node identifier and Imax
   represent minimum a higher update
      sequence number, it MUST immediately generate and maximum values for I, use a new random
      node identifier which is the time
   interval during not used by any other node.

   o  HNCP nodes MUST treat all Long Network State Update messages
      received via multicast on a link which at least k Trickle updates must be seen on a
   link to prevent local state transmission.  Bounds for recommended has DNCP security enabled
      as if they were Short Network State Update messages, i.e. they
      MUST ignore all contained Node State TLVs.

   o  HNCP nodes use the following Trickle values are described below.

      k=1 parameters:

      *  k SHOULD be used, as 1, given the timer reset on data updates, updates and
         retransmissions should handle packet loss.

      Imax MUST be at least one minute.

      *  Imin MUST SHOULD be at least 200 milliseconds (earliest but MUST NOT be lower.  Note:
         Earliest transmissions may occur at Imin/2 = 100 milliseconds given minimum values as per the
      Trickle algorithm).

4.2.  Protocol Messages

   Protocol messages are encoded as purely as a sequence of TLV objects
   (Section 5).  This section describes which set of TLVs MUST or MAY Imin / 2.

      *  Imax SHOULD be
   present in a given message.

   In order to facilitate fast comparing 7 doublings of local state with that in a
   received message update, all TLVs in every encoding scope (either
   root level, within the message itself, or within a container TLV) Imin (i.e. 25.6 seconds) but MUST
         NOT be placed in ascending order based on lower.

   o  HNCP nodes MUST use the binary comparison leading 64 bits of
   both TLV header and value.  By design, MD5 [RFC1321] as DNCP
      non-cryptographic hash function H(x).

   o  HNCP nodes MUST use the TLVs which keep-alive extension on all connections.
      The default keep-alive interval (DNCP_KEEPALIVE_INTERVAL) is 20
      seconds, the multiplier (DNCP_KEEPALIVE_MULTIPLIER) MUST be present
   have 2.1,
      the lowest available type values, ensuring they will naturally
   occur at grace-interval (DNCP_GRACE_INTERVAL) SHOULD be equal to
      DNCP_KEEPALIVE_MULTIPLIER times DNCP_KEEPALIVE_INTERVAL.

4.  Adjacent Links

   HNCP uses the start concept of the Protocol Message, resembling a fixed format
   preamble.

4.2.1.  Network State Update (NetState) Adjacent Links for some of its applications.
   This Message SHOULD be sent term is defined as follows:

   If the connection of a multicast message.

   The following TLVs MUST node is detected or configured to be present at an ad-hoc
   interface the start Adjacent Link only consists of said interface.

   Otherwise the message:

      Node Adjacent Link TLV (Section 5.2.1).

      Network State TLV (Section 5.2.2).

   The NetState Message MAY contain Node State TLV(s) (Section 5.2.3).
   If so, either contains all Node State TLVs are included (referred to as a
   "long" NetState Message), or none are included (referred to as interfaces bidirectionally
   reachable from a
   "short" NetState Message).  The NetState Message MUST NOT contain
   only given local interface.  An interface X of a portion node A
   and an interface Y of Node State TLVs as this could cause problems with
   the Protocol Message Processing (Section 4.3) algorithm.  Finally, a node B are bidirectionally reachable if and
   only if node A publishes a Neighbor TLV with the long version of the NetState message would exceed the minimum
   IPv6 MTU when sent, Neighbor Node
   Identifier B, the short version of Neighbor Connection Identifier Y and the NetState message MUST be
   used instead.

4.2.2.  Network State Request, (NetState-Req)

   This Message MUST be sent as Local
   Connection Identifier X and node B publishes a unicast message.

   The following TLVs MUST be present at the start of the message:

      Node Link TLV (Section 5.2.1).

      Request Network State Neighbor TLV (Section 5.1.1).

4.2.3. with the
   Neighbor Node Data Request (Node-Req)

   This Message MUST be sent as Identifier A, a unicast message.

   MUST be present:

      Node Link TLV (Section 5.2.1).

      one or more Request Node Data TLVs (Section 5.1.2).

4.2.4.  Network Neighbor Connection Identifier X and Node State Reply (NetNode-Reply)

   This Message MUST be sent as
   the Local Connection Identifier Y.  In addition a unicast message. node MUST be present:

      Node able
   to detect whether two of its local interfaces belong to the same
   Adjacent Link TLV (Section 5.2.1).

      Network State TLV (Section 5.2.2) and Node State TLV
      (Section 5.2.3) for every known node either by the sender, or

      one local means or more combinations of Node State by inferring that from the
   bidirectional reachability between two different local interfaces and Node Data TLVs
      (Section 5.2.4).

4.3.  HNCP Protocol Message Processing

   The majority of status updates among known nodes are handled via
   the
   Trickle-driven updates (Section 4.1). same remote interface.

5.  Border Discovery

   HNCP associates each HNCP interface with a category (e.g., internal
   or external).  This section describes
   processing of messages as received, along with associated actions defines the border discovery algorithm
   derived from the edge router interactions described in the Basic
   Requirements for IPv6 Customer Edge Routers [RFC7084].  This
   algorithm is suitable for both IPv4 and IPv6 (single or
   responses. dual-stack)
   and determines whether an HNCP interface is designed to operate between directly connected neighbors on a
   shared link using link-local IPv6 addresses.  If internal, external, or
   uses another fixed category.  This algorithm MUST be implemented by
   any router implementing HNCP.

   In order to avoid conflicts between border discovery and homenet
   routers running DHCPv4 [RFC2131] or DHCPv6-PD [RFC3633] servers, each
   router MUST implement the source address
   of following mechanism based on The User Class
   Option for DHCPv4 [RFC3004] and its DHCPv6 counterpart [RFC3315]:

   o  An HNCP router running a received DHCP client on a homenet interface MUST
      include a DHCP User-Class consisting of the ASCII-String
      "HOMENET".

   o  An HNCP packet router running a DHCP server on a homenet interface MUST
      ignore or reject DHCP-Requests containing a DHCP User-Class
      consisting of the ASCII-String "HOMENET".

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

   1.  If a fixed category is not an IPv6 link-local unicast address, configured for the packet SHOULD interface, it MUST be dropped.  Similarly, if
       used.

   2.  If a delegated prefix could be acquired by running a DHCPv6
       client on the destination address
   is not IPv6 link-local unicast or IPv6 link-local multicast address,
   packet SHOULD interface, it MUST be dropped.

   Upon receipt of:

      NetState Message (Section 4.2.1): considered external.

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

   4.  Otherwise the message matches interface MUST be considered internal.

   A router MUST allow setting a category of either auto-detected,
   internal or external for each interface which is suitable for both
   internal and external connections.  In addition the hash following
   specializations of the locally stored network state,
      consider Trickle state as consistent with no further processing
      required.  If internal category are defined to modify the hashes do not match,
   local router behavior:

   Leaf category:  This declares an interface used by client devices
      only.  A router MUST consider Trickle state such interface as
      inconsistent.  In internal but MUST
      NOT send nor receive HNCP messages on such interface.  A router
      SHOULD implement this case, if category.

   Guest category:  This declares an interface used by untrusted client
      devices only.  In addition to the message is "short" (contains
      zero Node State TLVs), reply with a NetState-Req Message
      (Section 4.2.2).  If restrictions of the message was in long format (contained all
      Node State TLVs), reply with NodeState-Req Leaf
      category, connected devices MUST NOT be able to reach other
      devices inside the HNCP network nor query services advertised by
      them unless explicitly allowed, instead they SHOULD only be able
      to reach the internet.  This category SHOULD be supported.

   Ad-hoc category:  This configures an interface to be ad-hoc
      (Section 4.2.3) for any
      nodes for which local information is outdated (local update number 4) and MAY be implemented.

   Hybrid category:  This declares an interface to be internal while
      still using external connections on it.  It is lower than assumed that within the message), potentially incorrect
      (local update number
      link is same and under control of a legacy, trustworthy non-HNCP router,
      still within the hash same network.  Detection of node data TLV
      differs) or missing.  Note that if local information this category
      automatically in addition to manual configuration is more
      recent than that out of scope
      for this document.  This category MAY be implemented.

   Each router MUST continuously scan each active interface that does
   not have a fixed category in order to dynamically reclassify it if
   necessary.  The router therefore runs an appropriately configured
   DHCPv4 and DHCPv6 client as long as the neighbor, there interface is no need active including
   states where it considers the interface to send a
      message.

      NetState-Req (Section 4.2.2): Provide requested data in be internal.  The router
   SHOULD wait for a NetNode-
      Reply Message containing Network State TLV and all Node State
      TLVs.

      NodeState-Req (Section 4.2.3): Provide requested data in reasonable time period (5 seconds as a
      NetNode-Reply containing Node State and Node Data TLVs.

      State-Reply (Section 4.2.4): If the message contains Node State
      TLVs that are more recent than local state (higher update number,
      different node data TLV hash, or we lack the node data
      altogether), and if the message also contains corresponding Node
      Data TLVs, update local state and reset Trickle.  If the message
      is lacking Node Data TLVs for some Node State TLVs default),
   during which are more
      recent than local state, reply with a NodeState-Req
      (Section 4.2.3) for the corresponding nodes.

   Each node is responsible for publishing DHCP clients can acquire a valid set of data TLVs.
   When there is lease, before treating a change in
   newly activated or previously external interface as internal.  Once
   it treats a node's set of data TLVs, the update
   number certain interface as internal it MUST be incremented accordingly.

   If a message containing Node State TLVs (Section 5.2.3) is received
   via unicast or multicast start forwarding
   traffic with the node's own node identifier and a
   higher update number than current local value, or the same update
   number appropriate source addresses between its internal
   interfaces and different hash, there is an error somewhere.  A
   recommended default way to handle this is allow internal traffic to attempt reach external networks
   according to assert local
   state by increasing the local update number to routes it publishes.  Once a value higher than
   that received and republish node data using router detects an
   interface transitioning to external it MUST stop any previously
   enabled internal forwarding.  In addition it SHOULD announce the same node identifier.
   If this happens more than 3 times
   acquired information for use in 60 seconds and the local node
   identifier is not globally unique, there may be more than one router
   with the same node identifier on network as described in later
   sections of this draft if the interface appears to be connected to an
   external network.  If there is no global
   guarantee of unique node identifier, a new node identifier SHOULD be
   generated and node data republished accordingly.

   In all cases, if node data for any node changes, all Trickle
   instances MUST be considered inconsistent (I=Imin + timer reset).

4.4.  Adding

6.  Autonomic Address Configuration

   This section specifies how HNCP routers configure host and Removing Neighbors

   Whenever multicast message or unicast reply is received on a link router
   addresses.  At first border routers share information obtained from another node, the node should be added
   service providers or local configuration by publishing one or more
   External Connection TLVs.  These contain other TLVs such as Neighbor TLV
   (Section 5.2.5) Delegated
   Prefix TLVs which are then used for current node.  If nothing (for example - no
   router advertisements, no prefix assignment.  Finally, HNCP traffic) is received from that
   neighbor in Imax seconds
   routers obtain addresses using a stateless (SLAAC-like) procedure or
   a specific stateful mechanism and the neighbor is not in neighbor
   discovery cache, hosts and no layer 2 indication 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 presence such prefix is available,
   at least 3 attempts set to ping it with request network state message
   (Section 4.2.2) SHOULD be sent with increasing timeouts (e.g. 1, 2, 4
   seconds).  If even after suitable period after 96 plus the last message
   nothing
   IPv4 prefix length.

6.1.  External Connections

   Each HNCP router MAY obtain external connection information from one
   or more sources, e.g.  DHCPv6-PD [RFC3633], NETCONF [RFC6241] or
   static configuration.  This section specifies how such information is received, the Neighbor
   encoded and advertised.

6.1.1.  External Connection TLV

   An External Connection TLV MUST be removed so that there
   are no dangling neighbors.  As an alternative, if there is a layer 2
   unreachability notification of some sort available for either whole
   link or for individual neighbor, it MAY be container-TLV used to immediately
   trigger removal of corresponding Neighbor TLV(s).

4.5.  Purging Unreachable Nodes

   When gather network
   configuration information associated with a single external
   connection.  A node data has changed, the neighbor graph SHOULD be traversed
   for each node following the bidirectional neighbor relationships.
   These are identified by looking for neighbor MAY publish zero, one or more instances 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: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Nested TLVs on both nodes, that
   have                          |

   The External Connection TLV is a container which:

   o  MAY contain zero, one or more Delegated Prefix TLVs.

   o  MUST NOT contain multiple Delegated Prefix TLVs with the remote node's identifier hash as h(neighbor node
   identifier), and local and neighbor link identifiers swapped.  After same
      prefix.  In such a situation, the traverse, unreachable nodes SHOULD container MUST be purged after some grace
   period.  During the grace period, ignored.

   o  MAY contain at most one DHCPv6 Data TLV and at most one DHCPv4
      Data TLV encoding options associated with the unreachable nodes External Connection
      but MUST NOT be
   used for calculation contain more than one of network state hash, or even be provided to
   any applications that need to use each otherwise the whole
      External Connection TLV graph.

5.  Type-Length-Value objects

   Every MUST be ignored.

   o  MAY contain other TLVs for future use.

6.1.2.  Delegated Prefix TLV

   The Delegated Prefix TLV is encoded as 2 octet type, followed used by 2 octet length (of HNCP routers to advertise
   prefixes which are allocated to the whole TLV, including header; 4 means no value), network and then the
   value itself (if any).  The actual length of TLV MUST be always
   divisible by 4; if the length of the value is not, zeroed padding
   bytes MUST will be inserted at the end of TLV.  The padding bytes used
   for prefix assignment.  All Delegated Prefix TLVs MUST NOT be included nested in the length field.
   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  Type: DELEGATED-PREFIX (34)  |           Length          Length: >= 9         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Value                        Valid Lifetime                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (variable # of bytes)                      Preferred Lifetime                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Encoding of type=123 (0x7b)
   | Prefix Length |                                               |
   +-+-+-+-+-+-+-+-+            Prefix [+ nested TLVs]             +
   |                                                               |

   Valid Lifetime:   The time in seconds the delegated prefix is valid.
      The value is relative to the point in time the Node-Data TLV with was
      last published.  It MUST be updated whenever the node republishes
      its Node-Data TLV.

   Preferred Lifetime:   The time in seconds the delegated prefix is
      preferred.  The value 'x' (120 = 0x78): 007B
   0005 7800 0000

   Notation:

      .. = octet string concatenation operation

      H(x) = MD5 hash is relative to the point in time the Node-
      Data TLV was last published.  It MUST be updated whenever the node
      republishes its Node-Data TLV.

   Prefix Length:   The number of x

      H-64(x) = H(x) truncated by taking just first 64 significant bits in the Prefix.

   Prefix:   Significant bits of the
      result.

5.1.  Request prefix padded with zeroes up to the
      next byte boundary.

   Nested TLVs:  Other TLVs (for use within unicast requests)
5.1.1.  Request Network State included in the Delegated Prefix TLV and
      starting at the next 32 bits boundary following the end of the
      encoded prefix.

         If the encoded prefix represents an IPv6 prefix, at most one
         DHCPv6 Data TLV MAY be included.

         If the encoded prefix represents an IPv4-mapped IPv6 address,
         at most one DHCPv4 Data TLV MAY be included.

         It MAY contain other TLVs for future use.

6.1.3.  DHCP Data TLVs

   Auxiliary connectivity information is encoded as a stream of DHCP
   options.  Such TLVs MUST only be present in an External Connection
   TLV or a Delegated Prefix TLV.  When included in an External
   Connection TLV, they MUST contain DHCP options which are relevant to
   the whole External Connection.  When included in a Delegated Prefix,
   they MUST contain DHCP options which are specific to the Delegated
   Prefix.

   The DHCPv6 Data TLV uses 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: REQ-NETWORK-STATE (2) DHCPV6-DATA (37)     |          Length: 4 > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.1.2.  Request Node
   |                      DHCPv6 option stream                     |

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

   The DHCPv4 Data TLV uses 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: REQ-NODE-DATA (3) DHCPV4-DATA (38)    |          Length: 20 > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DHCPv4 option stream                    |
   |                       H(node identifier)                      |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.  Data TLVs (for use

   DHCPv4 option stream:   DHCPv4 options encoded as specified in both multi-
      [RFC2131].

6.2.  Prefix Assignment

   HNCP uses the Distributed Prefix Assignment Algorithm specified in
   [I-D.ietf-homenet-prefix-assignment] in order to assign prefixes to
   HNCP internal links and unicast data)

5.2.1.  Node Link uses the terminology defined there.

6.2.1.  Assigned Prefix TLV

   Published Assigned Prefixes MUST be advertised 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: NODE-LINK (1) ASSIGNED-PREFIX (35)   |          Length: 24 >= 6         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                       H(node identifier)                      |
   |                                                               |
   |                     Connection Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link-Identifier                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.2.  Network State 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  Rsv. |    Type: NETWORK-STATE (4) Prty. |          Length: 20 Prefix Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            Prefix             +
   |                                                               |          H(H(node data TLV 1) .. H(node data

   Connection Identifier:   The DNCP Connection Identifier of the link
      the prefix is assigned to, or 0 if the link is a Private Link.

   Rsv.:   Bits reserved for future use.  MUST be set to zero when
      creating this TLV N))          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and ignored when parsing it.

   Prty:   The Node Data TLVs are ordered 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 used unless
         specified in the router's configuration.

      12-14:  Reserved for hashing future use.

      15   :  Provider priorities.  MAY only be used by octet comparison of the router
         advertising the corresponding node identifier hashes delegated prefix and 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 ascending order.

5.2.3. the Prefix field.

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

6.2.2.  Prefix Assignment Algorithm Parameters

   All HNCP nodes running the prefix assignment algorithm MUST use the
   following parameters:

   Node State 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-STATE (5)     |          Length: 44           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                       H(node identifier)                      |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Update Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Milliseconds since Origination                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                        H(node data TLV)                       |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IDs:   DNCP Node Identifiers are used.  The whole network should have roughly 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 HNCP internal, leaf, guest or
      hybrid links.  It is dynamically updated as HNCP links are added,
      removed, become internal or cease to be.

   Set of Private Links:   This document defines Private Links
      representing DHCPv6-PD clients or as a mean to advertise prefixes
      included in the same idea about DHCPv6 Exclude Prefix option.  Other
      implementation-specific Private Links may exist.

   Set of Advertised Prefixes:   The set of prefixes included in
      Assigned Prefix TLVs advertised by other HNCP routers.  The
      associated Advertised Prefix Priority is the time
   since origination, i.e. even priority specified in
      the originating router should increment TLV.  The associated Shared Link is determined as follows:

      *  If the time whenever it needs to send a new Node State TLV regarding
   itself without changing Link Identifier is zero, the corresponding Node Data TLV.  This age
   value Advertised Prefix is not included within
         assigned on a Shared Link.

      *  If the Node Data TLV, however, as that Link Identifier is
   immutable and potentially signed by not zero the originating node at Shared Link is equal to
         the time
   of origination.

5.2.4.  Node Data TLV

   0                   1                   2                   3 Adjacent Link (Section 4).  Advertised Prefixes as well as
         their associated priorities and associated Shared Links MUST be
         updated as Assigned Prefix TLVs or Neighbor TLVs are added,
         removed or updated.

   ADOPT_MAX_DELAY:   The default value is 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-DATA (6)      |        Length: >= 24          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                       H(node identifier)                      |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Update Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Nested TLVs containing node information            |

5.2.5.  Neighbor TLV (within Node 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 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 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Type: NEIGHBOR (8)      |          Length: 28           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                  H(neighbor node identifier)                  |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Neighbor Link Identifier                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Local Link Identifier                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This TLV indicates that the node seconds.

   Default Advertised Prefix Priority:   When a new assignment is
      created or an assignment is adopted - as specified in question vouches that the
   specified neighbor prefix
      assignment algorithm routine - the default Advertised Prefix
      Priority to be used is reachable by it on 2.

6.2.3.  Making New Assignments

   Whenever the local link id given.
   This reachability Prefix Assignment Algorithm routine is run on an
   Adjacent Link and whenever a new prefix may be unidirectional (if no unicast exchanges have
   been performed with the neighbor).  The presence assigned (case 1 of this TLV at least
   guarantees that
   the node publishing it has received traffic from routine), the
   neighbor recently.  For guaranteed bidirectional reachability,
   existence decision of both nodes' matching Neighbor TLVs should be checked.

5.3.  Custom whether the assignment of a new prefix
   is desired MUST follow these rules:

      If the Delegated Prefix TLV (within/without Node contains a DHCPv4 or 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: CUSTOM-DATA (9)     |         Length: >= 12         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            H-64(URI)                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Opaque Data                          |

   This TLV can be used to contain anything; TLV,
      and the URI used should be
   under control meaning of one of the DHCP options is not understood by
      the HNCP router, the creation of a new prefix is not desired.

      If the author remaining preferred lifetime of that specification.  For example:

   V=H-64('http://example.com/author/json-for-hncp') .. '{"cool": "json
   extension!"}'

   or

   V=H-64('mailto:author@example.com') .. '{"cool": "json extension!"}'

5.4.  Version TLV (within Node 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 the prefix is 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: VERSION (10)        |         Length: >= 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Version                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          User-agent                           |

   This TLV indicates which and there
      is another delegated prefix of the same IP version used for prefix
      assignment with a non-null preferred lifetime, the creation of HNCP TLV binary structures a
      new prefix is in
   use by this particular node.  All TLVs within node data from nodes
   that do not publish version TLV, or with different Version value than
   locally supported desired.

      Otherwise, the creation of a new prefix is 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 ignored (but forwarded).  The user-
   agent selected unless configured otherwise by an
   administrator.  In case no prefix of length 64 would be available, a
   longer prefix MAY be selected.

   If the considered delegated prefix is an optional human-readable UTF-8 string that can describe
   e.g. current HNCP implementation version.  This draft describes
   Version=1 TLVs.

6.  Border Discovery and Prefix Assignment

   This section defines border discovery algorithm derived from the edge
   router interactions described in the Basic Requirements for IPv6
   Customer Edge Routers [RFC7084].  The algorithm is designed to work
   for both IPv4 and IPv6 (single or dual-stack). prefix ( Section 6.4
   details how IPv4 delegated prefixes are generated), a prefix of
   length 24 SHOULD be preferred.

   In order to avoid conflicts between border discovery and homenet
   routers running DHCP [RFC2131] or DHCPv6-PD [RFC3633] servers each any case, a router MUST implement the following support a mechanism based suitable to distribute
   addresses from the considered prefix to clients on The User Class
   Option for DHCP [RFC3004] the link.
   Otherwise it MUST NOT create or its DHCPv6 counterpart [RFC3315]
   respectively into its DHCP and DHCPv6-logic:

      A homenet router running a DHCP-client on adopt it, i.e. a homenet-interface router assigning an
   IPv4 prefix MUST
      include a DHCP User-Class consisting of support the ASCII-String
      "HOMENET".

      A homenet router running a DHCP-server on L-capability and a homenet-interface router assigning an
   IPv6 prefix not suitable for stateless autoconfiguration MUST
      ignore or reject DHCP-Requests containing a DHCP User-Class
      consisting of support
   the ASCII-String "HOMENET". H-capability as defined in Section 10.

6.2.4.  Applying Assignments

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

   1.  If indicates when a fixed category prefix is set for applied to
   the respective Adjacent Link.  When that happens each router
   connected to said link:

      MUST create an interface, appropriate on-link route for said prefix and
      advertise it using the chosen routing protocol.

      MUST be used.

   2.  Any of participate in the following conditions indicate client configuration election as described
      in Section 7.

      MAY add an address from said prefix to the respective network
      interface MUST be
       considered external:

       1.  A as described in Section 6.3.

6.2.5.  DHCPv6-PD Excluded Prefix Support

   Whenever a DHCPv6 Prefix Exclude option [RFC6603] is received with a
   delegated prefix, the excluded prefix could MUST be acquired by running advertised as assigned
   to a
           DHCPv6-client on Private Link with the interface.

       2.  An IPv4-address could maximum priority (i.e. 15).

   The same procedure MAY be acquired applied in order to exclude prefixes
   obtained by running a DHCP-client on
           the interface.

   3.  As default fallback, interface MUST be considered internal.

   A other means of configuration.

6.2.6.  Downstream Prefix Delegation Support

   When an HNCP router MUST allow setting receives a category of either auto-detected,
   internal or external request for each interface which is suitable prefix delegation, it
   SHOULD assign one prefix per delegated prefix, wait for both
   internal them to be
   applied, and external connections.  In addition the following
   specializations of the internal category are defined delegate them to modify the
   local router behavior:

      Leaf category: This declares client.  Such assignment MUST be
   done in accordance with the Prefix Assignment Algorithm.  Each client
   MUST be considered as an interface used by clients only.  A
      router SHOULD implement this category independent Private Link and delegation MUST NOT send nor accept
      HNCP messages
   be based on these interfaces.

      Guest category: This declares an interface used by untrusted
      clients only.  In addition to the restrictions same set of the leaf
      category, clients connected to these interfaces Delegated Prefixes.

   The assigned prefixes MUST NOT be able given to reach devices inside the home network by default clients before they are
   applied, and instead
      SHOULD only be able to reach the internet.  This category SHOULD MUST be also supported.

      Ad-hoc category: This declares withdrawn whenever they are destroyed.  As an interface to be in ad-hoc mode.
      This indicates
   exception to HNCP applications such as prefix assignment that
      links on this interface are potentially non-transitive.  This
      category MAY be implemented.

      Hybrid category: This allows the rule a router to still accepts external
      connections MAY prematurely give out a prefix
   which is advertised but does not do border discovery.  It is assumed that
      the link is under control of yet applied if it does so with a legacy, trustworthy non-HNCP
      router, still within the same home network.  Detection valid
   lifetime of this
      category automatically in addition not more than 30 seconds and ensures removal or
   correction of lifetimes as soon as possible to manual configuration is out shorten delays of scope for this document.
   processed requests.

6.3.  Node Address Assignment

   This category MAY be implemented.

   A homenet router SHOULD provide basic connectivity to legacy CERs
   [RFC7084] connected to internal interfaces in order section specifies how HNCP nodes reserve addresses for their own
   use.  Nodes MAY, at any time, try to allow
   coexistence with existing devices.

   Each router MUST continuously scan each active interface that does
   not have reserve a fixed category in order to dynamically reclassify it if
   necessary. new address.  SLAAC
   SHOULD be used whenever possible.  The router therefore runs following method MUST be used
   otherwise.

   For any IPv6 prefix longer than 64 bits (resp. any IPv4 prefix)
   assigned to an appropriately configured
   DHCP and DHCPv6-client as long as Adjacent Link, the interface is active including
   states where it considers first quarter of the interface addresses are
   reserved for routers HNCP based assignments, whereas the last three
   quarters are left to be internal.  The the DHCPv6 (resp.  DHCPv4) elected router
   SHOULD wait for a reasonable time period (5 seconds as a possible
   default) in which
   (Section 10 specifies the DHCP-clients can acquire a lease before
   treating a newly activated or previously external interface as
   internal.  Once it treats a certain interface as internal it MUST
   start forwarding traffic with appropriate source addresses between
   its internal interfaces DHCP server election process).  For
   instance, if the prefix 192.0.2.0/24 is assigned and allow internal traffic applied to reach external
   networks.  Once a router detects an interface to be external it MUST
   stop any previously enabled internal forwarding.  In addition it
   SHOULD announce the acquired information for use
   Adjacent Link, addresses included in 192.0.2.0/26 are reserved for
   HNCP nodes and the homenet as
   described in later sections of this draft if the interface appears to
   be connected to an external network.

   To distribute an external connection in remaining addresses are reserved for the homenet an edge router
   announces one or more delegated prefixes and associated DHCP(v6)-
   encoded auxiliary information like recursive DNS-servers.  Each
   external connection is announced elected
   DHCPv4 server.

   HNCP routers assign themselves addresses using one container-TLV as follows: 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: EXTERNAL-CONNECTION (41)| NODE-ADDRESS (36)    |           Length: > 4 20          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Nested TLVs                     Connection Identifier                     |

   Auxiliary connectivity information
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           IP Address                          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Connection Identifier:   The DNCP Connection Identifier of the link
      the address is assigned to, or 0 if it is not assigned on an HNCP
      enabled link.

   IP Address:   The IPv6 address, or the IPv4 address encoded as a stream an
      IPv4-mapped IPv6 address [RFC4291].

   The process of
   DHCPv6-attributes or DHCP-attributes placed inside a TLV 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 be in the first quarter of type
   EXTERNAL-CONNECTION or DELEGATED-PREFIX (for IPv6 prefix-specific
   information).  There an assigned
      prefix currently applied on the specified link.

   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 same address is advertised by more than one instance of this TLV
   inside a container and node all
      but the order of one advertised by the DHCP(v6)-attributes contained
   within it node with the highest node
      identifier MUST be preserved as long as the information contained does
   not change.  The TLVs removed.

6.4.  Local IPv4 and ULA Prefixes

   HNCP routers can create an ULA or private IPv4 prefix to enable
   connectivity between local devices.  These prefixes are encoded inserted in
   HNCP as follows:

   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 if they were delegated prefixes.  The following rules apply:

      An HNCP router SHOULD create an ULA prefix if there is no other
      non-deprecated IPv6 prefix in the network.  It MAY also do so if
      there are other delegated IPv6 prefixes but none of which is a
      non-deprecated ULA but MUST NOT do so otherwise.  Whenever it
      detects another non-deprecated ULA being advertised it MUST cease
      to announce its locally generated one.  It MAY also do so once it
      detects a non-deprecated non-ULA IPv6 delegated prefix.

      An HNCP router MUST create a non-deprecated private IPv4 prefix
      [RFC1918] whenever it wishes to provide external IPv4 connectivity
      to the network and no other non-deprecated private IPv4 prefix
      currently exists.  It MAY also create a deprecated private IPv4
      prefix if no IPv4 prefix exists and it wants to enable local IPv4
      connectivity but MUST NOT do so otherwise.  In case multiple IPv4
      prefixes are announced all but one MUST be removed while non-
      deprecated ones take precedence over deprecated ones and
      announcements by nodes with a higher node identifier take
      precedence over those with a lower one.  The router publishing the
      non-deprecated prefix MUST announce an IPv4 default route using
      the routing protocol and perform NAT on behalf of the network as
      long as it publishes the prefix, other routers in the network MUST
      NOT.

   Creation of such ULA and IPv4 prefixes MUST be delayed by a random
   timespan between 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: DHCPV6-DATA (45)     |          Length: > 4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | and 10 seconds in which the router MUST scan for
   other nodes trying to do the same.

   When a new ULA prefix is created, the prefix is selected based on the
   configuration, using the last non-deprecated ULA prefix, or generated
   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 an
   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 to participate as a candidate in the election.

7.1.  DHCPv6 for Addressing or Configuration

   In general stateless address configuration is preferred whenever
   possible since it enables fast renumbering and low overhead, however
   stateful DHCPv6 can be useful in addition to collect hostnames and
   use them to provide naming services or if stateless configuration is
   not possible for the assigned prefix length.

   The designated stateful DHCPv6 server for a link is elected based on
   the capabilities described in Section 10.  The winner is the router
   connected to the Adjacent Link (Section 4) advertising the greatest
   H-capability.  In case of a tie, Capability Values and node
   identifiers are considered (greatest value is elected).  The elected
   router MUST serve stateful DHCPv6 and Router Advertisements on the
   given link.  Furthermore it MUST provide naming services for acquired
   hostnames as outlined in Section 8.  Stateful addresses being handed
   out SHOULD have a low preferred lifetime (e.g. 1s) to not hinder fast
   renumbering if either the DHCPv6 server or client do not support the
   DHCPv6 reconfigure mechanism and the address is from a prefix for
   which stateless autoconfiguration is supported as well.  In case no
   router was elected, stateful DHCPv6 is not provided and each router
   assigning IPv6 prefixes on said link MUST serve Router Advertisements
   and stateless DHCPv6.

7.2.  Sending Router Advertisements

   The HNCP router being elected as DHCPv6 server for addressing or
   configuration MUST send Router Advertisements periodically via
   multicast and via unicast in response to Router Solicitations.  In
   addition other routers on the link MAY announce Router
   Advertisements.  This might result in a more optimal routing decision
   for clients.  The following rules MUST be followed when sending
   Router Advertisements:

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

      The default Router Lifetime MUST be set to an appropriate non-null
      value whenever an IPv6 default route is known in the HNCP network
      and MUST be set to zero otherwise.

      A Prefix Information Option MUST be added for each assigned and
      applied IPv6 prefix on the given link.  The autonomous address-
      configuration flag MUST be set whenever the prefix is suitable for
      stateless configuration.  The preferred and valid lifetimes MUST
      be smaller than the preferred and valid lifetimes of the delegated
      prefix the prefix is from.  When a prefix is removed, it MUST be
      deprecated as specified in [RFC7084].

      A Route Information Option [RFC4191] MUST be added for each
      delegated IPv6 prefix known in the HNCP network.  Additional ones
      SHOULD be added for each non-default IPv6 route with an external
      destination advertised by the routing protocol.

      A Recursive DNS Server Option and a DNS Search List Option MUST be
      included with appropriate contents.

      To allow for optimized routing decisions for clients on the local
      link routers SHOULD adjust their Default Router Preference and
      Route Preferences [RFC4191] so that the priority is set to low if
      the next hop of the default or more specific route is on the same
      interface as the Route Advertisement being sent on.  Similarly the
      router MAY use the high priority if it is certain it has the best
      metric of all routers on the link for all routes known in the
      network with the respective destination.

   Every router sending Router Advertisements MUST immediately send an
   updated Router Advertisement via multicast as soon as it notices a
   condition resulting in a change of any advertised information.

7.3.  DHCPv6 attribute stream                    | for Prefix Delegation

   The designated DHCPv6 server for prefix-delegation on a link is
   elected based on the capabilities described in Section 10.  The
   winner is the router connected to the Adjacent Link (Section 4)
   advertising the greatest P-capability.  In case of a tie, Capability
   Values and

   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 Node Identifiers are considered (greatest value is
   elected).  The elected router MUST provide prefix-delegation services
   [RFC3633] on the given link and follow the rules in Section 6.2.6.

7.4.  DHCPv4 for Adressing and Configuration

   The designated DHCPv4 server on a link is elected based on the
   capabilities described in Section 10.  The winner is the router
   connected to the Adjacent Link (Section 4) advertising the greatest
   L-capability.  In case of a tie, Capability Values and node
   identifiers are considered (greatest value is elected).  The elected
   router MUST provide DHCPv4 services on the given link.

   The DHCPv4 serving router MUST announce itself as router [RFC2132] to
   clients if and only if there is an IPv4 default route known in the
   network.  In addition the router SHOULD announce a Classless Static
   Route Option [RFC3442] for each non-default IPv4 route advertised in
   the routing protocol with an external destination.

   DHCPv4 lease times SHOULD be short (i.e. not longer than 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: DHCP-DATA (44)      |          Length: > 4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      DHCP attribute stream                    |

   Each delegated prefix minutes)
   in order to provide reasonable response times to changes.

7.5.  Multicast DNS Proxy

   The designated MDNS [RFC6762]-proxy on a link is encoded using one TLV inside elected based on the
   capabilities described in Section 10.  The winner is the router with
   the highest Node Identifier among those with the highest Capability
   Value on the link that support the M-capability.  The elected router
   MUST provide an EXTERNAL-
   CONNECTION TLV.  For external IPv4 connections MDNS-proxy on the prefix is encoded 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 form
   user-friendliness of an IPv4-mapped address [RFC4291] IPv6 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 or
   user-configured name for each internal Adjacent Link (Section 4) for
   which it is usually from a
   private address range [RFC1918]. the designated DHCPv4, stateful DHCPv6 server or MDNS
   [RFC6762]-proxy and for which it provides DNS-services on behalf of
   devices on said link.  In addition it MAY provide reverse lookup
   services.

   The related following TLVs are defined and MUST be supported by all nodes
   implementing naming and service discovery:

8.1.  DNS Delegated Zone TLV

   This TLV is defined as
   follows. 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.  There MUST NOT be more than
   one delegation for the same zone in the whole DNCP network.  In case
   of a conflict the announcement of the node with the highest node
   identifier takes precedence and all other nodes MUST cease to
   announce the conflicting 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 (42) DNS-DELEGATED-ZONE (39) |        Length: >= 13 17          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Valid until (milliseconds)                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Preferred until (milliseconds)                           IP Address                          |
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                               | Prefix Length
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |reserved |L|B|S|                                               |
   +-+-+-+-+-+-+-+-+        Prefix Address [+ nested TLVs]         +  Zone (DNS label sequence - variable length)  |
   |

      Valid until                                                               |

      IP Address is the time in milliseconds IPv6 address of the delegated prefix is
      valid. authoritative DNS server for
      the zone; IPv4 addresses are represented as IPv4-mapped addresses
      [RFC4291].  The special value is relative to the point in time of :: (all-zero) means the TLV is
      first announced.

      Preferred until
      delegation is the time available in milliseconds the delegated prefix
      is preferred.  The value is relative to the point global DNS-hierarchy.

      reserved bits MUST be zero when creating and ignored when parsing
      this TLV.

      L-bit (DNS-SD [RFC6763] Legacy-Browse) indicates that this
      delegated zone should be included in time the TLV
      is first announced.

      Prefix length specifies the number network's DNS-SD legacy
      browse list of significant bits 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
      prefix.

      Prefix address is network's DNS-SD browse list of variable length and contains the significant
      bits 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 the prefix padded a fully-qualified DNS-SD domain,
      which should be used as base for DNS-SD domain enumeration, 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 zeroes up
      this flag SHOULD be added to the next byte
      boundary.

      Nested TLVs might contain prefix-specific information like
      DHCPv6-options.

   In order for routers search domains advertised to use
      clients.

      Zone is the distributed information, prefixes and
   addresses have label sequence of the zone, encoded according to
      [RFC1035].  Compression MUST NOT be assigned used.  The zone MUST end with
      an empty label.

8.2.  Domain Name TLV

   This TLV is used to indicate the interior links of base domain name for the homenet.
   A router MUST therefore implement network.
   It is the algorithm defined in Prefix and
   Address Assignment in zone used as a Home Network
   [I-D.ietf-homenet-prefix-assignment]. base for all non fully-qualified delegated
   zones and node names.  In order to announce case of conflicts the
   assigned prefixes announced domain of
   the following TLVs are defined.

   Each assigned prefix is given to an interior link and is encoded
   using one TLVs.  Assigned IPv4 prefixes are stored as mapped
   IPv4-addresses.  The TLV node with the highest node identifier takes precedence.  By
   default ".home" is defined as follows: used, i.e. if no node advertises such a 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 (43) DOMAIN-NAME (40)     |         Length: >= 9         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link Identifier > 0           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  R. |A| Pref. | Prefix Length |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Prefix Address        +
   |        Domain (DNS label sequence - variable length)          |

      Link Identifier
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Domain is the local HNCP identifier of the link the
      prefix is assigned to.

      R. is reserved for future additions and label sequence encoded according to [RFC1035].
      Compression MUST NOT be set to 0 when
      creating TLVs and ignored when parsing them.

      A is the authoritative flag which indicates that used.  The zone MUST end with an assignment empty
      label.

8.3.  Node Name TLV

   This TLV is
      enforced and ignores usual collision detection rules.

      Pref. describes the preference of the assignment and can be used to differentiate assign the importance name of a given assignment over others.

      Prefix length specifies the number of significant bits node in the
      prefix.

      Prefix address is network to a
   certain IP address.  In case of variable length and contains conflicts the significant
      bits announcement of the prefix padded
   node with zeroes up to the next byte
      boundary.

   In some cases (e.g.  IPv4) the set of addresses is very limited and
   stateless mechanisms are not really suitable highest node identifier for address assignment.
   Therefore HNCP can manage router address in these cases by itself.
   Each router assigning an address a name takes precedence and
   all other nodes MUST cease to one of its interfaces announces
   one TLV of announce the following kind: conflicting 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: ROUTER-ADDRESS (46) NODE-NAME (41)      |         Length: 24 > 16          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link Identifier                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           IP Address                          |
   |                         Router Address                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Name (not null-terminated - variable length)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Link Identifier is the local

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 identifier to enable bootstrapping of the link the
      address such
   third-party protocols and SHOULD therefore be used if such a need
   arises.  The following rules define how such a PSK is assigned to.

      Router Address managed and
   used:

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

   o  In case multiple routers announce such a TLV at the same time, all
      but the address assigned to one of with the highest node identifier stop advertising it
      and adopt the remaining one.

   o  The router
      interfaces.

7.  DNS-based Service Discovery

   Service discovery is generally limited to a local link.
   [I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf] defines a
   mechanism to automatically extended DNS-based service discovery
   across multiple links within currently advertising the home automatically.  Following TLVs
   MAY be used to provide transport for that specification.

7.1.  DNS Delegated Zone TLV Managed-PSK-TLV must generate
      and advertise a new random one whenever an unreachable node is
      purged as described in DNCP.

   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 (50) Managed-PSK (42)     |          Length: >= 21 32           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                            Address                                                               |
   |                                                               |
   |                           Random PSK                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved  |S|B|                                                               |
   +-+-+-+-+-+-+-+-+  Zone (DNS label sequence - variable length)
   |                                                               |
   |

7.2.  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: DOMAIN-NAME (51)
   |         Length: >= 4                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 to derive PSKs for the respective protocols:

      "ROUTING": to be used for IGPs

10.  HNCP Versioning and Capabilities

   Multiple versions of HNCP based on compatible DNCP
   [I-D.ietf-homenet-dncp] profiles may be present 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 in its
   Node Data and MUST ignore (except for DNCP synchronization purposes)
   any TLVs with a type greater than 32 of nodes not publishing an HNCP-
   Version TLV or publishing such a TLV with a different Version number.

   Capabilities are indicated by setting M, P, H and L fields in the
   TLV.  The "capability value" is a metric indicated by interpreting
   the bits as an integer, i.e.  (M << 12 | P << 8 |        Domain (DNS label sequence - variable length) H << 4 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7.3.  Router Name TLV L).

   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: ROUTER-NAME (52) HNCP-VERSION (32)    |         Length: >= 4 5          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Name (not null-terminated - variable length)    Version    |   Reserved    |   M   |   P   |   H   |   L   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.  Routing support

8.1.  Protocol Requirements

   In order to be advertised for use within the homenet, a routing
   protocol MUST:

      Comply with Requirements and Use Cases for Source/Destination
      Routing [I-D.baker-rtgwg-src-dst-routing-use-cases].

      Be configured with suitable defaults or have an auto-configuration
      mechanism (e.g.  [I-D.acee-ospf-ospfv3-autoconfig]) such that it
      will run in a homenet without requiring specific configuration
      from the home user.

   A router MUST NOT announce that it supports a certain routing
   protocol if its implementation
   |                          User-agent                           |
   Version:  Version indicates which version of the routing protocol does not meet
   these requirements, e.g. it does not implement extensions that are
   necessary for compliance.

8.2.  Announcement

   Each router SHOULD announce all routing protocols that it HNCP is capable
   of supporting currently in the homenet. use
      by this particular node.  It MUST announce at least one protocol
   or the fallback mechanism to be set to 0.  Nodes with
      different versions are considered incompatible.

   Reserved:  Bits reserved for protocol selection future use.  MUST be set to zero when
      creating this TLV and
   MAY omit announcing the fallback mechanism if it announces at least
   one other routing protocol.  It SHOULD assign a preference ignored when parsing it.

   M-capability:  Priority value used for
   each protocol that indicates its desire electing the on-link MDNS
      [RFC6762] proxy.  It MUST be set to use said protocol over
   other protocols it supports some value between 1 and SHOULD make these values
   configurable.

   Each 7
      included (4 is the default) if the router includes one HNCP TLV of type ROUTING-PROTOCOL for every
   such routing protocol.  This TLV is defined as follows:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 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 2 3 4 5 6 and 7 8 9 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 2 3 4 5 6 and 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type: ROUTING-PROTOCOL (60)  |           Length: 6           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Protocol ID  |   Preference  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Protocol ID included (4 is one of:

         0 = Fallback (explicit announcement)

         1 = Babel (dual-stack)

         2 = OSPFv3 (dual-stack)

         3 = IS-IS (dual-stack)

         4 = RIP (dual-stack)

      Preference the default) if the router is a value from
      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 255.  If a router some value between 1 and 7 included (4
      is neutral about
      a routing protocol it SHOULD use the value 128, otherwise default) if the router is capable of running a lower
      value indicating lower preference or legacy
      DHCPv4 server offering IPv4 addresses to clients and 0 otherwise.
      The values 8-15 are reserved for future use.

   User-Agent:  The user-agent is a higher value indicating
      higher preference respectively.

8.3.  Protocol Selection

   When HNCP detects null-terminated human-readable UTF-8
      string that a device has joined or left describes the homenet it
   MUST examine all advertised routing protocols name and preference values
   from all devices announcing at least one ROUTING-PROTOCOL-TLV in
   order to find the one routing protocol which:

   1.  Is understood by all routers in version of the homenet

   2.  Has current HNCP
      implementation.

11.  Requirements for HNCP Routers

   Each router implementing HNCP is subject to the highest preference value among all following
   requirements:

   o  It MUST implement HNCP-Versioning, Border Discovery, Prefix
      Assignment and Configuration of hosts and non-HNCP routers (calculated as
       sum of preference values)

   3.  Has the highest protocol ID among those with the highest
       preference

   If the router protocol selection results
      defined in this document.

   o  It MUST implement and run the need to change from
   one routing protocol to another on method for securing third-party
      protocols whenever it uses the homenet, security mechanism of HNCP.

   o  It SHOULD implement support for the router Service Discovery and Naming
      TLVs as defined in this document.

   o  It MUST stop
   the previously running protocol, remove associated routes, implement and start run the new protocol in a graceful manner.  If there is no common routing protocol available among $FOO with support
      for source-specific routes on all homenet routers, routers of the interfaces it sends and
      receives HNCP-messages on and MUST resort to announcing source-
      specific routes for external destinations appropriately.

   o  It MUST utilize use adequate security mechanisms for the Fallback Mechanism (Section 8.4).

8.4.  Fallback Mechanism

   In cases where there is no commonly supported routing protocol
   available
      on any interface where it also uses the following fallback algorithm security mechanisms of
      HNCP.  If the security mechanism is run to setup routing
   and preserve interoperability among based on a PSK it MUST use a
      PSK derived from the homenet.  While not intended Managed-PSK to replace a routing protocol, secure the IGP.

   o  It MUST comply with the Basic Requirements for IPv6 Customer Edge
      Routers [RFC7084] unless it would otherwise conflict with any
      requirements in this mechanism provides document (e.g. prefix assignment mandating a valid - but
   not necessarily optimal - routing topology.  This algorithm uses the
   node
      different prefix delegation and neighbor state already synchronized by HNCP, DHCP server election strategy).
      In general "WAN interface requirements" shall apply to external
      interfaces and therefore
   does not require any additional protocol message exchange.

   1.  Interpret the neighbor information received via "LAN interface requirements" to internal interfaces
      respectively.

   o  It SHOULD 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.

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 graph number of connected routers.

   2.  Use breadth-first traversal to determine the next-hop and hop-
       count
   threats.

   General security issues for existing home networks are discussed in the path
   [RFC7368].  The protocols used to each router in the homenet:

       1.  Start the traversal with set up addresses and routes in such
   networks to this day rarely have security enabled within the immediate neighbors
   configuration protocol itself.  However these issues are out of scope
   for the
           router running the algorithm.

       2.  Always visit the immediate neighbors of a router in ascending
           order security of their router ID.

       3.  Never visit HNCP itself.

   HNCP is a router more often than once.

   3. DNCP [I-D.ietf-homenet-dncp]-based state synchronization
   mechanism carrying information with varying threat potential.  For each delegated prefix P of any router R in the homenet:
       Create a default route via
   this consideration the next-hop for R acquired payloads defined in #2.
       Each DNCP and this document are
   reviewed:

   o  Network topology information such route MUST be source-restricted to only apply to
       traffic with a source address within P as HNCP nodes and their adjacent
      links

   o  Address assignment information such as delegated and its metric MUST
       reflect the hop-count to R.

   4.  For each assigned prefix A of a
      prefixes for individual links

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

12.1.  Border Determination

   As described in Section 5, an HNCP router R: Create determines the internal or
   external state on a route to per-link basis.  A via firewall perimeter is set up
   for the next-hop external links, and for R acquired in #2.  Each such route MUST NOT internal links, HNCP and IGP traffic
   is allowed.

   Threats concerning automatic border discovery cannot be
       source-restricted.

   5.  For the first router R visited mitigated by
   encrypting or authenticating HNCP traffic itself since external
   routers do not participate in the traversal announcing an
       IPv4-uplink: Create a default IPv4-route via protocol and often cannot be
   authenticated by other means.  These threats include propagation of
   forged uplinks in the next-hop for R
       acquired homenet in #2.

   6.  For each assigned IPv4-prefix A of a router R: Create an
       IPv4-route order to A via e.g. redirect traffic
   destined to external locations and forged internal status by external
   routers to e.g. circumvent the next-hop for R acquired in #2.

9.  Security Considerations

   General security issues for home networks are discussed at length in
   [RFC7368].  The protocols used 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 set up IP an adequate fixed-category in home networks today
   have rarely order to secure the
   homenet border.  Depending on the security enabled within of the control protocol itself. 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, DHCP DHCPv4 has defined [RFC3118] to authenticate DHCP 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 itself sends messages as clear text against internal threats like manipulation or
   eavesdropping by compromised devices on a link which is as secure, enabled for
   HNCP traffic.  If left unsecured, attackers may perform arbitrary
   eavesdropping, spoofing or
   insecure, as the security denial of the link it runs on.  As service attacks on HNCP messages
   are sent over IPv6 UDP, IPsec may services
   such as address assignment or service discovery.

   Detailed interface categories like "leaf" or "guest" can be used for confidentiality or
   message authentication.  This requires manually keyed IPsec per-port
   granularity for port IANA-UDP-PORT UDP traffic, to
   integrate not fully trusted devices to various degrees into the
   homenet by not exposing them to HNCP and a pre-shared key
   has IGP traffic or by using
   firewall rules to be utilized in prevent them from reaching homenet-internal
   resources.

   On links where this case given IKE cannot is not practical and lower layers do not provide
   adequate protection from attackers, DNCP secure mode MUST be used with
   multicast to
   secure traffic.  This seems acceptable, though, as most routing
   protocols also operate based on pre-shared keys,

12.3.  Other Protocols in the Home

   IGPs and other protocols are usually run alongside HNCP therefore the homenet
   architecture draft explicitly allows their use for securing
   them[RFC7368].  Other traffic
   individual security mechanisms are out aspects of scope
   for this specification.  There is ongoing work
   [I-D.barth-homenet-hncp-security-trust] to define a mechanism that the respective protocols must be
   considered.  It can however be used with HNCP and summarized that many protocols to be more user-friendly than
   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.

10. 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 should set up is requested to maintain a registry (policy TBD) for HNCP TLV types, with TLV-Types.

   HNCP inherits the TLV-Types and allocation policy defined in DNCP
   [I-D.ietf-homenet-dncp].  In addition the following initial contents:

   0: Reserved (should not happen on wire)

   1: Node link

   2: Request network state

   3: Request node data

   4: Network state

   5: Node state

   6: Node data

   7: (unused - was node public key, but never implemented)

   8: Neighbor
   9: Custom

   10: Version TLV-Types are
   defined in this document:

      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: External connection Node-Name

      42: Delegated prefix

   43: Assigned prefix

   44: DHCP-data

   45: DHCPv6-data

   46: Router-address

   50: DNS Delegated Zone

   51: Domain name

   52: Node name

   60: Routing protocol

   65535: Signature Managed-PSK

   HNCP will also require requires allocation of a UDP port number IANA-UDP-PORT, numbers HNCP-UDP-PORT and HNCP-
   DTLS-PORT, as well as an IPv6 link-local multicast address IANA-MULTICAST-ADDRESS.

11. All-
   Homenet-Routers.

14.  References

11.1.

14.1.  Normative references

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

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

   [RFC6206]  Levis, P., Clausen, T., Hui,

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

   [RFC6603]  Korhonen, J., Gnawali, O., Savolainen, T., Krishnan, S., and J. Ko,
              "The Trickle Algorithm", O. Troan,
              "Prefix Exclude Option for DHCPv6-based Prefix
              Delegation", RFC 6206, March 2011. 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, "Prefix and
              Address "Distributed
              Prefix Assignment in a Home Network", draft-ietf-homenet-
              prefix-assignment-01 (work in progress), October 2014.

   [I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf]
              Stenberg, M., "Auto-Configuration of a Network of Hybrid
              Unicast/Multicast DNS-Based Service Discovery Proxy
              Nodes", draft-stenberg-homenet-dnssd-hybrid-proxy-
              zeroconf-01 Algorithm", draft-ietf-homenet-prefix-
              assignment-02 (work in progress), June 2014.

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

   [I-D.troan-homenet-sadr]
              Troan, O.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and L. Colitti, "IPv6 Multihoming with Source
              Address Dependent Routing (SADR)", draft-troan-homenet-
              sadr-01 (work in progress), September 2013.

   [I-D.baker-rtgwg-src-dst-routing-use-cases]
              Baker, F., "Requirements and Use Cases for Source/
              Destination Routing", draft-baker-rtgwg-src-dst-routing-
              use-cases-01 (work in progress), October 2014.

   [I-D.acee-ospf-ospfv3-autoconfig]
              Lindem, A.
              specification", STD 13, RFC 1035, November 1987.

   [RFC6234]  Eastlake, D. and J. Arkko, "OSPFv3 Auto-Configuration",
              draft-acee-ospf-ospfv3-autoconfig-03 (work in progress),
              July 2012.

   [I-D.barth-homenet-hncp-security-trust]
              Barth, S., "HNCP - Security T. Hansen, "US Secure Hash Algorithms
              (SHA and Trust Management", draft-
              barth-homenet-hncp-security-trust-01 (work in progress),
              October 2014.

11.3.  URIs

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

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

Appendix A.  Some Outstanding Issues

   Should we use MD5 hashes, or EUI-64 node identifier to identify
   nodes?

   Is there a case for non-link-local unicast?  Currently explicitly
   stating this is link-local only protocol.

   Consider if using Trickle with k=1 really pays off, as we need to do
   reachability checks if layer 2 does not provide them periodically in
   any case.  Using Trickle with k=inf would remove the need for unicast
   reachability checks, but at cost of extra multicast traffic.  On the
   other hand, N*(N-1)/2 unicast reachability checks when lot of routers
   share a link is not appealing either.

   Valid 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 preferred are now 32 bit millisecond 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 you cannot even
   represent a month in them; is this enough?  Or should we switch to 32
   bit seconds (or 64 bit milliseconds)?

Appendix B.  Some Obvious Questions and Answers

   Q: Why not use TCP?

   A: It does not address the node discovery problem.  It also leads to
   N*(N-1)/2 connections when N nodes share a link, which is awkward.

   Q: Why not multicast-only?
   A: It would require defining application level fragmentation scheme.
   Hopefully the data amounts used will stay small so we just trust
   unicast UDP to handle 'big enough' packets to contain single node's
   TLV data.  On some link layers unicast is also much more reliable
   than multicast, especially Volz, "The Classless
              Static Route Option for large packets.  Also on wireless,
   multicast is much more power expensive than unicast.

   Q: Why so long IDs?

   A: Scalability of protocol is not really affected by using real
   (=cryptographic) hash function.

   Q: Why trust Dynamic Host Configuration
              Protocol (DHCP) version 4", RFC 3442, December 2002.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 fragmentation in unicast case?  Why not do L7
   fragmentation?

   A: Because it will be there for a while at least.  And while PMTU et
   al may be problems on open internet, in a home network environment
   UDP fragmentation should NOT be broken in the foreseeable future.

   Q: Should there be nested container syntax that is actually self-
   describing? (i.e. type flag that indicates container, no body except
   sub-TLVs?)

   A: Not for now, but perhaps valid design.. TBD.

   Q: Why not doing (performance thing X, Y or Z)?

   A: This is designed mostly to be minimal (only timers Trickle ones;
   everything triggered by Trickle-driven messages or local state
   changes).  However, feel free to suggest better (even more minimal)
   design which works. Unicast
              Addresses", RFC 4193, October 2005.

14.3.  URIs

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

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

Appendix C. A.  Changelog

   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 D. B.  Draft source

   As usual, this

   This draft is available at https://github.com/fingon/ietf-
   drafts/ https://github.com/fingon/ietf-drafts/ in
   source format (with nice Makefile too).  Feel free to send
   comments and/or format.  Issues and pull requests if are welcome.

Appendix C.  Implementation

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

Appendix E. D.  Acknowledgements

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

   Thanks to Eric Kline for the original border discovery work.

Authors' Addresses

   Markus Stenberg
   Helsinki  00930
   Finland

   Email: markus.stenberg@iki.fi

   Steven Barth
   Halle  06114
   Germany

   Email: cyrus@openwrt.org

   Pierre Pfister
   Cisco Systems
   Paris
   France

   Email: pierre.pfister@darou.fr