draft-ietf-homenet-dncp-08.txt   draft-ietf-homenet-dncp-09.txt 
Homenet Working Group M. Stenberg Homenet Working Group M. Stenberg
Internet-Draft S. Barth Internet-Draft S. Barth
Intended status: Standards Track Independent Intended status: Standards Track Independent
Expires: January 22, 2016 July 21, 2015 Expires: February 6, 2016 August 5, 2015
Distributed Node Consensus Protocol Distributed Node Consensus Protocol
draft-ietf-homenet-dncp-08 draft-ietf-homenet-dncp-09
Abstract Abstract
This document describes the Distributed Node Consensus Protocol This document describes the Distributed Node Consensus Protocol
(DNCP), a generic state synchronization protocol that uses Trickle (DNCP), a generic state synchronization protocol that uses the
and hash trees. DNCP is an abstract protocol, that must be combined Trickle algorithm and hash trees. DNCP is an abstract protocol, and
with a specific profile to make a complete implementable protocol. must be combined with a specific profile to make a complete
implementable protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 22, 2016. This Internet-Draft will expire on February 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Hash Tree . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Hash Tree . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Data Transport . . . . . . . . . . . . . . . . . . . . . 7 4.2. Data Transport . . . . . . . . . . . . . . . . . . . . . 8
4.3. Trickle-Driven Status Updates . . . . . . . . . . . . . . 8 4.3. Trickle-Driven Status Updates . . . . . . . . . . . . . . 9
4.4. Processing of Received TLVs . . . . . . . . . . . . . . . 9 4.4. Processing of Received TLVs . . . . . . . . . . . . . . . 10
4.5. Adding and Removing Peers . . . . . . . . . . . . . . . . 11 4.5. Adding and Removing Peers . . . . . . . . . . . . . . . . 12
4.6. Data Liveliness Validation . . . . . . . . . . . . . . . 12 4.6. Data Liveliness Validation . . . . . . . . . . . . . . . 13
5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 14 6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 15
6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 15 6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 16
6.1.2. Per-Endpoint Periodic Keep-Alives . . . . . . . . . . 16 6.1.2. Per-Endpoint Periodic Keep-Alives . . . . . . . . . . 16
6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 16 6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 17
6.1.4. Received TLV Processing Additions . . . . . . . . . . 16 6.1.4. Received TLV Processing Additions . . . . . . . . . . 17
6.1.5. Peer Removal . . . . . . . . . . . . . . . . . . . . 16 6.1.5. Peer Removal . . . . . . . . . . . . . . . . . . . . 17
6.2. Support For Dense Broadcast Links . . . . . . . . . . . . 16 6.2. Support For Dense Multicast-Enabled Links . . . . . . . . 17
7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 17 7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 18
7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 19
7.1.1. Request Network State TLV . . . . . . . . . . . . . . 18 7.1.1. Request Network State TLV . . . . . . . . . . . . . . 19
7.1.2. Request Node State TLV . . . . . . . . . . . . . . . 19 7.1.2. Request Node State TLV . . . . . . . . . . . . . . . 19
7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2.1. Node Endpoint TLV . . . . . . . . . . . . . . . . . . 19 7.2.1. Node Endpoint TLV . . . . . . . . . . . . . . . . . . 20
7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 19 7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 20
7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 20 7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 21
7.3. Data TLVs within Node State TLV . . . . . . . . . . . . . 21 7.3. Data TLVs within Node State TLV . . . . . . . . . . . . . 22
7.3.1. Peer TLV . . . . . . . . . . . . . . . . . . . . . . 21 7.3.1. Peer TLV . . . . . . . . . . . . . . . . . . . . . . 22
7.3.2. Keep-Alive Interval TLV . . . . . . . . . . . . . . . 21 7.3.2. Keep-Alive Interval TLV . . . . . . . . . . . . . . . 22
8. Security and Trust Management . . . . . . . . . . . . . . . . 22 8. Security and Trust Management . . . . . . . . . . . . . . . . 23
8.1. Pre-Shared Key Based Trust Method . . . . . . . . . . . . 22 8.1. Pre-Shared Key Based Trust Method . . . . . . . . . . . . 23
8.2. PKI Based Trust Method . . . . . . . . . . . . . . . . . 22 8.2. PKI Based Trust Method . . . . . . . . . . . . . . . . . 23
8.3. Certificate Based Trust Consensus Method . . . . . . . . 22 8.3. Certificate Based Trust Consensus Method . . . . . . . . 23
8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 23 8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 24
8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 24 8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 25
8.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 24 8.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 25
8.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 25 8.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 26
9. DNCP Profile-Specific Definitions . . . . . . . . . . . . . . 26 9. DNCP Profile-Specific Definitions . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative references . . . . . . . . . . . . . . . . . . 29 12.1. Normative references . . . . . . . . . . . . . . . . . . 30
12.2. Informative references . . . . . . . . . . . . . . . . . 29 12.2. Informative references . . . . . . . . . . . . . . . . . 30
Appendix A. Alternative Modes of Operation . . . . . . . . . . . 29
A.1. Read-only Operation . . . . . . . . . . . . . . . . . . . 29 Appendix A. Alternative Modes of Operation . . . . . . . . . . . 31
A.2. Forwarding Operation . . . . . . . . . . . . . . . . . . 30 A.1. Read-only Operation . . . . . . . . . . . . . . . . . . . 31
A.2. Forwarding Operation . . . . . . . . . . . . . . . . . . 31
Appendix B. Some Questions and Answers [RFC Editor: please Appendix B. Some Questions and Answers [RFC Editor: please
remove] . . . . . . . . . . . . . . . . . . . . . . 30 remove] . . . . . . . . . . . . . . . . . . . . . . 31
Appendix C. Changelog [RFC Editor: please remove] . . . . . . . 30 Appendix C. Changelog [RFC Editor: please remove] . . . . . . . 32
Appendix D. Draft Source [RFC Editor: please remove] . . . . . . 32 Appendix D. Draft Source [RFC Editor: please remove] . . . . . . 33
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 32 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
DNCP is designed to provide a way for each participating node to DNCP is designed to provide a way for each participating node to
publish a set of TLV (Type-Length-Value) tuples, and to provide a publish a set of TLV (Type-Length-Value) tuples, and to provide a
shared and common view about the data published by every currently or shared and common view about the data published by every currently or
recently bidirectionally reachable DNCP node in a network. recently bidirectionally reachable DNCP node in a network.
For state synchronization a hash tree is used. It is formed by first For state synchronization a hash tree is used. It is formed by first
calculating a hash for the dataset published by each node, called calculating a hash for the dataset published by each node, called
node data, and then calculating another hash over those node data node data, and then calculating another hash over those node data
hashes. The single resulting hash, called network state hash, is hashes. The single resulting hash, called network state hash, is
transmitted using the Trickle algorithm [RFC6206] to ensure that all transmitted using the Trickle algorithm [RFC6206] to ensure that all
nodes share the same view of the current state of the published data nodes share the same view of the current state of the published data
within the network. The use of Trickle with only short network state within the network. The use of Trickle with only short network state
hashes sent infrequently (in steady state) makes DNCP very thrifty hashes sent infrequently (in steady state, once the maximum Trickle
when updates happen rarely. interval per link or unicast connection has been reached) makes DNCP
very thrifty when updates happen rarely.
For maintaining liveliness of the topology and the data within it, a For maintaining liveliness of the topology and the data within it, a
combination of Trickled network state, keep-alives, and "other" means combination of Trickled network state, keep-alives, and "other" means
of ensuring reachability are used. The core idea is that if every of ensuring reachability are used. The core idea is that if every
node ensures its peers are present, transitively, the whole network node ensures its peers are present, transitively, the whole network
state also stays up-to-date. state also stays up-to-date.
1.1. Applicability
DNCP is most suitable for data that changes only infrequently to gain DNCP is most suitable for data that changes only infrequently to gain
the maximum benefit from using Trickle. As the network of nodes, or the maximum benefit from using Trickle. As the network of nodes
the rate of data changes grows over a given time interval, Trickle is grows, or the frequency of data changes per node increases, Trickle
eventually used less and less and the benefit of using DNCP is eventually used less and less and the benefit of using DNCP
diminishes. In these cases Trickle just provides extra complexity diminishes. In these cases Trickle just provides extra complexity
within the specification and little added value. If constant rapid within the specification and little added value.
state changes are needed, the preferable choice is to use an
additional point-to-point channel whose address or locator is The suitability of DNCP for a particular application can roughly be
published using DNCP. evaluated by considering the expected average network-wide state
change interval A_NC_I; it is computed by dividing the mean interval
at which a node originates a new TLV set by the number of
participating nodes. If keep-alives are used, A_NC_I is the minimum
of the computed A_NC_I and the keep-alive interval. If A_NC_I is
less than the (application-specific) Trickle minimum interval, DNCP
is most likely unsuitable for the application as Trickle will not be
utilized most of the time.
If constant rapid state changes are needed, the preferable choice is
to use an additional point-to-point channel whose address or locator
is published using DNCP. Nevertheless, if doing so does not raise
A_NC_I above the (sensibly chosen) Trickle interval parameters for a
particular application, using DNCP is probably not suitable for the
application.
Another consideration is the size of the published TLV set by a node
compared to the size of deltas in the TLV set. If the TLV set
published by a node is very large, and has frequent small changes,
DNCP as currently specified may be unsuitable since it does not
define any delta synchronization scheme but always transmits the
complete updated TLV set verbatim.
DNCP can be used in networks where only unicast transport is
available. While DNCP uses the least amount of bandwidth when
multicast is utilized, even in pure unicast mode, the use of Trickle
(ideally with k < 2) results in a protocol with an exponential
backoff timer and fewer transmissions than a simpler protocol not
using Trickle.
2. Terminology 2. Terminology
DNCP profile a definition of the set of rules and values DNCP profile the values for the set of parameters, given in
defining the behavior of a fully specified, Section 9. They are prefixed with DNCP_ in this
implementable protocol which uses DNCP. The DNCP document. The profile also specifies the set of
profile specifies transport method to be used, optional DNCP extensions to be used.
which optional parts of the DNCP specification are
required by that particular protocol, and various DNCP-based a protocol which provides a DNCP profile, according
parameters and optional behaviors. In this protocol to Section 9, and zero or more TLV assignments from
document any parameter that a DNCP profile the per-DNCP profile TLV registry as well as their
specifies is prefixed with DNCP_. Contents of a processing rules.
DNCP profile are specified in Section 9.
DNCP-based a protocol which provides a DNCP profile, and
protocol potentially much more, e.g., protocol-specific TLVs
and guidance on how they should be used.
DNCP node a single node which runs a DNCP-based protocol. DNCP node a single node which runs a DNCP-based protocol.
Link a link-layer media over which directly connected Link a link-layer media over which directly connected
nodes can communicate. nodes can communicate.
DNCP network a set of DNCP nodes running the same DNCP-based
protocol. The set consists of nodes that have DNCP network a set of DNCP nodes running DNCP-based protocol(s)
discovered each other using the transport method with matching DNCP profile(s). The set consists of
defined in the DNCP profile, via multicast on local nodes that have discovered each other using the
links, and/or by using unicast communication. transport method defined in the DNCP profile, via
multicast on local links, and / or by using unicast
communication.
Node identifier an opaque fixed-length identifier consisting of Node identifier an opaque fixed-length identifier consisting of
DNCP_NODE_IDENTIFIER_LENGTH bytes which uniquely DNCP_NODE_IDENTIFIER_LENGTH bytes which uniquely
identifies a DNCP node within a DNCP network. identifies a DNCP node within a DNCP network.
Interface a node's attachment to a particular link. Interface a node's attachment to a particular link.
Address As DNCP itself is relatively transport agnostic, an Address an identifier used as source or destination of a
address in this specification denotes just DNCP message flow, e.g., a tuple (IPv6 address, UDP
something that identifies an endpoint used by the port) for an IPv6 UDP transport.
transport protocol that is used by a DNCP-based
protocol. In case of an IPv6 UDP transport, an
address in this specification refers to a tuple
(IPv6 address, UDP port).
Endpoint a locally configured communication endpoint of a
DNCP node, such as a network socket. An endpoint
may be bound to a set of predefined unicast
Addresses representing remote DNCP nodes to
individually connect to or to accept connections
from whereby communication with each node is
separated (e.g., an individual unicast UDP message
flow per remote node). An endpoint may also be
bound to a whole network interface, then multicast
communication is used (in addition to individual
unicast flows) to send certain messages to all DNCP
nodes connected therewith at once as well as to
automatically discover new DNCP nodes. Endpoints
are usually in one of the transport modes specified
in Section 4.2.
Endpoint a 32-bit opaque value, which identifies a Endpoint a locally configured termination point for
identifier particular endpoint of a particular DNCP node. The (potential or established) DNCP message flows. An
value 0 is reserved for DNCP and DNCP-based endpoint is the source and destination for separate
protocol purposes and not used to identify an unicast message flows to individual nodes and
actual endpoint. This definition is in sync with optionally for multicast messages to all thereby
the interface index definition in [RFC3493], as the reachable nodes (e.g., for node discovery).
non-zero small positive integers should comfortably Endpoints are usually in one of the transport modes
fit within 32 bits. specified in Section 4.2.
Endpoint a 32-bit opaque and locally unique value, which
identifier identifies a particular endpoint of a particular
DNCP node. The value 0 is reserved for DNCP and
DNCP-based protocol purposes and not used to
identify an actual endpoint. This definition is in
sync with the interface index definition in
[RFC3493], as the non-zero small positive integers
should comfortably fit within 32 bits.
Peer another DNCP node with which a DNCP node Peer another DNCP node with which a DNCP node
communicates using a particular local and remote communicates using a particular local and remote
endpoint pair. endpoint pair.
Node data a set of TLVs published and owned by a node in the Node data a set of TLVs published and owned by a node in the
DNCP network. Other nodes pass it along as-is, even DNCP network. Other nodes pass it along as-is, even
if they cannot fully interpret it. if they cannot fully interpret it.
Node state a set of metadata attributes for node data. It Node state a set of metadata attributes for node data. It
skipping to change at page 6, line 5 skipping to change at page 6, line 21
the certificate based trust consensus mechanism. the certificate based trust consensus mechanism.
Effective trust the trust verdict with the highest priority within Effective trust the trust verdict with the highest priority within
verdict the set of trust verdicts announced for the verdict the set of trust verdicts announced for the
certificate in the DNCP network. certificate in the DNCP network.
Topology graph the undirected graph of DNCP nodes produced by Topology graph the undirected graph of DNCP nodes produced by
retaining only bidirectional peer relationships retaining only bidirectional peer relationships
between nodes. between nodes.
Bidirectionally a peer is locally unidirectionally reachable if a
reachable recent and consistent multicast or any unicast DNCP
message has been received by the local node (see
Section 4.5). If said peer in return also
considers the local node unidirectionally
reachable, then bidirectionally reachability is
established. As this process is based on
publishing peer relationships and evaluating the
resulting topology graph as described in Section
4.6, this information is available to the whole
DNCP network.
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
3. Overview 3. Overview
DNCP operates primarily using unicast exchanges between nodes, and DNCP operates primarily using unicast exchanges between nodes, and
may use multicast for Trickle-based shared state dissemination and may use multicast for Trickle-based shared state dissemination and
topology discovery. If used in pure unicast mode with unreliable topology discovery. If used in pure unicast mode with unreliable
transport, Trickle is also used between peers. transport, Trickle is also used between peers.
DNCP discovers the topology of its nodes and maintains the liveliness DNCP discovers the topology of the nodes in the DNCP network and
of published node data by ensuring that the publishing node was - at maintains the liveliness of published node data by ensuring that the
least recently - bidirectionally reachable. This is determined, publishing node was - at least recently - bidirectionally reachable.
e.g., by a recent and consistent multicast or unicast TLV exchange New potential peers can be discovered autonomously on multicast-
with its peers. New potential peers can be discovered autonomously enabled links, their addresses may be manually configured or they may
on multicast-enabled links, their addresses may be manually be found by some other means defined in a later specification.
configured or they may be found by some other means defined in a
later specification.
A hash tree is maintained by each node to represent the state of all A hash tree of height 1, rooted in itself, is maintained by each node
currently reachable nodes and the Trickle algorithm is used to to represent the state of all currently reachable nodes (see
trigger synchronization. The need to check peer nodes for state Section 4.1) and the Trickle algorithm is used to trigger
changes is thereby determined by comparing the current root of their synchronization (see Section 4.3). The need to check peer nodes for
respective trees, i.e., their individually calculated network state state changes is thereby determined by comparing the current root of
hashes. their respective hash trees, i.e., their individually calculated
network state hashes.
Before joining a DNCP network, a node starts with a hash tree (and Before joining a DNCP network, a node starts with a hash tree that
therefore a calculated network state hash) only consisting of the has only one leaf if the node publishes some TLVs, and no leaves
node itself. It then announces said hash by means of the Trickle otherwise. It then announces the network state hash calculated from
algorithm on all its configured endpoints. the hash tree by means of the Trickle algorithm on all its configured
endpoints.
When an update is detected by a node (e.g., by receiving a different When an update is detected by a node (e.g., by receiving a different
network state hash from a peer) the originator of the event is network state hash from a peer) the originator of the event is
requested to provide a list of the state of all nodes, i.e., all the requested to provide a list of the state of all nodes, i.e., all the
information it uses to calculate its own hash tree. The node uses information it uses to calculate its own hash tree. The node uses
the list to determine whether its own information is outdated and - the list to determine whether its own information is outdated and -
if necessary - requests the actual node data that has changed. if necessary - requests the actual node data that has changed.
Whenever a node's local copy of any node data and its hash tree are Whenever a node's local copy of any node data and its hash tree are
updated (e.g., due to its own or another node's node state changing updated (e.g., due to its own or another node's node state changing
skipping to change at page 7, line 30 skipping to change at page 8, line 11
The node data hashes in the leaves and the root network state hash The node data hashes in the leaves and the root network state hash
are updated on-demand and whenever any locally stored per-node state are updated on-demand and whenever any locally stored per-node state
changes. This includes local unidirectional reachability encoded in changes. This includes local unidirectional reachability encoded in
the published Peer TLVs (Section 7.3.1) and - when combined with the published Peer TLVs (Section 7.3.1) and - when combined with
remote data - results in awareness of bidirectional reachability remote data - results in awareness of bidirectional reachability
changes. changes.
4.2. Data Transport 4.2. Data Transport
DNCP has relatively few requirements for the underlying transport; it DNCP has few requirements for the underlying transport; it requires
requires some way of transmitting either unicast datagram or stream some way of transmitting either unicast datagram or stream data to a
data to a peer and, if used in multicast mode, a way of sending peer and, if used in multicast mode, a way of sending multicast
multicast datagrams. As multicast is used only to identify potential datagrams. As multicast is used only to identify potential new DNCP
new DNCP nodes and to send status messages which merely notify that a nodes and to send status messages which merely notify that a unicast
unicast exchange should be triggered, the multicast transport does exchange should be triggered, the multicast transport does not have
not have to be secured. If unicast security is desired and one of to be secured. If unicast security is desired and one of the built-
the built-in security methods is to be used, support for some TLS- in security methods is to be used, support for some TLS-derived
derived transport scheme - such as TLS [RFC5246] on top of TCP or transport scheme - such as TLS [RFC5246] on top of TCP or DTLS
DTLS [RFC6347] on top of UDP - is also required. A specific [RFC6347] on top of UDP - is also required. A specific definition of
definition of the transport(s) in use and their parameters MUST be the transport(s) in use and their parameters MUST be provided by the
provided by the DNCP profile. DNCP profile.
TLVs are sent across the transport as is, and they SHOULD be sent TLVs are sent across the transport as is, and they SHOULD be sent
together where, e.g., MTU considerations do not recommend sending together where, e.g., MTU considerations do not recommend sending
them in multiple batches. TLVs in general are handled individually them in multiple batches. TLVs in general are handled individually
and statelessly, with one exception: To form bidirectional peer and statelessly, with one exception: To form bidirectional peer
relationships DNCP requires identification of the endpoints used for relationships DNCP requires identification of the endpoints used for
communication. As bidirectional peer relationships are required for communication. As bidirectional peer relationships are required for
validating liveliness of published node data as described in validating liveliness of published node data as described in
Section 4.6, a DNCP node MUST send a Node Endpoint TLV Section 4.6, a DNCP node MUST send a Node Endpoint TLV
(Section 7.2.1). When it is sent varies, depending on the underlying (Section 7.2.1). When it is sent varies, depending on the underlying
skipping to change at page 8, line 42 skipping to change at page 9, line 25
Multicast+Unicast: If multicast datagram transport is available on Multicast+Unicast: If multicast datagram transport is available on
an endpoint, Trickle state is only maintained for the endpoint as an endpoint, Trickle state is only maintained for the endpoint as
a whole. It is used to send Network State TLVs every now and a whole. It is used to send Network State TLVs every now and
then, as specified in Section 4.3. Additionally, per-endpoint then, as specified in Section 4.3. Additionally, per-endpoint
keep-alives MAY be defined in the DNCP profile, as specified in keep-alives MAY be defined in the DNCP profile, as specified in
Section 6.1.2. Section 6.1.2.
MulticastListen+Unicast: Just like Unicast, except multicast MulticastListen+Unicast: Just like Unicast, except multicast
transmissions are listened to in order to detect changes of the transmissions are listened to in order to detect changes of the
highest node identifier. This mode is used only if the DNCP highest node identifier. This mode is used only if the DNCP
profile supports dense broadcast link optimization (Section 6.2). profile supports dense multicast-enabled link optimization
(Section 6.2).
4.3. Trickle-Driven Status Updates 4.3. Trickle-Driven Status Updates
The Trickle algorithm [RFC6206] has 3 parameters: Imin, Imax and k. The Trickle algorithm [RFC6206] has 3 parameters: Imin, Imax and k.
Imin and Imax represent the minimum and maximum values for I, which Imin and Imax represent the minimum and maximum values for I, which
is the time interval during which at least k Trickle updates must be is the time interval during which at least k Trickle updates must be
seen on an endpoint to prevent local state transmission. The actual seen on an endpoint to prevent local state transmission. The actual
suggested Trickle algorithm parameters are DNCP profile specific, as suggested Trickle algorithm parameters are DNCP profile specific, as
described in Section 9. described in Section 9.
skipping to change at page 10, line 39 skipping to change at page 11, line 25
reply, a local, current Network State TLV MAY also be sent. reply, a local, current Network State TLV MAY also be sent.
o Node State TLV (Section 7.2.3): o Node State TLV (Section 7.2.3):
* If the node identifier matches the local node identifier and * If the node identifier matches the local node identifier and
the TLV has a greater sequence number than its current local the TLV has a greater sequence number than its current local
value, or the same sequence number and a different hash, the value, or the same sequence number and a different hash, the
node SHOULD re-publish its own node data with a sequence number node SHOULD re-publish its own node data with a sequence number
significantly (e.g., 1000) greater than the received one, to significantly (e.g., 1000) greater than the received one, to
reclaim the node identifier. This difference is needed in reclaim the node identifier. This difference is needed in
order to ensure that it is higher then any potentially order to ensure that it is higher than any potentially
lingering copies of the node state in the network. This may lingering copies of the node state in the network. This may
occur normally once due to the local node restarting and not occur normally once due to the local node restarting and not
storing the most recently used sequence number. If this occurs storing the most recently used sequence number. If this occurs
more than once or for nodes not re-publishing their own node more than once or for nodes not re-publishing their own node
data, the DNCP profile MUST provide guidance on how to handle data, the DNCP profile MUST provide guidance on how to handle
these situations as it indicates the existence of another these situations as it indicates the existence of another
active node with the same node identifier. active node with the same node identifier.
* If the node identifier does not match the local node * If the node identifier does not match the local node
identifier, and one or more of the following conditions are identifier, and one or more of the following conditions are
skipping to change at page 12, line 16 skipping to change at page 12, line 46
on the endpoint and a Peer TLV (Section 7.3.1) MUST be created for on the endpoint and a Peer TLV (Section 7.3.1) MUST be created for
it. it.
o If received over multicast, the node MAY be sent a (possibly rate- o If received over multicast, the node MAY be sent a (possibly rate-
limited) unicast Request Network State TLV (Section 7.1.1). limited) unicast Request Network State TLV (Section 7.1.1).
If keep-alives specified in Section 6.1 are NOT sent by the peer If keep-alives specified in Section 6.1 are NOT sent by the peer
(either the DNCP profile does not specify the use of keep-alives or (either the DNCP profile does not specify the use of keep-alives or
the particular peer chooses not to send keep-alives), some other the particular peer chooses not to send keep-alives), some other
existing local transport-specific means (such as Ethernet carrier- existing local transport-specific means (such as Ethernet carrier-
detection or TCP keep-alive) MUST be used to ensure its presence. detection or TCP keep-alive) MUST be used to ensure its presence. If
When the peer is no longer present, the Peer TLV and the local DNCP the peer does not send keep-alives, and no means to verify presence
peer state MUST be removed. of the peer are available, the peer MUST be considered no longer
present and it SHOULD not be added back as a peer until it starts
sending keep-alives again. When the peer is no longer present, the
Peer TLV and the local DNCP peer state MUST be removed.
If the local endpoint is in the Multicast-Listen+Unicast transport If the local endpoint is in the Multicast-Listen+Unicast transport
mode, a Peer TLV (Section 7.3.1) MUST NOT be published for the peers mode, a Peer TLV (Section 7.3.1) MUST NOT be published for the peers
not having the highest node identifier. not having the highest node identifier.
4.6. Data Liveliness Validation 4.6. Data Liveliness Validation
The topology graph MUST be traversed either immediately or with a The topology graph MUST be traversed either immediately or with a
small delay shorter than the DNCP profile-defined Trickle Imin, small delay shorter than the DNCP profile-defined Trickle Imin,
whenever: whenever:
skipping to change at page 14, line 13 skipping to change at page 14, line 46
function used to compare them is described in Section 4.4. function used to compare them is described in Section 4.4.
o Origination time: the (estimated) time when the current TLV set o Origination time: the (estimated) time when the current TLV set
with the current sequence number was published. It is used to with the current sequence number was published. It is used to
populate the Milliseconds Since Origination field in a Node State populate the Milliseconds Since Origination field in a Node State
TLV (Section 7.2.3). Ideally it also has millisecond accuracy. TLV (Section 7.2.3). Ideally it also has millisecond accuracy.
Additionally, a DNCP node has a set of endpoints for which DNCP is Additionally, a DNCP node has a set of endpoints for which DNCP is
configured to be used. For each such endpoint, a node has: configured to be used. For each such endpoint, a node has:
o Endpoint identifier: the 32-bit opaque value uniquely identifying o Endpoint identifier: the 32-bit opaque locally unique value
the endpoint within the local node. It SHOULD NOT be reused identifying the endpoint within a node. It SHOULD NOT be reused
immediately after an endpoint is disabled. immediately after an endpoint is disabled.
o Trickle instance: the endpoint's Trickle instance with parameters o Trickle instance: the endpoint's Trickle instance with parameters
I, T, and c (only on an endpoint in Multicast+Unicast transport I, T, and c (only on an endpoint in Multicast+Unicast transport
mode). mode).
and one (or more) of the following: and one (or more) of the following:
o Interface: the assigned local network interface. o Interface: the assigned local network interface.
skipping to change at page 15, line 17 skipping to change at page 15, line 50
Trickle-driven status updates (Section 4.3) provide a mechanism for Trickle-driven status updates (Section 4.3) provide a mechanism for
handling of new peer detection on an endpoint, as well as state handling of new peer detection on an endpoint, as well as state
change notifications. Another mechanism may be needed to get rid of change notifications. Another mechanism may be needed to get rid of
old, no longer valid peers if the transport or lower layers do not old, no longer valid peers if the transport or lower layers do not
provide one. provide one.
If keep-alives are not specified in the DNCP profile, the rest of If keep-alives are not specified in the DNCP profile, the rest of
this subsection MUST be ignored. this subsection MUST be ignored.
A DNCP profile MAY specify either per-endpoint (sent using multicast A DNCP profile MAY specify either per-endpoint (sent using multicast
to all DNCP nodes connected to a multiple access link) or per-peer to all DNCP nodes connected to a multicast-enabled link) or per-peer
(sent using unicast to each peer individually) keep-alive support. (sent using unicast to each peer individually) keep-alive support.
For every endpoint that a keep-alive is specified for in the DNCP For every endpoint that a keep-alive is specified for in the DNCP
profile, the endpoint-specific keep-alive interval MUST be profile, the endpoint-specific keep-alive interval MUST be
maintained. By default, it is DNCP_KEEPALIVE_INTERVAL. If there is maintained. By default, it is DNCP_KEEPALIVE_INTERVAL. If there is
a local value that is preferred for that for any reason a local value that is preferred for that for any reason
(configuration, energy conservation, media type, ..), it can be (configuration, energy conservation, media type, ..), it can be
substituted instead. If a non-default keep-alive interval is used on substituted instead. If a non-default keep-alive interval is used on
any endpoint, a DNCP node MUST publish appropriate Keep-Alive any endpoint, a DNCP node MUST publish appropriate Keep-Alive
Interval TLV(s) (Section 7.3.2) within its node data. Interval TLV(s) (Section 7.3.2) within its node data.
skipping to change at page 16, line 46 skipping to change at page 17, line 35
For every peer on every endpoint, the endpoint-specific keep-alive For every peer on every endpoint, the endpoint-specific keep-alive
interval must be calculated by looking for Keep-Alive Interval TLVs interval must be calculated by looking for Keep-Alive Interval TLVs
(Section 7.3.2) published by the node, and if none exist, using the (Section 7.3.2) published by the node, and if none exist, using the
default value of DNCP_KEEPALIVE_INTERVAL. If the peer's last contact default value of DNCP_KEEPALIVE_INTERVAL. If the peer's last contact
timestamp has not been updated for at least locally chosen timestamp has not been updated for at least locally chosen
potentially endpoint-specific keep-alive multiplier (defaults to potentially endpoint-specific keep-alive multiplier (defaults to
DNCP_KEEPALIVE_MULTIPLIER) times the peer's endpoint-specific keep- DNCP_KEEPALIVE_MULTIPLIER) times the peer's endpoint-specific keep-
alive interval, the Peer TLV for that peer and the local DNCP peer alive interval, the Peer TLV for that peer and the local DNCP peer
state MUST be removed. state MUST be removed.
6.2. Support For Dense Broadcast Links 6.2. Support For Dense Multicast-Enabled Links
This optimization is needed to avoid a state space explosion. Given This optimization is needed to avoid a state space explosion. Given
a large set of DNCP nodes publishing data on an endpoint that uses a large set of DNCP nodes publishing data on an endpoint that uses
multicast on a link, every node will add a Peer TLV (Section 7.3.1) multicast on a link, every node will add a Peer TLV (Section 7.3.1)
for each peer. While Trickle limits the amount of traffic on the for each peer. While Trickle limits the amount of traffic on the
link in stable state to some extent, the total amount of data that is link in stable state to some extent, the total amount of data that is
added to and maintained in the DNCP network given N nodes on a added to and maintained in the DNCP network given N nodes on a
multicast-enabled link is O(N^2). Additionally if per-peer keep- multicast-enabled link is O(N^2). Additionally if per-peer keep-
alives are used, there will be O(N^2) keep-alives running on the link alives are used, there will be O(N^2) keep-alives running on the link
if liveliness of peers is not ensured using some other way (e.g., TCP if liveliness of peers is not ensured using some other way (e.g., TCP
connection lifetime, layer 2 notification, per-endpoint keep-alive). connection lifetime, layer 2 notification, per-endpoint keep-alive).
An upper bound for the number of peers that are allowed for a An upper bound for the number of peers that are allowed for a
particular type of link that an endpoint in Multicast+Unicast particular type of link that an endpoint in Multicast+Unicast
transport mode is used on SHOULD be provided by a DNCP profile, but transport mode is used on SHOULD be provided by a DNCP profile, but
MAY also be chosen at runtime. Main consideration when selecting a MAY also be chosen at runtime. The main consideration when selecting
bound (if any) for a particular type of link should be whether it a bound (if any) for a particular type of link should be whether it
supports broadcast traffic, and whether a too large number of peers supports multicast traffic, and whether a too large number of peers
case is likely to happen during the use of that DNCP profile on that case is likely to happen during the use of that DNCP profile on that
particular type of link. If neither is likely, there is little point particular type of link. If neither is likely, there is little point
specifying support for this for that particular link type. specifying support for this for that particular link type.
If a DNCP profile does not support this extension at all, the rest of If a DNCP profile does not support this extension at all, the rest of
this subsection MUST be ignored. This is because when this extension this subsection MUST be ignored. This is because when this extension
is used, the state within the DNCP network only contains a subset of is used, the state within the DNCP network only contains a subset of
the full topology of the network. Therefore every node must be aware the full topology of the network. Therefore every node must be aware
of the potential of it being used in a particular DNCP profile. of the potential of it being used in a particular DNCP profile.
skipping to change at page 17, line 49 skipping to change at page 18, line 38
identifier of the local node is the highest one, the node MUST switch identifier of the local node is the highest one, the node MUST switch
back to, or stay in Multicast+Unicast mode, and normally form peer back to, or stay in Multicast+Unicast mode, and normally form peer
relationships with all peers. relationships with all peers.
7. Type-Length-Value Objects 7. Type-Length-Value Objects
Each TLV is encoded as a 2 byte type field, followed by a 2 byte Each TLV is encoded as a 2 byte type field, followed by a 2 byte
length field (of the value excluding header, in bytes, 0 meaning no length field (of the value excluding header, in bytes, 0 meaning no
value) followed by the value itself, if any. Both type and length value) followed by the value itself, if any. Both type and length
fields in the header as well as all integer fields inside the value - fields in the header as well as all integer fields inside the value -
unless explicitly stated otherwise - are represented in network byte unless explicitly stated otherwise - are represented unsigned and in
order. Padding bytes with value zero MUST be added up to the next 4 network byte order. Padding bytes with value zero MUST be added up
byte boundary if the length is not divisible by 4. These padding to the next 4 byte boundary if the length is not divisible by 4.
bytes MUST NOT be included in the number stored in the length field. These padding bytes MUST NOT be included in the number stored in the
Each TLV which does not define optional fields or variable-length length field. Each TLV which does not define optional fields or
content MAY be sent with additional nested TLVs appended after the variable-length content MAY be sent with additional nested TLVs
required TLV fields - and padding (if applicable) to allow for appended after the required TLV fields - and padding (if applicable)
extensibility. In this case the length field includes the length of to allow for extensibility. In this case the length field includes
the original TLV, the length of the padding that are inserted before the length of the original TLV, the length of the padding that are
the embedded TLVs and the length of the added TLVs. Therefore, each inserted before the embedded TLVs and the length of the added TLVs.
node MUST accept received TLVs that are longer than the fixed fields Therefore, each node MUST accept received TLVs that are longer than
specified and ignore embedded TLVs it does not understand. the fixed fields specified and ignore embedded TLVs it does not
understand.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
.. ..
| (variable # of bytes) | | (variable # of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 34 skipping to change at page 21, line 34
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optionally) Node Data (a set of nested TLVs) | | (optionally) Node Data (a set of nested TLVs) |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV represents the local node's knowledge about the published This TLV represents the local node's knowledge about the published
state of a node in the DNCP network identified by the Node Identifier state of a node in the DNCP network identified by the Node Identifier
field in the TLV. field in the TLV.
Every node, including the originating one, MUST update the Every node, including the node publishing the node data, MUST update
Milliseconds Since Origination whenever it sends a Node State TLV the Milliseconds Since Origination whenever it sends a Node State TLV
based on when the node estimates the data was originally published. based on when the node estimates the data was originally published.
This is, e.g., to ensure that any relative timestamps contained This is, e.g., to ensure that any relative timestamps contained
within the published node data can be correctly offset and within the published node data can be correctly offset and
interpreted. Ultimately, what is provided is just an approximation, interpreted. Ultimately, what is provided is just an approximation,
as transmission delays are not accounted for. as transmission delays are not accounted for.
Absent any changes, if the originating node notices that the 32-bit Absent any changes, if the originating node notices that the 32-bit
milliseconds since origination value would be close to overflow milliseconds since origination value would be close to overflow
(greater than 2^32-2^16), the node MUST re-publish its TLVs even if (greater than 2^32-2^16), the node MUST re-publish its TLVs even if
there is no change. In other words, absent any other changes, the there is no change. In other words, absent any other changes, the
skipping to change at page 28, line 18 skipping to change at page 29, line 18
and for keep-alive purposes. However, no actual published data TLVs and for keep-alive purposes. However, no actual published data TLVs
will be sent across that channel. Therefore an attacker may only will be sent across that channel. Therefore an attacker may only
learn hash values of the state within DNCP and may be able to trigger learn hash values of the state within DNCP and may be able to trigger
unicast synchronization attempts between nodes on a local link this unicast synchronization attempts between nodes on a local link this
way. A DNCP node MUST therefore rate-limit its reactions to way. A DNCP node MUST therefore rate-limit its reactions to
multicast packets. multicast packets.
When using DNCP to bootstrap a network, PKI based solutions may have When using DNCP to bootstrap a network, PKI based solutions may have
issues when validating certificates due to potentially unavailable issues when validating certificates due to potentially unavailable
accurate time, or due to inability to use the network to either check accurate time, or due to inability to use the network to either check
Certifcate Revocation Lists or perform on-line validation. Certificate Revocation Lists or perform on-line validation.
The Certificate-based trust consensus mechanism defined in this The Certificate-based trust consensus mechanism defined in this
document allows for a consenting revocation, however in case of a document allows for a consenting revocation, however in case of a
compromised device the trust cache may be poisoned before the actual compromised device the trust cache may be poisoned before the actual
revocation happens allowing the distrusted device to rejoin the revocation happens allowing the distrusted device to rejoin the
network using a different identity. Stopping such an attack might network using a different identity. Stopping such an attack might
require physical intervention and flushing of the trust caches. require physical intervention and flushing of the trust caches.
11. IANA Considerations 11. IANA Considerations
IANA should set up a registry for DNCP TLV types, with the following IANA should set up a registry for the (decimal 16-bit) "DNCP TLV
initial contents: Types" under "Distributed Node Consensus Protocol (DNCP)", with the
following initial contents: ([RFC Editor: please remove] ideally as
http://www.iana.org/assignments/dncp-registry)
0: Reserved 0: Reserved
1: Request network state 1: Request network state
2: Request node state 2: Request node state
3: Node endpoint 3: Node endpoint
4: Network state 4: Network state
5: Node state 5: Node state
6: Reserved (was: Custom) 6: Reserved (was: Custom)
7: Reserved (was: Fragment count) 7: Reserved (was: Fragment count)
8: Peer 8: Peer
9: Keep-alive interval 9: Keep-alive interval
10: Trust-Verdict
10: Trust-Verdict 11-31: Free - policy of 'standards action' should be used
32-191: Reserved for per-DNCP profile use
192-255: Reserved for per-implementation experimentation. How 32-511: Reserved for per-DNCP profile use
collision is avoided is out of scope of this document.
For the rest of the values (11-31, 256-65535), policy of 'standards 512-767: Free - policy of 'standards action' should be used
action' should be used.
768-1023: Private use
1024-65535: Reserved for future protocol evolution (for example,
DNCP version 2)
12. References 12. References
12.1. Normative references 12.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, March 2011. "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI
10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>.
12.2. Informative references 12.2. Informative references
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC Stevens, "Basic Socket Interface Extensions for IPv6", RFC
3493, February 2003. 3493, DOI 10.17487/RFC3493, February 2003,
<http://www.rfc-editor.org/info/rfc3493>.
Appendix A. Alternative Modes of Operation Appendix A. Alternative Modes of Operation
Beyond what is described in the main text, the protocol allows for Beyond what is described in the main text, the protocol allows for
other uses. These are provided as examples. other uses. These are provided as examples.
A.1. Read-only Operation A.1. Read-only Operation
If a node uses just a single endpoint and does not need to publish If a node uses just a single endpoint and does not need to publish
any TLVs, full DNCP node functionality is not required. Such limited any TLVs, full DNCP node functionality is not required. Such limited
skipping to change at page 30, line 35 skipping to change at page 32, line 7
various operating systems, making for simpler implementation. various operating systems, making for simpler implementation.
Q: Why have topology information at all? Q: Why have topology information at all?
A: It is an alternative to the more traditional seq#/TTL-based 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- flooding schemes. In steady state, there is no need to, e.g., re-
publish every now and then. publish every now and then.
Appendix C. Changelog [RFC Editor: please remove] Appendix C. Changelog [RFC Editor: please remove]
draft-ietf-homenet-dncp-09:
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: draft-ietf-homenet-dncp-08:
o Removed fragmentation as it is somewhat underspecified and o Removed fragmentation as it is somewhat underspecified and
unimplemented. It may be specified in some future extension draft unimplemented. It may be specified in some future extension draft
or new version of DNCP. or new version of DNCP.
o Added generic sub-TLV extensibility mechanism. o Added generic sub-TLV extensibility mechanism.
draft-ietf-homenet-dncp-06: draft-ietf-homenet-dncp-06:
 End of changes. 55 change blocks. 
190 lines changed or deleted 251 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/