[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-stenberg-homenet-hncp) 00 01 02 03 04 05 06 07 08 09 10 RFC 7788

Homenet Working Group                                        M. Stenberg
Internet-Draft
Intended status: Standards Track                                S. Barth
Expires: April 30, 2015
                                                        October 27, 2014


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

Abstract

   This document describes the Home Networking Control Protocol (HNCP),
   a minimalist state synchronization protocol for homenet routers.

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

Copyright Notice

   Copyright (c) 2014 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.





Stenberg & Barth         Expires April 30, 2015                 [Page 1]


Internet-Draft      Home Networking Control Protocol        October 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements language . . . . . . . . . . . . . . . . . . . .   3
   3.  Data model  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Trickle-Driven Status Updates . . . . . . . . . . . . . .   4
     4.2.  Protocol Messages . . . . . . . . . . . . . . . . . . . .   4
       4.2.1.  Network State Update (NetState) . . . . . . . . . . .   5
       4.2.2.  Network State Request, (NetState-Req) . . . . . . . .   5
       4.2.3.  Node Data Request (Node-Req)  . . . . . . . . . . . .   5
       4.2.4.  Network and Node State Reply (NetNode-Reply)  . . . .   6
     4.3.  HNCP Protocol Message Processing  . . . . . . . . . . . .   6
     4.4.  Adding and Removing Neighbors . . . . . . . . . . . . . .   7
     4.5.  Purging Unreachable Nodes . . . . . . . . . . . . . . . .   8
   5.  Type-Length-Value objects . . . . . . . . . . . . . . . . . .   8
     5.1.  Request TLVs (for use within unicast requests)  . . . . .   8
       5.1.1.  Request Network State TLV . . . . . . . . . . . . . .   9
       5.1.2.  Request Node Data TLV . . . . . . . . . . . . . . . .   9
     5.2.  Data TLVs (for use in both multi- and unicast data) . . .   9
       5.2.1.  Node Link TLV . . . . . . . . . . . . . . . . . . . .   9
       5.2.2.  Network State TLV . . . . . . . . . . . . . . . . . .   9
       5.2.3.  Node State TLV  . . . . . . . . . . . . . . . . . . .  10
       5.2.4.  Node Data TLV . . . . . . . . . . . . . . . . . . . .  11
       5.2.5.  Neighbor TLV (within Node Data TLV) . . . . . . . . .  11
     5.3.  Custom TLV (within/without Node Data TLV) . . . . . . . .  11
     5.4.  Version TLV (within Node Data TLV)  . . . . . . . . . . .  12
   6.  Border Discovery and Prefix Assignment  . . . . . . . . . . .  12
   7.  DNS-based Service Discovery . . . . . . . . . . . . . . . . .  17
     7.1.  DNS Delegated Zone TLV  . . . . . . . . . . . . . . . . .  17
     7.2.  Domain Name TLV . . . . . . . . . . . . . . . . . . . . .  18
     7.3.  Router Name TLV . . . . . . . . . . . . . . . . . . . . .  18
   8.  Routing support . . . . . . . . . . . . . . . . . . . . . . .  18
     8.1.  Protocol Requirements . . . . . . . . . . . . . . . . . .  18
     8.2.  Announcement  . . . . . . . . . . . . . . . . . . . . . .  18
     8.3.  Protocol Selection  . . . . . . . . . . . . . . . . . . .  19
     8.4.  Fallback Mechanism  . . . . . . . . . . . . . . . . . . .  20
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     11.1.  Normative references . . . . . . . . . . . . . . . . . .  22
     11.2.  Informative references . . . . . . . . . . . . . . . . .  23
     11.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   Appendix A.  Some Outstanding Issues  . . . . . . . . . . . . . .  24
   Appendix B.  Some Obvious Questions and Answers . . . . . . . . .  24
   Appendix C.  Changelog  . . . . . . . . . . . . . . . . . . . . .  25
   Appendix D.  Draft source . . . . . . . . . . . . . . . . . . . .  26
   Appendix E.  Acknowledgements . . . . . . . . . . . . . . . . . .  26



Stenberg & Barth         Expires April 30, 2015                 [Page 2]


Internet-Draft      Home Networking Control Protocol        October 2014


   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

