One document matched: draft-ietf-homenet-hncp-07.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-07'
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="July" 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", "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. Unicast replies
to multicast and unicast messages MUST be sent to the IPv6 source
address and port of the original message. 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.
The following parameters are suggested:
<list style="symbols">
<t>Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20 seconds.</t>
<t>Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1.</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. A Common Link usually refers to a link layer broadcast
domain with certain properties and is used, e.g., to determine where
prefixes should be assigned or which neighboring nodes
participate in the election of a DHCP(v6) server.
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 either statelessly or using 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 anchor="prefixdomain" 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. See <xref target="specialpurpose"/>
for a more in-depth discussion.</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 | |
+-+-+-+-+-+-+-+-+ Value +
| |
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Domain Type: ">The type of the domain identifier.
<list style="hanging">
<t hangText="0 :">Internet connectivity
(no Value).</t>
<t hangText="1-128 :">Explicit destination prefix with the
Domain Type being the actual length of the prefix
(Value contains significant bits of the destination prefix
padded with zeroes up to the next byte boundary).</t>
<t hangText="129 :">DNS Zone (Value contains an <xref
target="RFC1035">RFC 1035</xref> encoded DNS label sequence).</t>
<t hangText="130 :">Opaque UTF-8 string (e.g. for administrative purposes).</t>
<t hangText="131-255:">Reserved for future additions.</t>
</list></t>
<t hangText="Value: ">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 anchor="assign" 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. This rule applies to TLVs
inside Delegated Prefix TLVs but not to those
inside External Connection TLVs.</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, if the
Delegated Prefix is either locally generated (does not have
any Prefix Domain TLVs) or intended for internet access
(has a Prefix Domain TLV of type 0). Local desirability
policies MAY override or provide additional desirability
rules for delegated prefixes, e.g., by matching different
Prefix Domain TLV values.</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. In case no prefix of length 64 would be available, a
longer prefix MAY be selected even without configuration.</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 if the link is
intended to be used by clients. In this case a router assigning
an IPv4 prefix MUST support the L-capability and a router
assigning an IPv6 prefix MUST support serving router
advertisements. In addition if an assigned IPv6 prefix is not
suitable for Stateless Address Autoconfiguration the router MUST
also 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 route for said prefix, indicating
it is directly reachable on the respective link
and advertise said route using the chosen routing protocol.</t>
<t>MUST participate in the client configuration election as
described in <xref target="client-config" />, if the link is
intended to be used by clients.</t>
<t>MAY add an address from said prefix to the respective
network interface as described in <xref target="node-addr" />,
e.g., if it is to be used as source for locally originating
traffic.</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 in the network.
This set of assigned prefix is then delegated to the client,
after it has been applied as described in 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 Link prefix
assignments.</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.
Each HNCP router MUST announce at least one IPv6 address and - if it
supports IPv4 - at least one IPv4 address, whenever matching prefixes
are assigned to at least one if its Common Links. These addresses are
published using Node Address TLVs and used to locally reach HNCP
nodes for other services. Nodes SHOULD NOT create and
announce more than one assignment per IP version to avoid cluttering
the node data with redundant information unless a special use case
requires it.</t>
<t>Stateless assignment based on Modified EUI64 interface identifiers
<xref target="RFC4291" />
SHOULD be used for address assignment whenever possible,
otherwise (e.g., for IPv4) the following method MUST be used instead:
For any assigned prefix for which SLAAC cannot be used, 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
IPv6 prefix with a preferred time greater than 0 in the network.
It MAY also do so, if there are other delegated IPv6 prefixes,
but none of which is locally generated (i.e., without any Prefix
Domain TLV) and has a preferred time greater than 0. However, it
MUST NOT do so otherwise. In case multiple locally generated
ULA prefixes are present, only the one published by the node with
the highest node identifier is kept among those with a preferred
time greater than 0 - if there is any.</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, only the one published by the node with the highest node
identifier is kept among those with a Prefix Domain of type 0 -
if there is any.
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.</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 anchor="specialpurpose" title="Special Purpose Prefixes">
<t>Some prefixes may have a special meaning and are not regularly
used for internal or internet connectivity, instead they may
provide access to special services like VPNs, sensor networks,
VoIP, IPTV, etc. Care must be taken that these prefixes are
properly integrated and dealt with in the network, in order to
avoid breaking connectivity for devices who are not aware of their
special characteristics.</t>
<t>Special purpose prefixes are distinguished using
<xref target="prefixdomain">Prefix Domain TLVs</xref>. Their
contents MAY be partly opaque to HNCP nodes, and their
identification and usage depends on local policy. However the
following general rules MUST be adhered to:
<list>
<t>Special rules apply when making address assignments for
prefixes with Prefix Domain TLVs other than type 0, as
described in <xref target="assign"/></t>
<t>In presence of any type 1 to 128 Prefix Domain TLV the
prefix is specialized to reach destinations denoted by any
such Prefix Domain TLV, i.e. in abscence of a type 0 Prefix
Domain TLV it is not usable for general internet connectivity.
An HNCP router MAY enforce this restriction with appropriate
packet filtering rules to provide increased security.</t>
<t>The presence of a type 129 (DNS zone) Prefix Domain TLV
indicates that the delegated prefix or its associated external
connection is specialized to reach destinations within the
given DNS zone. An HNCP router providing name resolving
services SHOULD prefer DNS servers listed in the associated
external connection's DHCPv4 or DHCPv6 Data TLVs when
resolving domains from that zone.</t>
</list>
</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 a 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, MDNS proxy, or for which it provides forward or
reverse DNS services on behalf of connected devices. HNCP routers
providing name resolving services MUST use the included DNS server
address to resolve names belonging to the zone.</t>
<t>Each HNCP router SHOULD announce a node name for itself to be
easily reachable and MAY do so on behalf of other devices. HNCP
routers providing name resolving services MUST resolve these names
to their respective IP addresses.</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.
This TLV MUST NOT be announced unless the domain name was explicitly
configured by an administrator.</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 single DNS label
(up to 63 characters, no leading length byte).</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 1.
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 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>
<t>In addition, normative language of <xref target="RFC7084">Basic
Requirements for IPv6 Customer Edge Routers</xref> applies with the
following adjustments:
<list>
<t>The section "WAN-Side Configuration" applies to HNCP interfaces
classified as external.</t>
<t>If the CE sends a size-hint as indicated in WPD-2, the hint
MUST NOT be determined by the number of LAN-interfaces of the CE,
but SHOULD instead be large enough to at least accommodate prefix
assignments announced for existing delegated or ULA-prefixes, if
such prefixes exist and unless explicitly configured otherwise.</t>
<t>The dropping of packets with a destination address belonging to
a delegated prefix mandated in WPD-5 MUST NOT be applied to
destinations that are part of any prefix announced using an
ASSIGNED-PREFIX TLV by any HNCP router in the network.</t>
<t>The section "LAN-Side Configuration" applies to HNCP interfaces
classified as internal.</t>
<t>The requirement L-2 to assign a separate /64 to each LAN interface
is replaced by the participation in the <xref target="pa">
prefix assignment mechanism</xref> for each such interface.</t>
<t>The requirement L-12 to make DHCPv6 options available is
adapted, in that a CER SHOULD publish the subset of options using
the DHCPv6 Data TLV in an External Connection TLV. Similarly it
SHOULD do the same for DHCPv4 options in a DHCPv4 Data TLV.
DHCPv6 options received inside an OPTION_IAPREFIX
<xref target="RFC3633" /> MUST be published using a DHCPv6 Data TLV
inside the respective Delegated Prefix TLV.
HNCP routers SHOULD make relevant DHCPv6 and DHCPv4 options available
to clients, i.e. options contained in External Connection TLVs that
also include delegated prefixes from which a subset is assigned to
the respective link.</t>
</list>
</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-07"?>
<?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-07: Using version 1 instead of version 0,
as existing implementations already use it.</t>
<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 11:02:20 |