tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7788

Proposed STD
Pages: 40
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: HOMENET

Home Networking Control Protocol

Part 1 of 2, p. 1 to 21
None       Next RFC Part


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                       M. Stenberg
Request for Comments: 7788                                      S. Barth
Category: Standards Track                                    Independent
ISSN: 2070-1721                                               P. Pfister
                                                           Cisco Systems
                                                              April 2016

                    Home Networking Control Protocol


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

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Page 2 
Copyright Notice

   Copyright (c) 2016 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
   ( 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
     1.1.  Applicability . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   7
   3.  DNCP Profile  . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  HNCP Versioning and Router Capabilities . . . . . . . . . . .   9
   5.  Interface Classification  . . . . . . . . . . . . . . . . . .   9
     5.1.  Interface Categories  . . . . . . . . . . . . . . . . . .   9
     5.2.  DHCP-Aided Auto-Detection . . . . . . . . . . . . . . . .  10
     5.3.  Algorithm for Border Discovery  . . . . . . . . . . . . .  11
   6.  Autonomous Address Configuration  . . . . . . . . . . . . . .  12
     6.1.  Common Link . . . . . . . . . . . . . . . . . . . . . . .  12
     6.2.  External Connections  . . . . . . . . . . . . . . . . . .  13
     6.3.  Prefix Assignment . . . . . . . . . . . . . . . . . . . .  14
       6.3.1.  Prefix Assignment Algorithm Parameters  . . . . . . .  14
       6.3.2.  Making New Assignments  . . . . . . . . . . . . . . .  16
       6.3.3.  Applying Assignments  . . . . . . . . . . . . . . . .  17
       6.3.4.  DHCPv6 Prefix Delegation  . . . . . . . . . . . . . .  17
     6.4.  Node Address Assignment . . . . . . . . . . . . . . . . .  17
     6.5.  Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . .  18
   7.  Configuration of Hosts and Non-HNCP Routers . . . . . . . . .  19
     7.1.  IPv6 Addressing and Configuration . . . . . . . . . . . .  19
     7.2.  DHCPv6 for Prefix Delegation  . . . . . . . . . . . . . .  20
     7.3.  DHCPv4 for Addressing and Configuration . . . . . . . . .  20
     7.4.  Multicast DNS Proxy . . . . . . . . . . . . . . . . . . .  21
   8.  Naming and Service Discovery  . . . . . . . . . . . . . . . .  21
   9.  Securing Third-Party Protocols  . . . . . . . . . . . . . . .  22

Top      ToC       Page 3 
   10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . .  23
     10.1.  HNCP-Version TLV . . . . . . . . . . . . . . . . . . . .  23
     10.2.  External-Connection TLV  . . . . . . . . . . . . . . . .  24
       10.2.1.  Delegated-Prefix TLV . . . . . . . . . . . . . . . .  25
       10.2.2.  DHCPv6-Data TLV  . . . . . . . . . . . . . . . . . .  27
       10.2.3.  DHCPv4-Data TLV  . . . . . . . . . . . . . . . . . .  27
     10.3.  Assigned-Prefix TLV  . . . . . . . . . . . . . . . . . .  28
     10.4.  Node-Address TLV . . . . . . . . . . . . . . . . . . . .  29
     10.5.  DNS-Delegated-Zone TLV . . . . . . . . . . . . . . . . .  30
     10.6.  Domain-Name TLV  . . . . . . . . . . . . . . . . . . . .  31
     10.7.  Node-Name TLV  . . . . . . . . . . . . . . . . . . . . .  31
     10.8.  Managed-PSK TLV  . . . . . . . . . . . . . . . . . . . .  32
   11. General Requirements for HNCP Nodes . . . . . . . . . . . . .  32
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  34
     12.1.  Interface Classification . . . . . . . . . . . . . . . .  34
     12.2.  Security of Unicast Traffic  . . . . . . . . . . . . . .  35
     12.3.  Other Protocols in the Home  . . . . . . . . . . . . . .  35
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  36
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  37
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  37
     14.2.  Informative References . . . . . . . . . . . . . . . . .  39
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  40
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40

1.  Introduction

   The Home Networking Control Protocol (HNCP) is designed to facilitate
   the sharing of state among home routers to fulfill the needs of the
   IPv6 homenet architecture [RFC7368], which assumes zero-configuration
   operation, multiple subnets, multiple home routers, and (potentially)
   multiple upstream service providers providing (potentially) multiple
   prefixes to the home network.  While RFC 7368 sets no requirements
   for IPv4 support, HNCP aims to support the dual-stack mode of
   operation, and therefore the functionality is designed with that in
   mind.  The state is shared as TLVs transported in the DNCP node state
   among the routers (and potentially advanced hosts) to enable:

   o  Autonomic discovery of network borders (Section 5.3) based on
      Distributed Node Consensus Protocol (DNCP) topology.

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

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

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

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

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

   HNCP is a protocol based on DNCP [RFC7787] and includes a DNCP
   profile that defines transport and synchronization details for
   sharing state across nodes defined in Section 3.  The rest of the
   document defines behavior of the services noted above, how the
   required TLVs are encoded (Section 10), as well as additional
   requirements on how HNCP nodes should behave (Section 11).

1.1.  Applicability

   While HNCP does not deal with routing protocols directly (except
   potentially informing them about internal and external interfaces if
   classification specified in Section 5.3 is used), in homenet
   environments where multiple IPv6 source prefixes can be present,
   routing based on the source and destination address is necessary
   [RFC7368].  Ideally, the routing protocol is also zero configuration
   (e.g., no need to configure identifiers or metrics), although HNCP
   can also be used with a manually configured routing protocol.

   As HNCP uses DNCP as the actual state synchronization protocol, the
   applicability statement of DNCP applies here as well; HNCP should not
   be used for any data that changes rapidly and constantly.  If such
   data needs to be published in an HNCP network, 1) a more applicable
   protocol should be used for those portions, and 2) locators to a
   server of said protocol should be announced using HNCP instead.  An
   example for this is naming and service discovery (Section 8) for
   which HNCP only transports DNS server addresses and no actual per-
   name or per-service data of hosts.

   HNCP TLVs specified within this document, in steady state, stay
   constant, with one exception: as Delegated-Prefix TLVs
   (Section 10.2.1) do contain lifetimes, they force republishing of
   that data every time the valid or preferred lifetimes of prefixes are
   updated (significantly).  Therefore, it is desirable for ISPs to
   provide large enough valid and preferred lifetimes to avoid
   unnecessary HNCP state churn in homes, but even given non-cooperating
   ISPs, the state churn is proportional only to the number of
   externally received delegated prefixes and not to the home network
   size, and it should therefore be relatively low.