1.  Introduction

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

   HNCP is designed to provide enough information for a routing protocol
   to operate without homenet-specific extensions.  In homenet
   environments where multiple IPv6 prefixes are 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.

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 of the HNCP protocol is simple: Every participating
   node has (and also knows for every other participating node):

      A unique node identifier.  It may be a public key, unique hardware
      ID, or some other unique blob of binary data which HNCP can run a
      hash upon to obtain a node identifier that is very likely unique
      among the set of routers in 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 is used 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.




Stenberg & Barth         Expires April 30, 2015                 [Page 3]


Internet-Draft      Home Networking Control Protocol        October 2014


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

4.  Operation

   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 in shared TLV data, and unicast state
   synchronization message exchanges when the Trickle state is found to
   be inconsistent.

4.1.  Trickle-Driven Status Updates

   Each node MUST send link-local multicast NetState Messages
   (Section 4.2.1) each time the Trickle algorithm [RFC6206] indicates
   they should on each link the protocol is active on.  When the locally
   stored network state hash changes (either by a local node event that
   affects the 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 and Imax
   represent minimum and maximum values for I, which is the time
   interval during which at least k Trickle updates must be seen on a
   link to prevent local state transmission.  Bounds for recommended
   Trickle values are described below.

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

      Imax MUST be at least one minute.

      Imin MUST be at least 200 milliseconds (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 be
   present in a given message.

   In order to facilitate fast comparing 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)
   MUST be placed in ascending order based on the binary comparison of



Stenberg & Barth         Expires April 30, 2015                 [Page 4]


Internet-Draft      Home Networking Control Protocol        October 2014


   both TLV header and value.  By design, the TLVs which MUST be present
   have the lowest available type values, ensuring they will naturally
   occur at the start of the Protocol Message, resembling a fixed format
   preamble.

4.2.1.  Network State Update (NetState)

   This Message SHOULD be sent as a multicast message.

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

      Node 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 all Node State TLVs are included (referred to as a
   "long" NetState Message), or none are included (referred to as a
   "short" NetState Message).  The NetState Message MUST NOT contain
   only a portion of Node State TLVs as this could cause problems with
   the Protocol Message Processing (Section 4.3) algorithm.  Finally, if
   the long version of the NetState message would exceed the minimum
   IPv6 MTU when sent, the short version of the NetState message MUST be
   used instead.

4.2.2.  Network State Request, (NetState-Req)

   This Message MUST be sent as 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 TLV (Section 5.1.1).

4.2.3.  Node Data Request (Node-Req)

   This Message MUST be sent as a unicast message.

   MUST be present:

      Node Link TLV (Section 5.2.1).

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







Stenberg & Barth         Expires April 30, 2015                 [Page 5]


Internet-Draft      Home Networking Control Protocol        October 2014


4.2.4.  Network and Node State Reply (NetNode-Reply)

   This Message MUST be sent as a unicast message.

   MUST be present:

      Node 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 by the sender, or

      one or more combinations of Node State 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).  This section describes
   processing of messages as received, along with associated actions or
   responses.

   HNCP is designed to operate between directly connected neighbors on a
   shared link using link-local IPv6 addresses.  If the source address
   of a received HNCP packet is not an IPv6 link-local unicast address,
   the packet SHOULD be dropped.  Similarly, if the destination address
   is not IPv6 link-local unicast or IPv6 link-local multicast address,
   packet SHOULD be dropped.

   Upon receipt of:

      NetState Message (Section 4.2.1): If the network state hash within
      the message matches the hash of the locally stored network state,
      consider Trickle state as consistent with no further processing
      required.  If the hashes do not match, consider Trickle state as
      inconsistent.  In this case, if the message is "short" (contains
      zero Node State TLVs), reply with a NetState-Req Message
      (Section 4.2.2).  If the message was in long format (contained all
      Node State TLVs), reply with NodeState-Req (Section 4.2.3) for any
      nodes for which local information is outdated (local update number
      is lower than that within the message), potentially incorrect
      (local update number is same and the hash of node data TLV
      differs) or missing.  Note that if local information is more
      recent than that of the neighbor, there is no need to send a
      message.

      NetState-Req (Section 4.2.2): Provide requested data in a NetNode-
      Reply Message containing Network State TLV and all Node State
      TLVs.



