One document matched: draft-ietf-homenet-hncp-03.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:
[SB] make (some?) DNCP references into actual <xrefs>
- 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-03'
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="January" 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 (group
All-Homenet-Routers). Received datagrams with an IPv6 source or
destination address which is not link-local scoped MUST be
ignored.</t>
<t>HNCP operates on multicast-capable interfaces only, thus every DNCP
Connection Identifier MUST refer to one, except for the value 0 which
is reserved for internal purposes and MUST NOT be used for connection
enumeration. Implementations MAY use a value equivalent to the
sin6_scope_id for the given interface.</t>
<t>HNCP unicast messages 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 the security mechanism 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 it receives a Node State
TLV with the same node identifier and a higher update sequence number,
it MUST immediately generate and use a new random node identifier which
is not used by any other node.</t>
<t>HNCP nodes MUST treat all Long Network State Update messages
received via multicast on a link which has DNCP security enabled as if
they were Short Network State Update messages, i.e. they MUST ignore
all contained Node State TLVs.</t>
<t>HNCP nodes use the following Trickle parameters:
<list style="symbols">
<t>k SHOULD be 1, given the timer reset on data updates and
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 the keep-alive extension on all connections.
The default keep-alive interval (DNCP_KEEPALIVE_INTERVAL) is 20
seconds, the multiplier (DNCP_KEEPALIVE_MULTIPLIER) MUST be 2.1,
the grace-interval (DNCP_GRACE_INTERVAL) SHOULD be equal to
DNCP_KEEPALIVE_MULTIPLIER times DNCP_KEEPALIVE_INTERVAL.</t>
</list>
</t>
</section>
<section title="Adjacent Links" anchor="links">
<t>HNCP uses the concept of Adjacent Links for some of its
applications. This term is defined as follows:</t>
<t>If the connection of a node is detected or configured to be an ad-hoc
interface the Adjacent Link only consists of said interface.</t>
<t>Otherwise the Adjacent Link contains all interfaces bidirectionally
reachable from a given local interface. An interface X of a node A and
an interface Y of a node B are bidirectionally reachable if and only if
node A publishes a Neighbor TLV with the Neighbor Node Identifier B,
the Neighbor Connection Identifier Y and the Local Connection Identifier
X and node B publishes a Neighbor TLV with the Neighbor Node Identifier
A, a Neighbor Connection Identifier X and the Local Connection
Identifier Y. In addition a node MUST be able to detect whether two of
its local interfaces belong to the same Adjacent Link either by local
means or by inferring that from the bidirectional reachability between
two different local interfaces and the same remote interface.</t>
</section>
<section title="Border Discovery" anchor="bd">
<t>HNCP associates each HNCP interface with a category (e.g., internal or external).
This section defines the border discovery algorithm derived from
the edge router interactions described in the <xref
target="RFC7084">Basic Requirements for IPv6 Customer Edge
Routers</xref>. This algorithm 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. This algorithm
MUST be implemented by any router implementing HNCP.</t>
<t>In order to avoid conflicts between border discovery and homenet
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 a homenet interface
MUST include a DHCP User-Class consisting of the ASCII-String
"HOMENET".</t>
<t>An HNCP router running a DHCP server on a homenet interface
MUST ignore or reject DHCP-Requests containing a DHCP User-Class
consisting of the ASCII-String "HOMENET".</t>
</list>
</t>
<t>The border discovery auto-detection algorithm works as follows,
with evaluation stopping at first match:
<list style="numbers">
<t>If a fixed category is 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>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. A router MUST consider such interface as
internal but MUST NOT send nor receive HNCP messages on such
interface. A router SHOULD implement this category.</t>
<t hangText="Guest category:"> This declares an interface used by
untrusted client devices only. In addition to the restrictions of
the Leaf category, connected devices MUST NOT be able to reach other
devices inside the HNCP network nor query services advertised by them
unless explicitly allowed, instead they SHOULD only be able to reach
the internet. This category SHOULD be supported.</t>
<t hangText="Ad-hoc category:"> This configures an interface to be
<xref target="links">ad-hoc</xref> and MAY be implemented.</t>
<t hangText="Hybrid category:"> This declares an interface to
be internal while still using external connections 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 for this document. This category MAY be implemented.</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 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 zero,
one or more 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: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested TLVs |
</artwork>
</figure>
<t>The External Connection TLV is a container which:
<list style="symbols">
<t>MAY contain zero, one or more Delegated Prefix TLVs.</t>
<t>MUST NOT contain multiple Delegated Prefix TLVs with the same
prefix. In such a situation, the container 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 whole External Connection TLV MUST be ignored.</t>
<t>MAY contain other TLVs for future use.</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. All Delegated Prefix TLVs 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 bits boundary following
the end of the encoded prefix.
<list>
<t>If the encoded prefix represents an IPv6 prefix, at
most one DHCPv6 Data TLV MAY be included.</t>
<t>If the encoded prefix represents an IPv4-mapped
IPv6 address, at most one DHCPv4 Data TLV MAY be
included.</t>
<t>It MAY contain other TLVs for future use.</t>
</list>
</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="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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsv. | Prty. | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +
| |
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Connection Identifier: ">The DNCP Connection
Identifier of the link the prefix is assigned to, or 0 if the
link is a Private Link.</t>
<t hangText="Rsv.: ">Bits reserved for future use. MUST be set
to zero when creating this TLV and ignored when parsing it.</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 specified in the router's
configuration.</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="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: ">DNCP 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 HNCP internal,
leaf, guest or hybrid links. It is dynamically updated as
HNCP links are added, removed, become internal or cease to be.</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 exist.</t>
<t hangText="Set of Advertised Prefixes: ">The set of prefixes
included in Assigned Prefix TLVs advertised by other HNCP
routers. 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 Link Identifier is not zero the Shared Link is
equal to the <xref target="links">Adjacent Link</xref>.
Advertised Prefixes as well as their associated priorities
and associated Shared Links MUST be updated as Assigned
Prefix TLVs or Neighbor TLVs are added, removed or updated.</t>
</list>
</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="Making New Assignments">
<t>Whenever the Prefix Assignment Algorithm routine is run on an
Adjacent Link and whenever a new prefix may be assigned (case 1
of the routine), 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 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 Adjacent 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.</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 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
to shorten delays of processed requests.</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.
SLAAC SHOULD be used whenever possible. The following method MUST be used
otherwise.</t>
<t>For any IPv6 prefix longer than 64 bits (resp. any IPv4 prefix)
assigned to an Adjacent Link, the first quarter of the addresses
are reserved for routers HNCP based 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 an Adjacent 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>
<!-- TBD This seems very v4-centric (see also above comment of no
SLAAC for routers). Yet 'using DHCP' and not DHCPv4. Hmm.
also, I am not sure why the address range part is inverted -
traditionally, routers etc, have smallest #s. -->
<!-- [SB] seconded, also IMO it would just make sense to reseve a
portion for HNCP allocations and leave the rest at discretion
of the router (i.e. not reserve them for DHCP explicitly)
-->
<!-- [PP] It is very IPv4 centric because some people will just bark
if I assume it could be use for something else (which it could).
I changed it back to first quarter, and moved the reservation
to the elected server.
-->
<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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="hanging">
<t hangText="Connection Identifier: ">The DNCP Connection
Identifier of the link the address is assigned to, or 0 if it is
not assigned on an HNCP enabled link.</t>
<t hangText="IP Address: ">The 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 the specified link.</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 an 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 a
non-deprecated ULA but MUST NOT do so otherwise. Whenever it detects
another non-deprecated ULA being advertised it MUST cease to
announce its locally generated one. It MAY also do so once it
detects a non-deprecated non-ULA IPv6 delegated prefix.</t>
<t>An HNCP router MUST create a non-deprecated
<xref target="RFC1918">private IPv4 prefix</xref>
whenever it wishes to provide external IPv4 connectivity to the
network and no other non-deprecated private IPv4 prefix currently
exists. It MAY also create a deprecated private IPv4 prefix if no
IPv4 prefix exists and it wants to enable local IPv4 connectivity
but MUST NOT do so otherwise. In case multiple IPv4 prefixes are
announced all but one MUST be removed while non-deprecated ones
take precedence over deprecated ones and announcements by nodes
with a higher node identifier take precedence over those with a
lower one. The router publishing the non-deprecated prefix 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 MUST NOT.</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 an
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 configuration is preferred whenever
possible since it enables fast renumbering and low overhead, however
stateful DHCPv6 can be useful in addition to collect hostnames and
use them to provide naming services or if stateless configuration
is not possible for the assigned prefix length.</t>
<t>The designated stateful DHCPv6 server for a link is elected
based on the capabilities described in <xref target="version-tlv"
/>. The winner is the router connected to the <xref
target="links">Adjacent Link</xref> 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 Router Advertisements
on the given link. Furthermore it MUST provide naming services for
acquired hostnames as outlined in <xref target="naming-sd" />.
Stateful addresses being handed out SHOULD have a low preferred
lifetime (e.g. 1s) to not hinder fast renumbering if either the
DHCPv6 server or client do not support the DHCPv6 reconfigure
mechanism and the address is from a prefix for which stateless
autoconfiguration is supported as well. In case no router was
elected, stateful DHCPv6 is not provided and each router assigning
IPv6 prefixes on said link MUST serve Router Advertisements and
stateless DHCPv6.</t>
</section>
<section title="Sending Router Advertisements">
<t>The HNCP router being elected as DHCPv6 server for addressing or
configuration MUST send Router Advertisements periodically via
multicast and via unicast in response to Router Solicitations. In
addition other routers on the link MAY announce Router Advertisements.
This might result in a more optimal routing decision for clients. The following rules
MUST be followed when sending Router Advertisements:
<list>
<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 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 link is
elected based on the capabilities described in
<xref target="version-tlv" />. The winner is the router connected to the
<xref target="links">Adjacent Link</xref> advertising the greatest
P-capability. In case of a tie, Capability Values and Node
Identifiers are considered (greatest value is elected).
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 Adressing and Configuration">
<t>The designated DHCPv4 server on a link is elected based on the
capabilities described in <xref target="version-tlv" />. The
winner is the router connected to the <xref target="links">Adjacent
Link</xref> advertising the greatest L-capability. In case of a
tie, Capability Values and node identifiers are considered
(greatest value is elected). 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>
<!-- [PP] What if we just want internal IPv4 connectivity ?
We don't announce self as router ? -->
<!-- [SB] yep. -->
<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
link is elected based on the capabilities described in <xref
target="version-tlv" />. The winner is the router with the highest
Node Identifier among those with the highest Capability Value on
the link that support the M-capability. 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">Adjacent
Link</xref> for which it is the designated DHCPv4, stateful
DHCPv6 server or <xref target="RFC6762">MDNS</xref>-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>
<t>IP Address is 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>reserved bits MUST be zero when creating and ignored when
parsing this TLV.</t>
<t>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>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>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>Zone is the label sequence of the zone, 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="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 highest node identifier takes precedence.
By default ".home" is used, i.e. if no node advertises such a 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: DOMAIN-NAME (40) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain (DNS label sequence - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list>
<t>Domain is 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 highest 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>
</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 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 highest 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>
</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
<xref target="I-D.ietf-homenet-dncp">DNCP</xref> 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 of nodes
not 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:">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 reserved for future use. MUST be set
to zero when creating this TLV and ignored when parsing it.
</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 null-terminated 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 the routing protocol $FOO
with support for source-specific routes on all of the interfaces it
sends and receives HNCP-messages on and MUST resort to announcing
source-specific routes for external destinations appropriately.</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>
<!-- [PP] It's probably fine to leave it like that for now. But I guess
we will have to provide the list of rules that apply at some point. -->
<t>It SHOULD 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 <xref target="I-D.ietf-homenet-dncp">DNCP</xref>-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
adjacent 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.</t>
<t>HNCP inherits the TLV-Types and allocation policy defined in
<xref target="I-D.ietf-homenet-dncp">DNCP</xref>. In addition 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-00"?>
<?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-02"?>
</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">
<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">
<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">
<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 09:01:10 |