Top      ToC       Page 5 
   HNCP assumes a certain level of control over host configuration
   servers (e.g., DHCP [RFC2131]) on links that are managed by its
   routers.  Some HNCP functionality (such as border discovery or some
   aspects of naming) might be affected by existing DHCP servers that
   are not aware of the HNCP-managed network and thus might need to be
   reconfigured to not result in unexpected behavior.

   While HNCP routers can provide configuration to and receive
   configuration from non-HNCP routers, they are not able to traverse
   such devices based solely on the protocol as defined in this
   document, i.e., HNCP routers that are connected only by different
   interfaces of a non-HNCP router will not be part of the same HNCP

   While HNCP is designed to be used by (home) routers, it can also be
   used by advanced hosts that want to do, e.g., their own address
   assignment and routing.

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

2.  Terminology

   The following terms are used as they are defined in [RFC7695]:

   o  Advertised Prefix Priority

   o  Advertised Prefix

   o  Assigned Prefix

   o  Delegated Prefix

   o  Prefix Adoption

   o  Private Link

   o  Published Assigned Prefix

   o  Applied Assigned Prefix

   o  Shared Link

Top      ToC       Page 6 
   The following terms are used as they are defined in [RFC7787]:

   o  DNCP profile

   o  Node identifier

   o  Link

   o  Interface

   (HNCP) node       a device implementing this specification.

   (HNCP) router     a device implementing this specification, which
                     forwards traffic on behalf of other devices.

   Greatest node     when comparing the DNCP node identifiers of
   identifier        multiple nodes, the one that has the greatest value
                     in a bitwise comparison.

   Border            separation point between administrative domains; in
                     this case, between the home network and any other
                     network, i.e., usually an ISP network.

   Internal link     a link that does not cross borders.

   Internal          an interface that is connected to an internal link.

   External          an interface that is connected to a link that is
   interface         not an internal link.

   Interface         a local configuration denoting the use of a
   category          particular interface.  The Interface category
                     determines how an HNCP node should treat the
                     particular interface.  The External and Internal
                     categories mark the interface as out of or within
                     the network border; there are also a number of
                     subcategories of Internal that further affect local
                     node behavior.  See Section 5.1 for a list of
                     interface categories and how they behave.  The
                     Internal or External category may also be auto-
                     detected (Section 5.3).

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