Stenberg & Barth         Expires April 30, 2015                 [Page 6]


Internet-Draft      Home Networking Control Protocol        October 2014


      NodeState-Req (Section 4.2.3): Provide requested data in 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 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 a valid set of data TLVs.
   When there is a change in a node's set of data TLVs, the update
   number MUST be incremented accordingly.

   If a message containing Node State TLVs (Section 5.2.3) is received
   via unicast or multicast with the node's own node identifier and a
   higher update number than current local value, or the same update
   number and different hash, there is an error somewhere.  A
   recommended default way to handle this is to attempt to assert local
   state by increasing the local update number to a value higher than
   that received and republish node data using the same node identifier.
   If this happens more than 3 times 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 the 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 and Removing Neighbors

   Whenever multicast message or unicast reply is received on a link
   from another node, the node should be added as Neighbor TLV
   (Section 5.2.5) for current node.  If nothing (for example - no
   router advertisements, no HNCP traffic) is received from that
   neighbor in Imax seconds and the neighbor is not in neighbor
   discovery cache, and no layer 2 indication of presence is available,
   at least 3 attempts 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 the last message
   nothing is received, the Neighbor 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 used to immediately
   trigger removal of corresponding Neighbor TLV(s).



Stenberg & Barth         Expires April 30, 2015                 [Page 7]


Internet-Draft      Home Networking Control Protocol        October 2014


4.5.  Purging Unreachable Nodes

   When 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 TLVs on both nodes, that
   have the remote node's identifier hash as h(neighbor node
   identifier), and local and neighbor link identifiers swapped.  After
   the traverse, unreachable nodes SHOULD be purged after some grace
   period.  During the grace period, the unreachable nodes MUST NOT be
   used for calculation of network state hash, or even be provided to
   any applications that need to use the whole TLV graph.

5.  Type-Length-Value objects

   Every TLV is encoded as 2 octet type, followed by 2 octet length (of
   the whole TLV, including header; 4 means no value), 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 be inserted at the end of TLV.  The padding bytes MUST NOT
   be included in the length field.

   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               |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Value                             |
   |                     (variable # of bytes)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Encoding of type=123 (0x7b) TLV with value 'x' (120 = 0x78): 007B
   0005 7800 0000

   Notation:

      .. = octet string concatenation operation

      H(x) = MD5 hash of x

      H-64(x) = H(x) truncated by taking just first 64 bits of the
      result.

5.1.  Request TLVs (for use within unicast requests)








Stenberg & Barth         Expires April 30, 2015                 [Page 8]


Internet-Draft      Home Networking Control Protocol        October 2014


5.1.1.  Request 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type: REQ-NETWORK-STATE (2)  |           Length: 4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.1.2.  Request 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 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: REQ-NODE-DATA (3)    |          Length: 20           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                       H(node identifier)                      |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.  Data TLVs (for use in both multi- and unicast data)

5.2.1.  Node Link 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)      |          Length: 24           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                       H(node identifier)                      |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link-Identifier                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.2.  Network State TLV












Stenberg & Barth         Expires April 30, 2015                 [Page 9]


Internet-Draft      Home Networking Control Protocol        October 2014


   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: NETWORK-STATE (4)    |          Length: 20           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |          H(H(node data TLV 1) .. H(node data TLV N))          |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Node Data TLVs are ordered for hashing by octet comparison of the
   corresponding node identifier hashes in ascending order.

5.2.3.  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)                       |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The whole network should have roughly the same idea about the time
   since origination, i.e. even the originating router should increment
   the time whenever it needs to send a new Node State TLV regarding
   itself without changing the corresponding Node Data TLV.  This age
   value is not included within the Node Data TLV, however, as that is
   immutable and potentially signed by the originating node at the time
   of origination.








Stenberg & Barth         Expires April 30, 2015                [Page 10]


Internet-Draft      Home Networking Control Protocol        October 2014


5.2.4.  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 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 4 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 in question vouches that the
   specified neighbor is reachable by it on the local link id given.
   This reachability may be unidirectional (if no unicast exchanges have
   been performed with the neighbor).  The presence of this TLV at least
   guarantees that the node publishing it has received traffic from the
   neighbor recently.  For guaranteed bidirectional reachability,
   existence of both nodes' matching Neighbor TLVs should be checked.

