One document matched: draft-ietf-homenet-hncp-09.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
-->
<!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-09'
category='std'
>
<front>
<title abbrev="Home Networking Control Protocol">
Home Networking Control Protocol
</title>
<author initials="M" surname="Stenberg" fullname="Markus Stenberg">
<organization>Independent</organization>
<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">
<organization>Independent</organization>
<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="August" 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. HNCP is described as a profile
of and extension to the Distributed Node Consensus Protocol (DNCP).
HNCP enables discovery of network borders, automated configuration of
addresses, name resolution, service discovery, and the use of any
routing protocol which supports routing based on both source and
destination address.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>HNCP is designed to facilitate sharing of state among home routers
to fulfill the needs of the <xref target="RFC7368">IPv6 homenet
architecture</xref>, which assumes zero-configuration operation,
multiple subnets, multiple home routers and (potentially) multiple
upstream service providers providing (potentially) multiple prefixes
to the home network.
While RFC7368 sets no requirements for IPv4 support, HNCP aims to
support dual-stack mode of operation, and therefore the functionality
is designed with that in mind.
The state is shared as TLVs among the routers (and potentially
advanced hosts) to enable:
<list style="symbols">
<t><xref target="bd">Autonomic discovery of network borders</xref>
based on DNCP topology.</t>
<t>Automated portioning of prefixes delegated by the service
providers as well as <xref target="pa">assigned prefixes to both
HNCP and non-HNCP routers</xref> using <xref
target="I-D.ietf-homenet-prefix-assignment" />. Prefixes assigned
to HNCP routers are used to:
<list style="symbols">
<t>Provide addresses to non-HNCP aware nodes (using SLAAC and
DHCP).</t>
<t>Provide space in which <xref target="node-addr">HNCP nodes
assign their own addresses</xref>.</t>
</list>
</t>
<t><xref target="naming-sd">Internal and external name resolution,
as well as multi-link service discovery</xref>.</t>
<t>Other services not defined in this document, that do need to
share state among homenet nodes, and do not cause rapid and constant
TLV changes (see following applicability section).</t>
</list>
</t>
<t>HNCP is a <xref target="I-D.ietf-homenet-dncp">DNCP</xref>-based
protocol and includes a DNCP profile which defines transport and
synchronization details for sharing state across nodes defined in
<xref target="profile" />. The rest of the document defines behavior
of the services noted above, <xref target="tlvs">how the required
TLVs are encoded</xref>, as well as <xref target="nodereq">additional
requirements on how HNCP nodes should behave</xref>.</t>
<section title="Applicability">
<t>While HNCP does not deal with routing protocols directly (except
potentially informing them about internal and external interfaces
if classification specified in <xref target="bd" /> is used), in
homenet environments where multiple IPv6 source-prefixes can be
present, routing based on source and destination address is
necessary <xref target="RFC7368" />. Ideally, the routing protocol
is also zero-configuration (e.g., no need to configure identifiers or
metrics) although HNCP can be used also with a manually configured
routing protocol.</t>
<t>As HNCP uses DNCP as the actual state synchronization protocol,
the applicability statement of DNCP can be used here as well; HNCP
should not be used for any data that changes rapidly and
constantly, and locators to find such services should be published
using it instead. This is why the <xref target="naming-sd">naming
and service discovery</xref> TLVs contain only DNS server
addresses, and no actual per-name or per-service data of
hosts.</t>
<t>HNCP TLVs specified within this document, in steady state, stay
constant, with one exception: as <xref target="dp-tlv">Delegated
Prefix TLVs</xref> do contain lifetimes, they force re-publishing
of that data every time the valid or preferred lifetimes of
prefixes are updated (significantly). Therefore, it is desirable for
ISPs to provide large enough valid and preferred lifetimes to avoid
unnecessary HNCP state churn in homes, but even given
non-cooperating ISPs, the state churn is proportional only to the
number of externally received delegated prefixes and not the home
network size, and should therefore be relatively low.</t>
<t>HNCP assumes a certain level of control over host configuration
servers (e.g., <xref target="RFC2131">DHCP</xref>) on links that are
managed by its routers. Some HNCP functionality (such as border
discovery or some aspects of naming) might be affected by existing
DHCP servers not aware of the HNCP-managed network and thus might
need to be reconfigured to not result in unexpected behavior.</t>
<t>While HNCP is designed to be used by (home) routers, it can also
be used by advanced hosts that want to do, e.g., their own address
assignment and routing.</t>
<t>HNCP is link layer agnostic; if a link supports IPv6
(link-local) multicast and unicast, HNCP will work on it. Trickle
retransmissions and keep-alives will handle both packet loss and
non-transitive connectivity, ensuring eventual convergence.</t>
</section>
</section>
<section anchor="terminology" title="Terminology">
<t>The following terms are used as they are defined in <xref
target="I-D.ietf-homenet-prefix-assignment" />:
<list style="symbols">
<t>Advertised Prefix Priority</t>
<t>Advertised Prefix</t>
<t>Assigned Prefix</t>
<t>Delegated Prefix</t>
<t>Prefix Adoption</t>
<t>Private Link</t>
<t>Published Assigned Prefix</t>
<t>Applied Assigned Prefix</t>
<t>Shared Link</t>
</list>
</t>
<t>The following terms are used as they are defined in <xref
target="I-D.ietf-homenet-dncp" />:
<list style="symbols">
<t>DNCP profile</t>
<t>Node identifier</t>
<t>Link</t>
<t>Interface</t>
</list>
</t>
<texttable suppress-title="true" style="none" align="left">
<ttcol width="25%" /><ttcol width="75%" />
<c>(HNCP) node</c>
<c>A device implementing this specification.</c>
<c>(HNCP) router</c>
<c>A device implementing this specification, which forwards
traffic on behalf of other devices.</c>
<c>Border</c>
<c>separation point between administrative domains; in this case,
between the home network and any other network, i.e., usually an
ISP network.</c>
<c /><c />
<c>Internal link</c>
<c>a link that does not cross borders.</c>
<c>Internal interface</c>
<c>an interface that is connected to an internal link.</c>
<c /><c />
<c>External interface</c>
<c>an interface that is connected to a link which is not an
internal link.</c>
<c /><c />
<c>Interface category</c>
<c>a local configuration denoting the use of a particular interface.
The interface category determines how a HNCP node
should treat the particular interface.
External and internal category mark the interface as out of or within
the network border; there are also a number of sub-categories to
internal that further affect local node behavior.
See <xref target="if-cat" /> for a list of
interface categories and how they behave.
The internal or external categories may also be <xref target="bd">
auto-detected</xref>.
</c>
<c /><c />
<c>Border router</c>
<c>a router announcing external connectivity and
forwarding traffic across the network border.</c>
<c /><c />
<c>Common Link</c>
<c>a set of nodes on a link which share a common view of it, i.e.,
they see each other's traffic and the same set of hosts.
Unless configured otherwise transitive connectivity is assumed.</c>
<c /><c />
<c>DHCPv4</c>
<c>refers to <xref target="RFC2131">Dynamic Host Configuration
Protocol</xref> in this document.</c>
<c>DHCPv6</c>
<c>refers to <xref target="RFC3315">Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)</xref> in this document.</c>
<c>DHCP</c>
<c>refers to cases which apply to both DHCPv4 and DHCPv6 in this
document.</c>
<c /><c />
</texttable>
<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>
<section anchor="profile" title="DNCP Profile">
<t>The DNCP profile of HNCP is defined as follows:
<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-Nodes is the HNCP group address).
Received datagrams where either or both of the IPv6 source or
destination address is not link-local scoped MUST be
ignored. 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 nodes
MUST assign a locally unique non-zero 32-bit endpoint identifier to each
interface for which HNCP is enabled. The value zero
it is not used in DNCP TLVs, but it
has a special
meaning in HNCP TLVs (see <xref target="ap-tlv" /> and <xref
target="node-addr" />).
Implementations MAY use a value equivalent to the IPv6 link-local
scope identifier for the given interface.</t>
<t>HNCP uses opaque 32-bit node identifiers
(DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP SHOULD
use a random node identifier. If there is a node identifier collision
(as specified
in the Node State TLV handling of Section 4.4 of <xref
target="I-D.ietf-homenet-dncp" />), the node MUST immediately
generate and use a new random node identifier which is not used by
any other node at the time, based on the current DNCP network state.</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 per-endpoint 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 on virtually
lossless links works fine as it allows for one lost
keep-alive. If used on a lossy link, considerably higher
multiplier, such as 15, should be used instead. In that case,
an implementation might prefer shorter keep-alive intervals on
that link as well to ensure that DNCP_KEEPALIVE_INTERVAL *
DNCP_KEEPALIVE_MULTIPLIER timeout after which (entirely) lost
nodes time out is low enough.</t>
</list>
</t>
<t>HNCP nodes use the following Trickle parameters for
the per-interface Trickle instances:
<list style="symbols">
<t>k SHOULD be 1, as the timer reset when data is updated and
further retransmissions should handle packet loss. Even on a
non-transitive lossy link, the eventual per-endpoint keep-alives
should ensure status synchronization occurs.</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 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 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>
</list>
</t>
</section>
<section anchor="versioning" title="HNCP Versioning and Router Capabilities">
<t>Multiple versions of HNCP based on compatible DNCP profiles may be
present in the same network when transitioning between HNCP versions
and for troubleshooting purposes it might be beneficial to identify
the HNCP agent version running. Therefore each node MUST include an
<xref target="version">HNCP-Version TLV</xref> 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.</t>
<t>HNCP routers may also have different capabilities regarding
interactions with hosts, e.g., for configuration or service discovery.
These are indicated by M, P, H and L values. The combined
"capability value" is a metric indicated by interpreting the bits as
an integer, i.e., (M << 12 | P << 8 | H << 4 | L).
These values are used to elect certain servers on a Common Link,
as described in <xref target="client-config" />. Nodes that are not
routers MUST announce the value 0 for all capabilities. Any node
announcing the value 0 is considered to not advertise the respective
capability and thus does not take part in the respective election.</t>
</section>
<section anchor="if-class" title="Interface Classification">
<section anchor="if-cat" title="Interface Categories">
<t>
HNCP specifies the following categories interfaces can be configured
to be in:
<list style="hanging">
<t hangText="Internal category:"> This declares an interfaces
to be internal, i.e., within the borders of the HNCP network.
HNCP traffic MUST be sent and received. Routers
MUST forward traffic with appropriate source addresses between
their internal interfaces and allow internal traffic to reach
external networks. All nodes MUST implement this category and
nodes not implementing any other category implicitly use it
as a fixed default.</t>
<t hangText="External category:"> This declares an interface
to be external, i.e., not within the borders of the HNCP network.
HNCP traffic MUST neither be sent nor received. Accessing internal
resources from external interfaces is restricted, i.e., the use of
<xref target="RFC6092" /> is RECOMMENDED.
HNCP routers SHOULD announce acquired configuration information
for use in the network as described in <xref target="ec" />,
if the interface appears to be connected to an external network.
HNCP routers MUST implement this category.</t>
<t hangText="Leaf category:"> This declares an interface used by
client devices only. Such an interface uses the Internal category
with the exception that HNCP traffic MUST NOT be sent on the
interface, and all such traffic received on the interface MUST be
ignored. This category SHOULD be supported by HNCP routers.</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 filter traffic from and to
the interface 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 by
HNCP routers.</t>
<t hangText="Ad-hoc category:"> This configures an interface to use
the Internal category but no assumption is made about the the link's
transitivity. All other interface categories assume transitive
connectivity.
This affects the <xref target="links">Common Link</xref> definition.
Support for this category is OPTIONAL.</t>
<t hangText="Hybrid category:"> This declares an interface to use
the Internal category while still trying to acquire (external)
configuration information on it, e.g., by running DHCP
clients. This is useful, e.g., if the link is shared with a
non-HNCP router under control and still within the borders of 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>
</section>
<section title="DHCP Aided Auto-Detection">
<t>Auto-detection of interface categories is possible based on
interaction with <xref target="RFC2131">DHCPv4</xref> and <xref
target="RFC3633">DHCPv6-PD</xref> servers on connected links.
HNCP defines special DHCP behavior to differentiate its internal
servers from external ones in order to achieve this. Therefore
all internal devices (including HNCP nodes) running DHCP servers
on links where auto-detection is used by any HNCP node MUST use
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>The device MUST ignore or reject DHCP-Requests containing a
DHCP User-Class consisting of the ASCII-String "HOMENET".</t>
</list>
Not following this rule (e.g., running unmodified DHCP servers)
might lead to false positives when auto-detection is used, i.e.,
HNCP nodes assume an interface to not be internal, even though
it was intended to be.
</t>
</section>
<section anchor="bd" title="Algorithm for Border Discovery">
<t>This section defines the interface classification algorithm. It is
suitable for both IPv4 and IPv6 (single or dual-stack) and
detects the category of an interface either automatically
or based on a fixed configuration. By determining the category for all
interfaces, the network borders are implicitly defined, i.e., all
interfaces not belonging to the External category are considered to be
within the borders of the network, all others are not.</t>
<t>The following algorithm MUST be implemented by any node
implementing HNCP. However, if the node does not implement
auto-detection, only the first step is required.
The algorithm works as follows, with evaluation stopping at
first match:
<list style="numbers">
<t>If a fixed category is configured for an interface, it is
used.</t>
<t>If a delegated prefix could be acquired by running a DHCPv6
client, it is considered external. The DHCPv6 client MUST
have included a DHCPv6 User-Class consisting of the ASCII-String
"HOMENET" in all of its requests.</t>
<t>If an IPv4 address could be acquired by running a DHCPv4
client on the interface, it is considered external. The DHCPv4
client MUST have included a DHCP User-Class consisting of the
ASCII-String "HOMENET" in all of its requests.</t>
<t>The interface is considered internal.</t>
</list>
Note that as other HNCP nodes will ignore the client due to the
user class option, any server that replies is clearly external (or
a malicious internal node).</t>
<t>An HNCP router SHOULD allow setting the fixed category for each
interface which may be connected to either an internal or external
device (e.g., an Ethernet port that can be connected to a modem,
another HNCP router or a client).</t>
<t>An HNCP router using auto-detection on an interface MUST run the
appropriately configured DHCP clients as long as the interface without
a fixed category is active (including states where auto-detection
considers it to be internal) and rerun the algorithm above to react
to conditions resulting in a different interface category. 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.</t>
</section>
</section>
<section anchor="aaddr" title="Autonomous Address Configuration">
<t>This section specifies how HNCP nodes configure host and node
addresses. At first border routers share information obtained from
service providers or local configuration by publishing one or more
<xref target="ec-tlv">External Connection TLVs</xref>. These contain
other TLVs such as <xref target="dp-tlv">Delegated Prefix TLVs</xref>
which are then used for prefix assignment. Finally, HNCP nodes obtain
addresses either <xref target="node-addr">statelessly or using a
specific stateful mechanism</xref>. Hosts and non-HNCP routers are
configured using SLAAC, DHCP or DHCPv6-PD.</t>
<section title="Common Link" anchor="links">
<t>HNCP uses the concept of Common Link both in autonomic address
configuration and <xref target="naming-sd">naming and service
discovery</xref>.
A Common Link refers to the set of interfaces of nodes
that see each other's traffic and presumably also the traffic of all
hosts that may use the nodes to, e.g., forward traffic.
Common Links are used, e.g., to determine where prefixes should be
assigned or which peers participate in the election of a DHCP
server.
The Common Link is computed separately for each local internal
interface, and it always contains the local interface. Additionally,
if the local interface is not set to ad-hoc category (see <xref
target="if-cat" />), it also contains the set of interfaces that are
bidirectionally reachable from the given local interface, that is,
every remote interface of a remote node meeting all of the following
requirements:
<list style="symbols">
<t>The local node publishes a Peer TLV with:
<list style="symbols">
<t>Peer Node Identifier = remote node's node identifier</t>
<t>Peer 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 Peer TLV with:
<list style="symbols">
<t>Peer Node Identifier = local node's node identifier</t>
<t>Peer 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 internal
interfaces are connected, e.g., by detecting an identical remote
interface being part of the Common Links of both local
interfaces.</t>
</section>
<section anchor="ec" title="External Connections">
<t>Each HNCP router MAY obtain external connection information such
as address prefixes, DNS server addresses and DNS search paths from
one or more sources, e.g., <xref target="RFC3633">DHCPv6-PD</xref>,
<xref target="RFC6241">NETCONF</xref> or static configuration.
Each individual external connection to be shared in the network is
represented by one <xref target="ec-tlv">External
Connection TLV</xref>.</t>
<t>Announcements of individual external connections may consist
of the following components:
<list style="hanging">
<t hangText="Delegated Prefixes: ">address space available for
assignment to internal links announced using <xref
target="dp-tlv">Delegated Prefix TLVs</xref>. Some address
spaces might have special properties which are necessary to
understand in order to handle them (e.g., information similar
to <xref target="RFC6603" />). This information is encoded
using <xref target="dhcpv6-data">DHCPv6 Data TLVs</xref> inside
the respective Delegated Prefix TLVs.</t>
<t hangText="Auxiliary Information: ">information about services
such as DNS or time synchronization regularly used by hosts in
addition to addressing and routing information. This information
is encoded using <xref target="dhcpv6-data">DHCPv6 Data TLVs
</xref> and <xref target="dhcpv4-data">DHCPv4 Data TLVs</xref>.
</t>
</list>
</t>
<t>Whenever information about reserved parts (e.g., as specified
in <xref target="RFC6603" />) is received for a delegated prefix,
the reserved parts MUST be advertised using <xref target="ap-tlv">
Assigned Prefix TLVs</xref> with the highest priority (i.e., 15),
as if they were assigned to a Private Link.</t>
<t>Some connections or delegated 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 or to only selectively allow certain
devices to use them. Such prefixes are distinguished using
<xref target="pp-tlv">Prefix Policy 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 Policy TLVs with type 131, as
described in <xref target="assign"/></t>
<t>In presence of any type 1 to 128 Prefix Policy TLV the
prefix is specialized to reach destinations denoted by any
such Prefix Policy TLV, i.e., in absence of a type 0 Prefix
Policy TLV it is not usable for general internet connectivity.
An HNCP router MAY enforce this restriction with appropriate
packet filter rules.</t>
</list>
</t>
</section>
<section anchor="pa" title="Prefix Assignment">
<t>HNCP uses the <xref
target="I-D.ietf-homenet-prefix-assignment">Prefix Assignment
Algorithm</xref> in order to assign prefixes to HNCP internal links
and uses <xref target="terminology">some of the terminology</xref>
defined there. HNCP furthermore defines the <xref target="ap-tlv">
Assigned Prefix TLV</xref> which MUST be used to announce Published
Assigned Prefixes.</t>
<section title="Prefix Assignment Algorithm Parameters">
<t>All HNCP nodes running the prefix assignment algorithm
use the following values for its 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 interfaces with internal, leaf, guest or ad-hoc
category. It is dynamically updated as 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 nodes.</t>
<t hangText="Set of Advertised Prefixes: ">The set of prefixes
included in Assigned Prefix TLVs advertised by other HNCP nodes
(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 anchor="assign" title="Making New Assignments">
<t>Whenever the prefix assignment algorithm subroutine (Section
4.1 of <xref target="I-D.ietf-homenet-prefix-assignment" />) is
run on a Common Link and whenever a new prefix may be assigned
(case 1 of the subroutine: no Best Assignment and no Current
Assignment), the decision of whether the assignment of a new
prefix is desired MUST follow these rules in order:
<list style="hanging">
<t>If the Delegated Prefix TLV contains a DHCPv6
Data TLV, and the meaning of one of the DHCP options is not
understood by the HNCP node, 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-zero preferred lifetime, the
creation of a new prefix is not desired.</t>
<t>If the Delegated Prefix does not
include a Prefix Policy TLV indicating restrictive assignment
(type 131) or if local policy exists to identify it based on,
e.g., other Prefix Policy TLV values and allows
assignment, the
creation of a new prefix is desired.</t>
<t>Otherwise, the creation of a new prefix is not
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. 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, an HNCP router making an assignment
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 announce the L-capability and a router
assigning an IPv6 prefix with a length greater than 64 MUST
announce the H-capability as defined in
<xref target="versioning" />.</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 forward traffic destined to said prefix to the
respective link.</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 Prefix Delegation" anchor="pd">
<t>When an HNCP router announcing the <xref target="versioning">
P-Capability</xref> receives a DHCPv6-PD request from a client,
it SHOULD assign one
prefix per delegated prefix in the network. This set of
assigned prefixes is then delegated to the client,
after it has been applied as described in the prefix assignment
algorithm. Each DHCPv6-PD 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, however the prefix length to be delegated
MAY be smaller than 64.</t>
<t>The assigned prefixes MUST NOT be given to DHCPv6-PD 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 node SHOULD announce an IPv6 address and - if it supports
IPv4 - MUST announce an IPv4 address, whenever matching prefixes
are assigned to at least one of 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 Semantically Opaque Interface
Identifiers <xref target="RFC7217" /> SHOULD be used for address
assignment whenever possible (e.g., the prefix length is 64),
otherwise (e.g., for IPv4 if supported) the following method MUST
be used instead:
For any assigned prefix for which stateless assignment is not used,
the first quarter of the addresses
are reserved for HNCP based address assignments, whereas the last
three quarters are left to the DHCP elected router
(<xref target="versioning" /> specifies the DHCP server election
process).
For example, 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 nodes assign themselves addresses, and then (to ensure
eventual lack of conflicting assignments) publish the assignments
using the <xref target="node-address">Node Address TLV</xref>.</t>
<t>The process of obtaining addresses is specified as follows:
<list style="symbols">
<t>A node MUST NOT start advertising an address if it is
already advertised by another node.</t>
<t>An assigned address MUST be part 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 a ULA or private IPv4 prefix to enable
connectivity between local devices. These prefixes are inserted in
HNCP as if they were delegated prefixes of a (virtual) <xref target="ec">
external connection</xref>. 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
Policy 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 Policy of type 0 -
if there is any.
The router publishing a prefix with internet connectivity
MUST forward IPv4 traffic to the internet 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 others trying to do the same.</t>
<t>When a new ULA prefix is created, the prefix is selected based
on the configuration, using the last non-deprecated ULA prefix,
or generated based on <xref target="RFC4193"/>.</t>
</section>
</section>
<section title="Configuration of Hosts and non-HNCP Routers" anchor="client-config">
<t>HNCP routers need to ensure that hosts and non-HNCP downstream
routers on internal links are configured with addresses and routes.
Since DHCP clients can usually only bind to one server at a time, a per-link
and per-service election takes place.</t>
<t>HNCP routers may have different capabilities for configuring
downstream devices and providing naming services. Each router MUST
therefore indicate its capabilities as specified in <xref
target="versioning" /> in order to participate as a candidate in the
election.</t>
<section title="IPv6 Addressing and Configuration">
<t>In general <xref target="RFC4861">Stateless Address
Autoconfiguration</xref> is used for client configuration for its
low overhead and fast renumbering capabilities. Therefore each HNCP
router sends Router Advertisements on interfaces which are intended
to be used by clients and MUST at least include a Prefix Information
Option for each Applied Assigned Prefix which it assigned to the
respective link in every such advertisement. 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="versioning"
/>. The winner is the router (connected to the Common Link) advertising the greatest
H-capability.
In case of a tie, <xref target="versioning">Capability Values</xref>
are compared, and the 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.
</t>
<t>The elected router MUST serve stateful DHCPv6 and SHOULD provide
naming services for acquired hostnames as outlined in <xref
target="naming-sd" />, all others nodes MUST NOT. 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, e.g., by only handing out leases from locally-generated
(ULA) prefixes and prefixes with a length different from 64, and by
using low renew and rebind times (i.e., not longer than 5 minutes).
In case no router was elected, stateful DHCPv6 is not provided.
Routers which cease to be elected DHCP servers SHOULD - when
applicable - invalidate remaining existing bindings in order to
trigger client reconfiguration.</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="versioning" />.
The winner is the router (connected to the Common Link) advertising
the greatest P-capability.
In case of a tie, <xref target="versioning">Capability Values</xref>
are compared, and the 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.
</t>
<t>The elected router MUST provide <xref
target="RFC3633">prefix-delegation services</xref> on the given link
(and follow the rules in <xref target="pd" />), all other nodes
MUST NOT.</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="versioning" />.
The winner is the router (connected to the Common Link) advertising
the greatest L-capability.
In case of a tie, <xref target="versioning">Capability Values</xref>
are compared, and the 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.
</t>
<t>
The elected router MUST provide DHCPv4 services on the given link,
all other nodes MUST NOT. The elected router MUST provide IP
addresses from the pool defined in <xref target="node-addr" />
and MUST announce itself as <xref target="RFC2132">router</xref>
to clients.</t>
<t>DHCPv4 lifetimes renew and rebind times (T1 and T2) SHOULD be short
(i.e., not longer than 5 minutes) in order to provide reasonable
response times to changes. Routers which cease to be elected DHCP
servers SHOULD - when applicable - invalidate remaining existing
bindings in order to trigger client reconfiguration.</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="versioning" />.
The winner is the router (connected to the Common Link) advertising
the greatest M-capability. In case of a tie, <xref
target="versioning">Capability Values</xref> are
compared, and the 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.</t>
<t>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 advertise a recursive name
resolving server to clients which honors the
announcements made in <xref target="delegated-zone-tlv">Delegated Zone
TLVs</xref>, <xref target="domain-name-tlv">Domain Name TLVs</xref> and
<xref target="node-name-tlv">Node Name TLVs</xref>, i.e., delegate
queries to the designated name servers and hand out appropriate
A, AAAA and PTR records according to the mentioned TLVs.</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.
This announcement is done using <xref target="delegated-zone-tlv">
Delegated Zone TLVs</xref> and MUST be unique in the whole 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. HNCP routers providing
recursive name resolving services MUST use the included DNS server
address within the TLV to resolve names belonging to the zone as if
there was an NS record.</t>
<t>Each HNCP node SHOULD announce a node name for itself to be easily
reachable and MAY do so on behalf of other devices. Announcements are
made using <xref target="node-name-tlv">Node Name TLVs</xref> and
MUST be unique in the whole 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. HNCP routers providing recursive name resolving services as
described above MUST resolve such announced names to their respective
IP addresses as if there were corresponding A/AAAA records.</t>
<t>Names and unqualified zones are used in an HNCP network to provide
naming and service discovery with local significance. A network-wide
zone is appended to all single labels or unqualified zones in order
to qualify them. ".home" is the default, however an administrator MAY
configure announcing of a <xref target="domain-name-tlv">Domain Name
TLV </xref> for the network to use a different one. In case multiple
are announced, the domain of the node with the greatest node
identifier takes precedence.
</t>
</section>
<section title="Securing Third-Party Protocols" anchor="secure-3p">
<t>Pre-shared keys (PSKs) are often required to secure (for example)
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.
The scheme SHOULD be used only in conjunction with secured HNCP
unicast transport (=DTLS), as transferring the PSK in plain-text
anywhere in the network is a potential risk, especially as the
originator may not know about security (and use of DNCP security) on
all links.
The following rules define how such a PSK
is managed and used:
<list style="symbols">
<t>If no <xref target="managed-psk">Managed PSK TLV</xref> is
currently being announced, an HNCP node using this mechanism
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 nodes 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 node currently advertising the Managed PSK TLV must generate
and advertise a new random one whenever an unreachable node is
removed from the DNCP topology as described in the Section 4.6 of
<xref target="I-D.ietf-homenet-dncp" />.</t>
</list>
</t>
<t>PSKs for individual protocols SHOULD be derived from the random
PSK using a suitable one-way hashing algorithm (e.g., by using
<xref target="RFC6234">HMAC-SHA256</xref> with a per-protocol HMAC-key)
so that disclosure of any derived key does not impact other users of
the managed PSK. Furthermore derived PSKs MUST be updated whenever
the managed PSK changes.</t>
</section>
<section anchor="tlvs" title="Type-Length-Value Objects">
<t>HNCP defines the following TLVs in addition to those defined by
DNCP. The same general rules and defaults for encoding as noted in
Section 7 of <xref target="I-D.ietf-homenet-dncp" />
apply. Note that most HNCP variable-length TLVs also support
optional nested TLVs, and they are encoded after the variable
length content, followed by the zero padding of the variable length
content to the next 32-bit boundary. </t>
<t>TLVs defined here are only valid when appearing in their designated
context, i.e., only directly within container TLVs mentioned in their
definition, or - absent any mentions - only as top-level TLVs within
the node data set. TLVs appearing outside their designated context
MUST be ignored.</t>
<t>TLVs encoding IP addresses or prefixes allow encoding both IPv6
and IPv4 addresses and prefixes. IPv6 information is encoded as is,
whereas for IPv4 <xref target="RFC4291">IPv4-mapped IPv6 addresses
format</xref> is used and prefix lengths are encoded as original
IPv4 prefix length increased by 96.</t>
<section anchor="version" title="HNCP Version 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: HNCP-VERSION (32) | Length: >= 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | M | P | H | L |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-agent |
</artwork>
</figure>
<t>
This TLV is used to indicate the supported version and
router capabilities of an HNCP node as described in
<xref target="versioning" />.
<list style="hanging">
<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="External Connection TLV" anchor="ec-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: EXTERNAL-CONNECTION (33)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
</artwork>
</figure>
<t>An External Connection TLV is a container TLV used to
gather network configuration information associated with
a single <xref target="ec">external connection</xref> to
be shared across the HNCP network. A node MAY publish
an arbitrary number of instances of this TLV to share
the desired number of external connections. Upon reception,
the information transmitted in any nested TLVs is used for
the purposes of <xref target="pa">prefix assignment</xref>
and <xref target="client-config">host configuration</xref>.
</t>
<section anchor="dp-tlv" title="Delegated Prefix 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: DELEGATED-PREFIX (34) | Length: >= 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | |
+-+-+-+-+-+-+-+-+ Prefix +
...
| | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
</artwork>
</figure>
<t>
The Delegated Prefix TLV is used by HNCP routers to advertise
prefixes which are allocated to the whole network and can be used
for prefix assignment. Delegated Prefix TLVs are only valid
inside External Connection TLVs and their prefixes MUST NOT
overlap with those of other such TLVs in the same container.
<list style="hanging">
<t hangText="Valid Lifetime Since Origination: ">
The time in seconds the delegated prefix was valid for at the
origination time of the node data containing this TLV. The
value MUST be updated whenever the node republishes its Node
State TLV.</t>
<t hangText="Preferred Lifetime Since Origination: ">
The time in seconds the delegated prefix was preferred for at
the origination time of the node data containing this
TLV. The value MUST be updated whenever the node republishes
its Node State 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>
</list>
</t>
<section anchor="pp-tlv" title="Prefix Policy 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: PREFIX-POLICY (43) | Length: >= 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy Type | |
+-+-+-+-+-+-+-+-+ Value +
| |
</artwork>
</figure>
<t>
The Prefix Policy TLV contains information about the policy or
applicability of a delegated prefix. This information can be used
to determine whether prefixes for a certain usecase (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="ec"/> for a more in-depth discussion.
This TLV is only valid inside a Delegated Prefix TLV.
<list style="hanging">
<t hangText="Policy Type: ">The type of the policy identifier.
<list style="hanging">
<t hangText="0 :">Internet connectivity
(no Value).</t>
<t hangText="1-128 :">Explicit destination prefix with the
Policy 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 :">Restrictive Assignment (no Value).</t>
<t hangText="132-255:">Reserved for future additions.</t>
</list></t>
<t hangText="Value: ">A variable length identifier
of the given type.</t>
</list>
</t>
</section>
</section>
<section title="DHCPv6 Data TLV" anchor="dhcpv6-data">
<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>
<t>This TLV is used to encode auxiliary IPv6 configuration
information (e.g., recursive DNS servers) encoded as a stream of
DHCPv6 options. It is only valid in an External Connection TLV
or a Delegated Prefix TLV encoding an IPv6 prefix and MUST NOT
occur more than once in any single container. When included in
an External Connection TLV, it contains DHCPv6 options relevant
to the External Connection as a whole. When included in a Delegated
Prefix, it contains options mandatory to handle said prefix.
<list style="hanging">
<t hangText="DHCPv6 option stream: ">DHCPv6 options encoded as
specified in <xref target="RFC3315"/>.</t>
</list>
</t>
</section>
<section title="DHCPv4 Data TLV" anchor="dhcpv4-data">
<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>
<t>This TLV is used to encode auxiliary IPv4 configuration
information (e.g., recursive DNS servers) encoded as a stream of
DHCPv4 options. It is only valid in an External Connection TLV and
MUST NOT occur more than once in any single container. It contains
DHCPv4 options relevant to the External Connection as a whole.
<list style="hanging">
<t hangText="DHCPv4 option stream: ">DHCPv4 options encoded as
specified in <xref target="RFC2131"/>.</t>
</list>
</t>
</section>
</section>
<section anchor="ap-tlv" title="Assigned Prefix 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: ASSIGNED-PREFIX (35) | Length: >= 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsv. | Prty. | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +
...
| | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
</artwork>
</figure>
<t>
This TLV is used to announce Published Assigned Prefixes
for the purposes of <xref target="pa">prefix assignment</xref>.
<list style="hanging">
<t hangText="Endpoint Identifier: ">The endpoint identifier
of the local interface the prefix is assigned to, or 0 if it
is assigned to 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="node-address" title="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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
</artwork>
</figure>
<t>This TLV is used to announce addresses assigned to an HNCP
node as described in <xref target="node-addr" />.
<list style="hanging">
<t hangText="Endpoint Identifier: ">The endpoint identifier
of the local interface 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>
</section>
<section anchor="delegated-zone-tlv" title="DNS Delegated Zone TLV">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: DNS-DELEGATED-ZONE (39) | Length: >= 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserved |L|B|S| |
+-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) |
...
| | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
</artwork>
</figure>
<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. Details
are specified in <xref target="naming-sd" />.
<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">
<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>
This TLV is used to indicate the base domain name for the
network as specified in <xref target="naming-sd" />.
This TLV MUST NOT be announced unless the domain name was explicitly
configured by an administrator.
<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="node-name-tlv" title="Node Name TLV">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: NODE-NAME (41) | Length: > 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Name |
...
| (not null-terminated, variable length) | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
</artwork>
</figure>
<t>
This TLV is used to assign the name of a node in the network
to a certain IP address as specified in
<xref target="naming-sd" />.
<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="Length: ">The length of the name (0-63).</t>
<t hangText="Name: ">The name of the node as a single DNS label.</t>
</list>
</t>
</section>
<section anchor="managed-psk" title="Managed PSK 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: MANAGED-PSK (42) | Length: 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| Random 256-bit PSK |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
</artwork>
</figure>
<t>
This TLV is used to announce a PSK for securing third-party
protocols exclusively supporting symmetric cryptography as
specified in <xref target="secure-3p" />.
</t>
</section>
</section>
<section title="General Requirements for HNCP Nodes" anchor="nodereq">
<t>Each node implementing HNCP is subject to the following
requirements:
<list style="symbols">
<t>It MUST implement <xref
target="versioning">HNCP-Versioning</xref> and <xref
target="if-class">Interface Classification</xref>.</t>
<t>It MUST implement and run <xref target="secure-3p">the method
for securing third-party protocols</xref> whenever it uses the
security mechanism of HNCP.</t>
</list></t>
<t>If the node is acting as a router, then the following requirements
apply in addition:
<list style="symbols">
<t>It MUST support <xref target="aaddr">Autonomous Address
Configuration</xref> and <xref target="client-config">Configuration
of Hosts and non-HNCP Routers</xref>.</t>
<t>It SHOULD implement support for the <xref
target="naming-sd">Service Discovery and Naming</xref> as defined
in this document.</t>
<t>It MAY be able to provide connectivity to IPv4-devices using
DHCPv4.</t>
<t>It SHOULD be able to <xref target="pd">delegate prefixes to
legacy IPv6 routers using DHCPv6-PD</xref>.</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 generic requirements G-4 and G-5 are relaxed such that any
known default router on any interface is sufficient for a router
to announce itself as default router, similarly only the loss of
all such default routers results in self-invalidation.</t>
<t>The section "WAN-Side Configuration" applies to 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 interfaces
not classified as external.</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-9 is modified, in that the M flag MUST be set
if and only if a router connected to the respective Common Link is
advertising a non-zero H-capability. The O flag SHOULD always be
set.</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>
<t>The requirement L-13 to deprecate prefixes is applied to all
delegated prefixes in the network from which assignments have been
made on the respective interface. Furthermore the Prefix
Information Options indicating deprecation MUST be included in
Router Advertisements for the remainder of the prefixes'
respective valid lifetime, but MAY be omitted after at least
2 hours have passed.</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 nodes.</t>
</list>
</t>
<section title="Interface Classification">
<t>As described in <xref target="bd" />, an HNCP node determines
the internal or external state on a per-interface basis. A firewall
perimeter is set up for the external interfaces, and for internal
interfaces, HNCP traffic is allowed, with the exception of
leaf and guest sub-categories.</t>
<t>Threats concerning automatic interface classification 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 appropriate 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 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 should set up a registry for the (decimal values within range
0-1023) "HNCP TLV Types" under "Distributed Node
Consensus Protocol (DNCP)", with the following initial contents:
<list>
<t>0-31: Reserved - specified in the DNCP registry</t>
<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>
<t>43: Prefix-Policy</t>
<t>44-512: Free - policy of 'RFC required' should be used.</t>
<t>512-767: Reserved - specified in the DNCP registry</t>
<t>768-1023: Reserved - to be used for per-implementation
experimentation. How collision is avoided is out of scope of this
document.</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-Nodes.</t>
</section>
</middle>
<back>
<references title="Normative references">
<?rfc include="reference.I-D.draft-ietf-homenet-dncp-09"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.6347.xml"?>
<?rfc include="reference.RFC.6603.xml"?>
<?rfc include="reference.I-D.draft-ietf-homenet-prefix-assignment-08"?>
</references>
<references title="Informative references">
<?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.4193.xml"?>
<?rfc include="reference.RFC.7084.xml"?>
<?rfc include="reference.RFC.7217.xml"?>
<?rfc include="reference.RFC.4861.xml"?>
<?rfc include="reference.RFC.6092.xml"?>
</references>
<section title="Changelog [RFC Editor: please remove]">
<t>draft-ietf-homenet-hncp-09: Added nested TLV definitions for
variable length TLVs. NOTE: Node name TLV encoding includes now
length byte. Version TLV now itself indicates version.</t>
<t>draft-ietf-homenet-hncp-08: Editorial reorganization.</t>
<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, Juliusz
Chroboczek and Thomas Clausen 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-22 16:56:07 |