Top      ToC       Page 7 
   Common Link       a set of nodes on a link that share a common view
                     of it, i.e., they see each other's traffic and the
                     same set of hosts.  Unless configured otherwise,
                     transitive connectivity is assumed.

   DHCPv4            refers to the Dynamic Host Configuration Protocol
                     [RFC2131] in this document.

   DHCPv6            refers to the Dynamic Host Configuration Protocol
                     for IPv6 (DHCPv6) [RFC3315] in this document.

   DHCP              refers to cases that apply to both DHCPv4 and
                     DHCPv6 in this document.

2.1.  Requirements Language

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

3.  DNCP Profile

   The DNCP profile for HNCP is defined as follows:

   o  HNCP uses UDP datagrams on port 8231 as a transport over link-
      local scoped IPv6, using unicast and multicast
      (FF02:0:0:0:0:0:0:11 is the HNCP group address).  Received
      datagrams where either or both of the IPv6 source or destination
      addresses are not link-local scoped MUST be ignored.  Replies to
      multicast and unicast messages MUST be sent to the IPv6 source
      address and port of the original message.  Each node MUST be able
      to receive (and potentially reassemble) UDP datagrams with a
      payload of at least 4000 bytes.

   o  HNCP operates on multicast-capable interfaces only.  HNCP nodes
      MUST assign a non-zero 32-bit endpoint identifier to each
      interface for which HNCP is enabled.  The value 0 is not used in
      DNCP TLVs but has a special meaning in HNCP TLVs (see Sections 6.4
      and 10.3).  These identifiers MUST be locally unique within the
      scope of the node, and using values equivalent to the IPv6 link-
      local scope identifiers for the given interfaces are RECOMMENDED.

   o  HNCP uses opaque 32-bit node identifiers
      (DNCP_NODE_IDENTIFIER_LENGTH = 32).  A node implementing HNCP
      SHOULD use a random node identifier.  If there is a node
      identifier collision (as specified in the Node-State TLV handling
      of Section 4.4 of [RFC7787]), the node MUST immediately generate