5.3.  Custom TLV (within/without Node Data TLV)









Stenberg & Barth         Expires April 30, 2015                [Page 11]


Internet-Draft      Home Networking Control Protocol        October 2014


   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; the URI used should be
   under control of the author 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 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: VERSION (10)        |         Length: >= 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Version                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          User-agent                           |

   This TLV indicates which version of HNCP TLV binary structures 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 one MUST be ignored (but forwarded).  The user-
   agent 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).

   In order to avoid conflicts between border discovery and homenet
   routers running DHCP [RFC2131] or DHCPv6-PD [RFC3633] servers each



Stenberg & Barth         Expires April 30, 2015                [Page 12]


Internet-Draft      Home Networking Control Protocol        October 2014


   router MUST implement the following mechanism based on The User Class
   Option for DHCP [RFC3004] or its DHCPv6 counterpart [RFC3315]
   respectively into its DHCP and DHCPv6-logic:

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

      A homenet 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 set for an interface, it MUST be used.

   2.  Any of the following conditions indicate an interface MUST be
       considered external:

       1.  A delegated prefix could be acquired by running a
           DHCPv6-client on the interface.

       2.  An IPv4-address could be acquired by running a DHCP-client on
           the interface.

   3.  As default fallback, 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 following
   specializations of the internal category are defined to modify the
   local router behavior:

      Leaf category: This declares an interface used by clients only.  A
      router SHOULD implement this category and MUST NOT send nor accept
      HNCP messages on these interfaces.

      Guest category: This declares an interface used by untrusted
      clients only.  In addition to the restrictions of the leaf
      category, clients connected to these interfaces MUST NOT be able
      to reach devices inside the home network by default and instead
      SHOULD only be able to reach the internet.  This category SHOULD
      be also supported.

      Ad-hoc category: This declares an interface to be in ad-hoc mode.
      This indicates to HNCP applications such as prefix assignment that




Stenberg & Barth         Expires April 30, 2015                [Page 13]


Internet-Draft      Home Networking Control Protocol        October 2014


      links on this interface are potentially non-transitive.  This
      category MAY be implemented.

      Hybrid category: This allows the router to still accepts external
      connections but does not do border discovery.  It is assumed that
      the link is under control of a legacy, trustworthy non-HNCP
      router, still within the same home network.  Detection of this
      category automatically in addition to manual configuration is out
      of scope for this document.  This category MAY be implemented.

   A homenet router SHOULD provide basic connectivity to legacy CERs
   [RFC7084] connected to internal interfaces in order to allow
   coexistence with existing devices.

   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
   DHCP and DHCPv6-client as long as the interface is active including
   states where it considers the interface to be internal.  The router
   SHOULD wait for a reasonable time period (5 seconds as a possible
   default) in which 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 and allow internal traffic 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 in 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 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 using one container-TLV 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 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type: EXTERNAL-CONNECTION (41)|          Length: > 4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Nested TLVs                          |

   Auxiliary connectivity information is encoded as a stream of
   DHCPv6-attributes or DHCP-attributes placed inside a TLV of type
   EXTERNAL-CONNECTION or DELEGATED-PREFIX (for IPv6 prefix-specific
   information).  There MUST NOT be more than one instance of this TLV
   inside a container and the order of the DHCP(v6)-attributes contained



Stenberg & Barth         Expires April 30, 2015                [Page 14]


Internet-Draft      Home Networking Control Protocol        October 2014


   within it MUST be preserved as long as the information contained does
   not change.  The TLVs are encoded 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 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: DHCPV6-DATA (45)     |          Length: > 4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    DHCPv6 attribute stream                    |

   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 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type: DHCP-DATA (44)      |          Length: > 4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      DHCP attribute stream                    |

   Each delegated prefix is encoded using one TLV inside an EXTERNAL-
   CONNECTION TLV.  For external IPv4 connections the prefix is encoded
   in the form of an IPv4-mapped address [RFC4291] and is usually from a
   private address range [RFC1918].  The related TLV is defined 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 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type: DELEGATED-PREFIX (42)  |         Length: >= 13         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Valid until (milliseconds)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Preferred until (milliseconds)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |                                               |
   +-+-+-+-+-+-+-+-+        Prefix Address [+ nested TLVs]         +
   |                                                               |

      Valid until is the time in milliseconds the delegated prefix is
      valid.  The value is relative to the point in time the TLV is
      first announced.

      Preferred until is the time in milliseconds the delegated prefix
      is preferred.  The value is relative to the point in time the TLV
      is first announced.

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



