One document matched: draft-ietf-homenet-hncp-01.xml
<?xml version='1.0' ?>
<!--
Created: Mon Nov 18 17:55:22 2013 mstenber
-->
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc autobreaks="yes"?>
<?rfc compact="yes"?>
<?rfc strict='yes'?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<rfc
ipr='trust200902'
docName='draft-ietf-homenet-hncp-01'
category='std'
>
<front>
<title abbrev="Home Networking Control Protocol">
Home Networking Control Protocol
</title>
<author initials="M" surname="Stenberg" fullname="Markus Stenberg">
<address>
<postal>
<street/>
<city>Helsinki</city>
<code>00930</code>
<country>Finland</country>
</postal>
<email>markus.stenberg@iki.fi</email>
</address>
</author>
<author initials="S" surname="Barth" fullname="Steven Barth">
<address>
<postal>
<street/>
<city></city>
<code></code>
<country></country>
</postal>
<email>cyrus@openwrt.org</email>
</address>
</author>
<date month="June" year="2014" />
<area>Internet</area>
<workgroup>Homenet Working Group</workgroup>
<keyword>IPv6</keyword>
<keyword>Homenet</keyword>
<abstract>
<t>This document describes the Home Networking Control Protocol
(HNCP), a minimalist state synchronization protocol for Homenet
routers. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>HNCP is designed to synchronize
state across a Homenet (or other small site) in order to facilitate
automated configuration within the site, integration with trusted
bootstrapping <xref target="I-D.behringer-homenet-trust-bootstrap"
/> and default perimeter detection <xref
target="I-D.kline-homenet-default-perimeter" />, automatic IP prefix
distribution <xref target="I-D.pfister-homenet-prefix-assignment"
/>, and service discovery across multiple links within the homenet
as defined in <xref
target="I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf"
/>. </t>
<t>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 <xref target="I-D.troan-homenet-sadr"/>. Routing protocol
requirements for source and destination routing are described in
section 3 of <xref
target="I-D.baker-rtgwg-src-dst-routing-use-cases" />. </t>
<t>A GPLv2-licensed implementation of the HNCP protocol is
currently under development at <eref target="https://github.com/sbyx/hnetd/">https://github.com/sbyx/hnetd/</eref>
and the binaries are available in the routing feed of <eref
target="http://www.openwrt.org">OpenWrt</eref> trunk release.
Some information how to get started with it is available at <eref
target="http://www.homewrt.org/doku.php?id=run-conf" />.
Comments and/or pull requests are welcome.</t>
</section>
<section anchor="kwd" title='Requirements language'>
<t>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
<xref target='RFC2119'>RFC 2119</xref>.</t>
</section>
<section title="Data model">
<t>The data model of the HNCP protocol is simple: Every participating node
has (and also knows for every other participating node):
<list>
<t>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.</t>
<t>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. </t>
<t>Latest update sequence number. A 32 bit number that is
incremented anytime TLV data changes are detected.</t>
<t>Relative time, in milliseconds, since last publishing of the
current TLV data set. It is also 32 bit number on the wire.</t>
</list>
</t>
<t>If HNCP security is enabled, each node will have a public/private
key pair defined. The private key is used to create signatures for
messages and node state updates and never sent across the network by
HNCP. The public key is used to verify signatures of messages and
node state updates. </t>
</section>
<section title="Operation">
<t>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 <xref target="RFC6206">Trickle</xref>
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.</t>
<section title="Trickle-Driven Status Updates" anchor="trickle-updates">
<t>Each node MUST send link-local multicast <xref
target="net-message">NetState Messages</xref> each time the <xref
target="RFC6206">Trickle algorithm</xref> 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.</t>
<t>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.
<list>
<t>k=1 SHOULD be used, as given the timer reset on data updates, retransmissions
should handle packet loss.</t>
<t>Imax MUST be at least one minute.</t>
<t>Imin MUST be at least 200 milliseconds (earliest transmissions may occur at Imin/2
= 100 milliseconds given minimum values as per the Trickle algorithm).</t>
</list>
</t>
</section>
<section title="Protocol Messages">
<t>Protocol messages are encoded as purely as a sequence of <xref target="tlvs">TLV
objects</xref>. This section describes which set of TLVs MUST or MAY be present
in a given message. </t>
<t>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 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.
</t>
<section title="Network State Update (NetState)"
anchor="net-message">
<t>This Message SHOULD be sent as a multicast message.</t>
<t>The following TLVs MUST be present at the start of the message:
<list>
<t><xref target="node-id">Node Link TLV</xref>.</t>
<t><xref target="net-hash">Network State TLV</xref>.</t>
</list>
</t>
<t>The NetState Message MAY contain <xref
target="node-state">Node State TLV(s)</xref>. 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 <xref
target="reception"> Protocol Message Processing</xref>
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.</t>
<t>If HNCP security is enabled, <xref
target="auth-tlvs">authentication TLVs</xref> MUST be
present.</t>
</section>
<section title="Network State Request, (NetState-Req)"
anchor="req-net-message">
<t>This Message MUST be sent as a unicast message.</t>
<t>The following TLVs MUST be present at the start of the message:
<list>
<t><xref target="node-id">Node Link TLV</xref>.</t>
<t><xref target="req-net-hash">Request Network State TLV</xref>.</t>
</list>
</t>
<t>If HNCP security is enabled, <xref
target="auth-tlvs">authentication TLVs</xref> MUST be
present.</t>
</section>
<section title="Node Data Request (Node-Req)"
anchor="req-node-message">
<t>This Message MUST be sent as a unicast message.</t>
<t>MUST be present:
<list>
<t><xref target="node-id">Node Link TLV</xref>.</t>
<t>one or more <xref
target="req-node-data">Request Node Data TLVs</xref>.</t>
</list>
</t>
<t>If HNCP security is enabled, <xref target="auth-tlvs">authentication TLVs</xref> MUST be present.</t>
</section>
<section title="Network and Node State Reply (NetNode-Reply)"
anchor="reply-message">
<t>This Message MUST be sent as a unicast message.</t>
<t>MUST be present:
<list>
<t><xref target="node-id">Node Link TLV</xref>.</t>
<t><xref target="net-hash">Network State TLV</xref>
and <xref target="node-state">Node State TLV</xref> for
every known node by the sender, or</t>
<t>one or more combinations of Node State and <xref target="node-data">Node Data TLVs</xref>.</t>
</list>
</t>
<t>If HNCP security is enabled, <xref target="auth-tlvs">authentication TLVs</xref> MUST be present.</t>
</section>
</section>
<section title="HNCP Protocol Message Processing" anchor="reception">
<t>The majority of status updates among known nodes are handled via the <xref target="trickle-updates">Trickle-driven
updates </xref>. This section describes processing
of messages as received, along with associated actions or responses.</t>
<t>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.</t>
<t>Upon receipt of:
<list>
<t><xref target="net-message">NetState Message</xref>: 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 <xref target="req-net-message">NetState-Req
Message</xref>. If the message was in long format (contained all
Node State TLVs), reply with <xref
target="req-node-message">NodeState-Req</xref> 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.</t>
<t><xref target="req-net-message">NetState-Req</xref>: Provide
requested data in a NetNode-Reply Message containing Network
State TLV and all Node State TLVs.</t>
<t><xref target="req-node-message">NodeState-Req</xref>: Provide
requested data in a NetNode-Reply containing Node State and Node
Data TLVs. </t>
<t><xref target="reply-message">State-Reply</xref>: 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
<xref target="req-node-message">NodeState-Req</xref> for the
corresponding nodes. </t>
</list>
</t>
<t>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.</t>
<t>If a message containing <xref target="node-state">Node State
TLVs</xref> 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 HNCP security is not enabled, a new node identifier
SHOULD be generated and node data republished accordingly. If HNCP
security is enabled, this is event is highly unlikely to occur as
collision of identifier hashes for public keys is highly
unlikely.</t>
<t>In all cases, if node data for any node changes, all Trickle instances MUST be considered inconsistent
(I=Imin + timer reset).</t>
</section>
<section title="Adding and Removing Neighbors" anchor="neighbor">
<t>Whenever multicast message or unicast reply is received on a
link from another node, the node should be added as <xref
target="neighbor-tlv">Neighbor TLV</xref> 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 <xref
target="req-net-message">request network state message</xref>
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).</t>
</section>
<section title="Purging Unreachable Nodes">
<t>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. </t>
</section>
</section>
<section anchor="tlvs" title="Type-Length-Value objects">
<t>
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.
</t>
<figure>
<artwork>
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
Encoding of type=123 (0x7b) TLV with value 'x' (120 = 0x78):
007B 0005 7800 0000
</t>
<t>Notation:
<list>
<t>.. = octet string concatenation operation</t>
<t>H(x) = MD5 hash of x</t>
<t>H-64(x) = H(x) truncated by taking just first 64 bits of the result.</t>
</list>
</t>
<section title="Request TLVs (for use within unicast requests)">
<section anchor="req-net-hash" title="Request Network State TLV">
<figure>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="req-node-data" title="Request Node Data TLV">
<figure>
<artwork>
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
</section>
<section title="Data TLVs (for use in both multi- and unicast data)">
<section anchor="node-id" title="Node Link TLV">
<figure>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="net-hash" title="Network State TLV">
<figure>
<artwork>
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)) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The Node Data TLVs are ordered for hashing by octet comparison of
the corresponding node identifier hashes in ascending order.</t>
</section>
<section anchor="node-state" title="Node State TLV">
<figure>
<artwork>
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>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.</t>
</section>
<section anchor="node-data" title="Node Data TLV">
<figure>
<artwork>
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 |
</artwork>
</figure>
<t>The <xref target="node-pk-tlv">Node Public Key TLV</xref>
SHOULD be always included if signatures are ever used. </t>
<t>If signatures are in use, the Node Data TLV SHOULD also contain
the originator's own <xref target="sig-tlv">Signature TLV</xref>.</t>
</section>
<section anchor="node-pk-tlv" title="Node Public Key TLV (within
Node Data TLV)">
<figure>
<artwork>
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: PUBLIC-KEY (7) | Length: >= 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key (raw node identifier) |
</artwork>
</figure>
<t>Public key data for the node. Only relevant if signatures are
used. Can be used to verify that H(node identifier) in the
received data for the node equals H(public key), and that the
Signature TLVs are signed by appropriate public keys.</t>
</section>
<section anchor="neighbor-tlv" title="Neighbor TLV (within Node Data TLV)">
<figure>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>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. </t>
</section>
</section>
<section anchor="user-tlv" title="Custom TLV (within/without Node Data TLV)">
<figure>
<artwork>
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 |
</artwork>
</figure>
<t>This TLV can be used to contain anything; the URI used should be
under control of the author of that specification.
For example:</t>
<t>V=H-64('http://example.com/author/json-for-hncp') .. '{"cool": "json
extension!"}'</t>
<t>or</t>
<t>V=H-64('mailto:author@example.com') .. '{"cool": "json
extension!"}'</t>
</section>
<section anchor="version-tlv" title="Version TLV (within Node Data TLV)">
<figure>
<artwork>
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 |
</artwork>
</figure>
<t>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 hnetd version. This draft describes Version=1
TLVs.</t>
</section>
<section title="Authentication TLVs" anchor="auth-tlvs">
<section title="Certificate-related TLVs">
<t>TBD; should be probably some sort of certificate ID to be used
in a lookup at most, as raw certificates will overflow easily IPv6
minimum MTU.</t>
</section>
<section anchor="sig-tlv" title="Signature TLV">
<t>TLV with T=0xFFFF, V=(TBD) public key algorithm based
signature of all TLVs within current scope as well as the parent
TLV header, if any. The assumed signature key is private key
matching the public key of the the originator of node link TLV
(if signature TLV is within main body of message), or that of the
originator of the node data TLV (if signature TLV is within Node
Data TLV)..</t>
<t>Given the ordering of TLVs, this TLV should be last one
processed within current scope.</t>
</section>
</section>
</section>
<section title="Border Discovery and Prefix Assignment">
<t>Using
<xref target="I-D.kline-homenet-default-perimeter">Default Border
Definition</xref> as a basis, this section defines border discovery algorithm
specifics derived from the edge router interactions
described in the <xref target="RFC7084">Basic Requirements for IPv6
Customer Edge Routers</xref>. The algorithm is designed to work for
both IPv4 and IPv6 (single or dual-stack). </t>
<t>In order to avoid conflicts between border discovery and homenet
routers running <xref target="RFC2131">DHCP</xref> or <xref target="RFC3633">DHCPv6-PD</xref> servers each router MUST implement the following
mechanism based on <xref target="RFC3004">The User Class Option for
DHCP</xref> or its <xref target="RFC3315">DHCPv6 counterpart</xref> respectively into its DHCP and DHCPv6-logic:
<list>
<t>A homenet router running a DHCP-client on a homenet-interface
MUST include a DHCP User-Class consisting of the ASCII-String
"HOMENET".</t>
<t>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".</t>
</list>
</t>
<t>The border discovery auto-detection algorithm works as follows,
with evaluation stopping at first match:
<list style="numbers">
<t>If a fixed category is set for an interface, it MUST be used.</t>
<t>Any of the following conditions indicate an interface MUST
be considered external:
<list style="numbers">
<t>A delegated prefix could be acquired by running a DHCPv6-client
on the interface.</t>
<t>An IPv4-address could be acquired by running a DHCP-client on
the interface.</t>
<t>HNCP security is enabled and there are routers on the interface
which could not be authenticated.</t>
</list>
</t>
<t>As default fallback, interface MUST be considered internal.</t>
</list>
</t>
<t>A router SHOULD 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 it MAY offer further
categories which modify the local router behavior, such as:
<list>
<t>Guest category: This is a specialization of the internal category which declares
an interface used for untrusted clients. The router MUST NOT send or accept HNCP
messages on these interfaces. 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.</t>
<t>Ad-hoc category: This is a specialization of the internal category which declares
an interface to be in ad-hoc mode. This indicates to HNCP applications such as prefix
assignment that links on this interface are potentially non-transitive.</t>
<t>Hybrid category: This is a specialization of the internal category in which the
router 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 is out of scope
for this document, and therefore it MAY be supported only via manual configuration on a per-router basis.</t>
</list>
</t>
<t>A homenet router SHOULD provide basic connectivity to <xref target="RFC7084">legacy CERs</xref> connected to internal interfaces in order to allow coexistence with existing devices.</t>
<t>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.</t>
<t>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:</t>
<figure>
<artwork>
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 |
</artwork>
</figure>
<t>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
within it MUST be preserved as long as the information contained does
not change. The TLVs are encoded as follows:</t>
<figure>
<artwork>
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 |
</artwork>
</figure>
<t>and</t>
<figure>
<artwork>
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 |
</artwork>
</figure>
<t>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 <xref target="RFC4291">IPv4-mapped address</xref>
and is usually from a <xref target="RFC1918">private address range</xref>.
The related TLV is defined as follows.</t>
<figure>
<artwork>
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] +
| |
</artwork>
</figure>
<t>
<list>
<t>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.</t>
<t>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.</t>
<t>Prefix length specifies the number of significant bits in the
prefix.</t>
<t>Prefix address is of variable length and contains the
significant bits of the prefix padded with zeroes up to the next
byte boundary.</t>
<t>Nested TLVs might contain prefix-specific information like
DHCPv6-options.</t>
</list>
</t>
<t>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
<xref target="I-D.pfister-homenet-prefix-assignment">Prefix and
Address Assignment in a Home Network</xref>. In order to announce
the assigned prefixes the following TLVs are defined.</t>
<t>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:</t>
<figure>
<artwork>
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 +
| |
</artwork>
</figure>
<t>
<list>
<t>Link Identifier is the local HNCP identifier of the link the
prefix is assigned to.</t>
<t>R. is reserved for future additions and MUST be set to 0 when
creating TLVs and ignored when parsing them.</t>
<t>A is the authoritative flag which indicates that an assignment
is enforced and ignores usual collision detection rules.</t>
<t>Pref. describes the preference of the assignment and can be
used to differentiate the importance of a given assignment over
others.</t>
<t>Prefix length specifies the number of significant bits in the
prefix.</t>
<t>Prefix address is of variable length and contains the
significant bits of the prefix padded with zeroes up to the next
byte boundary.</t>
</list>
</t>
<t>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:</t>
<figure>
<artwork>
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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list>
<t>Link Identifier is the local HNCP identifier of the link the
address is assigned to.</t>
<t>Router Address is the address assigned to one of the router interfaces.</t>
</list>
</t>
</section>
<section anchor="how" title="DNS-based Service Discovery">
<t>Service discovery is generally limited to a local link. <xref
target="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. </t>
<section anchor="delegated-zone-tlv" title="DNS Delegated Zone TLV">
<figure>
<artwork>
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) |
| |
</artwork>
</figure>
</section>
<section anchor="domain-name-tlv" title="Domain Name TLV">
<figure>
<artwork>
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="router-name-tlv" title="Router Name TLV">
<figure>
<artwork>
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
</section>
<section title="Routing support">
<section title="Protocol Requirements">
<t>In order to be advertised for use within the Homenet, a routing protocol MUST:
<list>
<t>Comply with <xref target="I-D.baker-rtgwg-src-dst-routing-use-cases">Requirements and Use Cases for Source/Destination Routing</xref>.</t>
<t>Be configured with suitable defaults or have an auto-configuration mechanism (e.g. <xref target="I-D.acee-ospf-ospfv3-autoconfig" />) such that it will run in a Homenet without requiring specific configuration from the Home user. </t>
</list>
</t>
<t>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.</t>
</section>
<section title="Announcement">
<t>Each router SHOULD announce all routing protocols that it is capable of supporting in the Homenet.
It SHOULD assign a preference value for each protocol that indicates its desire to use said protocol over other protocols it supports and SHOULD
make these values configurable.</t>
<t>Each router includes one HNCP TLV of type ROUTING-PROTOCOL for every such routing protocol. This TLV is defined as follows:</t>
<figure>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list>
<t>Protocol ID is one of:
<list>
<t>0 = reserved</t>
<t>1 = Babel (dual-stack)</t>
<t>2 = OSPFv3 (dual-stack)</t>
<t>3 = IS-IS (dual-stack)</t>
<t>4 = RIP (dual-stack)</t>
</list>
</t>
<t>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.</t>
</list>
</t>
</section>
<section title="Protocol Selection">
<t>When HNCP detects that a router has joined or left the Homenet it MUST examine all advertised
routing protocols and preference values from all routers in the Homenet in order to find the one
routing protocol which:
<list style="numbers">
<t>Is understood by all routers in the homenet</t>
<t>Has the highest preference value among
all routers (calculated as sum of preference
values)</t>
<t>Has the highest protocol ID among those with the
highest preference </t>
</list>
</t>
<t>If the router protocol selection results in the need to change from one routing protocol
to another on the homenet, the router MUST stop 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
<xref target="fallback">Fallback Mechanism</xref>.</t>
</section>
<section anchor="fallback" title="Fallback Mechanism">
<t>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.
<list style="numbers">
<t>Interpret the neighbor information received via HNCP as a graph of connected routers.</t>
<t>Use breadth-first traversal to determine the next-hop and hop-count in the path to each router in the homenet:
<list>
<t>Start the traversal with the immediate neighbors of the router running the algorithm.</t>
<t>Always visit the immediate neighbors of a router in ascending order of their router ID.</t>
<t>Never visit a router more often than once.</t>
</list>
</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
</section>
</section>
<section title="Security Considerations">
<t>General security issues for Home Networks are discussed at length
in <xref target="I-D.ietf-homenet-arch" />. The protocols used to
setup IP in home networks today have very little security enabled
within the control protocol itself. For example, DHCP has defined
<xref target="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 aims
to make security as easy as possible for the implementer by including
built-in capabilities for authentication of node data being exchanged
as well as the protocol messages themselves, but it is ultimately up
to the shipping system to take advantage of the protocol constructs
defined.</t>
<t>HNCP is designed to integrate with
<xref target="I-D.behringer-homenet-trust-bootstrap">trusted bootstrapping</xref>
including the ability to authenticate messages between nodes. This
authentication can be used to securely define a border as well as
protect against malicious attacks and spoofing attempts from inside
or outside the border. </t>
<t>HNCP itself sends messages as (possibly authenticated) clear text
which is as secure, or insecure, as the security of the link below
as discussed in <xref target="I-D.kline-homenet-default-perimeter"
/>. When no unique public key is available, a hardware fingerprint or
equivalent to identify routers must be available for use by HNCP.</t>
<t>As HNCP messages are sent over UDP/IP, IPsec may be used for
confidentiality or additional message authentication. However, this
requires manually keyed IPsec per-port granularity for port
IANA-UDP-PORT UDP traffic. Also, a pre-shared key has to be utilized
in this case given IKE cannot be used with multicast traffic.</t>
<t>If no router can be trusted and additional guarantees about source of
node status updates is necessary, real public and private keys should
be used to create signatures and verify them in HNCP on both on
per-node data TLVs as well as across the entire HNCP message. In
this mode, care must be taken in rate limiting verification of
invalid packets, as otherwise denial of service may occur due to
exhaustion of computation resources.</t>
<t>As a performance optimization, instead of providing signatures for
actual node data and the protocol messages themselves, it is also
possible to provide signatures just for protocol messages. While this
means it is no longer possible to verify the original source of the
node data itself, as long as the set of routers is trusted (i.e., no
router in the set has itself been hacked to provide malicious node
data) then one can assume the node data is trusted because the router
is trusted and the data arrived in a protected protocol message.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>IANA should set up a registry (policy TBD) for HNCP TLV types, with following
initial contents:</t>
<t>0: Reserved (should not happen on wire)</t>
<t>1: Node link</t>
<t>2: Request network state</t>
<t>3: Request node data</t>
<t>4: Network state</t>
<t>5: Node state</t>
<t>6: Node data</t>
<t>7: Node public key</t>
<t>8: Neighbor</t>
<t>9: Custom</t>
<t>10: Version</t>
<t>41: External connection</t>
<t>42: Delegated prefix</t>
<t>43: Assigned prefix</t>
<t>44: DHCP-data</t>
<t>45: DHCPv6-data</t>
<t>46: Router-address</t>
<t>50: DNS Delegated Zone</t>
<t>51: Domain name</t>
<t>52: Node name</t>
<t>60: Routing protocol</t>
<t>65535: Signature</t>
<t>HNCP will also require allocation of a UDP port number IANA-UDP-PORT, as well as
IPv6 link-local multicast address IANA-MULTICAST-ADDRESS.</t>
</section>
</middle>
<back>
<references title="Normative references">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.6206.xml"?>
<?rfc include="reference.I-D.draft-pfister-homenet-prefix-assignment-01"?>
<?rfc include="reference.I-D.draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-01"?>
</references>
<references title="Informative references">
<?rfc include="reference.RFC.7084.xml"?>
<?rfc include="reference.RFC.3004.xml"?>
<?rfc include="reference.RFC.3118.xml"?>
<?rfc include="reference.RFC.2131.xml"?>
<?rfc include="reference.RFC.3315.xml"?>
<?rfc include="reference.RFC.3633.xml"?>
<?rfc include="reference.RFC.1918.xml"?>
<?rfc include="reference.RFC.4291.xml"?>
<?rfc include="reference.I-D.draft-ietf-homenet-arch-13.xml"?>
<?rfc include="reference.I-D.draft-troan-homenet-sadr-01.xml"?>
<?rfc include="reference.I-D.draft-behringer-homenet-trust-bootstrap-02.xml"?>
<?rfc include="reference.I-D.draft-baker-rtgwg-src-dst-routing-use-cases-00.xml"?>
<?rfc include="reference.I-D.draft-kline-homenet-default-perimeter-00.xml"?>
<?rfc include="reference.I-D.draft-acee-ospf-ospfv3-autoconfig-03.xml"?>
</references>
<section title="Some Outstanding Issues">
<t>Should we use MD5 hashes, or EUI-64 node identifier to identify
nodes?</t>
<t>Is there a case for non-link-local unicast? Currently explicitly
stating this is link-local only protocol. </t>
<t>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.</t>
<t>Should we use something else than MD5 as hash? It IS somewhat
insecure; however signature stuff (TBD) should rely on it mainly for
security in any case, and MD5 is used in a non-security role.</t>
<t>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)?</t>
</section>
<section title="Some Obvious Questions and Answers">
<t>Q: Why not use TCP?</t>
<t>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. </t>
<t>Q: Why not multicast-only?</t>
<t>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.</t>
<t>Q: Why so long IDs? Why real hash even in insecure mode?</t>
<t>A: Scalability of protocol is not really affected by using real
(=cryptographic) hash function.</t>
<t>Q: Why trust IPv6 fragmentation in unicast case? Why not do L7
fragmentation?</t>
<t>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. </t>
<t>Q: Should there be nested container syntax that is actually
self-describing? (i.e. type flag that indicates container, no body
except sub-TLVs?)</t>
<t>A: Not for now, but perhaps valid design.. TBD.</t>
<t>Q: Why not doing (performance thing X, Y or Z)?</t>
<t>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. </t>
</section>
<section title="Changelog">
<t>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. </t>
<t>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. </t>
</section>
<section title="Draft source">
<t>As usual, this draft is available at <eref
target="https://github.com/fingon/ietf-drafts/">https://github.com/fingon/ietf-drafts/</eref>
in source format (with nice Makefile too). Feel free to send comments
and/or pull requests if and when you have changes to it! </t>
</section>
<section title="Acknowledgements">
<t>Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley
and Juliusz Chroboczek for their contributions to the draft.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:02:21 |