One document matched: draft-ietf-homenet-hncp-06.xml
<?xml version='1.0' ?>
<!--
Created: Mon Nov 18 17:55:22 2013 mstenber
split from draft-ietf-homenet-hncp-03-pre - homenet specific ones
TBD:
- A lot of RFCs seem to assume DHCP = DHCPv4. Perhaps define the fact
somewhere that DHCP = DHCPv4+DHCPv6 here?
[SB] should be unambiguous now, if not please mark single occurences where it isn't
[MSt] it is now. some initial definition would still be nice ;)
- Announce <> publish term bit mixed; hmm
[SB] is that problematic? what is the "genuine" term?
[MSt] Not really problematic I think, just makes it potentially harder to
read for someone not initiated to this stuff. There are some cases where
'announce' is only valid verb though in the current text, and TLVs are typically
published/originated/whatever in the link-state literature. (Mostly to
indicate that they persist for long period of time, as opposed just to
announce, which by definition is only transient occurrence. Why the hell am
I writing an essay on this. :-p)
-->
<!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-06'
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>Halle</city>
<code>06114</code>
<country>Germany</country>
</postal>
<email>cyrus@openwrt.org</email>
</address>
</author>
<author initials="P" surname="Pfister" fullname="Pierre Pfister">
<organization>Cisco Systems</organization>
<address>
<postal>
<street/>
<city>Paris</city>
<country>France</country>
</postal>
<email>pierre.pfister@darou.fr</email>
</address>
</author>
<date month="June" year="2015" />
<area>Internet</area>
<workgroup>Homenet Working Group</workgroup>
<keyword>IPv6</keyword>
<keyword>Homenet</keyword>
<keyword>DNCP</keyword>
<abstract>
<t>This document describes the Home Networking Control Protocol
(HNCP), an extensible configuration protocol and a set of requirements
for home network devices on top of the Distributed Node Consensus
Protocol (DNCP). It enables automated configuration of addresses, naming,
network borders and the seamless use of a routing protocol.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>HNCP synchronizes state across a small site
in order to allow automated network configuration.
The protocol enables use of border discovery, address prefix
distribution <xref target="I-D.ietf-homenet-prefix-assignment" />,
naming and other services across multiple links.</t>
<t>HNCP provides enough information for a routing protocol to operate
without homenet-specific extensions. In homenet environments where
multiple IPv6 source-prefixes can be present, routing based on source
and destination address is necessary <xref target="RFC7368" />.</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="DNCP Profile">
<t>HNCP is defined as a profile of <xref target="I-D.ietf-homenet-dncp">
DNCP</xref> with the following parameters:
<list style="symbols">
<t>HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport
over link-local scoped IPv6, using unicast and multicast
(All-Homenet-Routers is the HNCP group address).
Received datagrams with an IPv6 source or
destination address which is not link-local scoped MUST be
ignored. Each node MUST be able to receive (and potentially reassemble)
UDP datagrams with a payload of at least 4000 bytes.</t>
<t>HNCP operates on multicast-capable interfaces only. HNCP routers
MUST assign a unique 32-bit endpoint identifier to each
interface for which HNCP is enabled. The value zero is reserved
for internal purposes.
Implementations MAY use a value equivalent to the sin6_scope_id for
the given interface.</t>
<t>HNCP unicast traffic SHOULD be secured using <xref
target="RFC6347">DTLS</xref> as described in DNCP if exchanged over
unsecured links. UDP on port HNCP-DTLS-PORT is used for this
purpose. A node implementing HNCP security MUST support
the DNCP Pre-Shared Key method, SHOULD support the DNCP Certificate
Based Trust Consensus and MAY support the PKI-based trust
method.</t>
<t>HNCP uses opaque 32-bit node identifiers
(DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP SHOULD
generate and use a random node identifier. If using a random node
identifier and there is a node identifier collision, the node MUST
immediately generate and use a new random node identifier which is
not used by any other node.</t>
<t>HNCP nodes MUST ignore all Node State TLVs received via
multicast on a link which has DNCP security enabled in order
to prevent spoofing of node state changes.</t>
<t>HNCP nodes use the following Trickle parameters:
<list style="symbols">
<t>k SHOULD be 1, as the timer reset when data is updated and
further retransmissions should handle packet loss.</t>
<t>Imin SHOULD be 200 milliseconds but MUST NOT be lower.
Note: Earliest transmissions may occur at Imin / 2.</t>
<t>Imax SHOULD be 7 doublings of Imin (i.e. 25.6 seconds)
but MUST NOT be lower.</t>
</list>
</t>
<t>HNCP nodes MUST use the leading 64 bits of <xref
target="RFC1321">MD5</xref> as DNCP non-cryptographic hash function
H(x).</t>
<t>HNCP nodes MUST use DNCP's keep-alive extension on all endpoints
with the following parameters:
<list style="symbols">
<t>The default keep-alive interval (DNCP_KEEPALIVE_INTERVAL) is 20
seconds.</t>
<t>The multiplier (DNCP_KEEPALIVE_MULTIPLIER) MUST be 2.1.</t>
<t>The grace-interval (DNCP_GRACE_INTERVAL) SHOULD be equal to
DNCP_KEEPALIVE_MULTIPLIER times DNCP_KEEPALIVE_INTERVAL.</t>
</list>
</t>
</list>
</t>
</section>
<section title="Common Links" anchor="links">
<t>HNCP uses the concept of Common Links for some of its
applications. The Common Link is computed separately for each local
interface, and it always contains the local interface. Additionally,
if the local interface is not in ad-hoc mode, it also contains the
set of interfaces that are bidirectionally reachable from the given
local interface, i.e. every remote interface of a remote node meeting
all of the following requirements:
<list style="symbols">
<t>The local node publishes a Neighbor TLV with:
<list style="symbols">
<t>Neighbor Node Identifier = remote node's node identifier</t>
<t>Neighbor Endpoint Identifier = remote interface's endpoint
identifier</t>
<t>Endpoint Identifier = local interface's endpoint identifier</t>
</list>
</t>
<t>The remote node publishes a Neighbor TLV with:
<list style="symbols">
<t>Neighbor Node Identifier = local node's node identifier</t>
<t>Neighbor Endpoint Identifier = local interface's endpoint
identifier</t>
<t>Endpoint Identifier = remote interface's endpoint identifier</t>
</list>
</t>
</list>
</t>
<t>A node MUST be able to detect whether two of its local interfaces are
connected, e.g. by detecting an identical remote interface
being part of the Common Links of both local interfaces.</t>
</section>
<section title="Border Discovery" anchor="bd">
<t>HNCP router's interfaces are either internal, external or of a different
category derived from the internal one.
This section defines the border discovery algorithm.
It is suitable for both IPv4 and IPv6 (single or dual-stack) and
determines whether an HNCP interface is internal, external,
or uses another fixed category. The algorithm is derived from the
edge router interactions described in the
<xref target="RFC7084">Basic Requirements for IPv6 Customer Edge
Routers</xref>. This algorithm
MUST be implemented by any router implementing HNCP.</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 configured for the interface, it MUST be used.</t>
<t>If a delegated prefix could be acquired by running a DHCPv6
client on the interface, it MUST be considered external.</t>
<t>If an IPv4 address could be acquired by running a DHCPv4 client
on the interface it MUST be considered external.</t>
<t>Otherwise the interface MUST be considered internal.</t>
</list>
</t>
<t>In order to avoid conflicts between border discovery and HNCP
routers running <xref target="RFC2131">DHCPv4</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 DHCPv4</xref> and its <xref target="RFC3315">DHCPv6
counterpart</xref>:
<list style="symbols">
<t>An HNCP router running a DHCP client on an HNCP interface
MUST include a DHCP User-Class consisting of the ASCII-String
"HOMENET".</t>
<t>An HNCP router running a DHCP server on an HNCP interface
MUST ignore or reject DHCP-Requests containing a DHCP User-Class
consisting of the ASCII-String "HOMENET".</t>
</list>
</t>
<t>A router MUST allow setting a category of either auto-detected,
internal or external for each interface which is suitable for both
internal and external connections. In addition the following
specializations of the internal category are defined to modify the
local router behavior:
<list style="hanging">
<t hangText="Leaf category:"> This declares an interface used by
client devices only. Such an interface acts as an internal interface
with the exception that HNCP or routing protocol traffic MUST NOT be sent
on the interface, and all such traffic received on the interface MUST be ignored.
This category SHOULD be supported.</t>
<t hangText="Guest category:"> This declares an interface used by
untrusted client devices only. In addition to the restrictions of
the Leaf category, HNCP routers MUST enable firewalling rules such that
connected devices are unable to reach other
devices inside the HNCP network or query services advertised by them
unless explicitly allowed. This category SHOULD be supported.</t>
<t hangText="Ad-hoc category:"> This configures an interface to be
<xref target="links">ad-hoc</xref>. Ad-hoc interfaces are considered internal but no
assumption is made on the the link transitivity properties.
Support for this category is OPTIONAL.</t>
<t hangText="Hybrid category:"> This declares an interface to
be internal while still running DHCPv4 and DHCPv6-PD clients on it. It
is assumed that the link is under control of a legacy, trustworthy
non-HNCP router, still within the same network. Detection of this
category automatically in addition to manual configuration is
out of scope of this document. Support for this category is OPTIONAL.</t>
</list>
</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
DHCPv4 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 default),
during 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 according to the routes it publishes.
Once a router detects an interface transitioning to external it MUST
stop any previously enabled internal forwarding. In addition it
SHOULD announce the acquired information for use in the network as
described in later sections of this draft if the interface appears to
be connected to an external network.</t>
</section>
<section title="Autonomic Address Configuration">
<t>This section specifies how HNCP routers configure host and router
addresses. At first border routers share information obtained from
service providers or local configuration by publishing one or more
External Connection TLVs. These contain other TLVs such as Delegated
Prefix TLVs which are then used for prefix assignment. Finally, HNCP
routers obtain addresses using a stateless (SLAAC-like) procedure or a
specific stateful mechanism and hosts and legacy routers are configured
using SLAAC or DHCP.</t>
<t>In all TLVs specified in this section which include a prefix, IPv4 prefixes
are encoded using the <xref target="RFC4291">IPv4-mapped IPv6 addresses format</xref>.
The prefix length of such IPv4 prefix is set to 96 plus the IPv4 prefix length.</t>
<section title="External Connections">
<t>Each HNCP router MAY obtain external connection information from
one or more sources, e.g., <xref target="RFC3633">DHCPv6-PD</xref>,
<xref target="RFC6241">NETCONF</xref> or static configuration. This
section specifies how such information is encoded and advertised.</t>
<section title="External Connection TLV">
<t>An External Connection TLV is a container-TLV used to
gather network configuration information associated with
a single external connection. A node MAY publish an arbitrary
number of instances of this TLV.</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 (33)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested TLVs |
</artwork>
</figure>
<t>The External Connection TLV is a container which:
<list style="symbols">
<t>MAY contain an arbitrary number of Delegated Prefix TLVs.</t>
<t>MUST NOT contain multiple Delegated Prefix TLVs with identical or
overlapping prefixes. In such a situation, the External Connection TLV MUST be ignored.</t>
<t>MAY contain at most one DHCPv6 Data TLV and at most one
DHCPv4 Data TLV encoding options associated with the External
Connection but MUST NOT contain more than one of each otherwise
the External Connection TLV MUST be ignored.</t>
<t>MAY contain other TLVs for future use.
Such additional TLVs MUST be ignored.</t>
</list>
</t>
</section>
<section title="Delegated Prefix TLV">
<t>The Delegated Prefix TLV is used by HNCP routers to advertise
prefixes which are allocated to the whole network and will be used
for prefix assignment. Any Delegated Prefix TLV MUST be nested
in an External Connection TLV.</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 (34) | Length: >= 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | |
+-+-+-+-+-+-+-+-+ Prefix [+ nested TLVs] +
| |
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Valid Lifetime: ">The time in seconds the delegated
prefix is valid. The value is relative to the point in time the
Node-Data TLV was last published. It MUST be updated whenever
the node republishes its Node-Data TLV.</t>
<t hangText="Preferred Lifetime: ">The time in seconds the
delegated prefix is preferred. The value is relative to the
point in time the Node-Data TLV was last published. It MUST be
updated whenever the node republishes its Node-Data TLV.</t>
<t hangText="Prefix Length: ">The number of significant bits in
the Prefix.</t>
<t hangText="Prefix: ">Significant bits of the prefix padded
with zeroes up to the next byte boundary.</t>
<t hangText="Nested TLVs:">Other TLVs included in the Delegated
Prefix TLV and starting at the next 32-bit boundary following
the end of the encoded prefix:
<list style="symbols">
<t>Zero or more Prefix Domain TLVs. In absence of any such
TLV the prefix is assumed to be generated by an HNCP-router
and for internal use only.</t>
<t>If the encoded prefix represents an IPv6 prefix, at
most one DHCPv6 Data TLV MAY be included, and any included
DHCPv4 Data TLV MUST be ignored.</t>
<t>If the prefix represents an IPv4 prefix (encoded as an IPv4-mapped IPv6 prefix),
at most one DHCPv4 Data TLV MAY be
included, and any included DHCPv6 Data TLV MUST be ignored.</t>
<t>It MAY contain other TLVs for future use.
Such additional TLVs MUST be ignored.</t>
</list>
</t>
</list>
</t>
</section>
<section title="Prefix Domain TLV">
<t>The Prefix Domain TLV contains information about the origin and
applicability of a delegated prefix. This information can be used
to determine whether prefixes for a certain domain (e.g. local
reachability, internet connectivity) do exist or should be acquired
and to make decisions about assigning prefixes to certain links or
to fine-tune border firewalls.</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: PREFIX-DOMAIN (43) | Length: >= 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Type | |
+-+-+-+-+-+-+-+-+ Domain ID +
| |
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Domain Type: ">The type of the domain identifier.
<list style="hanging">
<t hangText="0 :">Internet connectivity
(domain ID is empty).</t>
<t hangText="1-128 :">Explicit destination prefix with the
Domain Type being the actual length of the prefix
(Domain ID contains significant bits of the destination prefix
padded with zeroes up to the next byte boundary).</t>
<t hangText="129 :">UTF-8 String (e.g. FQDN).</t>
<t hangText="130-255:">Reserved for future additions.</t>
</list></t>
<t hangText="Domain Identifier: ">A variable length identifier
of the given type.</t>
</list>
</t>
</section>
<section title="DHCP Data TLVs">
<t>Auxiliary connectivity information is encoded as a stream of
DHCP options. Such TLVs MUST only be present in an
External Connection TLV or a Delegated Prefix TLV. When included in
an External Connection TLV, they MUST contain DHCP options which are
relevant to the whole External Connection. When included in a
Delegated Prefix, they MUST contain DHCP options which are specific
to the Delegated Prefix.</t>
<t>The DHCPv6 Data TLV uses the following format:
<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 (37) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv6 option stream |
</artwork>
</figure>
<list style="hanging">
<t hangText="DHCPv6 option stream: ">DHCPv6 options encoded as
specified in <xref target="RFC3315"/>.</t>
</list>
</t>
<t>The DHCPv4 Data TLV uses the following format:
<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: DHCPV4-DATA (38) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv4 option stream |
</artwork>
</figure>
<list style="hanging">
<t hangText="DHCPv4 option stream: ">DHCPv4 options encoded as
specified in <xref target="RFC2131"/>.</t>
</list>
</t>
</section>
</section>
<section anchor="pa" title="Prefix Assignment">
<t>HNCP uses the Distributed Prefix Assignment Algorithm specified in
<xref target="I-D.ietf-homenet-prefix-assignment" /> in order to
assign prefixes to HNCP internal links and uses the terminology
defined there.</t>
<section title="Prefix Assignment Algorithm Parameters">
<t>All HNCP nodes running the prefix assignment algorithm MUST use
the following parameters:
<list style="hanging">
<t hangText="Node IDs: ">HNCP node identifiers are used. The
comparison operation is defined as bit-wise comparison.</t>
<t hangText="Set of Delegated Prefixes: ">The set of prefixes
encoded in Delegated Prefix TLVs which are not strictly included
in prefixes encoded in other Delegated Prefix TLVs. Note that
Delegated Prefix TLVs included in ignored External Connection
TLVs are not considered. It is dynamically updated as Delegated
Prefix TLVs are added or removed.</t>
<t hangText="Set of Shared Links: ">The set of Common Links associated
with internal, leaf, guest or ad-hoc interfaces. It is dynamically updated as
HNCP interfaces are added, removed, or switch from one category to another.
When multiple interfaces are detected as belonging to the same Common Link,
prefix assignment is disabled on all of these interfaces except one.</t>
<t hangText="Set of Private Links: ">This document defines
Private Links representing DHCPv6-PD clients or as a mean to
advertise prefixes included in the DHCPv6 Exclude Prefix option.
Other implementation-specific Private Links may be defined whenever
a prefix needs to be assigned for a purpose that does not require
a consensus with other HNCP routers.</t>
<t hangText="Set of Advertised Prefixes: ">The set of prefixes
included in Assigned Prefix TLVs advertised by other HNCP
routers (Prefixes advertised by the local node are not in this set).
The associated Advertised Prefix Priority is the
priority specified in the TLV. The associated Shared Link
is determined as follows:
<list style="symbols">
<t>If the Link Identifier is zero, the Advertised Prefix
is not assigned on a Shared Link.</t>
<t>If the other node's interface identified by the Link Identifier
is included in one of the Common Links used for prefix assignment, it is
considered as assigned on the given Common Link.
</t>
<t>Otherwise, the Advertised Prefix is not assigned on a Shared Link.</t>
</list>
Advertised Prefixes as well as their associated priorities
and associated Shared Links MUST be updated as Assigned
Prefix TLVs are added, updated or removed, and as Common Links
are modified.
</t>
<t hangText="ADOPT_MAX_DELAY: ">The default value is 0
seconds (i.e. prefix adoption MAY be done instantly).</t>
<t hangText="BACKOFF_MAX_DELAY: ">The default value is
4 seconds.</t>
<t hangText="RANDOM_SET_SIZE: ">The default value is 64.</t>
<t hangText="Flooding Delay: ">The default value is
5 seconds.</t>
<t hangText="Default Advertised Prefix Priority: ">When a
new assignment is created or an assignment is adopted -
as specified in the prefix assignment algorithm routine -
the default Advertised Prefix Priority to be used is 2.</t>
</list>
</t>
</section>
<section title="Assigned Prefix TLV">
<t>Published Assigned Prefixes MUST be advertised using the Assigned
Prefix TLV:</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 (35) | Length: >= 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsv. | Prty. | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +
| |
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Endpoint Identifier: ">The endpoint identifier
of the local interface that belongs to the Common Link the
prefix is assigned to, or 0 if the Common Link is a Private
Link (e.g., when the prefix is assigned for downstream prefix
delegation).</t>
<t hangText="Rsv.: ">Bits are reserved for future use. They
MUST be set to zero when creating this TLV, and their value
MUST be ignored when processing the TLV.</t>
<t hangText="Prty: ">The Advertised Prefix Priority from 0 to 15.
<list style="hanging">
<t hangText="0-1 :">Low priorities.</t>
<t hangText="2 :">Default priority.</t>
<t hangText="3-7 :">High priorities.</t>
<t hangText="8-11 :">Administrative priorities. MUST NOT
be used unless configured otherwise.</t>
<t hangText="12-14:">Reserved for future use.</t>
<t hangText="15 :">Provider priorities. MAY only be used
by the router advertising the corresponding
delegated prefix and based on static or dynamic
configuration (e.g., for excluding a prefix based on
<xref target="RFC6603">DHCPv6-PD Prefix Exclude Option</xref>).
</t>
</list>
</t>
<t hangText="Prefix Length: ">The number of significant bits
in the Prefix field.</t>
<t hangText="Prefix: ">The significant bits of the prefix padded
with zeroes up to the next byte boundary.</t>
</list>
</t>
</section>
<section title="Making New Assignments">
<t>Whenever the Prefix Assignment Algorithm subroutine is run on a
Common Link and whenever a new prefix may be assigned (case 1
of the subroutine), the decision of whether the assignment of a new
prefix is desired MUST follow these rules:
<list style="hanging">
<t>If the Delegated Prefix TLV contains a DHCPv4 or DHCPv6
Data TLV, and the meaning of one of the DHCP options is not
understood by the HNCP router, the creation of a new prefix
is not desired.</t>
<t>If the remaining preferred lifetime of the prefix is 0 and
there is another delegated prefix of the same IP version used for
prefix assignment with a non-null preferred lifetime, the
creation of a new prefix is not desired.</t>
<t>Otherwise, the creation of a new prefix is desired.</t>
</list>
</t>
<t>If the considered delegated prefix is an IPv6 prefix, and
whenever there is at least one available prefix of length 64, a
prefix of length 64 MUST be selected unless configured
otherwise by an administrator. In case no prefix of length 64
would be available, a longer prefix MAY be selected.</t>
<t>If the considered delegated prefix is an IPv4 prefix (<xref
target="ula" /> details how IPv4 delegated prefixes are
generated), a prefix of length 24 SHOULD be preferred.</t>
<t>In any case, a router MUST support a mechanism suitable to
distribute addresses from the considered prefix to clients on
the link. Otherwise it MUST NOT create or adopt it, i.e. a
router assigning an IPv4 prefix MUST support the L-capability
and a router assigning an IPv6 prefix not suitable for
Stateless Address Autoconfiguration MUST support the H-capability as
defined in <xref target="version-tlv" />.
</t>
</section>
<section title="Applying Assignments">
<t>The prefix assignment algorithm indicates when a prefix is
applied to the respective Common Link. When that happens
each router connected to said link:
<list>
<t>MUST create an appropriate on-link route for said prefix
and advertise it using the chosen routing protocol.</t>
<t>MUST participate in the client configuration election as
described in <xref target="client-config" />.</t>
<t>MAY add an address from said prefix to the respective
network interface as described in <xref target="node-addr" />.
</t>
</list>
</t>
</section>
<section title="DHCPv6-PD Excluded Prefix Support">
<t>Whenever a <xref target="RFC6603">DHCPv6 Prefix Exclude option
</xref> is received with a delegated prefix, the excluded prefix
MUST be advertised as assigned to a Private Link with the maximum
priority (i.e. 15).</t>
<t>The same procedure MAY be applied in order to exclude
prefixes obtained by other means of configuration.</t>
</section>
<section title="Downstream Prefix Delegation Support" anchor="pd">
<t>When an HNCP router receives a request for prefix delegation,
it SHOULD assign one prefix per delegated prefix, wait for them to be applied,
and delegate them to the client. Such assignment MUST be done in
accordance with the Prefix Assignment Algorithm. Each client
MUST be considered as an independent Private Link and delegation
MUST be based on the same set of Delegated Prefixes as the one
used for Common Links prefixes assignment.</t>
<t>The assigned prefixes MUST NOT be given to clients before
they are applied, and MUST be withdrawn whenever they are
destroyed. As an exception to this rule, in order to shorten
delays of processed requests, a router MAY prematurely
give out a prefix which is advertised but not yet applied if it
does so with a valid lifetime of not more than 30 seconds and
ensures removal or correction of lifetimes as soon as possible.</t>
</section>
</section>
<section title="Node Address Assignment" anchor="node-addr">
<t>This section specifies how HNCP nodes reserve addresses for their
own use. Nodes MAY, at any time, try to reserve a new address from any
applied Assigned Prefix. SLAAC SHOULD be used whenever possible.
The following method MUST be used otherwise.</t>
<t>For any IPv6 prefix for which SLAAC cannot be used (resp. any IPv4 prefix)
assigned to a Common Link, the first quarter of the addresses
are reserved for routers HNCP based address assignments, whereas the last
three quarters are left to the DHCPv6 (resp. DHCPv4) elected router
(<xref target="version-tlv" /> specifies the DHCP server election process).
For instance, if the prefix 192.0.2.0/24 is assigned and
applied to a Common Link, addresses included in 192.0.2.0/26 are
reserved for HNCP nodes and the remaining addresses are reserved
for the elected DHCPv4 server.</t>
<t>HNCP routers assign themselves addresses using the Node Address 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-ADDRESS (36) | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="hanging">
<t hangText="Endpoint Identifier: ">The endpoint identifier
of the local interface that belongs to the Common Link the
prefix is assigned to, or 0 if it is not assigned on an HNCP
enabled link.</t>
<t hangText="IP Address: ">The globally scoped IPv6 address, or the IPv4 address
encoded as an <xref target="RFC4291">IPv4-mapped IPv6 address</xref>.</t>
</list>
</t>
<t>The process of obtaining addresses is specified as follows:
<list style="symbols">
<t>A router MUST NOT start advertising an address if it is
already advertised by another router.</t>
<t>An assigned address MUST be in the first quarter of an
assigned prefix currently applied on a Common Link which includes
the interface specified by the endpoint identifier.</t>
<t>An address MUST NOT be used unless it has been advertised for
at least ADDRESS_APPLY_DELAY consecutive seconds, and is still
currently being advertised. The default value for ADDRESS_APPLY_DELAY
is 3 seconds.</t>
<t>Whenever the same address is advertised by more than one node,
all but the one advertised by the node with the highest node identifier
MUST be removed.</t>
</list>
</t>
</section>
<section anchor="ula" title="Local IPv4 and ULA Prefixes">
<t>HNCP routers can create an ULA or private IPv4 prefix to enable
connectivity between local devices. These prefixes are inserted in
HNCP as if they were delegated prefixes. The following rules apply:
<list>
<t>An HNCP router SHOULD create a ULA prefix if there is no other
non-deprecated IPv6 prefix in the network. It MAY also do so
if there are other delegated IPv6 prefixes but none of which is
generated by an HNCP router (i.e., none of which is specified in a
Delegated Prefix TLV which also includes a Prefix Domain TLV)
but MUST NOT do so otherwise. Whenever it detects
another non-deprecated IPv6 prefix generated by an HNCP router with
a greater HNCP identifier, it MUST cease to announce its own locally generated one.</t>
<t>An HNCP router MUST create a <xref target="RFC1918">
private IPv4 prefix</xref> whenever it wishes to provide IPv4 internet
connectivity to the network and no other private IPv4 prefix with
internet connectivity currently exists. It MAY also enable local IPv4
connectivity by creating a private IPv4 prefix if no IPv4 prefix exists
but MUST NOT do so otherwise.
In case multiple IPv4 prefixes are announced all but one MUST be removed
while those associated with a Prefix Domain TLV of type 0
take precedence over those without and, in case of a tie, announcements by nodes
with a greater node identifier take precedence over those with a
lower one. The router publishing a prefix with internet connectivity
MUST announce an IPv4 default route using the routing protocol and
perform NAT on behalf of the network as long as it publishes the
prefix, other routers in the network MAY choose not to.
Internet Connectivity is indicated using a Prefix Domain TLV.</t>
</list>
</t>
<t>Creation of such ULA and IPv4 prefixes MUST be delayed by a
random timespan between 0 and 10 seconds in which the router MUST
scan for other nodes trying to do the same.</t>
<t>When a new ULA prefix is created, the prefix is selected based
on the configuration, using the last non-deprecated ULA prefix,
or generated based on <xref target="RFC4193"/>.</t>
</section>
</section>
<section title="Configuration of Hosts and non-HNCP Routers" anchor="client-config">
<t>HNCP routers need to ensure that hosts and non-HNCP downstream
routers on internal links are configured with addresses and routes.
Since DHCP-clients can usually only bind to one server at a time, a per-link
and per-service election takes place.</t>
<t>HNCP routers may have different capabilities for configuring
downstream devices and providing naming services. Each router MUST
therefore indicate its capabilities as specified in <xref
target="version-tlv" /> in order to participate as a candidate in the
election.</t>
<section title="DHCPv6 for Addressing or Configuration">
<t>In general Stateless Address Autoconfiguration is used for client
configuration for its low overhead and fast renumbering capabilities,
however stateful DHCPv6 can be used in addition by administrative choice,
to e.g. collect hostnames and use them to provide naming services
or whenever stateless configuration is not applicable.</t>
<t>The designated stateful DHCPv6 server for a <xref
target="links">Common Link</xref> is elected
based on the capabilities described in <xref target="version-tlv"
/>. The winner is the router (connected to the Common Link) advertising the greatest
H-capability. In case of a tie, Capability Values and node
identifiers are considered (greatest value is elected). The
elected router MUST serve stateful DHCPv6 and MUST provide naming services for
acquired hostnames as outlined in <xref target="naming-sd" />.
Stateful addresses SHOULD be assigned in a way not hindering
fast renumbering even if the DHCPv6 server or client do not support
the DHCPv6 reconfigure mechanism. In case no router was
elected, stateful DHCPv6 is not provided and each router assigning
IPv6-prefixes on said link MUST provide stateless DHCPv6 service.</t>
</section>
<section title="Sending Router Advertisements">
<t>All HNCP routers MUST send Router Advertisements periodically via multicast and via unicast in
response to Router Solicitations.
<list style="symbols">
<t>The "Managed address configuration" flag MUST be set whenever
a router connected to the link is advertising a non-null
H-capability and MUST NOT be set otherwise. The "Other configuration"
flag MUST always be set.</t>
<t>The default Router Lifetime MUST be set to an appropriate non-null value
whenever an IPv6 default route is known in the HNCP network and
MUST be set to zero otherwise.</t>
<t>A Prefix Information Option MUST be added for each assigned and applied IPv6
prefix on the given link. The autonomous address-configuration flag
MUST be set whenever the prefix is suitable for stateless
configuration. The preferred and valid lifetimes MUST be
smaller than the preferred and valid lifetimes of the
delegated prefix the prefix is from. When a prefix is removed,
it MUST be deprecated as specified in <xref target="RFC7084"/>.</t>
<t>A <xref target="RFC4191">Route Information Option</xref> MUST be
added for each delegated IPv6 prefix known in the HNCP network.
Additional ones SHOULD be added for each non-default IPv6 route
with an external destination prefix advertised by the routing protocol.</t>
<t>A Recursive DNS Server Option and a DNS Search List Option MUST
be included with appropriate contents.</t>
<t>To allow for optimized routing decisions for clients on the local
link routers SHOULD adjust their <xref target="RFC4191">Default
Router Preference and Route Preferences</xref> so that the priority
is set to low if the next hop of the default or more specific route
is on the same interface as the Route Advertisement being sent on.
Similarly the router MAY use the high priority if it is certain it
has the best metric of all routers on the link for all routes known
in the network with the respective destination.</t>
</list>
Every router sending Router Advertisements MUST immediately send an
updated Router Advertisement via multicast as soon as it notices a
condition resulting in a change of any advertised information.
</t>
</section>
<section title="DHCPv6 for Prefix Delegation">
<t>The designated DHCPv6 server for prefix-delegation on a Common Link is
elected based on the capabilities described in <xref
target="version-tlv" />.
The winner is the router (connected to the Common Link) advertising
the greatest P-capability. In case of a tie, Capability Values are
compared, and router with the greatest value is elected. In case of
another tie, the router with the highest node identifier is elected
among the routers with tied Capability Values.
The elected router MUST provide <xref
target="RFC3633">prefix-delegation services</xref> on the given
link and follow the rules in <xref target="pd" />.</t>
</section>
<section title="DHCPv4 for Addressing and Configuration">
<t>The designated DHCPv4 server on a <xref
target="links">Common Link</xref> is elected based on the
capabilities described in <xref target="version-tlv" />.
The winner is the router (connected to the Common Link) advertising
the greatest L-capability. In case of a tie, Capability Values are
compared, and router with the greatest value is elected. In case of
another tie, the router with the highest node identifier is elected
among the routers with tied Capability Values.
The elected router MUST provide
DHCPv4 services on the given link.</t>
<t>The DHCPv4 serving router MUST announce itself as
<xref target="RFC2132">router</xref> to clients if and only if there
is an IPv4 default route known in the network. In addition, the router
SHOULD announce a
<xref target="RFC3442">Classless Static Route Option</xref>
for each non-default IPv4 route advertised in the routing protocol
with an external destination.</t>
<t>DHCPv4 lease times SHOULD be short (i.e. not longer than 5 minutes)
in order to provide reasonable response times to changes.</t>
</section>
<section title="Multicast DNS Proxy">
<t>The designated <xref target="RFC6762">MDNS</xref> proxy on a
Common Link is elected based on the capabilities described in <xref
target="version-tlv" />.
The winner is the router (connected to the Common Link) advertising
the greatest M-capability. In case of a tie, Capability Values are
compared, and router with the greatest value is elected. In case of
another tie, the router with the highest node identifier is elected
among the routers with tied Capability Values.
The elected router MUST provide an MDNS-proxy on the given link and
announce it as described in <xref target="naming-sd" />.</t>
</section>
</section>
<section title="Naming and Service Discovery" anchor="naming-sd">
<t>Network-wide naming and service discovery can greatly improve the
user-friendliness of an IPv6 network. The following mechanism provides
means to setup and delegate naming and service discovery across
multiple HNCP routers.</t>
<t>Each HNCP router SHOULD provide and announce an auto-generated or
user-configured name for each internal <xref target="links">Common
Link</xref> for which it is the designated DHCPv4, stateful
DHCPv6 server or MDNS proxy and for
which it provides DNS services on behalf of devices on said link.
In addition it MAY provide reverse lookup services.</t>
<t>The following TLVs are defined and MUST be supported by all nodes
implementing naming and service discovery:</t>
<section anchor="delegated-zone-tlv" title="DNS Delegated Zone TLV">
<t>This TLV is used to announce a forward or reverse DNS zone
delegation in the HNCP network. Its meaning is roughly equivalent
to specifying an NS and A/AAAA record for said zone. There MUST NOT
be more than one delegation for the same zone in the whole DNCP
network. In case of a conflict the announcement of the node with
the highest node identifier takes precedence and all other nodes
MUST cease to announce the conflicting TLV.</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: DNS-DELEGATED-ZONE (39) | Length: >= 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserved |L|B|S| |
+-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) |
| |
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="IP Address :"> The IPv6 address of the authoritative
DNS server for the zone; IPv4 addresses are represented as
<xref target="RFC4291">IPv4-mapped addresses</xref>. The
special value of :: (all-zero) means the delegation is
available in the global DNS-hierarchy.</t>
<t hangText="Reserved :">Those bits MUST be set to zero when creating the TLV
and ignored when parsing it unless defined in a later specification.</t>
<t hangText="L-bit :"> <xref target="RFC6763">DNS-SD</xref> Legacy-Browse,
indicates that this delegated zone should be included in the
network's DNS-SD legacy browse list of domains at lb._dns-
sd._udp.(DOMAIN-NAME). Local forward zones SHOULD have this
bit set, reverse zones SHOULD NOT.</t>
<t hangText="B-bit :"> (<xref target="RFC6763">DNS-SD</xref> Browse)
indicates that this delegated zone should be included in the
network's DNS-SD browse list of domains at b._dns-sd._udp.
(DOMAIN-NAME). Local forward zones SHOULD have this bit set,
reverse zones SHOULD NOT.</t>
<t hangText="S-bit :"> (fully-qualified <xref target="RFC6763">DNS-SD</xref>
domain) indicates that this delegated zone consists of a
fully-qualified DNS-SD domain, which should be used as base for
DNS-SD domain enumeration, i.e. _dns-sd._udp.(Zone) exists.
Forward zones MAY have this bit set, reverse zones MUST NOT.
This can be used to provision DNS search path to hosts for
non-local services (such as those provided by an ISP, or other
manually configured service providers). Zones with this flag
SHOULD be added to the search domains advertised to clients.</t>
<t hangText="Zone :">The label sequence of the zone, encoded as
the domain names are encoded DNS messages as specified in <xref
target="RFC1035"/>. The last label in the zone MUST be
empty.</t>
</list>
</t>
</section>
<section anchor="domain-name-tlv" title="Domain Name TLV">
<t>This TLV is used to indicate the base domain name for the
network. It is the zone used as a base for all non fully-qualified
delegated zones and node names. In case of conflicts the announced
domain of the node with the greatest node identifier takes precedence.
By default, i.e., if no node advertises such a TLV., ".home" is used.</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: DOMAIN-NAME (40) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain (DNS label sequence - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Domain: ">The label sequence encoded according to <xref
target="RFC1035"/>. Compression MUST NOT be used. The zone
MUST end with an empty label.</t>
</list>
</t>
</section>
<section anchor="router-name-tlv" title="Node Name TLV">
<t>This TLV is used to assign the name of a node in the network
to a certain IP address. In case of conflicts the announcement of
the node with the greatest node identifier for a name takes precedence
and all other nodes MUST cease to announce the conflicting TLV.</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: NODE-NAME (41) | Length: > 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name (not null-terminated - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="IP Address: ">The IP address associated with the name. IPv4
addresses are encoded using IPv4-mapped IPv6 addresses.</t>
<t hangText="Name: ">The name of the node as a DNS label. The
length of the label is the Length value of the TLV minus
16. </t>
</list>
</t>
</section>
</section>
<section title="Securing Third-Party Protocols">
<t>Pre-shared keys (PSKs) are often required to secure IGPs and other
protocols which lack support for asymmetric security. The following
mechanism manages PSKs using HNCP to enable bootstrapping of such
third-party protocols and SHOULD therefore be used if such a need
arises. The following rules define how such a PSK is managed and used:
<list style="symbols">
<t>If no Managed-PSK-TLV is currently being announced, an HNCP
router MUST create one after a random delay of 0 to 10 seconds
with a 32 bytes long random key and add it to its node data.</t>
<t>In case multiple routers announce such a TLV at the same time,
all but the one with the greatest node identifier stop advertising it and
adopt the remaining one.</t>
<t>The router currently advertising the Managed-PSK-TLV must
generate and advertise a new random one whenever an unreachable node
is purged as described in DNCP.</t>
<!-- [PP] Shouldn't we add some grace period to that. Changing the key
is an heavy operation which we probably don't want to do when there
is a flappy link. -->
</list>
</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: Managed-PSK (42) | Length: 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| Random PSK |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>PSKs for individual protocols are derived from the random PSK
through the use of <xref target="RFC6234">HMAC-SHA256</xref> with a
pre-defined per-protocol HMAC-key in ASCII-format. The following
HMAC-keys are currently defined to derive PSKs for the respective
protocols:
<list>
<t>"ROUTING": to be used for IGPs</t>
</list>
</t>
</section>
<section anchor="version-tlv" title="HNCP Versioning and Capabilities">
<t>Multiple versions of HNCP based on compatible
DNCP profiles may be
present in the same network when transitioning between HNCP versions
and HNCP routers may have different capabilities to support clients.
The following mechanism describes a way to announce the currently active
version and User-agent of a node. Each node MUST include an
HNCP-Version-TLV in its Node Data and MUST ignore (except for DNCP
synchronization purposes) any TLVs with a type greater than 32 published
by nodes not also publishing an HNCP-Version TLV or publishing such a TLV with a
different Version number.</t>
<t>Capabilities are indicated by setting M, P, H and L fields in the TLV. The
"capability value" is a metric indicated by interpreting the bits as an
integer, i.e. (M << 12 | P << 8 | H << 4 | L).</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: HNCP-VERSION (32) | Length: >= 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | M | P | H | L |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-agent |
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Version:">Indicates which version of HNCP is
currently in use by this particular node. It MUST be set to 0.
Nodes with different versions are considered incompatible.
</t>
<t hangText="Reserved:">Bits are reserved for future use. They
MUST be set to zero when creating this TLV, and their value
MUST be ignored when processing the TLV.
</t>
<t hangText="M-capability:">Priority value used for electing the
on-link <xref target="RFC6762">MDNS</xref> proxy. It MUST be
set to some value between 1 and 7 included (4 is the default)
if the router is capable of proxying MDNS and 0 otherwise.
The values 8-15 are reserved for future use.</t>
<t hangText="P-capability:">Priority value used for electing the
on-link DHCPv6-PD server. It MUST be set to some value between
1 and 7 included (4 is the default) if the router is capable of
<xref target="pd">providing prefixes through DHCPv6-PD</xref>
and 0 otherwise.
The values 8-15 are reserved for future use.</t>
<t hangText="H-capability:">Priority value used for electing the
on-link DHCPv6 server offering non-temporary addresses. It
MUST be set to some value between 1 and 7 included
(4 is the default) if the router is capable of providing such
addresses and 0 otherwise.
The values 8-15 are reserved for future use.</t>
<t hangText="L-capability:">Priority value used for electing the
on-link DHCPv4 server. It MUST be set to some value between
1 and 7 included (4 is the default) if the router is
capable of running a legacy DHCPv4 server offering
IPv4 addresses to clients and 0 otherwise.
The values 8-15 are reserved for future use.</t>
<t hangText="User-Agent:">
The user-agent is a human-readable UTF-8 string
that describes the name and version of the current HNCP
implementation.
</t>
</list>
</t>
</section>
<section title="Requirements for HNCP Routers">
<t>Each router implementing HNCP is subject to the following
requirements:
<list style="symbols">
<t>It MUST implement HNCP-Versioning, Border Discovery, Prefix
Assignment and Configuration of hosts and non-HNCP routers
as defined in this document.</t>
<t>It MUST implement and run the method for securing third-party
protocols whenever it uses the security mechanism of HNCP.</t>
<t>It SHOULD implement support for the Service Discovery and Naming
TLVs as defined in this document.</t>
<t>It MUST implement and run a routing protocol appropriate for the
given link type on all of the interfaces it sends and receives HNCP
traffic on. The protocol MUST support source-specific routes and
MUST correctly propagate those also for the external destinations
that may have only implicit source-specific information, such as
a combination of a DHCPv6 PD-derived prefix and a non-source-specific
default route.</t>
<t>It MUST use adequate security mechanisms for the routing
protocol on any interface where it also uses the security
mechanisms of HNCP. If the security mechanism is based on a PSK it
MUST use a PSK derived from the Managed-PSK to secure the IGP.</t>
<t>It MUST comply with the <xref target="RFC7084">Basic
Requirements for IPv6 Customer Edge Routers</xref> unless it would
otherwise conflict with any requirements in this document (e.g. prefix
assignment mandating a different prefix delegation and DHCP server
election strategy). In general "WAN interface requirements" shall
apply to external interfaces and "LAN interface requirements"
to internal interfaces respectively.</t>
<t>It MAY be able to provide connectivity to IPv4-devices using
DHCPv4.</t>
<t>It SHOULD be able to delegate prefixes to legacy IPv6 routers
using DHCPv6-PD.</t>
</list></t>
</section>
<section title="Security Considerations">
<t>HNCP enables self-configuring networks, requiring
as little user intervention as possible. However this
zero-configuration goal usually conflicts with security goals and
introduces a number of threats.</t>
<t>General security issues for existing home networks are discussed
in <xref target="RFC7368" />. The protocols used to set up addresses
and routes in such networks to this day rarely have security enabled
within the configuration protocol itself. However these issues are out
of scope for the security of HNCP itself.</t>
<t>HNCP is a DNCP-based
state synchronization mechanism carrying information with varying
threat potential. For this consideration the payloads defined in DNCP
and this document are reviewed:
<list style="symbols">
<t>Network topology information such as HNCP nodes and their
common links.</t>
<t>Address assignment information such as delegated and assigned
prefixes for individual links.</t>
<t>Naming and service discovery information such as auto-generated
or customized names for individual links and routers.</t>
</list>
</t>
<section title="Border Determination">
<t>As described in <xref target="bd" />, an HNCP router determines
the internal or external state on a per-link basis. A firewall
perimeter is set up for the external links, and for internal links,
HNCP and IGP traffic is allowed.</t>
<t>Threats concerning automatic border discovery cannot be
mitigated by encrypting or authenticating HNCP traffic itself since
external routers do not participate in the protocol and often
cannot be authenticated by other means. These threats include
propagation of forged uplinks in the homenet in order to
e.g. redirect traffic destined to external locations and forged
internal status by external routers to e.g. circumvent the
perimeter firewall.</t>
<t>It is therefore imperative to either secure individual links on
the physical or link-layer or preconfigure the adjacent interfaces
of HNCP routers to an adequate fixed-category in order to secure
the homenet border. Depending on the security of the external link
eavesdropping, man-in-the-middle and similar attacks on external
traffic can still happen between a homenet border router and the
ISP, however these cannot be mitigated from inside the homenet. For
example, DHCPv4 has defined <xref target="RFC3118" /> to authenticate
DHCPv4 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.</t>
</section>
<section title="Security of Unicast Traffic">
<t>Once the homenet border has been established there are several
ways to secure HNCP against internal threats like manipulation or
eavesdropping by compromised devices on a link which is enabled for
HNCP traffic. If left unsecured, attackers may perform arbitrary
eavesdropping, spoofing or denial of service attacks on HNCP services
such as address assignment or service discovery.</t>
<t>Detailed interface categories like "leaf" or "guest" can be used
to integrate not fully trusted devices to various degrees into the
homenet by not exposing them to HNCP and IGP traffic or by using
firewall rules to prevent them from reaching homenet-internal
resources. </t>
<t>On links where this is not practical and lower layers do not
provide adequate protection from attackers, DNCP secure mode MUST be
used to secure traffic.</t>
</section>
<section title="Other Protocols in the Home">
<t>IGPs and other protocols are usually run alongside HNCP therefore
the individual security aspects of the respective protocols must be
considered. It can however be summarized that many protocols to be
run in the home (like IGPs) provide - to a certain extent - similar
security mechanisms. Most of these protocols do not support
encryption and only support authentication based on pre-shared keys
natively. This influences the effectiveness of any encryption-based
security mechanism deployed by HNCP as homenet routing information is
thus usually not encrypted.</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>IANA is requested to maintain a registry for HNCP TLV-Types.
This registry inherits TLV-Types and allocation policy defined in
<xref target="I-D.ietf-homenet-dncp">DNCP</xref>, but is independent
with regard to all TLV-Types not specified or reserved by DNCP. Particularly,
other DNCP profile may have there own registries, using same TLV numbers.</t>
<t>The following TLV-Types are defined in this document:
<list>
<t>32: HNCP-Version</t>
<t>33: External-Connection</t>
<t>34: Delegated-Prefix</t>
<t>35: Assigned-Prefix</t>
<t>36: Node-Address</t>
<t>37: DHCPv4-Data</t>
<t>38: DHCPv6-Data</t>
<t>39: DNS-Delegated-Zone</t>
<t>40: Domain-Name</t>
<t>41: Node-Name</t>
<t>42: Managed-PSK</t>
</list>
</t>
<t>HNCP requires allocation of UDP port numbers
HNCP-UDP-PORT and HNCP-DTLS-PORT, as well as an IPv6 link-local
multicast address All-Homenet-Routers.</t>
</section>
</middle>
<back>
<references title="Normative references">
<?rfc include="reference.I-D.draft-ietf-homenet-dncp-05"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.6347.xml"?>
<?rfc include="reference.RFC.6603.xml"?>
<?rfc include="reference.RFC.4191.xml"?>
<?rfc include="reference.I-D.draft-ietf-homenet-prefix-assignment-07"?>
</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.RFC.7368.xml"?>
<?rfc include="reference.RFC.1035.xml"?>
<?rfc include="reference.RFC.6234.xml"?>
<?rfc include="reference.RFC.1321.xml"?>
<?rfc include="reference.RFC.6762.xml"?>
<?rfc include="reference.RFC.6763.xml"?>
<?rfc include="reference.RFC.6241.xml"?>
<?rfc include="reference.RFC.2132.xml"?>
<?rfc include="reference.RFC.3442.xml"?>
<?rfc include="reference.RFC.4193.xml"?>
</references>
<section title="Changelog [RFC Editor: please remove]">
<t>draft-ietf-homenet-hncp-06: Various edits based on feedback,
hopefully without functional delta.</t>
<t>draft-ietf-homenet-hncp-05: Renamed "Adjacent Link" to "Common Link".
Changed single IPv4 uplink election from MUST to MAY. Added explicit
indication to distinguish (IPv4)-PDs for local connectivity and ones
with uplink connectivity allowing e.g. better local-only
IPv4-connectivity.</t>
<t>draft-ietf-homenet-hncp-04: Change the responsibility for sending
RAs to the router assigning the prefix.</t>
<t>draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and
HNCP (homenet profile).</t>
<t>draft-ietf-homenet-hncp-02: Removed any built-in security. Relying
on IPsec. Reorganized interface categories, added requirements languages,
made manual border configuration a MUST-support. Redesigned routing
protocol election to consider non-router devices.</t>
<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 [RFC Editor: please remove]">
<t>This draft is available at <eref
target="https://github.com/fingon/ietf-drafts/">https://github.com/fingon/ietf-drafts/</eref>
in source format. Issues and pull requests are welcome.</t>
</section>
<section title="Implementation [RFC Editor: please remove]">
<t>A GPLv2-licensed implementation of HNCP is currently under
development at <eref target="https://github.com/sbyx/hnetd/">
https://github.com/sbyx/hnetd/</eref> and binaries are available in
the <eref target="http://www.openwrt.org">OpenWrt</eref> package
repositories. See <eref
target="http://www.homewrt.org/doku.php?id=run-conf" /> for more
information. Feedback and contributions are welcome.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Ole Troan, Mark Baugher, Mark Townsley
and Juliusz Chroboczek for their contributions to the draft.</t>
<t>Thanks to Eric Kline for the original border discovery work.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:46:36 |