Stenberg & Barth         Expires April 30, 2015                [Page 15]


Internet-Draft      Home Networking Control Protocol        October 2014


      Prefix address is of variable length and contains the significant
      bits of the prefix padded with zeroes up to the next byte
      boundary.

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

   In order for routers to use the distributed information, prefixes and
   addresses have to be assigned to the interior links of the homenet.
   A router MUST therefore implement the algorithm defined in Prefix and
   Address Assignment in a Home Network
   [I-D.ietf-homenet-prefix-assignment].  In order to announce the
   assigned prefixes 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 is defined 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 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type: ASSIGNED-PREFIX (43)   |          Length: >= 9         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link Identifier                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  R. |A| Pref. | Prefix Length |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Prefix Address        +
   |                                                               |

      Link Identifier is the local HNCP identifier of the link the
      prefix is assigned to.

      R. is reserved for future additions and MUST be set to 0 when
      creating TLVs and ignored when parsing them.

      A is the authoritative flag which indicates that an assignment is
      enforced and ignores usual collision detection rules.

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

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

      Prefix address is of variable length and contains the significant
      bits of the prefix padded with zeroes up to the next byte
      boundary.




Stenberg & Barth         Expires April 30, 2015                [Page 16]


Internet-Draft      Home Networking Control Protocol        October 2014


   In some cases (e.g.  IPv4) the set of addresses is very limited and
   stateless mechanisms are not really suitable for address assignment.
   Therefore HNCP can manage router address in these cases by itself.
   Each router assigning an address to one of its interfaces announces
   one TLV of the following kind:

   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)   |           Length: 24          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Link Identifier                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         Router Address                        |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Link Identifier is the local HNCP identifier of the link the
      address is assigned to.

      Router Address is the address assigned to one of 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 the home automatically.  Following TLVs
   MAY be used to provide transport for that specification.

7.1.  DNS Delegated Zone TLV

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type: DNS-DELEGATED-ZONE (50) |        Length: >= 21          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                            Address                            |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved  |S|B|                                               |
   +-+-+-+-+-+-+-+-+  Zone (DNS label sequence - variable length)  |
   |                                                               |



Stenberg & Barth         Expires April 30, 2015                [Page 17]


Internet-Draft      Home Networking Control Protocol        October 2014


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          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Domain (DNS label sequence - variable length)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7.3.  Router 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: ROUTER-NAME (52)     |         Length: >= 4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Name (not null-terminated - variable length)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 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 is capable
   of supporting in the homenet.  It MUST announce at least one protocol
   or the fallback mechanism to be considered for protocol selection and
   MAY omit announcing the fallback mechanism if it announces at least
   one other routing protocol.  It SHOULD assign a preference value for
   each protocol that indicates its desire to use said protocol over



Stenberg & Barth         Expires April 30, 2015                [Page 18]


Internet-Draft      Home Networking Control Protocol        October 2014


   other protocols it supports and SHOULD make these values
   configurable.

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

      Protocol ID 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 is a value from 0 to 255.  If a router is neutral about
      a routing protocol it SHOULD use the value 128, otherwise a lower
      value indicating lower preference or a higher value indicating
      higher preference respectively.

8.3.  Protocol Selection

   When HNCP detects that a device has joined or left the homenet it
   MUST examine all advertised routing protocols 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 the homenet

   2.  Has the highest preference value among all 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 in the need to change from
   one routing protocol to another on the homenet, the router MUST stop



Stenberg & Barth         Expires April 30, 2015                [Page 19]


Internet-Draft      Home Networking Control Protocol        October 2014


   the previously running protocol, remove associated routes, and start
   the new protocol in a graceful manner.  If there is no common routing
   protocol available among all homenet routers, routers MUST utilize
   the Fallback Mechanism (Section 8.4).