Top      ToC       Page 8 
      and use a new random node identifier that is not used by any other
      node at the time, based on the current DNCP network state.

   o  HNCP nodes MUST use the leading 64 bits of the MD5 message digest
      [RFC1321] as the DNCP hash function H(x) used in building the DNCP
      hash tree.

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

      *  Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20

      *  Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1 on virtually
         lossless links works fine, as it allows for one lost keep-
         alive.  If used on a lossy link, a considerably higher
         multiplier, such as 15, should be used instead.  In that case,
         an implementation might prefer shorter keep-alive intervals on
         that link as well to ensure that the timeout (equal to
         which entirely lost nodes time out is low enough.

   o  HNCP nodes use the following Trickle parameters for the per-
      interface Trickle instances:

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

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

      *  Imax SHOULD be 7 doublings of Imin [RFC6206] but MUST NOT be

   o  HNCP unicast traffic SHOULD be secured using Datagram Transport
      Layer Security (DTLS) [RFC6347] as described in DNCP if exchanged
      over unsecured links.  UDP on port 8232 is used for this purpose.
      A node implementing HNCP security MUST support the DNCP Pre-Shared
      Key (PSK) method, SHOULD support the PKI-based trust method, and
      MAY support the DNCP certificate-based trust consensus method.
      [RFC7525] provides guidance on how to securely utilize DTLS.

   o  HNCP nodes MUST ignore all Node-State TLVs received via multicast
      on a link that has DNCP security enabled in order to prevent
      spoofing of node state changes.

Top      ToC       Page 9 
4.  HNCP Versioning and Router Capabilities

   Multiple versions of HNCP based on compatible DNCP profiles may be
   present in the same network when transitioning between HNCP versions,
   and for troubleshooting purposes, it might be beneficial to identify
   the HNCP agent version running.  Therefore, each node MUST include an
   HNCP-Version TLV (Section 10.1) indicating the currently supported
   version in its node data and MUST ignore (except for DNCP
   synchronization purposes) any TLVs that have a type greater than 32
   and that are published by nodes that didn't also publish an HNCP-
   Version TLV.

   HNCP routers may also have different capabilities regarding
   interactions with hosts, e.g., for configuration or service
   discovery.  These are indicated by M, P, H, and L values.  The
   combined "capability value" is a metric indicated by interpreting the
   bits as an integer, i.e., (M << 12 | P << 8 | H << 4 | L).  These
   values are used to elect certain servers on a Common Link, as
   described in Section 7.  Nodes that are not routers MUST announce the
   value 0 for all capabilities.  Any node announcing the value 0 for a
   capability is considered to not advertise said capability and thus
   does not take part in the respective election.

5.  Interface Classification

5.1.  Interface Categories

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

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

   External category:  This declares an interface to be external, i.e.,
      not within the borders of the HNCP network.  The interface MUST
      NOT operate as a DNCP endpoint.  Accessing internal resources from
      external interfaces is restricted, i.e., the use of Recommended
      Simple Security Capabilities in Customer Premises Equipments
      (CPEs) [RFC6092] is RECOMMENDED.  HNCP routers SHOULD announce
      acquired configuration information for use in the network as
      described in Section 6.2, if the interface appears to be connected
      to an external network.  HNCP routers MUST implement this

Top      ToC       Page 10 
   Leaf category:  This declares an interface used by client devices
      only.  Such an interface uses the Internal category with the
      exception that it MUST NOT operate as a DNCP endpoint.  This
      category SHOULD be supported by HNCP routers.

   Guest category:  This declares an interface used by untrusted client
      devices only.  In addition to the restrictions of the Leaf
      category, HNCP routers MUST filter traffic from and to the
      interface such that connected devices are unable to reach other
      devices inside the HNCP network or query services advertised by
      them unless explicitly allowed.  This category SHOULD be supported
      by HNCP routers.

   Ad Hoc category:  This configures an interface to use the Internal
      category, but no assumption is made about the link's transitivity.
      All other interface categories assume transitive connectivity.
      This affects the Common Link (Section 6.1) definition.  Support
      for this category is OPTIONAL.

   Hybrid category:  This declares an interface to use the Internal
      category while still trying to acquire (external) configuration
      information on it, e.g., by running DHCP clients.  This is useful,
      e.g., if the link is shared with a non-HNCP router under control
      and still within the borders of the same network.  Detection of
      this category automatically in addition to manual configuration is
      out of scope of this document.  Support for this category is

5.2.  DHCP-Aided Auto-Detection

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

   o  The device MUST ignore or reject DHCP-Requests containing a DHCP
      user class consisting of the ASCII string "HOMENET".

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

Top      ToC       Page 11 
5.3.  Algorithm for Border Discovery

   This section defines the interface classification algorithm.  It is
   suitable for both IPv4 and IPv6 (single or dual stack) and detects
   the category of an interface either automatically or based on a fixed
   configuration.  By determining the category for all interfaces, the
   network borders are implicitly defined, i.e., all interfaces not
   belonging to the External category are considered to be within the
   borders of the network; all others are not.

   The following algorithm MUST be implemented by any node implementing
   HNCP.  However, if the node does not implement auto-detection, only
   the first and last step are required.  The algorithm works as
   follows, with evaluation stopping at first match:

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

   2.  If a delegated prefix could be acquired by running a DHCPv6
       client, it is considered external.  The DHCPv6 client MUST have
       included a DHCPv6 user class consisting of the ASCII string
       "HOMENET" in all of its requests.

   3.  If an IPv4 address could be acquired by running a DHCPv4 client
       on the interface, it is considered external.  The DHCPv4 client
       MUST have included a DHCP user class consisting of the ASCII
       string "HOMENET" in all of its requests.

   4.  The interface is considered internal.

   Note that as other HNCP nodes will ignore the client due to the User
   Class option, any server that replies is clearly external (or a
   malicious internal node).

   An HNCP router SHOULD allow setting the fixed category for each
   interface that may be connected to either an internal or external
   device (e.g., an Ethernet port that can be connected to a modem,
   another HNCP router, or a client).  Note that all fixed categories
   except internal and external cannot be auto-detected and can only be
   selected using manual configuration.

   An HNCP router using auto-detection on an interface MUST run the
   appropriately configured DHCP clients as long as the interface
   without a fixed category is active (including states where auto-
   detection considers it to be internal) and rerun the algorithm above
   to react to conditions resulting in a different interface category.
   The router SHOULD wait for a reasonable time period (5 seconds as a

Top      ToC       Page 12 
   default), during which the DHCP clients can acquire a lease, before
   treating a newly activated or previously external interface as

6.  Autonomous Address Configuration

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

6.1.  Common Link

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

   o  The local node publishes a Peer TLV with:

      *  Peer Node Identifier = remote node's node identifier

      *  Peer Endpoint Identifier = remote interface's endpoint

      *  Endpoint Identifier = local interface's endpoint identifier

   o  The remote node publishes a Peer TLV with:

      *  Peer Node Identifier = local node's node identifier

      *  Peer Endpoint Identifier = local interface's endpoint

Top      ToC       Page 13 
      *  Endpoint Identifier = remote interface's endpoint identifier

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

6.2.  External Connections

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

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

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

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

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

   Some connections or delegated prefixes may have a special meaning and
   are not regularly used for internal or Internet connectivity;
   instead, they may provide access to special services like VPNs,
   sensor networks, Voice over IP (VoIP), IPTV, etc.  Care must be taken
   that these prefixes are properly integrated and dealt with in the
   network, in order to avoid breaking connectivity for devices who are
   not aware of their special characteristics or to only selectively
   allow certain devices to use them.  Such prefixes are distinguished
   using Prefix-Policy TLVs (Section  Their contents MAY be

Top      ToC       Page 14 
   partly opaque to HNCP nodes, and their identification and usage
   depends on local policy.  However, the following general rules MUST
   be adhered to:

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

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

6.3.  Prefix Assignment

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

6.3.1.  Prefix Assignment Algorithm Parameters

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

   Node IDs:   HNCP node identifiers are used.  The comparison operation
      is defined as bitwise comparison.

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

   Set of Shared Links:   The set of Common Links associated with
      interfaces with the Internal, Leaf, Guest, or Ad Hoc category.  It
      is dynamically updated as interfaces are added, removed, or
      switched from one category to another.  When multiple interfaces
      are detected as belonging to the same Common Link, prefix
      assignment is disabled on all of these interfaces except one.

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

   Set of Advertised Prefixes:   The set of prefixes included in
      Assigned-Prefix TLVs advertised by other HNCP nodes (prefixes
      advertised by the local node are not in this set).  The associated
      Advertised Prefix Priority is the priority specified in the TLV.
      The associated Shared Link is determined as follows:

      *  If the Link Identifier is 0, the Advertised Prefix is not
         assigned on a Shared Link.

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

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

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

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

   BACKOFF_MAX_DELAY:   The default value is 4 seconds.

   RANDOM_SET_SIZE:   The default value is 64.

   Flooding Delay:   The default value is 5 seconds.

   Default Advertised Prefix Priority:   When a new assignment is
      created or an assignment is adopted -- as specified in the prefix
      assignment algorithm routine -- the default Advertised Prefix
      Priority to be used is 2.

Top      ToC       Page 16 
6.3.2.  Making New Assignments

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

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

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

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

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

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

   If the considered delegated prefix is an IPv4 prefix (Section 6.5
   details how IPv4-delegated prefixes are generated), a prefix of
   length 24 SHOULD be preferred.

   In any case, an HNCP router making an assignment MUST support a
   mechanism suitable to distribute addresses from the considered prefix
   if the link is intended to be used by clients.  In this case, a
   router assigning an IPv4 prefix MUST announce the L-capability, and a
   router assigning an IPv6 prefix with a length greater than 64 MUST
   announce the H-capability as defined in Section 4.

Top      ToC       Page 17 
6.3.3.  Applying Assignments

   The prefix assignment algorithm indicates when a prefix is applied to
   the respective Common Link.  When that happens, each router connected
   to said link:

      MUST forward traffic destined to said prefix to the respective

      MUST participate in the client configuration election as described
      in Section 7, if the link is intended to be used by clients.

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

6.3.4.  DHCPv6 Prefix Delegation

   When an HNCP router announcing the P-Capability (Section 4) receives
   a DHCPv6-PD request from a client, it SHOULD assign one prefix per
   delegated prefix in the network.  This set of assigned prefixes is
   then delegated to the client, after it has been applied as described
   in the prefix assignment algorithm.  Each DHCPv6-PD client MUST be
   considered as an independent Private Link, and delegation MUST be
   based on the same set of delegated prefixes as the one used for
   Common Link prefix assignments; however, the prefix length to be
   delegated MAY be smaller than 64.

   The assigned prefixes MUST NOT be given to DHCPv6-PD clients before
   they are applied and MUST be withdrawn whenever they are destroyed.
   As an exception to this rule, in order to shorten delays of processed
   requests, a router MAY prematurely give out a prefix that is
   advertised but not yet applied if it does so with a valid lifetime of
   not more than 30 seconds and ensures removal or correction of
   lifetimes as soon as possible.

6.4.  Node Address Assignment

   This section specifies how HNCP nodes reserve addresses for their own
   use.  Nodes MAY, at any time, try to reserve a new address from any
   Applied Assigned Prefix.  Each HNCP node SHOULD announce an IPv6
   address and -- if it supports IPv4 -- MUST announce an IPv4 address,
   whenever matching prefixes are assigned to at least one of its Common
   Links.  These addresses are published using Node-Address TLVs and
   used to locally reach HNCP nodes for other services.  Nodes SHOULD
   NOT create and announce more than one assignment per IP version to
   avoid cluttering the node data with redundant information unless a
   special use case requires it.

Top      ToC       Page 18 
   Stateless assignment based on Semantically Opaque Interface
   Identifiers [RFC7217] SHOULD be used for address assignment whenever
   possible (e.g., the prefix length is 64), otherwise (e.g., for IPv4
   if supported) the following method MUST be used instead: For any
   assigned prefix for which stateless assignment is not used, the first
   quarter of the addresses are reserved for HNCP-based address
   assignments, whereas the last three quarters are left to the DHCP
   elected router (Section 4 specifies the DHCP server election
   process).  For example, if the prefix is assigned and
   applied to a Common Link, addresses included in are
   reserved for HNCP nodes, and the remaining addresses are reserved for
   the elected DHCPv4 server.

   HNCP nodes assign addresses to themselves and then (to ensure
   eventual lack of conflicting assignments) publish the assignments
   using the Node-Address TLV (Section 10.4).

   The process of obtaining addresses is specified as follows:

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

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

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

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

6.5.  Local IPv4 and ULA Prefixes

   HNCP routers can create a Unique Local Address (ULA) or private IPv4
   prefix to enable connectivity between local devices.  These prefixes
   are inserted in HNCP as if they were delegated prefixes of a
   (virtual) external connection (Section 6.2).  The following rules

      An HNCP router SHOULD create a ULA prefix if there is no other
      IPv6 prefix with a preferred time greater than 0 in the network.
      It MAY also do so if there are other delegated IPv6 prefixes, but
      none of which is locally generated (i.e., without any Prefix-
      Policy TLV) and has a preferred time greater than 0.  However, it

Top      ToC       Page 19 
      MUST NOT do so otherwise.  In case multiple locally generated ULA
      prefixes are present, only the one published by the node with the
      greatest node identifier is kept among those with a preferred time
      greater than 0 -- if there is any.

      An HNCP router MUST create a private IPv4 prefix [RFC1918]
      whenever it wishes to provide IPv4 Internet connectivity to the
      network and no other private IPv4 prefix with Internet
      connectivity currently exists.  It MAY also enable local IPv4
      connectivity by creating a private IPv4 prefix if no IPv4 prefix
      exists but MUST NOT do so otherwise.  In case multiple IPv4
      prefixes are announced, only the one published by the node with
      the greatest node identifier is kept among those with a Prefix-
      Policy TLV of type 0 -- if there is any.  The router publishing a
      prefix with Internet connectivity MUST forward IPv4 traffic to the
      Internet and perform NAT on behalf of the network as long as it
      publishes the prefix; other routers in the network MAY choose not

   Creation of such ULA and IPv4 prefixes MUST be delayed by a random
   time span between 0 and 10 seconds in which the router MUST scan for
   others 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, a
   per-link and per-service election takes place.

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

7.1.  IPv6 Addressing and Configuration

   In general, Stateless Address Autoconfiguration [RFC4861] is used for
   client configuration for its low overhead and fast renumbering
   capabilities.  Therefore, each HNCP router sends Router
   Advertisements on interfaces that are intended to be used by clients
   and MUST at least include a Prefix Information Option for each
   Applied Assigned Prefix that it assigned to the respective link in
   every such advertisement.  However, stateful DHCPv6 can be used in

Top      ToC       Page 20 
   addition by administrative choice to, e.g., collect hostnames and use
   them to provide naming services or whenever stateless configuration
   is not applicable.

   The designated stateful DHCPv6 server for a Common Link (Section 6.1)
   is elected based on the capabilities described in Section 4.  The
   winner is the router (connected to the Common Link) advertising the
   greatest H-capability.  In case of a tie, Capability Values
   (Section 4) are compared, and the router with the greatest value is
   elected.  In case of another tie, the router with the greatest node
   identifier is elected among the routers with tied Capability Values.

   The elected router MUST serve stateful DHCPv6 and SHOULD provide
   naming services for acquired hostnames as outlined in Section 8; all
   other nodes MUST NOT.  Stateful addresses SHOULD be assigned in a way
   that does not hinder fast renumbering even if the DHCPv6 server or
   client do not support the DHCPv6 reconfigure mechanism, e.g., by only
   handing out leases from locally generated (ULA) prefixes and prefixes
   with a length different from 64 and by using low renew and rebind
   times (i.e., not longer than 5 minutes).  In case no router was
   elected, stateful DHCPv6 is not provided.  Routers that cease to be
   elected DHCP servers SHOULD -- when applicable -- invalidate
   remaining existing bindings in order to trigger client

7.2.  DHCPv6 for Prefix Delegation

   The designated DHCPv6 server for prefix delegation on a Common Link
   is elected based on the capabilities described in Section 4.  The
   winner is the router (connected to the Common Link) advertising the
   greatest P-capability.  In case of a tie, Capability Values
   (Section 4) are compared, and the router with the greatest value is
   elected.  In case of another tie, the router with the greatest node
   identifier is elected among the routers with tied Capability Values.

   The elected router MUST provide prefix delegation services [RFC3633]
   on the given link (and follow the rules in Section 6.3.4); all other
   nodes MUST NOT.

7.3.  DHCPv4 for Addressing and Configuration

   The designated DHCPv4 server on a Common Link (Section 6.1) is
   elected based on the capabilities described in Section 4.  The winner
   is the router (connected to the Common Link) advertising the greatest
   L-capability.  In case of a tie, Capability Values (Section 4) are
   compared, and the router with the greatest value is elected.  In case
   of another tie, the router with the greatest node identifier is
   elected among the routers with tied Capability Values.

Top      ToC       Page 21 
   The elected router MUST provide DHCPv4 services on the given link;
   all other nodes MUST NOT.  The elected router MUST provide IP
   addresses from the pool defined in Section 6.4 and MUST announce
   itself as router [RFC2132] to clients.

   DHCPv4 lifetimes renew and rebind times (T1 and T2) SHOULD be short
   (i.e., not longer than 5 minutes) in order to provide reasonable
   response times to changes.  Routers that cease to be elected DHCP
   servers SHOULD -- when applicable -- invalidate remaining existing
   bindings in order to trigger client reconfiguration.

7.4.  Multicast DNS Proxy

   The designated Multicast DNS (mDNS) [RFC6762] proxy on a Common Link
   is elected based on the capabilities described in Section 4.  The
   winner is the router (connected to the Common Link) advertising the
   greatest M-capability.  In case of a tie, Capability Values
   (Section 4) are compared, and the router with the greatest value is
   elected.  In case of another tie, the router with the greatest node
   identifier is elected among the routers with tied Capability Values.

   The elected router MUST provide an mDNS proxy on the given link and
   announce it as described in Section 8.

(page 21 continued on part 2)

Next RFC Part