draft-ietf-homenet-hncp-05.txt   draft-ietf-homenet-hncp-06.txt 
Homenet Working Group M. Stenberg Homenet Working Group M. Stenberg
Internet-Draft Internet-Draft
Intended status: Standards Track S. Barth Intended status: Standards Track S. Barth
Expires: December 4, 2015 Expires: December 19, 2015
P. Pfister P. Pfister
Cisco Systems Cisco Systems
June 2, 2015 June 17, 2015
Home Networking Control Protocol Home Networking Control Protocol
draft-ietf-homenet-hncp-05 draft-ietf-homenet-hncp-06
Abstract Abstract
This document describes the Home Networking Control Protocol (HNCP), This document describes the Home Networking Control Protocol (HNCP),
an extensible configuration protocol and a set of requirements for an extensible configuration protocol and a set of requirements for
home network devices on top of the Distributed Node Consensus home network devices on top of the Distributed Node Consensus
Protocol (DNCP). It enables automated configuration of addresses, Protocol (DNCP). It enables automated configuration of addresses,
naming, network borders and the seamless use of a routing protocol. naming, network borders and the seamless use of a routing protocol.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 4, 2015. This Internet-Draft will expire on December 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3
3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Common Links . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Common Links . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Border Discovery . . . . . . . . . . . . . . . . . . . . . . 5 5. Border Discovery . . . . . . . . . . . . . . . . . . . . . . 5
6. Autonomic Address Configuration . . . . . . . . . . . . . . . 6 6. Autonomic Address Configuration . . . . . . . . . . . . . . . 7
6.1. External Connections . . . . . . . . . . . . . . . . . . 7 6.1. External Connections . . . . . . . . . . . . . . . . . . 7
6.1.1. External Connection TLV . . . . . . . . . . . . . . . 7 6.1.1. External Connection TLV . . . . . . . . . . . . . . . 7
6.1.2. Delegated Prefix TLV . . . . . . . . . . . . . . . . 7 6.1.2. Delegated Prefix TLV . . . . . . . . . . . . . . . . 8
6.1.3. Prefix Domain TLV . . . . . . . . . . . . . . . . . . 9 6.1.3. Prefix Domain TLV . . . . . . . . . . . . . . . . . . 9
6.1.4. DHCP Data TLVs . . . . . . . . . . . . . . . . . . . 9 6.1.4. DHCP Data TLVs . . . . . . . . . . . . . . . . . . . 10
6.2. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 10 6.2. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 11
6.2.1. Assigned Prefix TLV . . . . . . . . . . . . . . . . . 10 6.2.1. Prefix Assignment Algorithm Parameters . . . . . . . 11
6.2.2. Prefix Assignment Algorithm Parameters . . . . . . . 11 6.2.2. Assigned Prefix TLV . . . . . . . . . . . . . . . . . 12
6.2.3. Making New Assignments . . . . . . . . . . . . . . . 12 6.2.3. Making New Assignments . . . . . . . . . . . . . . . 13
6.2.4. Applying Assignments . . . . . . . . . . . . . . . . 13 6.2.4. Applying Assignments . . . . . . . . . . . . . . . . 14
6.2.5. DHCPv6-PD Excluded Prefix Support . . . . . . . . . . 13 6.2.5. DHCPv6-PD Excluded Prefix Support . . . . . . . . . . 14
6.2.6. Downstream Prefix Delegation Support . . . . . . . . 13 6.2.6. Downstream Prefix Delegation Support . . . . . . . . 14
6.3. Node Address Assignment . . . . . . . . . . . . . . . . . 14 6.3. Node Address Assignment . . . . . . . . . . . . . . . . . 15
6.4. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 15 6.4. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 16
7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 16 7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 17
7.1. DHCPv6 for Addressing or Configuration . . . . . . . . . 16 7.1. DHCPv6 for Addressing or Configuration . . . . . . . . . 17
7.2. Sending Router Advertisements . . . . . . . . . . . . . . 17 7.2. Sending Router Advertisements . . . . . . . . . . . . . . 17
7.3. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 18 7.3. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 18
7.4. DHCPv4 for Adressing and Configuration . . . . . . . . . 18 7.4. DHCPv4 for Addressing and Configuration . . . . . . . . . 18
7.5. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 18 7.5. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 19
8. Naming and Service Discovery . . . . . . . . . . . . . . . . 18 8. Naming and Service Discovery . . . . . . . . . . . . . . . . 19
8.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 19 8.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 19
8.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 20 8.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 21
8.3. Node Name TLV . . . . . . . . . . . . . . . . . . . . . . 20 8.3. Node Name TLV . . . . . . . . . . . . . . . . . . . . . . 21
9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 21 9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 22
10. HNCP Versioning and Capabilities . . . . . . . . . . . . . . 22 10. HNCP Versioning and Capabilities . . . . . . . . . . . . . . 22
11. Requirements for HNCP Routers . . . . . . . . . . . . . . . . 23 11. Requirements for HNCP Routers . . . . . . . . . . . . . . . . 24
12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12.1. Border Determination . . . . . . . . . . . . . . . . . . 24 12.1. Border Determination . . . . . . . . . . . . . . . . . . 25
12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 25 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 26
12.3. Other Protocols in the Home . . . . . . . . . . . . . . 25 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 26
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Normative references . . . . . . . . . . . . . . . . . . 26 14.1. Normative references . . . . . . . . . . . . . . . . . . 27
14.2. Informative references . . . . . . . . . . . . . . . . . 27 14.2. Informative references . . . . . . . . . . . . . . . . . 28
Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 28 Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 29
Appendix B. Draft source [RFC Editor: please remove] . . . . . . 29 Appendix B. Draft source [RFC Editor: please remove] . . . . . . 30
Appendix C. Implementation [RFC Editor: please remove] . . . . . 29 Appendix C. Implementation [RFC Editor: please remove] . . . . . 30
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 29 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
HNCP synchronizes state across a small site in order to allow HNCP synchronizes state across a small site in order to allow
automated network configuration. The protocol enables use of border automated network configuration. The protocol enables use of border
discovery, address prefix distribution discovery, address prefix distribution
[I-D.ietf-homenet-prefix-assignment], naming and other services [I-D.ietf-homenet-prefix-assignment], naming and other services
across multiple links. across multiple links.
HNCP provides enough information for a routing protocol to operate HNCP provides enough information for a routing protocol to operate
skipping to change at page 3, line 34 skipping to change at page 3, line 34
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. DNCP Profile 3. DNCP Profile
HNCP is defined as a profile of DNCP [I-D.ietf-homenet-dncp] with the HNCP is defined as a profile of DNCP [I-D.ietf-homenet-dncp] with the
following parameters: following parameters:
o HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport over o HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport over
link-local scoped IPv6, using unicast and multicast (group All- link-local scoped IPv6, using unicast and multicast (All-Homenet-
Homenet-Routers). Received datagrams with an IPv6 source or Routers is the HNCP group address). Received datagrams with an
destination address which is not link-local scoped MUST be IPv6 source or destination address which is not link-local scoped
ignored. Each node MUST be able to receive (and potentially MUST be ignored. Each node MUST be able to receive (and
reassemble) UDP datagrams with a payload of at least 4000 bytes. potentially reassemble) UDP datagrams with a payload of at least
4000 bytes.
o HNCP operates on multicast-capable interfaces only, thus every o HNCP operates on multicast-capable interfaces only. HNCP routers
DNCP Endpoint Identifier MUST refer to one, except for the value 0 MUST assign a unique 32-bit endpoint identifier to each interface
which is reserved for internal purposes and MUST NOT be used for for which HNCP is enabled. The value zero is reserved for
endpoint enumeration. Implementations MAY use a value equivalent internal purposes. Implementations MAY use a value equivalent to
to the sin6_scope_id for the given interface. the sin6_scope_id for the given interface.
o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as
described in DNCP if exchanged over unsecured links. UDP on port described in DNCP if exchanged over unsecured links. UDP on port
HNCP-DTLS-PORT is used for this purpose. A node implementing the HNCP-DTLS-PORT is used for this purpose. A node implementing HNCP
security mechanism MUST support the DNCP Pre-Shared Key method, security MUST support the DNCP Pre-Shared Key method, SHOULD
SHOULD support the DNCP Certificate Based Trust Consensus and MAY support the DNCP Certificate Based Trust Consensus and MAY support
support the PKI-based trust method. the PKI-based trust method.
o HNCP uses opaque 32-bit node identifiers o HNCP uses opaque 32-bit node identifiers
(DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP (DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP
SHOULD generate and use a random node identifier. If it receives SHOULD generate and use a random node identifier. If using a
a Node State TLV with the same node identifier and a higher update random node identifier and there is a node identifier collision,
sequence number, it MUST immediately generate and use a new random the node MUST immediately generate and use a new random node
node identifier which is not used by any other node. identifier which is not used by any other node.
o HNCP nodes MUST ignore all Node State TLVs received via multicast o HNCP nodes MUST ignore all Node State TLVs received via multicast
on a link which has DNCP security enabled. on a link which has DNCP security enabled in order to prevent
spoofing of node state changes.
o HNCP nodes use the following Trickle parameters: o HNCP nodes use the following Trickle parameters:
* k SHOULD be 1, given the timer reset on data updates and * k SHOULD be 1, as the timer reset when data is updated and
retransmissions should handle packet loss. further retransmissions should handle packet loss.
* Imin SHOULD be 200 milliseconds but MUST NOT be lower. Note: * Imin SHOULD be 200 milliseconds but MUST NOT be lower. Note:
Earliest transmissions may occur at Imin / 2. Earliest transmissions may occur at Imin / 2.
* Imax SHOULD be 7 doublings of Imin (i.e. 25.6 seconds) but MUST * Imax SHOULD be 7 doublings of Imin (i.e. 25.6 seconds) but MUST
NOT be lower. NOT be lower.
o HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP o HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP
non-cryptographic hash function H(x). non-cryptographic hash function H(x).
o HNCP nodes MUST use the keep-alive extension on all endpoints. o HNCP nodes MUST use DNCP's keep-alive extension on all endpoints
The default keep-alive interval (DNCP_KEEPALIVE_INTERVAL) is 20 with the following parameters:
seconds, the multiplier (DNCP_KEEPALIVE_MULTIPLIER) MUST be 2.1,
the grace-interval (DNCP_GRACE_INTERVAL) SHOULD be equal to * The default keep-alive interval (DNCP_KEEPALIVE_INTERVAL) is 20
DNCP_KEEPALIVE_MULTIPLIER times DNCP_KEEPALIVE_INTERVAL. 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 4. Common Links
HNCP uses the concept of Common Links for some of its applications. HNCP uses the concept of Common Links for some of its applications.
This term is defined as follows: The Common Link is computed separately for each local interface, and
it always contains the local interface. Additionally, if the local
interface is not in ad-hoc mode, it also contains the set of
interfaces that are bidirectionally reachable from the given local
interface, i.e. every remote interface of a remote node meeting all
of the following requirements:
If the endpoint of a node is detected or configured to be an ad-hoc o The local node publishes a Neighbor TLV with:
interface the Common Link only consists of said interface.
Otherwise the Common Link contains all interfaces bidirectionally * Neighbor Node Identifier = remote node's node identifier
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
bidirectional reachability between two different local interfaces and
the same remote interface.
5. Border Discovery * Neighbor Endpoint Identifier = remote interface's endpoint
identifier
HNCP associates each HNCP interface with a category (e.g., internal * Endpoint Identifier = local interface's endpoint identifier
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 o The remote node publishes a Neighbor TLV with:
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 * Neighbor Node Identifier = local node's node identifier
include a DHCP User-Class consisting of the ASCII-String
"HOMENET".
o An HNCP router running a DHCP server on a homenet interface MUST * Neighbor Endpoint Identifier = local interface's endpoint
ignore or reject DHCP-Requests containing a DHCP User-Class identifier
consisting of the ASCII-String "HOMENET".
* Endpoint Identifier = remote interface's endpoint identifier
A node MUST be able to detect whether two of its local interfaces are
connected, e.g. by detecting an identical remote interface being part
of the Common Links of both local interfaces.
5. Border Discovery
HNCP router's interfaces are either internal, external or of a
different category derived from the internal one. This section
defines the border discovery algorithm. It is suitable for both IPv4
and IPv6 (single or dual-stack) and determines whether an HNCP
interface is internal, external, or uses another fixed category. The
algorithm is derived from the edge router interactions described in
the Basic Requirements for IPv6 Customer Edge Routers [RFC7084].
This algorithm MUST be implemented by any router implementing HNCP.
The border discovery auto-detection algorithm works as follows, with The border discovery auto-detection algorithm works as follows, with
evaluation stopping at first match: evaluation stopping at first match:
1. If a fixed category is configured for the interface, it MUST be 1. If a fixed category is configured for the interface, it MUST be
used. used.
2. If a delegated prefix could be acquired by running a DHCPv6 2. If a delegated prefix could be acquired by running a DHCPv6
client on the interface, it MUST be considered external. client on the interface, it MUST be considered external.
3. If an IPv4 address could be acquired by running a DHCPv4 client 3. If an IPv4 address could be acquired by running a DHCPv4 client
on the interface it MUST be considered external. on the interface it MUST be considered external.
4. Otherwise the interface MUST be considered internal. 4. Otherwise the interface MUST be considered internal.
In order to avoid conflicts between border discovery and HNCP 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 an HNCP interface MUST
include a DHCP User-Class consisting of the ASCII-String
"HOMENET".
o An HNCP router running a DHCP server on an HNCP interface MUST
ignore or reject DHCP-Requests containing a DHCP User-Class
consisting of the ASCII-String "HOMENET".
A router MUST allow setting a category of either auto-detected, A router MUST allow setting a category of either auto-detected,
internal or external for each interface which is suitable for both internal or external for each interface which is suitable for both
internal and external connections. In addition the following internal and external connections. In addition the following
specializations of the internal category are defined to modify the specializations of the internal category are defined to modify the
local router behavior: local router behavior:
Leaf category: This declares an interface used by client devices Leaf category: This declares an interface used by client devices
only. A router MUST consider such interface as internal but MUST only. Such an interface acts as an internal interface with the
NOT send nor receive HNCP traffic on such interface. A router exception that HNCP or routing protocol traffic MUST NOT be sent
SHOULD implement this category. on the interface, and all such traffic received on the interface
MUST be ignored. This category SHOULD be supported.
Guest category: This declares an interface used by untrusted client Guest category: This declares an interface used by untrusted client
devices only. In addition to the restrictions of the Leaf devices only. In addition to the restrictions of the Leaf
category, connected devices MUST NOT be able to reach other category, HNCP routers MUST enable firewalling rules such that
devices inside the HNCP network nor query services advertised by connected devices are unable to reach other devices inside the
them unless explicitly allowed, instead they SHOULD only be able HNCP network or query services advertised by them unless
to reach the internet. This category SHOULD be supported. explicitly allowed. This category SHOULD be supported.
Ad-hoc category: This configures an interface to be ad-hoc Ad-hoc category: This configures an interface to be ad-hoc
(Section 4) and MAY be implemented. (Section 4). Ad-hoc interfaces are considered internal but no
assumption is made on the the link transitivity properties.
Support for this category is OPTIONAL.
Hybrid category: This declares an interface to be internal while Hybrid category: This declares an interface to be internal while
still using external connections on it. It is assumed that the still running DHCPv4 and DHCPv6-PD clients on it. It is assumed
link is under control of a legacy, trustworthy non-HNCP router, that the link is under control of a legacy, trustworthy non-HNCP
still within the same network. Detection of this category router, still within the same network. Detection of this category
automatically in addition to manual configuration is out of scope automatically in addition to manual configuration is out of scope
for this document. This category MAY be implemented. of this document. Support for this category is OPTIONAL.
Each router MUST continuously scan each active interface that does Each router MUST continuously scan each active interface that does
not have a fixed category in order to dynamically reclassify it if not have a fixed category in order to dynamically reclassify it if
necessary. The router therefore runs an appropriately configured necessary. The router therefore runs an appropriately configured
DHCPv4 and DHCPv6 client as long as the interface is active including DHCPv4 and DHCPv6 client as long as the interface is active including
states where it considers the interface to be internal. The router states where it considers the interface to be internal. The router
SHOULD wait for a reasonable time period (5 seconds as a default), SHOULD wait for a reasonable time period (5 seconds as a default),
during which the DHCP clients can acquire a lease, before treating a during which the DHCP clients can acquire a lease, before treating a
newly activated or previously external interface as internal. Once newly activated or previously external interface as internal. Once
it treats a certain interface as internal it MUST start forwarding it treats a certain interface as internal it MUST start forwarding
skipping to change at page 7, line 9 skipping to change at page 7, line 31
addresses. At first border routers share information obtained from addresses. At first border routers share information obtained from
service providers or local configuration by publishing one or more service providers or local configuration by publishing one or more
External Connection TLVs. These contain other TLVs such as Delegated External Connection TLVs. These contain other TLVs such as Delegated
Prefix TLVs which are then used for prefix assignment. Finally, HNCP Prefix TLVs which are then used for prefix assignment. Finally, HNCP
routers obtain addresses using a stateless (SLAAC-like) procedure or routers obtain addresses using a stateless (SLAAC-like) procedure or
a specific stateful mechanism and hosts and legacy routers are a specific stateful mechanism and hosts and legacy routers are
configured using SLAAC or DHCP. configured using SLAAC or DHCP.
In all TLVs specified in this section which include a prefix, IPv4 In all TLVs specified in this section which include a prefix, IPv4
prefixes are encoded using the IPv4-mapped IPv6 addresses format prefixes are encoded using the IPv4-mapped IPv6 addresses format
[RFC4291]. The prefix length of such prefix is set to 96 plus the [RFC4291]. The prefix length of such IPv4 prefix is set to 96 plus
IPv4 prefix length. the IPv4 prefix length.
6.1. External Connections 6.1. External Connections
Each HNCP router MAY obtain external connection information from one Each HNCP router MAY obtain external connection information from one
or more sources, e.g. DHCPv6-PD [RFC3633], NETCONF [RFC6241] or or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or
static configuration. This section specifies how such information is static configuration. This section specifies how such information is
encoded and advertised. encoded and advertised.
6.1.1. External Connection TLV 6.1.1. External Connection TLV
An External Connection TLV is a container-TLV used to gather network An External Connection TLV is a container-TLV used to gather network
configuration information associated with a single external configuration information associated with a single external
connection. A node MAY publish zero, one or more instances of this connection. A node MAY publish an arbitrary number of instances of
TLV. this TLV.
0 1 2 3 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 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 | | Type: EXTERNAL-CONNECTION (33)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested TLVs | | Nested TLVs |
The External Connection TLV is a container which: The External Connection TLV is a container which:
o MAY contain zero, one or more Delegated Prefix TLVs. o MAY contain an arbitrary number of Delegated Prefix TLVs.
o MUST NOT contain multiple Delegated Prefix TLVs with the same o MUST NOT contain multiple Delegated Prefix TLVs with identical or
prefix. In such a situation, the container MUST be ignored. overlapping prefixes. In such a situation, the External
Connection TLV MUST be ignored.
o MAY contain at most one DHCPv6 Data TLV and at most one DHCPv4 o MAY contain at most one DHCPv6 Data TLV and at most one DHCPv4
Data TLV encoding options associated with the External Connection Data TLV encoding options associated with the External Connection
but MUST NOT contain more than one of each otherwise the whole but MUST NOT contain more than one of each otherwise the External
External Connection TLV MUST be ignored. Connection TLV MUST be ignored.
o MAY contain other TLVs for future use. o MAY contain other TLVs for future use. Such additional TLVs MUST
be ignored.
6.1.2. Delegated Prefix TLV 6.1.2. Delegated Prefix TLV
The Delegated Prefix TLV is used by HNCP routers to advertise The Delegated Prefix TLV is used by HNCP routers to advertise
prefixes which are allocated to the whole network and will be used prefixes which are allocated to the whole network and will be used
for prefix assignment. All Delegated Prefix TLVs MUST be nested in for prefix assignment. Any Delegated Prefix TLV MUST be nested in an
an External Connection TLV. External Connection TLV.
0 1 2 3 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 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 | | Type: DELEGATED-PREFIX (34) | Length: >= 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime | | Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime | | Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 36 skipping to change at page 9, line 16
preferred. The value is relative to the point in time the Node- preferred. The value is relative to the point in time the Node-
Data TLV was last published. It MUST be updated whenever the node Data TLV was last published. It MUST be updated whenever the node
republishes its Node-Data TLV. republishes its Node-Data TLV.
Prefix Length: The number of significant bits in the Prefix. Prefix Length: The number of significant bits in the Prefix.
Prefix: Significant bits of the prefix padded with zeroes up to the Prefix: Significant bits of the prefix padded with zeroes up to the
next byte boundary. next byte boundary.
Nested TLVs: Other TLVs included in the Delegated Prefix TLV and Nested TLVs: Other TLVs included in the Delegated Prefix TLV and
starting at the next 32 bits boundary following the end of the starting at the next 32-bit boundary following the end of the
encoded prefix. encoded prefix:
Zero or more Prefix Domain TLVs. In abscence of any such TLV * Zero or more Prefix Domain TLVs. In absence of any such TLV
the prefix is assumed to be generated by an HNCP-router and for the prefix is assumed to be generated by an HNCP-router and for
internal use only. internal use only.
If the encoded prefix represents an IPv6 prefix, at most one * If the encoded prefix represents an IPv6 prefix, at most one
DHCPv6 Data TLV MAY be included. DHCPv6 Data TLV MAY be included, and any included DHCPv4 Data
TLV MUST be ignored.
If the encoded prefix represents an IPv4-mapped IPv6 address, * If the prefix represents an IPv4 prefix (encoded as an
at most one DHCPv4 Data TLV MAY be included. IPv4-mapped IPv6 prefix), at most one DHCPv4 Data TLV MAY be
included, and any included DHCPv6 Data TLV MUST be ignored.
It MAY contain other TLVs for future use. * It MAY contain other TLVs for future use. Such additional TLVs
MUST be ignored.
6.1.3. Prefix Domain TLV 6.1.3. Prefix Domain TLV
The Prefix Domain TLV contains information about the origin and The Prefix Domain TLV contains information about the origin and
applicability of a delegated prefix. This information can be used to applicability of a delegated prefix. This information can be used to
determine whether prefixes for a certain domain (e.g. local determine whether prefixes for a certain domain (e.g. local
reachability, internet connectivity) do exist or should be acquired reachability, internet connectivity) do exist or should be acquired
and to make decisions about assigning prefixes to certain links or and to make decisions about assigning prefixes to certain links or to
fine-tuning border firewalls. fine-tune border firewalls.
0 1 2 3 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 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 | | Type: PREFIX-DOMAIN (43) | Length: >= 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Type | | | Domain Type | |
+-+-+-+-+-+-+-+-+ Domain ID + +-+-+-+-+-+-+-+-+ Domain ID +
| | | |
Domain Type: The type of the domain identifier. Domain Type: The type of the domain identifier.
0 : Internet connectivity (domain ID is empty) 0 : Internet connectivity (domain ID is empty).
1-128 : Explicit destination with given length (domain ID 1-128 : Explicit destination prefix with the Domain Type being
contains significant bits of the destination prefix padded with the actual length of the prefix (Domain ID contains significant
zeroes up to the next byte boundary.) bits of the destination prefix padded with zeroes up to the
next byte boundary).
129 : Null-terminated UTF-8 String (e.g. FQDN) 129 : UTF-8 String (e.g. FQDN).
130-255: reserved for future additions 130-255: Reserved for future additions.
Domain Identifier: A variable length identifier of the given type. Domain Identifier: A variable length identifier of the given type.
6.1.4. DHCP Data TLVs 6.1.4. DHCP Data TLVs
Auxiliary connectivity information is encoded as a stream of DHCP Auxiliary connectivity information is encoded as a stream of DHCP
options. Such TLVs MUST only be present in an External Connection options. Such TLVs MUST only be present in an External Connection
TLV or a Delegated Prefix TLV. When included in an External TLV or a Delegated Prefix TLV. When included in an External
Connection TLV, they MUST contain DHCP options which are relevant to Connection TLV, they MUST contain DHCP options which are relevant to
the whole External Connection. When included in a Delegated Prefix, the whole External Connection. When included in a Delegated Prefix,
skipping to change at page 10, line 33 skipping to change at page 11, line 11
DHCPv4 option stream: DHCPv4 options encoded as specified in DHCPv4 option stream: DHCPv4 options encoded as specified in
[RFC2131]. [RFC2131].
6.2. Prefix Assignment 6.2. Prefix Assignment
HNCP uses the Distributed Prefix Assignment Algorithm specified in HNCP uses the Distributed Prefix Assignment Algorithm specified in
[I-D.ietf-homenet-prefix-assignment] in order to assign prefixes to [I-D.ietf-homenet-prefix-assignment] in order to assign prefixes to
HNCP internal links and uses the terminology defined there. HNCP internal links and uses the terminology defined there.
6.2.1. Assigned Prefix TLV 6.2.1. Prefix Assignment Algorithm Parameters
All HNCP nodes running the prefix assignment algorithm MUST use the
following parameters:
Node IDs: HNCP 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 Common Links associated with
internal, leaf, guest or ad-hoc interfaces. It is dynamically
updated as HNCP interfaces are added, removed, or switch from one
category to another. When multiple interfaces are detected as
belonging to the same Common Link, prefix assignment is disabled
on all of these interfaces except one.
Set of Private Links: This document defines Private Links
representing DHCPv6-PD clients or as a mean to advertise prefixes
included in the DHCPv6 Exclude Prefix option. Other
implementation-specific Private Links may be defined whenever a
prefix needs to be assigned for a purpose that does not require a
consensus with other HNCP routers.
Set of Advertised Prefixes: The set of prefixes included in
Assigned Prefix TLVs advertised by other HNCP routers (Prefixes
advertised by the local node are not in this set). The associated
Advertised Prefix Priority is the priority specified in the TLV.
The associated Shared Link is determined as follows:
* If the Link Identifier is zero, the Advertised Prefix is not
assigned on a Shared Link.
* 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.
* Otherwise, the Advertised Prefix is not assigned on a Shared
Link.
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.
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.2. Assigned Prefix TLV
Published Assigned Prefixes MUST be advertised using the Assigned Published Assigned Prefixes MUST be advertised using the Assigned
Prefix TLV: Prefix TLV:
0 1 2 3 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 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 | | Type: ASSIGNED-PREFIX (35) | Length: >= 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier | | Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsv. | Prty. | Prefix Length | | | Rsv. | Prty. | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +
| | | |
Endpoint Identifier: The DNCP Endpoint Identifier of the link the Endpoint Identifier: The endpoint identifier of the local interface
prefix is assigned to, or 0 if the link is a Private Link. that belongs to the Common Link the prefix is assigned to, or 0 if
the Common Link is a Private Link (e.g., when the prefix is
assigned for downstream prefix delegation).
Rsv.: Bits reserved for future use. MUST be set to zero when Rsv.: Bits are reserved for future use. They MUST be set to zero
creating this TLV and ignored when parsing it. when creating this TLV, and their value MUST be ignored when
processing the TLV.
Prty: The Advertised Prefix Priority from 0 to 15. Prty: The Advertised Prefix Priority from 0 to 15.
0-1 : Low priorities. 0-1 : Low priorities.
2 : Default priority. 2 : Default priority.
3-7 : High priorities. 3-7 : High priorities.
8-11 : Administrative priorities. MUST NOT be used unless 8-11 : Administrative priorities. MUST NOT be used unless
specified in the router's configuration. configured otherwise.
12-14: Reserved for future use. 12-14: Reserved for future use.
15 : Provider priorities. MAY only be used by the router 15 : Provider priorities. MAY only be used by the router
advertising the corresponding delegated prefix and based on advertising the corresponding delegated prefix and based on
static or dynamic configuration (e.g., for excluding a prefix static or dynamic configuration (e.g., for excluding a prefix
based on DHCPv6-PD Prefix Exclude Option [RFC6603]). based on DHCPv6-PD Prefix Exclude Option [RFC6603]).
Prefix Length: The number of significant bits in the Prefix field. Prefix Length: The number of significant bits in the Prefix field.
Prefix: The significant bits of the prefix padded with zeroes up to Prefix: The significant bits of the prefix padded with zeroes up to
the next byte boundary. 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
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 6.2.3. Making New Assignments
Whenever the Prefix Assignment Algorithm routine is run on an Common Whenever the Prefix Assignment Algorithm subroutine is run on a
Link and whenever a new prefix may be assigned (case 1 of the 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 subroutine), the decision of whether the assignment of a new prefix
desired MUST follow these rules: is desired MUST follow these rules:
If the Delegated Prefix TLV contains a DHCPv4 or DHCPv6 Data TLV, 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 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. the HNCP router, the creation of a new prefix is not desired.
If the remaining preferred lifetime of the prefix is 0 and there If the remaining preferred lifetime of the prefix is 0 and there
is another delegated prefix of the same IP version used for prefix is another delegated prefix of the same IP version used for prefix
assignment with a non-null preferred lifetime, the creation of a assignment with a non-null preferred lifetime, the creation of a
new prefix is not desired. new prefix is not desired.
Otherwise, the creation of a new prefix is desired. Otherwise, the creation of a new prefix is desired.
If the considered delegated prefix is an IPv6 prefix, and whenever If the considered delegated prefix is an IPv6 prefix, and whenever
there is at least one available prefix of length 64, a prefix of there is at least one available prefix of length 64, a prefix of
length 64 MUST be selected unless configured otherwise by an length 64 MUST be selected unless configured otherwise by an
administrator. In case no prefix of length 64 would be available, a administrator. In case no prefix of length 64 would be available, a
longer prefix MAY be selected. longer prefix MAY be selected.
If the considered delegated prefix is an IPv4 prefix ( Section 6.4 If the considered delegated prefix is an IPv4 prefix (Section 6.4
details how IPv4 delegated prefixes are generated), a prefix of details how IPv4 delegated prefixes are generated), a prefix of
length 24 SHOULD be preferred. length 24 SHOULD be preferred.
In any case, a router MUST support a mechanism suitable to distribute In any case, a router MUST support a mechanism suitable to distribute
addresses from the considered prefix to clients on the link. addresses from the considered prefix to clients on the link.
Otherwise it MUST NOT create or adopt it, i.e. a router assigning an 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 IPv4 prefix MUST support the L-capability and a router assigning an
IPv6 prefix not suitable for stateless autoconfiguration MUST support IPv6 prefix not suitable for Stateless Address Autoconfiguration MUST
the H-capability as defined in Section 10. support the H-capability as defined in Section 10.
6.2.4. Applying Assignments 6.2.4. Applying Assignments
The prefix assignment algorithm indicates when a prefix is applied to The prefix assignment algorithm indicates when a prefix is applied to
the respective Common Link. When that happens each router connected the respective Common Link. When that happens each router connected
to said link: to said link:
MUST create an appropriate on-link route for said prefix and MUST create an appropriate on-link route for said prefix and
advertise it using the chosen routing protocol. advertise it using the chosen routing protocol.
skipping to change at page 14, line 5 skipping to change at page 14, line 43
The same procedure MAY be applied in order to exclude prefixes The same procedure MAY be applied in order to exclude prefixes
obtained by other means of configuration. obtained by other means of configuration.
6.2.6. Downstream Prefix Delegation Support 6.2.6. Downstream Prefix Delegation Support
When an HNCP router receives a request for prefix delegation, it When an HNCP router receives a request for prefix delegation, it
SHOULD assign one prefix per delegated prefix, wait for them to be SHOULD assign one prefix per delegated prefix, wait for them to be
applied, and delegate them to the client. Such assignment MUST be applied, and delegate them to the client. Such assignment MUST be
done in accordance with the Prefix Assignment Algorithm. Each client done in accordance with the Prefix Assignment Algorithm. Each client
MUST be considered as an independent Private Link and delegation MUST MUST be considered as an independent Private Link and delegation MUST
be based on the same set of Delegated Prefixes. be based on the same set of Delegated Prefixes as the one used for
Common Links prefixes assignment.
The assigned prefixes MUST NOT be given to clients before they are The assigned prefixes MUST NOT be given to clients before they are
applied, and MUST be withdrawn whenever they are destroyed. As an applied, and MUST be withdrawn whenever they are destroyed. As an
exception to this rule a router MAY prematurely give out a prefix exception to this rule, in order to shorten delays of processed
which is advertised but not yet applied if it does so with a valid requests, a router MAY prematurely give out a prefix which is
lifetime of not more than 30 seconds and ensures removal or advertised but not yet applied if it does so with a valid lifetime of
correction of lifetimes as soon as possible to shorten delays of not more than 30 seconds and ensures removal or correction of
processed requests. lifetimes as soon as possible.
6.3. Node Address Assignment 6.3. Node Address Assignment
This section specifies how HNCP nodes reserve addresses for their own This section specifies how HNCP nodes reserve addresses for their own
use. Nodes MAY, at any time, try to reserve a new address. SLAAC use. Nodes MAY, at any time, try to reserve a new address from any
SHOULD be used whenever possible. The following method MUST be used applied Assigned Prefix. SLAAC SHOULD be used whenever possible.
otherwise. The following method MUST be used otherwise.
For any IPv6 prefix longer than 64 bits (resp. any IPv4 prefix) For any IPv6 prefix for which SLAAC cannot be used (resp. any IPv4
assigned to a Common Link, the first quarter of the addresses are prefix) assigned to a Common Link, the first quarter of the addresses
reserved for routers HNCP based assignments, whereas the last three are reserved for routers HNCP based address assignments, whereas the
quarters are left to the DHCPv6 (resp. DHCPv4) elected router last three quarters are left to the DHCPv6 (resp. DHCPv4) elected
(Section 10 specifies the DHCP server election process). For 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 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 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 nodes and the remaining addresses are reserved for the elected DHCPv4
server. server.
HNCP routers assign themselves addresses using the Node Address TLV: HNCP routers assign themselves addresses using the Node Address TLV:
0 1 2 3 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 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 | | Type: NODE-ADDRESS (36) | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier | | Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IP Address | | IP Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Endpoint Identifier: The DNCP Endpoint Identifier of the link the Endpoint Identifier: The endpoint identifier of the local interface
address is assigned to, or 0 if it is not assigned on an HNCP that belongs to the Common Link the prefix is assigned to, or 0 if
enabled link. it is not assigned on an HNCP enabled link.
IP Address: The globally scoped IPv6 address, or the IPv4 address IP Address: The globally scoped IPv6 address, or the IPv4 address
encoded as an IPv4-mapped IPv6 address [RFC4291]. encoded as an IPv4-mapped IPv6 address [RFC4291].
The process of obtaining addresses is specified as follows: The process of obtaining addresses is specified as follows:
o A router MUST NOT start advertising an address if it is already o A router MUST NOT start advertising an address if it is already
advertised by another router. advertised by another router.
o An assigned address MUST be in the first quarter of an assigned o An assigned address MUST be in the first quarter of an assigned
prefix currently applied on the specified link. prefix currently applied on a Common Link which includes the
interface specified by the endpoint identifier.
o An address MUST NOT be used unless it has been advertised for at o An address MUST NOT be used unless it has been advertised for at
least ADDRESS_APPLY_DELAY consecutive seconds, and is still least ADDRESS_APPLY_DELAY consecutive seconds, and is still
currently being advertised. The default value for currently being advertised. The default value for
ADDRESS_APPLY_DELAY is 3 seconds. ADDRESS_APPLY_DELAY is 3 seconds.
o Whenever the same address is advertised by more than one node all o Whenever the same address is advertised by more than one node, all
but the one advertised by the node with the highest node but the one advertised by the node with the highest node
identifier MUST be removed. identifier MUST be removed.
6.4. Local IPv4 and ULA Prefixes 6.4. Local IPv4 and ULA Prefixes
HNCP routers can create an ULA or private IPv4 prefix to enable HNCP routers can create an ULA or private IPv4 prefix to enable
connectivity between local devices. These prefixes are inserted in connectivity between local devices. These prefixes are inserted in
HNCP as if they were delegated prefixes. The following rules apply: HNCP as if they were delegated prefixes. The following rules apply:
An HNCP router SHOULD create an ULA prefix if there is no other An HNCP router SHOULD create a ULA prefix if there is no other
non-deprecated IPv6 prefix in the network. It MAY also do so if non-deprecated IPv6 prefix in the network. It MAY also do so if
there are other delegated IPv6 prefixes but none of which is there are other delegated IPv6 prefixes but none of which is
generated by an HNCP router (i.e. not delegated by an external generated by an HNCP router (i.e., none of which is specified in a
entity) but MUST NOT do so otherwise. Whenever it detects another Delegated Prefix TLV which also includes a Prefix Domain TLV) but
non-deprecated IPv6 prefix generated by an HNCP router it MUST MUST NOT do so otherwise. Whenever it detects another non-
cease to announce its own locally generated one. deprecated IPv6 prefix generated by an HNCP router with a greater
HNCP identifier, it MUST cease to announce its own locally
generated one.
An HNCP router MUST create a private IPv4 prefix [RFC1918] An HNCP router MUST create a private IPv4 prefix [RFC1918]
whenever it wishes to provide IPv4 internet connectivity to the whenever it wishes to provide IPv4 internet connectivity to the
network and no other private IPv4 prefix with internet network and no other private IPv4 prefix with internet
connectivity currently exists. It MAY also enable local IPv4 connectivity currently exists. It MAY also enable local IPv4
connectivity by creating a private IPv4 prefix if no IPv4 prefix connectivity by creating a private IPv4 prefix if no IPv4 prefix
exists but MUST NOT do so otherwise. In case multiple IPv4 exists but MUST NOT do so otherwise. In case multiple IPv4
prefixes are announced all but one MUST be removed while those prefixes are announced all but one MUST be removed while those
with internet connectivity take precedence over those without and associated with a Prefix Domain TLV of type 0 take precedence over
announcements by nodes with a higher node identifier take those without and, in case of a tie, announcements by nodes with a
precedence over those with a lower one. The router publishing a greater node identifier take precedence over those with a lower
prefix with internet connectivity MUST announce an IPv4 default one. The router publishing a prefix with internet connectivity
route using the routing protocol and perform NAT on behalf of the MUST announce an IPv4 default route using the routing protocol and
network as long as it publishes the prefix, other routers in the perform NAT on behalf of the network as long as it publishes the
network MAY choose not to. Internet Connectivity is indicated prefix, other routers in the network MAY choose not to. Internet
using a Prefix Domain TLV. Connectivity is indicated using a Prefix Domain TLV.
Creation of such ULA and IPv4 prefixes MUST be delayed by a random 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 timespan between 0 and 10 seconds in which the router MUST scan for
other nodes trying to do the same. other nodes trying to do the same.
When a new ULA prefix is created, the prefix is selected based on the When a new ULA prefix is created, the prefix is selected based on the
configuration, using the last non-deprecated ULA prefix, or generated configuration, using the last non-deprecated ULA prefix, or generated
based on [RFC4193]. based on [RFC4193].
7. Configuration of Hosts and non-HNCP Routers 7. Configuration of Hosts and non-HNCP Routers
HNCP routers need to ensure that hosts and non-HNCP downstream HNCP routers need to ensure that hosts and non-HNCP downstream
routers on internal links are configured with addresses and routes. routers on internal links are configured with addresses and routes.
Since DHCP-clients can usually only bind to one server at a time an Since DHCP-clients can usually only bind to one server at a time, a
election takes place. per-link and per-service election takes place.
HNCP routers may have different capabilities for configuring HNCP routers may have different capabilities for configuring
downstream devices and providing naming services. Each router MUST downstream devices and providing naming services. Each router MUST
therefore indicate its capabilities as specified in Section 10 in therefore indicate its capabilities as specified in Section 10 in
order to participate as a candidate in the election. order to participate as a candidate in the election.
7.1. DHCPv6 for Addressing or Configuration 7.1. DHCPv6 for Addressing or Configuration
In general stateless address configuration is preferred whenever In general Stateless Address Autoconfiguration is used for client
possible since it enables fast renumbering and low overhead, however configuration for its low overhead and fast renumbering capabilities,
stateful DHCPv6 can be useful in addition to collect hostnames and however stateful DHCPv6 can be used in addition by administrative
use them to provide naming services or if stateless configuration is choice, to e.g. collect hostnames and use them to provide naming
not possible for the assigned prefix length. services or whenever stateless configuration is not applicable.
The designated stateful DHCPv6 server for a link is elected based on The designated stateful DHCPv6 server for a Common Link (Section 4)
the capabilities described in Section 10. The winner is the router is elected based on the capabilities described in Section 10. The
connected to the Common Link (Section 4) advertising the greatest winner is the router (connected to the Common Link) advertising the
H-capability. In case of a tie, Capability Values and node greatest H-capability. In case of a tie, Capability Values and node
identifiers are considered (greatest value is elected). The elected identifiers are considered (greatest value is elected). The elected
router MUST serve stateful DHCPv6 and Router Advertisements on the router MUST serve stateful DHCPv6 and MUST provide naming services
given link. Furthermore it MUST provide naming services for acquired for acquired hostnames as outlined in Section 8. Stateful addresses
hostnames as outlined in Section 8. Stateful addresses being handed SHOULD be assigned in a way not hindering fast renumbering even if
out SHOULD have a low preferred lifetime (e.g. 1s) to not hinder fast the DHCPv6 server or client do not support the DHCPv6 reconfigure
renumbering if either the DHCPv6 server or client do not support the mechanism. In case no router was elected, stateful DHCPv6 is not
DHCPv6 reconfigure mechanism and the address is from a prefix for provided and each router assigning IPv6-prefixes on said link MUST
which stateless autoconfiguration is supported as well. In case no provide stateless DHCPv6 service.
router was elected, stateful DHCPv6 is not provided and each router
assigning IPv6-prefixes on said link MUST provide stateless DHCPv6
service.
7.2. Sending Router Advertisements 7.2. Sending Router Advertisements
Each HNCP router assigning an IPV6-prefix to an interface MUST send All HNCP routers MUST send Router Advertisements periodically via
Router Advertisements periodically via multicast and via unicast in multicast and via unicast in response to Router Solicitations.
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 o The "Managed address configuration" flag MUST be set whenever a
router connected to the link is advertising a non-null router connected to the link is advertising a non-null
H-capability and MUST NOT be set otherwise. The "Other H-capability and MUST NOT be set otherwise. The "Other
configuration" flag MUST always be set. configuration" flag MUST always be set.
The default Router Lifetime MUST be set to an appropriate non-null o The default Router Lifetime MUST be set to an appropriate non-null
value whenever an IPv6 default route is known in the HNCP network value whenever an IPv6 default route is known in the HNCP network
and MUST be set to zero otherwise. and MUST be set to zero otherwise.
A Prefix Information Option MUST be added for each assigned and o A Prefix Information Option MUST be added for each assigned and
applied IPv6 prefix on the given link. The autonomous address- applied IPv6 prefix on the given link. The autonomous address-
configuration flag MUST be set whenever the prefix is suitable for configuration flag MUST be set whenever the prefix is suitable for
stateless configuration. The preferred and valid lifetimes MUST stateless configuration. The preferred and valid lifetimes MUST
be smaller than the preferred and valid lifetimes of the delegated be smaller than the preferred and valid lifetimes of the delegated
prefix the prefix is from. When a prefix is removed, it MUST be prefix the prefix is from. When a prefix is removed, it MUST be
deprecated as specified in [RFC7084]. deprecated as specified in [RFC7084].
A Route Information Option [RFC4191] MUST be added for each o A Route Information Option [RFC4191] MUST be added for each
delegated IPv6 prefix known in the HNCP network. Additional ones delegated IPv6 prefix known in the HNCP network. Additional ones
SHOULD be added for each non-default IPv6 route with an external SHOULD be added for each non-default IPv6 route with an external
destination advertised by the routing protocol. destination prefix advertised by the routing protocol.
A Recursive DNS Server Option and a DNS Search List Option MUST be o A Recursive DNS Server Option and a DNS Search List Option MUST be
included with appropriate contents. included with appropriate contents.
To allow for optimized routing decisions for clients on the local o To allow for optimized routing decisions for clients on the local
link routers SHOULD adjust their Default Router Preference and link routers SHOULD adjust their Default Router Preference and
Route Preferences [RFC4191] so that the priority is set to low if 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 the next hop of the default or more specific route is on the same
interface as the Route Advertisement being sent on. Similarly the interface as the Route Advertisement being sent on. Similarly the
router MAY use the high priority if it is certain it has the best 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 metric of all routers on the link for all routes known in the
network with the respective destination. network with the respective destination.
Every router sending Router Advertisements MUST immediately send an Every router sending Router Advertisements MUST immediately send an
updated Router Advertisement via multicast as soon as it notices a updated Router Advertisement via multicast as soon as it notices a
condition resulting in a change of any advertised information. condition resulting in a change of any advertised information.
7.3. DHCPv6 for Prefix Delegation 7.3. DHCPv6 for Prefix Delegation
The designated DHCPv6 server for prefix-delegation on a link is The designated DHCPv6 server for prefix-delegation on a Common Link
elected based on the capabilities described in Section 10. The is elected based on the capabilities described in Section 10. The
winner is the router connected to the Common Link (Section 4) winner is the router (connected to the Common Link) advertising the
advertising the greatest P-capability. In case of a tie, Capability greatest P-capability. In case of a tie, Capability Values are
Values and Node Identifiers are considered (greatest value is compared, and router with the greatest value is elected. In case of
elected). The elected router MUST provide prefix-delegation services another tie, the router with the highest node identifier is elected
[RFC3633] on the given link and follow the rules in Section 6.2.6. among the routers with tied Capability Values. 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 7.4. DHCPv4 for Addressing and Configuration
The designated DHCPv4 server on a link is elected based on the The designated DHCPv4 server on a Common Link (Section 4) is elected
capabilities described in Section 10. The winner is the router based on the capabilities described in Section 10. The winner is the
connected to the Common Link (Section 4) advertising the greatest router (connected to the Common Link) advertising the greatest
L-capability. In case of a tie, Capability Values and node L-capability. In case of a tie, Capability Values are compared, and
identifiers are considered (greatest value is elected). The elected router with the greatest value is elected. In case of another tie,
router MUST provide DHCPv4 services on the given link. the router with the highest node identifier is elected among the
routers with tied Capability Values. The elected router MUST provide
DHCPv4 services on the given link.
The DHCPv4 serving router MUST announce itself as router [RFC2132] to 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 clients if and only if there is an IPv4 default route known in the
network. In addition the router SHOULD announce a Classless Static network. In addition, the router SHOULD announce a Classless Static
Route Option [RFC3442] for each non-default IPv4 route advertised in Route Option [RFC3442] for each non-default IPv4 route advertised in
the routing protocol with an external destination. the routing protocol with an external destination.
DHCPv4 lease times SHOULD be short (i.e. not longer than 5 minutes) DHCPv4 lease times SHOULD be short (i.e. not longer than 5 minutes)
in order to provide reasonable response times to changes. in order to provide reasonable response times to changes.
7.5. Multicast DNS Proxy 7.5. Multicast DNS Proxy
The designated MDNS [RFC6762]-proxy on a link is elected based on the The designated MDNS [RFC6762] proxy on a Common Link is elected based
capabilities described in Section 10. The winner is the router with on the capabilities described in Section 10. The winner is the
the highest Node Identifier among those with the highest Capability router (connected to the Common Link) advertising the greatest
Value on the link that support the M-capability. The elected router M-capability. In case of a tie, Capability Values are compared, and
MUST provide an MDNS-proxy on the given link and announce it as router with the greatest value is elected. In case of another tie,
described in Section 8. the router with the highest node identifier is elected among the
routers with tied Capability Values. The elected router MUST provide
an MDNS-proxy on the given link and announce it as described in
Section 8.
8. Naming and Service Discovery 8. Naming and Service Discovery
Network-wide naming and service discovery can greatly improve the Network-wide naming and service discovery can greatly improve the
user-friendliness of an IPv6 network. The following mechanism user-friendliness of an IPv6 network. The following mechanism
provides means to setup and delegate naming and service discovery provides means to setup and delegate naming and service discovery
across multiple HNCP routers. across multiple HNCP routers.
Each HNCP router SHOULD provide and announce an auto-generated or Each HNCP router SHOULD provide and announce an auto-generated or
user-configured name for each internal Common Link (Section 4) for user-configured name for each internal Common Link (Section 4) for
which it is the designated DHCPv4, stateful DHCPv6 server or MDNS which it is the designated DHCPv4, stateful DHCPv6 server or MDNS
[RFC6762]-proxy and for which it provides DNS-services on behalf of proxy and for which it provides DNS services on behalf of devices on
devices on said link. In addition it MAY provide reverse lookup said link. In addition it MAY provide reverse lookup services.
services.
The following TLVs are defined and MUST be supported by all nodes The following TLVs are defined and MUST be supported by all nodes
implementing naming and service discovery: implementing naming and service discovery:
8.1. DNS Delegated Zone TLV 8.1. DNS Delegated Zone TLV
This TLV is used to announce a forward or reverse DNS zone delegation This TLV is used to announce a forward or reverse DNS zone delegation
in the HNCP network. Its meaning is roughly equivalent to specifying 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 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 one delegation for the same zone in the whole DNCP network. In case
skipping to change at page 19, line 30 skipping to change at page 20, line 17
0 1 2 3 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 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 | | Type: DNS-DELEGATED-ZONE (39) | Length: >= 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IP Address | | IP Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|reserved |L|B|S| | |Reserved |L|B|S| |
+-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) | +-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) |
| | | |
IP Address is the IPv6 address of the authoritative DNS server for IP Address : The IPv6 address of the authoritative DNS server for
the zone; IPv4 addresses are represented as IPv4-mapped addresses the zone; IPv4 addresses are represented as IPv4-mapped addresses
[RFC4291]. The special value of :: (all-zero) means the [RFC4291]. The special value of :: (all-zero) means the
delegation is available in the global DNS-hierarchy. delegation is available in the global DNS-hierarchy.
reserved bits MUST be zero when creating and ignored when parsing Reserved : Those bits MUST be set to zero when creating the TLV and
this TLV. ignored when parsing it unless defined in a later specification.
L-bit (DNS-SD [RFC6763] Legacy-Browse) indicates that this L-bit : DNS-SD [RFC6763] Legacy-Browse, indicates that this
delegated zone should be included in the network's DNS-SD legacy delegated zone should be included in the network's DNS-SD legacy
browse list of domains at lb._dns- sd._udp.(DOMAIN-NAME). Local browse list of domains at lb._dns- sd._udp.(DOMAIN-NAME). Local
forward zones SHOULD have this bit set, reverse zones SHOULD NOT. forward zones SHOULD have this bit set, reverse zones SHOULD NOT.
B-bit (DNS-SD [RFC6763] Browse) indicates that this delegated zone B-bit : (DNS-SD [RFC6763] Browse) indicates that this delegated zone
should be included in the network's DNS-SD browse list of domains should be included in the network's DNS-SD browse list of domains
at b._dns-sd._udp. (DOMAIN-NAME). Local forward zones SHOULD at b._dns-sd._udp. (DOMAIN-NAME). Local forward zones SHOULD
have this bit set, reverse zones SHOULD NOT. have this bit set, reverse zones SHOULD NOT.
S-bit (fully-qualified DNS-SD [RFC6763] -domain) indicates that S-bit : (fully-qualified DNS-SD [RFC6763] domain) indicates that
this delegated zone consists of a fully-qualified DNS-SD domain, this delegated zone consists of a fully-qualified DNS-SD domain,
which should be used as base for DNS-SD domain enumeration, i.e. 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, _dns-sd._udp.(Zone) exists. Forward zones MAY have this bit set,
reverse zones MUST NOT. This can be used to provision DNS search 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 path to hosts for non-local services (such as those provided by an
ISP, or other manually configured service providers). Zones with ISP, or other manually configured service providers). Zones with
this flag SHOULD be added to the search domains advertised to this flag SHOULD be added to the search domains advertised to
clients. clients.
Zone is the label sequence of the zone, encoded according to Zone : The label sequence of the zone, encoded as the domain names
[RFC1035]. Compression MUST NOT be used. The zone MUST end with are encoded DNS messages as specified in [RFC1035]. The last
an empty label. label in the zone MUST be empty.
8.2. Domain Name TLV 8.2. Domain Name TLV
This TLV is used to indicate the base domain name for the network. 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 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 zones and node names. In case of conflicts the announced domain of
the node with the highest node identifier takes precedence. By the node with the greatest node identifier takes precedence. By
default ".home" is used, i.e. if no node advertises such a TLV. default, i.e., if no node advertises such a TLV., ".home" is used.
0 1 2 3 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 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 | | Type: DOMAIN-NAME (40) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain (DNS label sequence - variable length) | | Domain (DNS label sequence - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Domain is the label sequence encoded according to [RFC1035]. Domain: The label sequence encoded according to [RFC1035].
Compression MUST NOT be used. The zone MUST end with an empty Compression MUST NOT be used. The zone MUST end with an empty
label. label.
8.3. Node Name TLV 8.3. Node Name TLV
This TLV is used to assign the name of a node in the network to a 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 certain IP address. In case of conflicts the announcement of the
node with the highest node identifier for a name takes precedence and node with the greatest node identifier for a name takes precedence
all other nodes MUST cease to announce the conflicting TLV. and all other nodes MUST cease to announce the conflicting TLV.
0 1 2 3 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 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 | | Type: NODE-NAME (41) | Length: > 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IP Address | | IP Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name (not null-terminated - variable length) | | Name (not null-terminated - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address: The IP address associated with the name. IPv4
addresses are encoded using IPv4-mapped IPv6 addresses.
Name: The name of the node as a DNS label. The length of the label
is the Length value of the TLV minus 16.
9. Securing Third-Party Protocols 9. Securing Third-Party Protocols
Pre-shared keys (PSKs) are often required to secure IGPs and other Pre-shared keys (PSKs) are often required to secure IGPs and other
protocols which lack support for asymmetric security. The following protocols which lack support for asymmetric security. The following
mechanism manages PSKs using HNCP to enable bootstrapping of such mechanism manages PSKs using HNCP to enable bootstrapping of such
third-party protocols and SHOULD therefore be used if such a need third-party protocols and SHOULD therefore be used if such a need
arises. The following rules define how such a PSK is managed and arises. The following rules define how such a PSK is managed and
used: used:
o If no Managed-PSK-TLV is currently being announced, an HNCP router 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 MUST create one after a random delay of 0 to 10 seconds with a 32
node data. 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 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 but the one with the greatest node identifier stop advertising it
and adopt the remaining one. and adopt the remaining one.
o The router currently advertising the Managed-PSK-TLV must generate o The router currently advertising the Managed-PSK-TLV must generate
and advertise a new random one whenever an unreachable node is and advertise a new random one whenever an unreachable node is
purged as described in DNCP. purged as described in DNCP.
0 1 2 3 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 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 | | Type: Managed-PSK (42) | Length: 32 |
skipping to change at page 22, line 4 skipping to change at page 22, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| | | |
| Random PSK | | Random PSK |
| | | |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PSKs for individual protocols are derived from the random PSK through PSKs for individual protocols are derived from the random PSK through
the use of HMAC-SHA256 [RFC6234] with a pre-defined per-protocol the use of HMAC-SHA256 [RFC6234] with a pre-defined per-protocol
HMAC-key in ASCII-format. The following HMAC-keys are currently HMAC-key in ASCII-format. The following HMAC-keys are currently
defined to derive PSKs for the respective protocols: defined to derive PSKs for the respective protocols:
"ROUTING": to be used for IGPs "ROUTING": to be used for IGPs
10. HNCP Versioning and Capabilities 10. HNCP Versioning and Capabilities
Multiple versions of HNCP based on compatible DNCP Multiple versions of HNCP based on compatible DNCP profiles may be
[I-D.ietf-homenet-dncp] profiles may be present in the same network present in the same network when transitioning between HNCP versions
when transitioning between HNCP versions and HNCP routers may have and HNCP routers may have different capabilities to support clients.
different capabilities to support clients. The following mechanism
describes a way to announce the currently active version and User- The following mechanism describes a way to announce the currently
agent of a node. Each node MUST include an HNCP-Version-TLV in its active version and User-agent of a node. Each node MUST include an
Node Data and MUST ignore (except for DNCP synchronization purposes) HNCP-Version-TLV in its Node Data and MUST ignore (except for DNCP
any TLVs with a type greater than 32 of nodes not publishing an HNCP- synchronization purposes) any TLVs with a type greater than 32
Version TLV or publishing such a TLV with a different Version number. published by nodes not also 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 Capabilities are indicated by setting M, P, H and L fields in the
TLV. The "capability value" is a metric indicated by interpreting TLV. The "capability value" is a metric indicated by interpreting
the bits as an integer, i.e. (M << 12 | P << 8 | H << 4 | L). the bits as an integer, i.e. (M << 12 | P << 8 | H << 4 | L).
0 1 2 3 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 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 | | Type: HNCP-VERSION (32) | Length: >= 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | M | P | H | L | | Version | Reserved | M | P | H | L |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-agent | | User-agent |
Version: Version indicates which version of HNCP is currently in use Version: Indicates which version of HNCP is currently in use by this
by this particular node. It MUST be set to 0. Nodes with particular node. It MUST be set to 0. Nodes with different
different versions are considered incompatible. versions are considered incompatible.
Reserved: Bits reserved for future use. MUST be set to zero when Reserved: Bits are reserved for future use. They MUST be set to
creating this TLV and ignored when parsing it. zero when creating this TLV, and their value MUST be ignored when
processing the TLV.
M-capability: Priority value used for electing the on-link MDNS M-capability: Priority value used for electing the on-link MDNS
[RFC6762] proxy. It MUST be set to some value between 1 and 7 [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 included (4 is the default) if the router is capable of proxying
MDNS and 0 otherwise. The values 8-15 are reserved for future MDNS and 0 otherwise. The values 8-15 are reserved for future
use. use.
P-capability: Priority value used for electing the on-link DHCPv6-PD 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 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 is the default) if the router is capable of providing prefixes
skipping to change at page 23, line 19 skipping to change at page 24, line 8
value between 1 and 7 included (4 is the default) if the router is value between 1 and 7 included (4 is the default) if the router is
capable of providing such addresses and 0 otherwise. The values capable of providing such addresses and 0 otherwise. The values
8-15 are reserved for future use. 8-15 are reserved for future use.
L-capability: Priority value used for electing the on-link DHCPv4 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 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 is the default) if the router is capable of running a legacy
DHCPv4 server offering IPv4 addresses to clients and 0 otherwise. DHCPv4 server offering IPv4 addresses to clients and 0 otherwise.
The values 8-15 are reserved for future use. The values 8-15 are reserved for future use.
User-Agent: The user-agent is a null-terminated human-readable UTF-8 User-Agent: The user-agent is a human-readable UTF-8 string that
string that describes the name and version of the current HNCP describes the name and version of the current HNCP implementation.
implementation.
11. Requirements for HNCP Routers 11. Requirements for HNCP Routers
Each router implementing HNCP is subject to the following Each router implementing HNCP is subject to the following
requirements: requirements:
o It MUST implement HNCP-Versioning, Border Discovery, Prefix o It MUST implement HNCP-Versioning, Border Discovery, Prefix
Assignment and Configuration of hosts and non-HNCP routers as Assignment and Configuration of hosts and non-HNCP routers as
defined in this document. defined in this document.
o It MUST implement and run the method for securing third-party o It MUST implement and run the method for securing third-party
protocols whenever it uses the security mechanism of HNCP. protocols whenever it uses the security mechanism of HNCP.
o It SHOULD implement support for the Service Discovery and Naming o It SHOULD implement support for the Service Discovery and Naming
TLVs as defined in this document. TLVs as defined in this document.
o It MUST implement and run a routing protocol appropriate for the o It MUST implement and run a routing protocol appropriate for the
given link type and with support for source-specific routes on all given link type on all of the interfaces it sends and receives
of the interfaces it sends and receives HNCP traffic on and MUST HNCP traffic on. The protocol MUST support source-specific routes
resort to announcing source-specific routes for external and MUST correctly propagate those also for the external
destinations appropriately. destinations that may have only implicit source-specific
information, such as a combination of a DHCPv6 PD-derived prefix
and a non-source-specific default route.
o It MUST use adequate security mechanisms for the routing protocol o It MUST use adequate security mechanisms for the routing protocol
on any interface where it also uses the security mechanisms of 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 HNCP. If the security mechanism is based on a PSK it MUST use a
PSK derived from the Managed-PSK to secure the IGP. PSK derived from the Managed-PSK to secure the IGP.
o It MUST comply with the Basic Requirements for IPv6 Customer Edge o It MUST comply with the Basic Requirements for IPv6 Customer Edge
Routers [RFC7084] unless it would otherwise conflict with any Routers [RFC7084] unless it would otherwise conflict with any
requirements in this document (e.g. prefix assignment mandating a requirements in this document (e.g. prefix assignment mandating a
different prefix delegation and DHCP server election strategy). different prefix delegation and DHCP server election strategy).
In general "WAN interface requirements" shall apply to external In general "WAN interface requirements" shall apply to external
interfaces and "LAN interface requirements" to internal interfaces interfaces and "LAN interface requirements" to internal interfaces
respectively. respectively.
o It SHOULD be able to provide connectivity to IPv4-devices using o It MAY be able to provide connectivity to IPv4-devices using
DHCPv4. DHCPv4.
o It SHOULD be able to delegate prefixes to legacy IPv6 routers o It SHOULD be able to delegate prefixes to legacy IPv6 routers
using DHCPv6-PD. using DHCPv6-PD.
12. Security Considerations 12. Security Considerations
HNCP enables self-configuring networks, requiring as little user HNCP enables self-configuring networks, requiring as little user
intervention as possible. However this zero-configuration goal intervention as possible. However this zero-configuration goal
usually conflicts with security goals and introduces a number of usually conflicts with security goals and introduces a number of
threats. threats.
General security issues for existing home networks are discussed in General security issues for existing home networks are discussed in
[RFC7368]. The protocols used to set up addresses and routes in such [RFC7368]. The protocols used to set up addresses and routes in such
networks to this day rarely have security enabled within the networks to this day rarely have security enabled within the
configuration protocol itself. However these issues are out of scope configuration protocol itself. However these issues are out of scope
for the security of HNCP itself. for the security of HNCP itself.
HNCP is a DNCP [I-D.ietf-homenet-dncp]-based state synchronization HNCP is a DNCP-based state synchronization mechanism carrying
mechanism carrying information with varying threat potential. For information with varying threat potential. For this consideration
this consideration the payloads defined in DNCP and this document are the payloads defined in DNCP and this document are reviewed:
reviewed:
o Network topology information such as HNCP nodes and their common o Network topology information such as HNCP nodes and their common
links links.
o Address assignment information such as delegated and assigned o Address assignment information such as delegated and assigned
prefixes for individual links prefixes for individual links.
o Naming and service discovery information such as auto-generated or o Naming and service discovery information such as auto-generated or
customized names for individual links and routers customized names for individual links and routers.
12.1. Border Determination 12.1. Border Determination
As described in Section 5, an HNCP router determines the internal or 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 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 for the external links, and for internal links, HNCP and IGP traffic
is allowed. is allowed.
Threats concerning automatic border discovery cannot be mitigated by Threats concerning automatic border discovery cannot be mitigated by
encrypting or authenticating HNCP traffic itself since external encrypting or authenticating HNCP traffic itself since external
skipping to change at page 26, line 9 skipping to change at page 26, line 44
considered. It can however be summarized that many protocols to be considered. It can however be summarized that many protocols to be
run in the home (like IGPs) provide - to a certain extent - similar run in the home (like IGPs) provide - to a certain extent - similar
security mechanisms. Most of these protocols do not support security mechanisms. Most of these protocols do not support
encryption and only support authentication based on pre-shared keys encryption and only support authentication based on pre-shared keys
natively. This influences the effectiveness of any encryption-based natively. This influences the effectiveness of any encryption-based
security mechanism deployed by HNCP as homenet routing information is security mechanism deployed by HNCP as homenet routing information is
thus usually not encrypted. thus usually not encrypted.
13. IANA Considerations 13. IANA Considerations
IANA is requested to maintain a registry for HNCP TLV-Types. IANA is requested to maintain a registry for HNCP TLV-Types. This
registry inherits TLV-Types and allocation policy defined in DNCP
[I-D.ietf-homenet-dncp], but is independent with regard to all TLV-
Types not specified or reserved by DNCP. Particularly, other DNCP
profile may have there own registries, using same TLV numbers.
HNCP inherits the TLV-Types and allocation policy defined in DNCP The following TLV-Types are defined in this document:
[I-D.ietf-homenet-dncp]. In addition the following TLV-Types are
defined in this document:
32: HNCP-Version 32: HNCP-Version
33: External-Connection 33: External-Connection
34: Delegated-Prefix 34: Delegated-Prefix
35: Assigned-Prefix 35: Assigned-Prefix
36: Node-Address 36: Node-Address
skipping to change at page 26, line 47 skipping to change at page 27, line 37
HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP- HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP-
DTLS-PORT, as well as an IPv6 link-local multicast address All- DTLS-PORT, as well as an IPv6 link-local multicast address All-
Homenet-Routers. Homenet-Routers.
14. References 14. References
14.1. Normative references 14.1. Normative references
[I-D.ietf-homenet-dncp] [I-D.ietf-homenet-dncp]
Stenberg, M. and S. Barth, "Distributed Node Consensus Stenberg, M. and S. Barth, "Distributed Node Consensus
Protocol", draft-ietf-homenet-dncp-04 (work in progress), Protocol", draft-ietf-homenet-dncp-05 (work in progress),
June 2015. June 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012. Delegation", RFC 6603, May 2012.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[I-D.ietf-homenet-prefix-assignment] [I-D.ietf-homenet-prefix-assignment]
Pfister, P., Paterson, B., and J. Arkko, "Distributed Pfister, P., Paterson, B., and J. Arkko, "Distributed
Prefix Assignment Algorithm", draft-ietf-homenet-prefix- Prefix Assignment Algorithm", draft-ietf-homenet-prefix-
assignment-06 (work in progress), May 2015. assignment-07 (work in progress), June 2015.
14.2. Informative references 14.2. Informative references
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013. November 2013.
[RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
A., Beser, B., and J. Privat, "The User Class Option for A., Beser, B., and J. Privat, "The User Class Option for
DHCP", RFC 3004, November 2000. DHCP", RFC 3004, November 2000.
skipping to change at page 28, line 46 skipping to change at page 29, line 33
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
14.3. URIs 14.3. URIs
[3] http://www.openwrt.org [3] http://www.openwrt.org
[4] http://www.homewrt.org/doku.php?id=run-conf [4] http://www.homewrt.org/doku.php?id=run-conf
Appendix A. Changelog [RFC Editor: please remove] Appendix A. Changelog [RFC Editor: please remove]
draft-ietf-homenet-hncp-06: Various edits based on feedback,
hopefully without functional delta.
draft-ietf-homenet-hncp-05: Renamed "Adjacent Link" to "Common Link". draft-ietf-homenet-hncp-05: Renamed "Adjacent Link" to "Common Link".
Changed single IPv4 uplink election from MUST to MAY. Added explicit Changed single IPv4 uplink election from MUST to MAY. Added explicit
indication to distinguish (IPv4)-PDs for local connectivity and ones indication to distinguish (IPv4)-PDs for local connectivity and ones
with uplink connectivity allowing e.g. better local-only with uplink connectivity allowing e.g. better local-only
IPv4-connectivity. IPv4-connectivity.
draft-ietf-homenet-hncp-04: Change the responsibility for sending RAs draft-ietf-homenet-hncp-04: Change the responsibility for sending RAs
to the router assigning the prefix. to the router assigning the prefix.
draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP
 End of changes. 116 change blocks. 
347 lines changed or deleted 406 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/