8.4.  Fallback Mechanism

   In cases where there is no commonly supported routing protocol
   available the following fallback algorithm is run to setup routing
   and preserve interoperability among the homenet.  While not intended
   to replace a routing protocol, this mechanism provides a valid - but
   not necessarily optimal - routing topology.  This algorithm uses the
   node and neighbor state already synchronized by HNCP, and therefore
   does not require any additional protocol message exchange.

   1.  Interpret the neighbor information received via HNCP as a graph
       of connected routers.

   2.  Use breadth-first traversal to determine the next-hop and hop-
       count in the path to each router in the homenet:

       1.  Start the traversal with the immediate neighbors of the
           router running the algorithm.

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

       3.  Never visit a router more often than once.

   3.  For each delegated prefix P of any router R in the homenet:
       Create a default route via the next-hop for R acquired in #2.
       Each such route MUST be source-restricted to only apply to
       traffic with a source address within P and its metric MUST
       reflect the hop-count to R.

   4.  For each assigned prefix A of a router R: Create a route to A via
       the next-hop for R acquired in #2.  Each such route MUST NOT be
       source-restricted.

   5.  For the first router R visited in the traversal announcing an
       IPv4-uplink: Create a default IPv4-route via the next-hop for R
       acquired in #2.

   6.  For each assigned IPv4-prefix A of a router R: Create an
       IPv4-route to A via the next-hop for R acquired in #2.






Stenberg & Barth         Expires April 30, 2015                [Page 20]


Internet-Draft      Home Networking Control Protocol        October 2014


9.  Security Considerations

   General security issues for home networks are discussed at length in
   [RFC7368].  The protocols used to set up IP in home networks today
   have rarely security enabled within the control protocol itself.  For
   example, DHCP has defined [RFC3118] to authenticate DHCP 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.

   HNCP itself sends messages as clear text which is as secure, or
   insecure, as the security of the link it runs on.  As HNCP messages
   are sent over IPv6 UDP, IPsec may be used for confidentiality or
   message authentication.  This requires manually keyed IPsec per-port
   granularity for port IANA-UDP-PORT UDP traffic, and a pre-shared key
   has to be utilized in this case given IKE cannot be used with
   multicast traffic.  This seems acceptable, though, as most routing
   protocols also operate based on pre-shared keys, and the homenet
   architecture draft explicitly allows their use for securing
   them[RFC7368].  Other traffic security mechanisms are out of scope
   for this specification.  There is ongoing work
   [I-D.barth-homenet-hncp-security-trust] to define a mechanism that
   can be used with HNCP and be more user-friendly than pre-shared keys.

10.  IANA Considerations

   IANA should set up a registry (policy TBD) for HNCP TLV types, with
   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



Stenberg & Barth         Expires April 30, 2015                [Page 21]


Internet-Draft      Home Networking Control Protocol        October 2014


   9: Custom

   10: Version

   41: External connection

   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

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

11.  References

11.1.  Normative references

   [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, J., Gnawali, O., and J. Ko,
              "The Trickle Algorithm", RFC 6206, March 2011.

   [I-D.ietf-homenet-prefix-assignment]
              Pfister, P., Paterson, B., and J. Arkko, "Prefix and
              Address Assignment in a Home Network", draft-ietf-homenet-
              prefix-assignment-01 (work in progress), October 2014.








Stenberg & Barth         Expires April 30, 2015                [Page 22]


Internet-Draft      Home Networking Control Protocol        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 (work in progress), June 2014.

11.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. and L. Colitti, "IPv6 Multihoming with Source
              Address Dependent Routing (SADR)", draft-troan-homenet-
              sadr-01 (work in progress), September 2013.






Stenberg & Barth         Expires April 30, 2015                [Page 23]


Internet-Draft      Home Networking Control Protocol        October 2014


   [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. 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 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 and preferred are now 32 bit millisecond 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?



Stenberg & Barth         Expires April 30, 2015                [Page 24]


Internet-Draft      Home Networking Control Protocol        October 2014


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

Appendix C.  Changelog

   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.





Stenberg & Barth         Expires April 30, 2015                [Page 25]


Internet-Draft      Home Networking Control Protocol        October 2014


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

   As usual, this draft is available at https://github.com/fingon/ietf-
   drafts/ in source format (with nice Makefile too).  Feel free to send
   comments and/or pull requests if and when you have changes to it!

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

   Email: cyrus@openwrt.org






















Stenberg & Barth         Expires April 30, 2015                [Page 26]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/