Distributed Node Consensus Protocol
draft-ietf-homenet-dncp-12

   If multicast is used, a well-known address should be specified, and
   for e.g.  IPv6 respectively the desired address scopes.  In most
   cases link-local and possibly site-local are useful scopes.

B.3.  (Optional) Transport Security

   In terms of provided security, DTLS and TLS are equivalent; they also
   consume similar amount of state on the devices.  While TLS is on top
   of a stream protocol, using DTLS also requires relatively long
   session caching within the DTLS layer to avoid expensive re-
   authentication/authorization steps if and when any state within the
   DNCP network changes or per-peer keep-alive (if enabled) is sent.

   TLS implementations (at the time of the writing of the specification)
   seem more mature and available (as open source) than DTLS ones.  This
   may be due to a long history of use with HTTPS.

   Some libraries seem not to support multiplexing between insecure and
   secure communication on the same port, so specifying distinct ports
   for secured and unsecured communication may be beneficial.

Appendix C.  Example Profile

   This is the DNCP profile of SHSP, an experimental (and for the
   purposes of this document fictional) home automation protocol.  The
   protocol itself is used to make key-value store published by each of
   the nodes available to all other nodes for distributed monitoring and
   control of a home infrastructure.  It defines only one additional TLV
   type: a key=value TLV which contains a single key=value assignment
   for publication.

   o  Unicast transport: IPv6 TCP on port EXAMPLE-P1 since only absolute
      timestamps are used within the key=value data and since it focuses
      primarily on Linux-based nodes which support both protocols well.
      Connections from and to non-link-local addresses are ignored to
      avoid exposing this protocol outside the secure links.

   o  Multicast transport: IPv6 UDP on port EXAMPLE-P2 to link-local
      scoped multicast address ff02:EXAMPLE.  At least one node per link
      in the home is assumed to facilitate node discovery without
      depending on any other infrastructure.

   o  Security: None.  It is to be used only on trusted links (WPA2-x
      wireless, physically secure wired links).

   o  Additional TLVs to be ignored: None.  No DNCP security is
      specified, and no new TLVs are defined outside of node data.

Stenberg & Barth           Expires May 5, 2016                 [Page 37]
Internet-Draft     Distributed Node Consensus Protocol     November 2015

   o  Node identifier length (DNCP_NODE_IDENTIFIER_LENGTH): 32 bits that
      are randomly generated.

   o  Node identifier collision handling: Pick new random node
      identifier.

   o  Trickle parameters: Imin = 200ms, Imax = 7, k = 1.  It means at
      least one multicast per link in 25 seconds in stable state (0.2 *
      2^7).

   o  Hash function H(x) + length: SHA-256, only 128 bits used.
      Relatively fast, and 128 bits should be plenty to prevent random
      conflicts (64 bits would most likely be sufficient, too).

   o  No in-protocol keep-alives (Section 6.1); TCP keep-alive is to be
      used.  In practice TCP keep-alive is seldom encountered anyway as
      changes in network state cause packets to be sent on the unicast
      connections, and those that fail sufficiently many retransmissions
      are dropped much before keep-alive actually would fire.

   o  No support for dense multicast-enabled link optimization
      (Section 6.2); SHSP is a simple protocol for few nodes (network-
      wide, not even to mention on a single link), and therefore would
      not provide any benefit.

Appendix D.  Some Questions and Answers [RFC Editor: please remove]

   Q: 32-bit endpoint id?

   A: Here, it would save 32 bits per peer if it was 16 bits (and less
   is not realistic).  However, TLVs defined elsewhere would not seem to
   even gain that much on average.  32 bits is also used for ifindex in
   various operating systems, making for simpler implementation.

   Q: Why have topology information at all?

   A: It is an alternative to the more traditional seq#/TTL-based
   flooding schemes.  In steady state, there is no need to, e.g., re-
   publish every now and then.

Appendix E.  Changelog [RFC Editor: please remove]

   draft-ietf-homenet-dncp-10:

   o  Added profile guidance section, as well as example profile.

   draft-ietf-homenet-dncp-09:

Stenberg & Barth           Expires May 5, 2016                 [Page 38]
Internet-Draft     Distributed Node Consensus Protocol     November 2015

   o  Reserved 1024+ TLV types for future versions (=versioning
      mechanism); private use section moved from 192-255 to 512-767.

   o  Added applicability statement and clarified some text based on
      reviews.

   draft-ietf-homenet-dncp-08:

   o  Removed fragmentation as it is somewhat underspecified and
      unimplemented.  It may be specified in some future extension draft
      or new version of DNCP.

   o  Added generic sub-TLV extensibility mechanism.

   draft-ietf-homenet-dncp-06:

   o  Removed custom TLV.

   o  Made keep-alive multipliers local implementation choice, profiles
      just provide guidance on sane default value.

   o  Removed the DNCP_GRACE_INTERVAL as it is really implementation
      choice.

   o  Simplified the suggested structures in data model.

   o  Reorganized the document and provided an overview section.

   draft-ietf-homenet-dncp-04:

   o  Added mandatory rate limiting for network state requests, and
      optional slightly faster convergence mechanism by including
      current local network state in the remote network state requests.

   draft-ietf-homenet-dncp-03:

   o  Renamed connection -> endpoint.

   o  !!! Backwards incompatible change: Renumbered TLVs, and got rid of
      node data TLV; instead, node data TLV's contents are optionally
      within node state TLV.

   draft-ietf-homenet-dncp-02:

   o  Changed DNCP "messages" into series of TLV streams, allowing
      optimized round-trip saving synchronization.

Stenberg & Barth           Expires May 5, 2016                 [Page 39]
Internet-Draft     Distributed Node Consensus Protocol     November 2015

   o  Added fragmentation support for bigger node data and for chunking
      in absence of reliable L2 and L3 fragmentation.

   draft-ietf-homenet-dncp-01:

   o  Fixed keep-alive semantics to consider unicast requests also
      updates of most recently consistent, and added proactive unicast
      request to ensure even inconsistent keep-alive messages eventually
      triggering consistency timestamp update.

   o  Facilitated (simple) read-only clients by making Node Connection
      TLV optional if just using DNCP for read-only purposes.

   o  Added text describing how to deal with "dense" networks, but left
      actual numbers and mechanics up to DNCP profiles and (local)
      configurations.

   draft-ietf-homenet-dncp-00: Split from pre-version of draft-ietf-
   homenet-hncp-03 generic parts.  Changes that affect implementations:

   o  TLVs were renumbered.

   o  TLV length does not include header (=-4).  This facilitates, e.g.,
      use of DHCPv6 option parsing libraries (same encoding), and
      reduces complexity (no need to handle error values of length less
      than 4).

   o  Trickle is reset only when locally calculated network state hash
      is changes, not as remote different network state hash is seen.
      This prevents, e.g., attacks by multicast with one multicast
      packet to force Trickle reset on every interface of every node on
      a link.

   o  Instead of 'ping', use 'keep-alive' (optional) for dead peer
      detection.  Different message used!

Appendix F.  Draft Source [RFC Editor: please remove]

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

   Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley,
   Juliusz Chroboczek, Jiazi Yi, Mikael Abrahamsson, Brian Carpenter,
   Thomas Clausen, DENG Hui and Margaret Cullen for their contributions
   to the draft.

Stenberg & Barth           Expires May 5, 2016                 [Page 40]
Internet-Draft     Distributed Node Consensus Protocol     November 2015

   Thanks to Kaiwen Jin and Xavier Bonnetain for their related research
   work.

Authors' Addresses

   Markus Stenberg
   Independent
   Helsinki  00930
   Finland

   Email: markus.stenberg@iki.fi

   Steven Barth
   Independent
   Halle  06114
   Germany

   Email: cyrus@openwrt.org

Stenberg & Barth           Expires May 5, 2016                 [Page 41]