Homenet Working Group M. Stenberg
Internet-Draft
Intended status: Standards Track S. Barth
Expires: December 4, 2015
P. Pfister
Cisco Systems
June 2, 2015
Home Networking Control Protocol
draft-ietf-homenet-hncp-05
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 4, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Stenberg, et al. Expires December 4, 2015 [Page 1]
Internet-Draft Home Networking Control Protocol June 2015
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements language . . . . . . . . . . . . . . . . . . . . 3
3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Common Links . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Border Discovery . . . . . . . . . . . . . . . . . . . . . . 5
6. Autonomic Address Configuration . . . . . . . . . . . . . . . 6
6.1. External Connections . . . . . . . . . . . . . . . . . . 7
6.1.1. External Connection TLV . . . . . . . . . . . . . . . 7
6.1.2. Delegated Prefix TLV . . . . . . . . . . . . . . . . 7
6.1.3. Prefix Domain TLV . . . . . . . . . . . . . . . . . . 9
6.1.4. DHCP Data TLVs . . . . . . . . . . . . . . . . . . . 9
6.2. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 10
6.2.1. Assigned Prefix TLV . . . . . . . . . . . . . . . . . 10
6.2.2. Prefix Assignment Algorithm Parameters . . . . . . . 11
6.2.3. Making New Assignments . . . . . . . . . . . . . . . 12
6.2.4. Applying Assignments . . . . . . . . . . . . . . . . 13
6.2.5. DHCPv6-PD Excluded Prefix Support . . . . . . . . . . 13
6.2.6. Downstream Prefix Delegation Support . . . . . . . . 13
6.3. Node Address Assignment . . . . . . . . . . . . . . . . . 14
6.4. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 15
7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 16
7.1. DHCPv6 for Addressing or Configuration . . . . . . . . . 16
7.2. Sending Router Advertisements . . . . . . . . . . . . . . 17
7.3. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 18
7.4. DHCPv4 for Adressing and Configuration . . . . . . . . . 18
7.5. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 18
8. Naming and Service Discovery . . . . . . . . . . . . . . . . 18
8.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 19
8.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 20
8.3. Node Name TLV . . . . . . . . . . . . . . . . . . . . . . 20
9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 21
10. HNCP Versioning and Capabilities . . . . . . . . . . . . . . 22
11. Requirements for HNCP Routers . . . . . . . . . . . . . . . . 23
12. Security Considerations . . . . . . . . . . . . . . . . . . . 24
12.1. Border Determination . . . . . . . . . . . . . . . . . . 24
12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 25
12.3. Other Protocols in the Home . . . . . . . . . . . . . . 25
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.1. Normative references . . . . . . . . . . . . . . . . . . 26
14.2. Informative references . . . . . . . . . . . . . . . . . 27
Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 28
Stenberg, et al. Expires December 4, 2015 [Page 2]
Internet-Draft Home Networking Control Protocol June 2015
Appendix B. Draft source [RFC Editor: please remove] . . . . . . 29
Appendix C. Implementation [RFC Editor: please remove] . . . . . 29
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
HNCP synchronizes state across a small site in order to allow
automated network configuration. The protocol enables use of border
discovery, address prefix distribution
[I-D.ietf-homenet-prefix-assignment], naming and other services
across multiple links.
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 [RFC7368].
2. Requirements language
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 RFC 2119 [RFC2119].
3. DNCP Profile
HNCP is defined as a profile of DNCP [I-D.ietf-homenet-dncp] with the
following parameters:
o 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. Each node MUST be able to receive (and potentially
reassemble) UDP datagrams with a payload of at least 4000 bytes.
o HNCP operates on multicast-capable interfaces only, thus every
DNCP Endpoint Identifier MUST refer to one, except for the value 0
which is reserved for internal purposes and MUST NOT be used for
endpoint enumeration. Implementations MAY use a value equivalent
to the sin6_scope_id for the given interface.
o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] 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.
Stenberg, et al. Expires December 4, 2015 [Page 3]
Internet-Draft Home Networking Control Protocol June 2015
o 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.
o HNCP nodes MUST ignore all Node State TLVs received via multicast
on a link which has DNCP security enabled.
o HNCP nodes use the following Trickle parameters:
* k SHOULD be 1, given the timer reset on data updates and
retransmissions should handle packet loss.
* Imin SHOULD be 200 milliseconds but MUST NOT be lower. Note:
Earliest transmissions may occur at Imin / 2.
* Imax SHOULD be 7 doublings of Imin (i.e. 25.6 seconds) but MUST
NOT be lower.
o HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP
non-cryptographic hash function H(x).
o HNCP nodes MUST use the keep-alive extension on all endpoints.
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.
4. Common Links
HNCP uses the concept of Common Links for some of its applications.
This term is defined as follows:
If the endpoint of a node is detected or configured to be an ad-hoc
interface the Common Link only consists of said interface.
Otherwise the Common 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 Endpoint Identifier Y and the Local
Endpoint Identifier X and node B publishes a Neighbor TLV with the
Neighbor Node Identifier A, a Neighbor Endpoint Identifier X and the
Local Endpoint Identifier Y. In addition a node MUST be able to
detect whether two of its local interfaces belong to the same Common
Link either by local means or by inferring that from the
Stenberg, et al. Expires December 4, 2015 [Page 4]
Internet-Draft Home Networking Control Protocol June 2015
bidirectional reachability between two different local interfaces and
the same remote interface.
5. Border Discovery
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 Basic
Requirements for IPv6 Customer Edge Routers [RFC7084]. 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.
In order to avoid conflicts between border discovery and homenet
routers running DHCPv4 [RFC2131] or DHCPv6-PD [RFC3633] servers, each
router MUST implement the following mechanism based on The User Class
Option for DHCPv4 [RFC3004] and its DHCPv6 counterpart [RFC3315]:
o An HNCP router running a DHCP client on a homenet interface MUST
include a DHCP User-Class consisting of the ASCII-String
"HOMENET".
o 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".
The border discovery auto-detection algorithm works as follows, with
evaluation stopping at first match:
1. If a fixed category is configured for the interface, it MUST be
used.
2. If a delegated prefix could be acquired by running a DHCPv6
client on the interface, it MUST be considered external.
3. If an IPv4 address could be acquired by running a DHCPv4 client
on the interface it MUST be considered external.
4. Otherwise the interface MUST be considered internal.
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:
Stenberg, et al. Expires December 4, 2015 [Page 5]
Internet-Draft Home Networking Control Protocol June 2015
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 traffic on such interface. A router
SHOULD implement this category.
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.
Ad-hoc category: This configures an interface to be ad-hoc
(Section 4) and MAY be implemented.
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.
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.
6. Autonomic Address Configuration
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
Stenberg, et al. Expires December 4, 2015 [Page 6]
Internet-Draft Home Networking Control Protocol June 2015
a specific stateful mechanism and hosts and legacy routers are
configured using SLAAC or DHCP.
In all TLVs specified in this section which include a prefix, IPv4
prefixes are encoded using the IPv4-mapped IPv6 addresses format
[RFC4291]. The prefix length of such prefix is set to 96 plus the
IPv4 prefix length.
6.1. External Connections
Each HNCP router MAY obtain external connection information from one
or more sources, e.g. DHCPv6-PD [RFC3633], NETCONF [RFC6241] or
static configuration. This section specifies how such information is
encoded and advertised.
6.1.1. External Connection TLV
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.
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 |
The External Connection TLV is a container which:
o MAY contain zero, one or more Delegated Prefix TLVs.
o MUST NOT contain multiple Delegated Prefix TLVs with the same
prefix. In such a situation, the container MUST be ignored.
o 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.
o MAY contain other TLVs for future use.
6.1.2. Delegated Prefix TLV
The Delegated Prefix TLV is used by HNCP routers to advertise
prefixes which are allocated to the whole network and will be used
Stenberg, et al. Expires December 4, 2015 [Page 7]
Internet-Draft Home Networking Control Protocol June 2015
for prefix assignment. All Delegated Prefix TLVs MUST be nested in
an External Connection TLV.
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] +
| |
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.
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.
Prefix Length: The number of significant bits in the Prefix.
Prefix: Significant bits of the prefix padded with zeroes up to the
next byte boundary.
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.
Zero or more Prefix Domain TLVs. In abscence of any such TLV
the prefix is assumed to be generated by an HNCP-router and for
internal use only.
If the encoded prefix represents an IPv6 prefix, at most one
DHCPv6 Data TLV MAY be included.
If the encoded prefix represents an IPv4-mapped IPv6 address,
at most one DHCPv4 Data TLV MAY be included.
It MAY contain other TLVs for future use.
Stenberg, et al. Expires December 4, 2015 [Page 8]
Internet-Draft Home Networking Control Protocol June 2015
6.1.3. Prefix Domain TLV
The Prefix Domain TLV contains information about the origin and
applicability of a delegated prefix. This information can be used to
determine whether prefixes for a certain domain (e.g. local
reachability, internet connectivity) do exist or should be acquired
and to make decisions about assigning prefixes to certain links or
fine-tuning border firewalls.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: PREFIX-DOMAIN (43) | Length: >= 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Type | |
+-+-+-+-+-+-+-+-+ Domain ID +
| |
Domain Type: The type of the domain identifier.
0 : Internet connectivity (domain ID is empty)
1-128 : Explicit destination with given length (domain ID
contains significant bits of the destination prefix padded with
zeroes up to the next byte boundary.)
129 : Null-terminated UTF-8 String (e.g. FQDN)
130-255: reserved for future additions
Domain Identifier: A variable length identifier of the given type.
6.1.4. DHCP Data TLVs
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.
The DHCPv6 Data TLV uses the following format:
Stenberg, et al. Expires December 4, 2015 [Page 9]
Internet-Draft Home Networking Control Protocol June 2015
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 |
DHCPv6 option stream: DHCPv6 options encoded as specified in
[RFC3315].
The DHCPv4 Data TLV uses the following format:
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 |
DHCPv4 option stream: DHCPv4 options encoded as specified in
[RFC2131].
6.2. Prefix Assignment
HNCP uses the Distributed Prefix Assignment Algorithm specified in
[I-D.ietf-homenet-prefix-assignment] in order to assign prefixes to
HNCP internal links and uses the terminology defined there.
6.2.1. Assigned Prefix TLV
Published Assigned Prefixes MUST be advertised using the Assigned
Prefix TLV:
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 +
| |
Endpoint Identifier: The DNCP Endpoint Identifier of the link the
prefix is assigned to, or 0 if the link is a Private Link.
Stenberg, et al. Expires December 4, 2015 [Page 10]
Internet-Draft Home Networking Control Protocol June 2015
Rsv.: Bits reserved for future use. MUST be set to zero when
creating this TLV and ignored when parsing it.
Prty: The Advertised Prefix Priority from 0 to 15.
0-1 : Low priorities.
2 : Default priority.
3-7 : High priorities.
8-11 : Administrative priorities. MUST NOT be used unless
specified in the router's configuration.
12-14: Reserved for future use.
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 DHCPv6-PD Prefix Exclude Option [RFC6603]).
Prefix Length: The number of significant bits in the Prefix field.
Prefix: The significant bits of the prefix padded with zeroes up to
the next byte boundary.
6.2.2. Prefix Assignment Algorithm Parameters
All HNCP nodes running the prefix assignment algorithm MUST use the
following parameters:
Node IDs: DNCP Node Identifiers are used. The comparison operation
is defined as bit-wise comparison.
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.
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.
Set of Private Links: This document defines Private Links
representing DHCPv6-PD clients or as a mean to advertise prefixes
Stenberg, et al. Expires December 4, 2015 [Page 11]
Internet-Draft Home Networking Control Protocol June 2015
included in the DHCPv6 Exclude Prefix option. Other
implementation-specific Private Links may exist.
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:
* If the Link Identifier is zero, the Advertised Prefix is not
assigned on a Shared Link.
* If the Link Identifier is not zero the Shared Link is equal to
the Common Link (Section 4). 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.
ADOPT_MAX_DELAY: The default value is 0 seconds (i.e. prefix
adoption MAY be done instantly).
BACKOFF_MAX_DELAY: The default value is 4 seconds.
RANDOM_SET_SIZE: The default value is 64.
Flooding Delay: The default value is 5 seconds.
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.
6.2.3. Making New Assignments
Whenever the Prefix Assignment Algorithm routine is run on an Common
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:
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.
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.
Otherwise, the creation of a new prefix is desired.
Stenberg, et al. Expires December 4, 2015 [Page 12]
Internet-Draft Home Networking Control Protocol June 2015
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.
If the considered delegated prefix is an IPv4 prefix ( Section 6.4
details how IPv4 delegated prefixes are generated), a prefix of
length 24 SHOULD be preferred.
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 Section 10.
6.2.4. Applying Assignments
The prefix assignment algorithm indicates when a prefix is applied to
the respective Common Link. When that happens each router connected
to said link:
MUST create an appropriate on-link route for said prefix and
advertise it using the chosen routing protocol.
MUST participate in the client configuration election as described
in Section 7.
MAY add an address from said prefix to the respective network
interface as described in Section 6.3.
6.2.5. DHCPv6-PD Excluded Prefix Support
Whenever a DHCPv6 Prefix Exclude option [RFC6603] 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).
The same procedure MAY be applied in order to exclude prefixes
obtained by other means of configuration.
6.2.6. Downstream Prefix Delegation Support
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
Stenberg, et al. Expires December 4, 2015 [Page 13]
Internet-Draft Home Networking Control Protocol June 2015
MUST be considered as an independent Private Link and delegation MUST
be based on the same set of Delegated Prefixes.
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.
6.3. Node Address Assignment
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.
For any IPv6 prefix longer than 64 bits (resp. any IPv4 prefix)
assigned to a Common 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
(Section 10 specifies the DHCP server election process). For
instance, if the prefix 192.0.2.0/24 is assigned and applied to a
Common Link, addresses included in 192.0.2.0/26 are reserved for HNCP
nodes and the remaining addresses are reserved for the elected DHCPv4
server.
HNCP routers assign themselves addresses using the Node Address TLV:
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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Endpoint Identifier: The DNCP Endpoint Identifier of the link the
address is assigned to, or 0 if it is not assigned on an HNCP
enabled link.
Stenberg, et al. Expires December 4, 2015 [Page 14]
Internet-Draft Home Networking Control Protocol June 2015
IP Address: The globally scoped IPv6 address, or the IPv4 address
encoded as an IPv4-mapped IPv6 address [RFC4291].
The process of obtaining addresses is specified as follows:
o A router MUST NOT start advertising an address if it is already
advertised by another router.
o An assigned address MUST be in the first quarter of an assigned
prefix currently applied on the specified link.
o 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.
o 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.
6.4. Local IPv4 and ULA Prefixes
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:
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
generated by an HNCP router (i.e. not delegated by an external
entity) but MUST NOT do so otherwise. Whenever it detects another
non-deprecated IPv6 prefix generated by an HNCP router it MUST
cease to announce its own locally generated one.
An HNCP router MUST create a private IPv4 prefix [RFC1918]
whenever it wishes to provide IPv4 internet connectivity to the
network and no other private IPv4 prefix with internet
connectivity currently exists. It MAY also enable local IPv4
connectivity by creating a private IPv4 prefix if no IPv4 prefix
exists but MUST NOT do so otherwise. In case multiple IPv4
prefixes are announced all but one MUST be removed while those
with internet connectivity take precedence over those without and
announcements by nodes with a higher node identifier take
precedence over those with a lower one. The router publishing a
prefix with internet connectivity MUST announce an IPv4 default
route using the routing protocol and perform NAT on behalf of the
network as long as it publishes the prefix, other routers in the
Stenberg, et al. Expires December 4, 2015 [Page 15]
Internet-Draft Home Networking Control Protocol June 2015
network MAY choose not to. Internet Connectivity is indicated
using a Prefix Domain TLV.
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.
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 [RFC4193].
7. Configuration of Hosts and non-HNCP Routers
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.
HNCP routers may have different capabilities for configuring
downstream devices and providing naming services. Each router MUST
therefore indicate its capabilities as specified in Section 10 in
order to participate as a candidate in the election.
7.1. DHCPv6 for Addressing or Configuration
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.
The designated stateful DHCPv6 server for a link is elected based on
the capabilities described in Section 10. The winner is the router
connected to the Common Link (Section 4) 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 Section 8. 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 provide stateless DHCPv6
service.
Stenberg, et al. Expires December 4, 2015 [Page 16]
Internet-Draft Home Networking Control Protocol June 2015
7.2. Sending Router Advertisements
Each HNCP router assigning an IPV6-prefix to an interface 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:
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.
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.
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 [RFC7084].
A Route Information Option [RFC4191] 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.
A Recursive DNS Server Option and a DNS Search List Option MUST be
included with appropriate contents.
To allow for optimized routing decisions for clients on the local
link routers SHOULD adjust their Default Router Preference and
Route Preferences [RFC4191] 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.
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.
Stenberg, et al. Expires December 4, 2015 [Page 17]
Internet-Draft Home Networking Control Protocol June 2015
7.3. DHCPv6 for Prefix Delegation
The designated DHCPv6 server for prefix-delegation on a link is
elected based on the capabilities described in Section 10. The
winner is the router connected to the Common Link (Section 4)
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 prefix-delegation services
[RFC3633] on the given link and follow the rules in Section 6.2.6.
7.4. DHCPv4 for Adressing and Configuration
The designated DHCPv4 server on a link is elected based on the
capabilities described in Section 10. The winner is the router
connected to the Common Link (Section 4) 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.
The DHCPv4 serving router MUST announce itself as router [RFC2132] to
clients if and only if there is an IPv4 default route known in the
network. In addition the router SHOULD announce a Classless Static
Route Option [RFC3442] for each non-default IPv4 route advertised in
the routing protocol with an external destination.
DHCPv4 lease times SHOULD be short (i.e. not longer than 5 minutes)
in order to provide reasonable response times to changes.
7.5. Multicast DNS Proxy
The designated MDNS [RFC6762]-proxy on a link is elected based on the
capabilities described in Section 10. 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 Section 8.
8. Naming and Service Discovery
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.
Each HNCP router SHOULD provide and announce an auto-generated or
user-configured name for each internal Common Link (Section 4) for
which it is the designated DHCPv4, stateful DHCPv6 server or MDNS
[RFC6762]-proxy and for which it provides DNS-services on behalf of
Stenberg, et al. Expires December 4, 2015 [Page 18]
Internet-Draft Home Networking Control Protocol June 2015
devices on said link. In addition it MAY provide reverse lookup
services.
The following TLVs are defined and MUST be supported by all nodes
implementing naming and service discovery:
8.1. DNS Delegated Zone TLV
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.
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) |
| |
IP Address is the IPv6 address of the authoritative DNS server for
the zone; IPv4 addresses are represented as IPv4-mapped addresses
[RFC4291]. The special value of :: (all-zero) means the
delegation is available in the global DNS-hierarchy.
reserved bits MUST be zero when creating and ignored when parsing
this TLV.
L-bit (DNS-SD [RFC6763] 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.
B-bit (DNS-SD [RFC6763] 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.
Stenberg, et al. Expires December 4, 2015 [Page 19]
Internet-Draft Home Networking Control Protocol June 2015
S-bit (fully-qualified DNS-SD [RFC6763] -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.
Zone is the label sequence of the zone, encoded according to
[RFC1035]. Compression MUST NOT be used. The zone MUST end with
an empty label.
8.2. Domain Name TLV
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.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Domain is the label sequence encoded according to [RFC1035].
Compression MUST NOT be used. The zone MUST end with an empty
label.
8.3. Node Name TLV
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.
Stenberg, et al. Expires December 4, 2015 [Page 20]
Internet-Draft Home Networking Control Protocol June 2015
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9. Securing Third-Party Protocols
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:
o 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.
o 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.
o 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.
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 |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stenberg, et al. Expires December 4, 2015 [Page 21]
Internet-Draft Home Networking Control Protocol June 2015
PSKs for individual protocols are derived from the random PSK through
the use of HMAC-SHA256 [RFC6234] 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:
"ROUTING": to be used for IGPs
10. HNCP Versioning and Capabilities
Multiple versions of HNCP based on compatible DNCP
[I-D.ietf-homenet-dncp] profiles may be present in the same network
when transitioning between HNCP versions and HNCP routers may have
different capabilities to support clients. The following mechanism
describes a way to announce the currently active version and User-
agent of a node. Each node MUST include an HNCP-Version-TLV in its
Node Data and MUST ignore (except for DNCP synchronization purposes)
any TLVs with a type greater than 32 of nodes not publishing an HNCP-
Version TLV or publishing such a TLV with a different Version number.
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).
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 |
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.
Reserved: Bits reserved for future use. MUST be set to zero when
creating this TLV and ignored when parsing it.
M-capability: Priority value used for electing the on-link MDNS
[RFC6762] 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.
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 providing prefixes
Stenberg, et al. Expires December 4, 2015 [Page 22]
Internet-Draft Home Networking Control Protocol June 2015
through DHCPv6-PD (Section 6.2.6) and 0 otherwise. The values
8-15 are reserved for future use.
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.
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.
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.
11. Requirements for HNCP Routers
Each router implementing HNCP is subject to the following
requirements:
o It MUST implement HNCP-Versioning, Border Discovery, Prefix
Assignment and Configuration of hosts and non-HNCP routers as
defined in this document.
o It MUST implement and run the method for securing third-party
protocols whenever it uses the security mechanism of HNCP.
o It SHOULD implement support for the Service Discovery and Naming
TLVs as defined in this document.
o It MUST implement and run a routing protocol appropriate for the
given link type and with support for source-specific routes on all
of the interfaces it sends and receives HNCP traffic on and MUST
resort to announcing source-specific routes for external
destinations appropriately.
o 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.
o It MUST comply with the Basic Requirements for IPv6 Customer Edge
Routers [RFC7084] unless it would otherwise conflict with any
requirements in this document (e.g. prefix assignment mandating a
Stenberg, et al. Expires December 4, 2015 [Page 23]
Internet-Draft Home Networking Control Protocol June 2015
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.
o It SHOULD be able to provide connectivity to IPv4-devices using
DHCPv4.
o It SHOULD be able to delegate prefixes to legacy IPv6 routers
using DHCPv6-PD.
12. Security Considerations
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.
General security issues for existing home networks are discussed in
[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.
HNCP is a DNCP [I-D.ietf-homenet-dncp]-based state synchronization
mechanism carrying information with varying threat potential. For
this consideration the payloads defined in DNCP and this document are
reviewed:
o Network topology information such as HNCP nodes and their common
links
o Address assignment information such as delegated and assigned
prefixes for individual links
o Naming and service discovery information such as auto-generated or
customized names for individual links and routers
12.1. Border Determination
As described in Section 5, 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.
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
Stenberg, et al. Expires December 4, 2015 [Page 24]
Internet-Draft Home Networking Control Protocol June 2015
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.
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 [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.
12.2. Security of Unicast Traffic
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.
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.
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.
12.3. Other Protocols in the Home
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
Stenberg, et al. Expires December 4, 2015 [Page 25]
Internet-Draft Home Networking Control Protocol June 2015
security mechanism deployed by HNCP as homenet routing information is
thus usually not encrypted.
13. IANA Considerations
IANA is requested to maintain a registry for HNCP TLV-Types.
HNCP inherits the TLV-Types and allocation policy defined in DNCP
[I-D.ietf-homenet-dncp]. In addition the following TLV-Types are
defined in this document:
32: HNCP-Version
33: External-Connection
34: Delegated-Prefix
35: Assigned-Prefix
36: Node-Address
37: DHCPv4-Data
38: DHCPv6-Data
39: DNS-Delegated-Zone
40: Domain-Name
41: Node-Name
42: Managed-PSK
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.
14. References
14.1. Normative references
[I-D.ietf-homenet-dncp]
Stenberg, M. and S. Barth, "Distributed Node Consensus
Protocol", draft-ietf-homenet-dncp-04 (work in progress),
June 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Stenberg, et al. Expires December 4, 2015 [Page 26]
Internet-Draft Home Networking Control Protocol June 2015
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[I-D.ietf-homenet-prefix-assignment]
Pfister, P., Paterson, B., and J. Arkko, "Distributed
Prefix Assignment Algorithm", draft-ietf-homenet-prefix-
assignment-06 (work in progress), May 2015.
14.2. Informative references
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013.
[RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
A., Beser, B., and J. Privat, "The User Class Option for
DHCP", RFC 3004, November 2000.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Stenberg, et al. Expires December 4, 2015 [Page 27]
Internet-Draft Home Networking Control Protocol June 2015
[RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"IPv6 Home Networking Architecture Principles", RFC 7368,
October 2014.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless
Static Route Option for Dynamic Host Configuration
Protocol (DHCP) version 4", RFC 3442, December 2002.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
14.3. URIs
[3] http://www.openwrt.org
[4] http://www.homewrt.org/doku.php?id=run-conf
Appendix A. Changelog [RFC Editor: please remove]
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.
Stenberg, et al. Expires December 4, 2015 [Page 28]
Internet-Draft Home Networking Control Protocol June 2015
draft-ietf-homenet-hncp-04: Change the responsibility for sending RAs
to the router assigning the prefix.
draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP
(homenet profile).
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.
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.
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.
Appendix B. Draft source [RFC Editor: please remove]
This draft is available at https://github.com/fingon/ietf-drafts/ in
source format. Issues and pull requests are welcome.
Appendix C. Implementation [RFC Editor: please remove]
A GPLv2-licensed implementation of HNCP is currently under
development at https://github.com/sbyx/hnetd/ and binaries are
available in the OpenWrt [3] package repositories. See [4] for more
information. Feedback and contributions are welcome.
Appendix D. Acknowledgements
Thanks to Ole Troan, Mark Baugher, Mark Townsley and Juliusz
Chroboczek for their contributions to the draft.
Thanks to Eric Kline for the original border discovery work.
Authors' Addresses
Stenberg, et al. Expires December 4, 2015 [Page 29]
Internet-Draft Home Networking Control Protocol June 2015
Markus Stenberg
Helsinki 00930
Finland
Email: markus.stenberg@iki.fi
Steven Barth
Halle 06114
Germany
Email: cyrus@openwrt.org
Pierre Pfister
Cisco Systems
Paris
France
Email: pierre.pfister@darou.fr
Stenberg, et al. Expires December 4, 2015 [Page 30]
