draft-ietf-homenet-hncp-10.txt   rfc7788.txt 
Homenet Working Group M. Stenberg Internet Engineering Task Force (IETF) M. Stenberg
Internet-Draft S. Barth Request for Comments: 7788 S. Barth
Intended status: Standards Track Independent Category: Standards Track Independent
Expires: May 30, 2016 P. Pfister ISSN: 2070-1721 P. Pfister
Cisco Systems Cisco Systems
November 27, 2015 April 2016
Home Networking Control Protocol Home Networking Control Protocol
draft-ietf-homenet-hncp-10
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. HNCP is described as a profile of and home network devices. HNCP is described as a profile of and
extension to the Distributed Node Consensus Protocol (DNCP). HNCP extension to the Distributed Node Consensus Protocol (DNCP). HNCP
enables discovery of network borders, automated configuration of enables discovery of network borders, automated configuration of
addresses, name resolution, service discovery, and the use of any addresses, name resolution, service discovery, and the use of any
routing protocol which supports routing based on both source and routing protocol that supports routing based on both the source and
destination address. destination address.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on May 30, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7788.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements language . . . . . . . . . . . . . . . . . . 7 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 7
3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 7 3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 7
4. HNCP Versioning and Router Capabilities . . . . . . . . . . . 8 4. HNCP Versioning and Router Capabilities . . . . . . . . . . . 9
5. Interface Classification . . . . . . . . . . . . . . . . . . 9 5. Interface Classification . . . . . . . . . . . . . . . . . . 9
5.1. Interface Categories . . . . . . . . . . . . . . . . . . 9 5.1. Interface Categories . . . . . . . . . . . . . . . . . . 9
5.2. DHCP Aided Auto-Detection . . . . . . . . . . . . . . . . 10 5.2. DHCP-Aided Auto-Detection . . . . . . . . . . . . . . . . 10
5.3. Algorithm for Border Discovery . . . . . . . . . . . . . 10 5.3. Algorithm for Border Discovery . . . . . . . . . . . . . 11
6. Autonomous Address Configuration . . . . . . . . . . . . . . 11 6. Autonomous Address Configuration . . . . . . . . . . . . . . 12
6.1. Common Link . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Common Link . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. External Connections . . . . . . . . . . . . . . . . . . 12 6.2. External Connections . . . . . . . . . . . . . . . . . . 13
6.3. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 14 6.3. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 14
6.3.1. Prefix Assignment Algorithm Parameters . . . . . . . 14 6.3.1. Prefix Assignment Algorithm Parameters . . . . . . . 14
6.3.2. Making New Assignments . . . . . . . . . . . . . . . 15 6.3.2. Making New Assignments . . . . . . . . . . . . . . . 16
6.3.3. Applying Assignments . . . . . . . . . . . . . . . . 16 6.3.3. Applying Assignments . . . . . . . . . . . . . . . . 17
6.3.4. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . 16 6.3.4. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . 17
6.4. Node Address Assignment . . . . . . . . . . . . . . . . . 17 6.4. Node Address Assignment . . . . . . . . . . . . . . . . . 17
6.5. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 18 6.5. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 18
7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 19 7. Configuration of Hosts and Non-HNCP Routers . . . . . . . . . 19
7.1. IPv6 Addressing and Configuration . . . . . . . . . . . . 19 7.1. IPv6 Addressing and Configuration . . . . . . . . . . . . 19
7.2. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 20 7.2. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 20
7.3. DHCPv4 for Addressing and Configuration . . . . . . . . . 20 7.3. DHCPv4 for Addressing and Configuration . . . . . . . . . 20
7.4. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 20 7.4. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 21
8. Naming and Service Discovery . . . . . . . . . . . . . . . . 21 8. Naming and Service Discovery . . . . . . . . . . . . . . . . 21
9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 22 9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 22
10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 22 10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 23
10.1. HNCP Version TLV . . . . . . . . . . . . . . . . . . . . 23 10.1. HNCP-Version TLV . . . . . . . . . . . . . . . . . . . . 23
10.2. External Connection TLV . . . . . . . . . . . . . . . . 24 10.2. External-Connection TLV . . . . . . . . . . . . . . . . 24
10.2.1. Delegated Prefix TLV . . . . . . . . . . . . . . . . 24 10.2.1. Delegated-Prefix TLV . . . . . . . . . . . . . . . . 25
10.2.2. DHCPv6 Data TLV . . . . . . . . . . . . . . . . . . 26 10.2.2. DHCPv6-Data TLV . . . . . . . . . . . . . . . . . . 27
10.2.3. DHCPv4 Data TLV . . . . . . . . . . . . . . . . . . 26 10.2.3. DHCPv4-Data TLV . . . . . . . . . . . . . . . . . . 27
10.3. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . 27 10.3. Assigned-Prefix TLV . . . . . . . . . . . . . . . . . . 28
10.4. Node Address TLV . . . . . . . . . . . . . . . . . . . . 28 10.4. Node-Address TLV . . . . . . . . . . . . . . . . . . . . 29
10.5. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 28 10.5. DNS-Delegated-Zone TLV . . . . . . . . . . . . . . . . . 30
10.6. Domain Name TLV . . . . . . . . . . . . . . . . . . . . 29 10.6. Domain-Name TLV . . . . . . . . . . . . . . . . . . . . 31
10.7. Node Name TLV . . . . . . . . . . . . . . . . . . . . . 30 10.7. Node-Name TLV . . . . . . . . . . . . . . . . . . . . . 31
10.8. Managed PSK TLV . . . . . . . . . . . . . . . . . . . . 30 10.8. Managed-PSK TLV . . . . . . . . . . . . . . . . . . . . 32
11. General Requirements for HNCP Nodes . . . . . . . . . . . . . 31 11. General Requirements for HNCP Nodes . . . . . . . . . . . . . 32
12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
12.1. Interface Classification . . . . . . . . . . . . . . . . 33 12.1. Interface Classification . . . . . . . . . . . . . . . . 34
12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 34 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 35
12.3. Other Protocols in the Home . . . . . . . . . . . . . . 34 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 35
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
14.1. Normative references . . . . . . . . . . . . . . . . . . 35 14.1. Normative References . . . . . . . . . . . . . . . . . . 37
14.2. Informative references . . . . . . . . . . . . . . . . . 37 14.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 38 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. Draft source [RFC Editor: please remove] . . . . . . 39
Appendix C. Implementation [RFC Editor: please remove] . . . . . 39
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Home Networking Control Protocol (HNCP) is designed to facilitate The Home Networking Control Protocol (HNCP) is designed to facilitate
sharing of state among home routers to fulfill the needs of the IPv6 the sharing of state among home routers to fulfill the needs of the
homenet architecture [RFC7368], which assumes zero-configuration IPv6 homenet architecture [RFC7368], which assumes zero-configuration
operation, multiple subnets, multiple home routers and (potentially) operation, multiple subnets, multiple home routers, and (potentially)
multiple upstream service providers providing (potentially) multiple multiple upstream service providers providing (potentially) multiple
prefixes to the home network. While RFC7368 sets no requirements for prefixes to the home network. While RFC 7368 sets no requirements
IPv4 support, HNCP aims to support dual-stack mode of operation, and for IPv4 support, HNCP aims to support the dual-stack mode of
therefore the functionality is designed with that in mind. The state operation, and therefore the functionality is designed with that in
is shared as TLVs transported in the DNCP node state among the mind. The state is shared as TLVs transported in the DNCP node state
routers (and potentially advanced hosts) to enable: among the routers (and potentially advanced hosts) to enable:
o Autonomic discovery of network borders (Section 5.3) based on o Autonomic discovery of network borders (Section 5.3) based on
Distributed Node Consensus Protocol (DNCP) topology. Distributed Node Consensus Protocol (DNCP) topology.
o Automated portioning of prefixes delegated by the service o Automated portioning of prefixes delegated by the service
providers as well as assigned prefixes to both HNCP and non-HNCP providers as well as assigned prefixes to both HNCP and non-HNCP
routers (Section 6.3) using [RFC7695]. Prefixes assigned to HNCP routers (Section 6.3) using [RFC7695]. Prefixes assigned to HNCP
routers are used to: routers are used to:
* Provide addresses to non-HNCP aware nodes (using SLAAC and * Provide addresses to non-HNCP aware nodes (using Stateless
DHCP). Address Autoconfiguration (SLAAC) and DHCP).
* Provide space in which HNCP nodes assign their own addresses * Provide space in which HNCP nodes assign their own addresses
(Section 6.4). (Section 6.4).
o Internal and external name resolution, as well as multi-link o Internal and external name resolution, as well as multi-link
service discovery (Section 8). service discovery (Section 8).
o Other services not defined in this document, that do need to share o Other services not defined in this document that do need to share
state among homenet nodes, and do not cause rapid and constant TLV state among homenet nodes and do not cause rapid and constant TLV
changes (see following applicability section). changes (see the following applicability section).
HNCP is a DNCP [I-D.ietf-homenet-dncp]-based protocol and includes a HNCP is a protocol based on DNCP [RFC7787] and includes a DNCP
DNCP profile which defines transport and synchronization details for profile that defines transport and synchronization details for
sharing state across nodes defined in Section 3. The rest of the sharing state across nodes defined in Section 3. The rest of the
document defines behavior of the services noted above, how the document defines behavior of the services noted above, how the
required TLVs are encoded (Section 10), as well as additional required TLVs are encoded (Section 10), as well as additional
requirements on how HNCP nodes should behave (Section 11). requirements on how HNCP nodes should behave (Section 11).
1.1. Applicability 1.1. Applicability
While HNCP does not deal with routing protocols directly (except While HNCP does not deal with routing protocols directly (except
potentially informing them about internal and external interfaces if potentially informing them about internal and external interfaces if
classification specified in Section 5.3 is used), in homenet classification specified in Section 5.3 is used), in homenet
environments where multiple IPv6 source-prefixes can be present, environments where multiple IPv6 source prefixes can be present,
routing based on source and destination address is necessary routing based on the source and destination address is necessary
[RFC7368]. Ideally, the routing protocol is also zero-configuration [RFC7368]. Ideally, the routing protocol is also zero configuration
(e.g., no need to configure identifiers or metrics) although HNCP can (e.g., no need to configure identifiers or metrics), although HNCP
be used also with a manually configured routing protocol. can also be used with a manually configured routing protocol.
As HNCP uses DNCP as the actual state synchronization protocol, the As HNCP uses DNCP as the actual state synchronization protocol, the
applicability statement of DNCP applies here as well; HNCP should not applicability statement of DNCP applies here as well; HNCP should not
be used for any data that changes rapidly and constantly. If such be used for any data that changes rapidly and constantly. If such
data needs to be published in an HNCP network, a more applicable data needs to be published in an HNCP network, 1) a more applicable
protocol should be used for those portions and locators to a server protocol should be used for those portions, and 2) locators to a
of said protocol can be announced using HNCP instead. An example for server of said protocol should be announced using HNCP instead. An
this is naming and service discovery (Section 8) for which HNCP only example for this is naming and service discovery (Section 8) for
transports DNS server addresses, and no actual per-name or per- which HNCP only transports DNS server addresses and no actual per-
service data of hosts. name or per-service data of hosts.
HNCP TLVs specified within this document, in steady state, stay HNCP TLVs specified within this document, in steady state, stay
constant, with one exception: as Delegated Prefix TLVs constant, with one exception: as Delegated-Prefix TLVs
(Section 10.2.1) do contain lifetimes, they force re-publishing of (Section 10.2.1) do contain lifetimes, they force republishing of
that data every time the valid or preferred lifetimes of prefixes are that data every time the valid or preferred lifetimes of prefixes are
updated (significantly). Therefore, it is desirable for ISPs to updated (significantly). Therefore, it is desirable for ISPs to
provide large enough valid and preferred lifetimes to avoid provide large enough valid and preferred lifetimes to avoid
unnecessary HNCP state churn in homes, but even given non-cooperating unnecessary HNCP state churn in homes, but even given non-cooperating
ISPs, the state churn is proportional only to the number of ISPs, the state churn is proportional only to the number of
externally received delegated prefixes and not the home network size, externally received delegated prefixes and not to the home network
and should therefore be relatively low. size, and it should therefore be relatively low.
HNCP assumes a certain level of control over host configuration HNCP assumes a certain level of control over host configuration
servers (e.g., DHCP [RFC2131]) on links that are managed by its servers (e.g., DHCP [RFC2131]) on links that are managed by its
routers. Some HNCP functionality (such as border discovery or some routers. Some HNCP functionality (such as border discovery or some
aspects of naming) might be affected by existing DHCP servers not aspects of naming) might be affected by existing DHCP servers that
aware of the HNCP-managed network and thus might need to be are not aware of the HNCP-managed network and thus might need to be
reconfigured to not result in unexpected behavior. reconfigured to not result in unexpected behavior.
While HNCP routers can provide configuration to and receive While HNCP routers can provide configuration to and receive
configuration from non-HNCP routers, they are not able to traverse configuration from non-HNCP routers, they are not able to traverse
such devices based solely on the protocol as defined in this such devices based solely on the protocol as defined in this
document, i.e., HNCP routers that are connected only by different document, i.e., HNCP routers that are connected only by different
interfaces of a non-HNCP router will not be part of the same HNCP interfaces of a non-HNCP router will not be part of the same HNCP
network. network.
While HNCP is designed to be used by (home) routers, it can also be While HNCP is designed to be used by (home) routers, it can also be
used by advanced hosts that want to do, e.g., their own address used by advanced hosts that want to do, e.g., their own address
assignment and routing. assignment and routing.
HNCP is link layer agnostic; if a link supports IPv6 (link-local) HNCP is link-layer agnostic; if a link supports IPv6 (link-local)
multicast and unicast, HNCP will work on it. Trickle retransmissions multicast and unicast, HNCP will work on it. Trickle retransmissions
and keep-alives will handle both packet loss and non-transitive and keep-alives will handle both packet loss and non-transitive
connectivity, ensuring eventual convergence. connectivity, ensuring eventual convergence.
2. Terminology 2. Terminology
The following terms are used as they are defined in [RFC7695]: The following terms are used as they are defined in [RFC7695]:
o Advertised Prefix Priority o Advertised Prefix Priority
skipping to change at page 5, line 39 skipping to change at page 6, line 4
o Prefix Adoption o Prefix Adoption
o Private Link o Private Link
o Published Assigned Prefix o Published Assigned Prefix
o Applied Assigned Prefix o Applied Assigned Prefix
o Shared Link o Shared Link
The following terms are used as they are defined in [RFC7787]:
The following terms are used as they are defined in
[I-D.ietf-homenet-dncp]:
o DNCP profile o DNCP profile
o Node identifier o Node identifier
o Link o Link
o Interface o Interface
(HNCP) node A device implementing this specification.
(HNCP) router A device implementing this specification, which (HNCP) node a device implementing this specification.
(HNCP) router a device implementing this specification, which
forwards traffic on behalf of other devices. forwards traffic on behalf of other devices.
highest node When comparing the DNCP node identifiers of
identifier multiple nodes, the one that has the highest value Greatest node when comparing the DNCP node identifiers of
identifier multiple nodes, the one that has the greatest value
in a bitwise comparison. in a bitwise comparison.
Border separation point between administrative domains; in Border separation point between administrative domains; in
this case, between the home network and any other this case, between the home network and any other
network, i.e., usually an ISP network. network, i.e., usually an ISP network.
Internal link a link that does not cross borders. Internal link a link that does not cross borders.
Internal an interface that is connected to an internal link. Internal an interface that is connected to an internal link.
interface interface
External an interface that is connected to a link which is External an interface that is connected to a link that is
interface not an internal link. interface not an internal link.
Interface a local configuration denoting the use of a Interface a local configuration denoting the use of a
category particular interface. The interface category category particular interface. The Interface category
determines how a HNCP node should treat the determines how an HNCP node should treat the
particular interface. External and internal particular interface. The External and Internal
category mark the interface as out of or within the categories mark the interface as out of or within
network border; there are also a number of sub- the network border; there are also a number of
categories to internal that further affect local subcategories of Internal that further affect local
node behavior. See Section 5.1 for a list of node behavior. See Section 5.1 for a list of
interface categories and how they behave. The interface categories and how they behave. The
internal or external categories may also be auto- Internal or External category may also be auto-
detected (Section 5.3). detected (Section 5.3).
Border router a router announcing external connectivity and Border router a router announcing external connectivity and
forwarding traffic across the network border. forwarding traffic across the network border.
Common Link a set of nodes on a link which share a common view Common Link a set of nodes on a link that share a common view
of it, i.e., they see each other's traffic and the of it, i.e., they see each other's traffic and the
same set of hosts. Unless configured otherwise same set of hosts. Unless configured otherwise,
transitive connectivity is assumed. transitive connectivity is assumed.
DHCPv4 refers to Dynamic Host Configuration Protocol DHCPv4 refers to the Dynamic Host Configuration Protocol
[RFC2131] in this document. [RFC2131] in this document.
DHCPv6 refers to Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) [RFC3315] in this document. DHCPv6 refers to the Dynamic Host Configuration Protocol
DHCP refers to cases which apply to both DHCPv4 and for IPv6 (DHCPv6) [RFC3315] in this document.
DHCP refers to cases that apply to both DHCPv4 and
DHCPv6 in this document. DHCPv6 in this document.
2.1. Requirements language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
3. DNCP Profile 3. DNCP Profile
The DNCP profile for HNCP is defined as follows: The DNCP profile for HNCP is defined as follows:
o HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport over o HNCP uses UDP datagrams on port 8231 as a transport over link-
link-local scoped IPv6, using unicast and multicast (All-Homenet- local scoped IPv6, using unicast and multicast
Nodes is the HNCP group address). Received datagrams where either (FF02:0:0:0:0:0:0:11 is the HNCP group address). Received
or both of the IPv6 source or destination address is not link- datagrams where either or both of the IPv6 source or destination
local scoped MUST be ignored. Replies to multicast and unicast addresses are not link-local scoped MUST be ignored. Replies to
messages MUST be sent to the IPv6 source address and port of the multicast and unicast messages MUST be sent to the IPv6 source
original message. Each node MUST be able to receive (and address and port of the original message. Each node MUST be able
potentially reassemble) UDP datagrams with a payload of at least to receive (and potentially reassemble) UDP datagrams with a
4000 bytes. payload of at least 4000 bytes.
o HNCP operates on multicast-capable interfaces only. HNCP nodes o HNCP operates on multicast-capable interfaces only. HNCP nodes
MUST assign a non-zero 32-bit endpoint identifier to each MUST assign a non-zero 32-bit endpoint identifier to each
interface for which HNCP is enabled. The value zero is not used interface for which HNCP is enabled. The value 0 is not used in
in DNCP TLVs, but has a special meaning in HNCP TLVs (see DNCP TLVs but has a special meaning in HNCP TLVs (see Sections 6.4
Section 10.3 and Section 6.4). These identifiers MUST be locally and 10.3). These identifiers MUST be locally unique within the
unique within the scope of the node and using values equivalent to scope of the node, and using values equivalent to the IPv6 link-
the IPv6 link-local scope identifiers for the given interfaces are local scope identifiers for the given interfaces are RECOMMENDED.
RECOMMENDED.
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 use a random node identifier. If there is a node SHOULD use a random node identifier. If there is a node
identifier collision (as specified in the Node State TLV handling identifier collision (as specified in the Node-State TLV handling
of Section 4.4 of [I-D.ietf-homenet-dncp]), the node MUST of Section 4.4 of [RFC7787]), the node MUST immediately generate
immediately generate and use a new random node identifier which is and use a new random node identifier that is not used by any other
not used by any other node at the time, based on the current DNCP node at the time, based on the current DNCP network state.
network state.
o HNCP nodes MUST use the leading 64 bits of the MD5 message digest o HNCP nodes MUST use the leading 64 bits of the MD5 message digest
[RFC1321] as the DNCP hash function H(x) used in building the DNCP [RFC1321] as the DNCP hash function H(x) used in building the DNCP
hash tree. hash tree.
o HNCP nodes MUST use DNCP's per-endpoint keep-alive extension on o HNCP nodes MUST use DNCP's per-endpoint keep-alive extension on
all endpoints. The following parameters are suggested: all endpoints. The following parameters are suggested:
* Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20 * Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20
seconds. seconds.
* Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1 on virtually * Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1 on virtually
lossless links works fine as it allows for one lost keep-alive. lossless links works fine, as it allows for one lost keep-
If used on a lossy link, considerably higher multiplier, such alive. If used on a lossy link, a considerably higher
as 15, should be used instead. In that case, an implementation multiplier, such as 15, should be used instead. In that case,
might prefer shorter keep-alive intervals on that link as well an implementation might prefer shorter keep-alive intervals on
to ensure that DNCP_KEEPALIVE_INTERVAL * that link as well to ensure that the timeout (equal to
DNCP_KEEPALIVE_MULTIPLIER timeout after which (entirely) lost DNCP_KEEPALIVE_INTERVAL * DNCP_KEEPALIVE_MULTIPLIER) after
nodes time out is low enough. which entirely lost nodes time out is low enough.
o HNCP nodes use the following Trickle parameters for the per- o HNCP nodes use the following Trickle parameters for the per-
interface Trickle instances: interface Trickle instances:
* k SHOULD be 1, as the timer reset when data is updated and * k SHOULD be 1, as the timer reset when data is updated, and
further retransmissions should handle packet loss. Even on a further retransmissions should handle packet loss. Even on a
non-transitive lossy link, the eventual per-endpoint keep- non-transitive lossy link, the eventual per-endpoint keep-
alives should ensure status synchronization occurs. alives should ensure status synchronization occurs.
* 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 [RFC6206] but MUST NOT be * Imax SHOULD be 7 doublings of Imin [RFC6206] but MUST NOT be
lower. lower.
o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as o HNCP unicast traffic SHOULD be secured using Datagram Transport
described in DNCP if exchanged over unsecured links. UDP on port Layer Security (DTLS) [RFC6347] as described in DNCP if exchanged
HNCP-DTLS-PORT is used for this purpose. A node implementing HNCP over unsecured links. UDP on port 8232 is used for this purpose.
security MUST support the DNCP Pre-Shared Key method, SHOULD A node implementing HNCP security MUST support the DNCP Pre-Shared
support the PKI-based trust method and MAY support the DNCP Key (PSK) method, SHOULD support the PKI-based trust method, and
Certificate Based Trust Consensus method. [RFC7525] provides MAY support the DNCP certificate-based trust consensus method.
guidance on how to securely utilize DTLS. [RFC7525] provides guidance on how to securely utilize DTLS.
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 in order to prevent on a link that has DNCP security enabled in order to prevent
spoofing of node state changes. spoofing of node state changes.
4. HNCP Versioning and Router Capabilities 4. HNCP Versioning and Router Capabilities
Multiple versions of HNCP based on compatible DNCP profiles may be Multiple versions of HNCP based on compatible DNCP profiles may be
present in the same network when transitioning between HNCP versions present in the same network when transitioning between HNCP versions,
and for troubleshooting purposes it might be beneficial to identify and for troubleshooting purposes, it might be beneficial to identify
the HNCP agent version running. Therefore each node MUST include an the HNCP agent version running. Therefore, each node MUST include an
HNCP-Version TLV (Section 10.1) indicating the currently supported HNCP-Version TLV (Section 10.1) indicating the currently supported
version in its Node Data and MUST ignore (except for DNCP version in its node data and MUST ignore (except for DNCP
synchronization purposes) any TLVs with a type greater than 32 synchronization purposes) any TLVs that have a type greater than 32
published by nodes not also publishing an HNCP-Version TLV. and that are published by nodes that didn't also publish an HNCP-
Version TLV.
HNCP routers may also have different capabilities regarding HNCP routers may also have different capabilities regarding
interactions with hosts, e.g., for configuration or service interactions with hosts, e.g., for configuration or service
discovery. These are indicated by M, P, H and L values. The discovery. These are indicated by M, P, H, and L values. The
combined "capability value" is a metric indicated by interpreting the combined "capability value" is a metric indicated by interpreting the
bits as an integer, i.e., (M << 12 | P << 8 | H << 4 | L). These bits as an integer, i.e., (M << 12 | P << 8 | H << 4 | L). These
values are used to elect certain servers on a Common Link, as values are used to elect certain servers on a Common Link, as
described in Section 7. Nodes that are not routers MUST announce the described in Section 7. Nodes that are not routers MUST announce the
value 0 for all capabilities. Any node announcing the value 0 for a value 0 for all capabilities. Any node announcing the value 0 for a
capability is considered to not advertise said capability and thus capability is considered to not advertise said capability and thus
does not take part in the respective election. does not take part in the respective election.
5. Interface Classification 5. Interface Classification
5.1. Interface Categories 5.1. Interface Categories
HNCP specifies the following categories interfaces can be configured HNCP specifies the following categories that interfaces can be
to be in: configured to be in:
Internal category: This declares an interfaces to be internal, i.e., Internal category: This declares an interface to be internal, i.e.,
within the borders of the HNCP network. The interface MUST within the borders of the HNCP network. The interface MUST
operate as a DNCP endpoint. Routers MUST forward traffic with operate as a DNCP endpoint. Routers MUST forward traffic with
appropriate source addresses between their internal interfaces and appropriate source addresses between their internal interfaces and
allow internal traffic to reach external networks. All nodes MUST allow internal traffic to reach external networks. All nodes MUST
implement this category and nodes not implementing any other implement this category, and nodes not implementing any other
category implicitly use it as a fixed default. category implicitly use it as a fixed default.
External category: This declares an interface to be external, i.e., External category: This declares an interface to be external, i.e.,
not within the borders of the HNCP network. The interface MUST not within the borders of the HNCP network. The interface MUST
NOT operate as a DNCP endpoint. Accessing internal resources from NOT operate as a DNCP endpoint. Accessing internal resources from
external interfaces is restricted, i.e., the use of Recommended external interfaces is restricted, i.e., the use of Recommended
Simple Security Capabilities in CPEs [RFC6092] is RECOMMENDED. Simple Security Capabilities in Customer Premises Equipments
HNCP routers SHOULD announce acquired configuration information (CPEs) [RFC6092] is RECOMMENDED. HNCP routers SHOULD announce
for use in the network as described in Section 6.2, if the acquired configuration information for use in the network as
interface appears to be connected to an external network. HNCP described in Section 6.2, if the interface appears to be connected
routers MUST implement this category. to an external network. HNCP routers MUST implement this
category.
Leaf category: This declares an interface used by client devices Leaf category: This declares an interface used by client devices
only. Such an interface uses the Internal category with the only. Such an interface uses the Internal category with the
exception that it MUST NOT operate as a DNCP endpoint This exception that it MUST NOT operate as a DNCP endpoint. This
category SHOULD be supported by HNCP routers. category SHOULD be supported by HNCP routers.
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, HNCP routers MUST filter traffic from and to the category, HNCP routers MUST filter traffic from and to the
interface such that connected devices are unable to reach other interface such that connected devices are unable to reach other
devices inside the HNCP network or query services advertised by devices inside the HNCP network or query services advertised by
them unless explicitly allowed. This category SHOULD be supported them unless explicitly allowed. This category SHOULD be supported
by HNCP routers. by HNCP routers.
Ad-hoc category: This configures an interface to use the Internal Ad Hoc category: This configures an interface to use the Internal
category but no assumption is made about the the link's category, but no assumption is made about the link's transitivity.
transitivity. All other interface categories assume transitive All other interface categories assume transitive connectivity.
connectivity. This affects the Common Link (Section 6.1) This affects the Common Link (Section 6.1) definition. Support
definition. Support for this category is OPTIONAL. for this category is OPTIONAL.
Hybrid category: This declares an interface to use the Internal Hybrid category: This declares an interface to use the Internal
category while still trying to acquire (external) configuration category while still trying to acquire (external) configuration
information on it, e.g., by running DHCP clients. This is useful, information on it, e.g., by running DHCP clients. This is useful,
e.g., if the link is shared with a non-HNCP router under control e.g., if the link is shared with a non-HNCP router under control
and still within the borders of the same network. Detection of and still within the borders of the same network. Detection of
this category automatically in addition to manual configuration is this category automatically in addition to manual configuration is
out of scope of this document. Support for this category is out of scope of this document. Support for this category is
OPTIONAL. OPTIONAL.
5.2. DHCP Aided Auto-Detection 5.2. DHCP-Aided Auto-Detection
Auto-detection of interface categories is possible based on Auto-detection of interface categories is possible based on
interaction with DHCPv4 [RFC2131] and DHCPv6-PD [RFC3633] servers on interaction with DHCPv4 [RFC2131] and DHCPv6 Prefix Delegation
connected links. HNCP defines special DHCP behavior to differentiate (DHCPv6-PD) [RFC3633] servers on connected links. HNCP defines
its internal servers from external ones in order to achieve this. special DHCP behavior to differentiate its internal servers from
Therefore all internal devices (including HNCP nodes) running DHCP external ones in order to achieve this. Therefore, all internal
servers on links where auto-detection is used by any HNCP node MUST devices (including HNCP nodes) running DHCP servers on links where
use the following mechanism based on The User Class Option for DHCPv4 auto-detection is used by any HNCP node MUST use the following
[RFC3004] and its DHCPv6 counterpart [RFC3315]: mechanism based on "The User Class Option for DHCP" [RFC3004] and its
DHCPv6 counterpart [RFC3315]:
o The device MUST ignore or reject DHCP-Requests containing a DHCP o The device MUST ignore or reject DHCP-Requests containing a DHCP
User-Class consisting of the ASCII-String "HOMENET". user class consisting of the ASCII string "HOMENET".
Not following this rule (e.g., running unmodified DHCP servers) might Not following this rule (e.g., running unmodified DHCP servers) might
lead to false positives when auto-detection is used, i.e., HNCP nodes lead to false positives when auto-detection is used, i.e., HNCP nodes
assume an interface to not be internal, even though it was intended assume an interface to not be internal, even though it was intended
to be. to be.
5.3. Algorithm for Border Discovery 5.3. Algorithm for Border Discovery
This section defines the interface classification algorithm. It is This section defines the interface classification algorithm. It is
suitable for both IPv4 and IPv6 (single or dual-stack) and detects suitable for both IPv4 and IPv6 (single or dual stack) and detects
the category of an interface either automatically or based on a fixed the category of an interface either automatically or based on a fixed
configuration. By determining the category for all interfaces, the configuration. By determining the category for all interfaces, the
network borders are implicitly defined, i.e., all interfaces not network borders are implicitly defined, i.e., all interfaces not
belonging to the External category are considered to be within the belonging to the External category are considered to be within the
borders of the network, all others are not. borders of the network; all others are not.
The following algorithm MUST be implemented by any node implementing The following algorithm MUST be implemented by any node implementing
HNCP. However, if the node does not implement auto-detection, only HNCP. However, if the node does not implement auto-detection, only
the first and last step are required. The algorithm works as the first and last step are required. The algorithm works as
follows, with evaluation stopping at first match: follows, with evaluation stopping at first match:
1. If a fixed category is configured for an interface, it is used. 1. If a fixed category is configured for an interface, it is 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, it is considered external. The DHCPv6 client MUST have client, it is considered external. The DHCPv6 client MUST have
included a DHCPv6 User-Class consisting of the ASCII-String included a DHCPv6 user class consisting of the ASCII string
"HOMENET" in all of its requests. "HOMENET" in all of its requests.
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 is considered external. The DHCPv4 client on the interface, it is considered external. The DHCPv4 client
MUST have included a DHCP User-Class consisting of the ASCII- MUST have included a DHCP user class consisting of the ASCII
String "HOMENET" in all of its requests. string "HOMENET" in all of its requests.
4. The interface is considered internal. 4. The interface is considered internal.
Note that as other HNCP nodes will ignore the client due to the user Note that as other HNCP nodes will ignore the client due to the User
class option, any server that replies is clearly external (or a Class option, any server that replies is clearly external (or a
malicious internal node). malicious internal node).
An HNCP router SHOULD allow setting the fixed category for each An HNCP router SHOULD allow setting the fixed category for each
interface which may be connected to either an internal or external interface that may be connected to either an internal or external
device (e.g., an Ethernet port that can be connected to a modem, device (e.g., an Ethernet port that can be connected to a modem,
another HNCP router or a client). Note that all fixed categories another HNCP router, or a client). Note that all fixed categories
except internal and external cannot be auto-detected and can only be except internal and external cannot be auto-detected and can only be
selected using manual configuration. selected using manual configuration.
An HNCP router using auto-detection on an interface MUST run the An HNCP router using auto-detection on an interface MUST run the
appropriately configured DHCP clients as long as the interface appropriately configured DHCP clients as long as the interface
without a fixed category is active (including states where auto- without a fixed category is active (including states where auto-
detection considers it to be internal) and rerun the algorithm above detection considers it to be internal) and rerun the algorithm above
to react to conditions resulting in a different interface category. to react to conditions resulting in a different interface category.
The router SHOULD wait for a reasonable time period (5 seconds as a The router SHOULD wait for a reasonable time period (5 seconds as a
default), during which the DHCP clients can acquire a lease, before default), during which the DHCP clients can acquire a lease, before
treating a newly activated or previously external interface as treating a newly activated or previously external interface as
internal. internal.
6. Autonomous Address Configuration 6. Autonomous Address Configuration
This section specifies how HNCP nodes configure host and node This section specifies how HNCP nodes configure host and node
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 (Section 10.2). These contain other TLVs External-Connection TLVs (Section 10.2). These contain other TLVs
such as Delegated Prefix TLVs (Section 10.2.1) which are then used such as Delegated-Prefix TLVs (Section 10.2.1) that are then used for
for prefix assignment. Finally, HNCP nodes obtain addresses either prefix assignment. Finally, HNCP nodes obtain addresses either
statelessly or using a specific stateful mechanism (Section 6.4). statelessly or using a specific stateful mechanism (Section 6.4).
Hosts and non-HNCP routers are configured using SLAAC, DHCP or Hosts and non-HNCP routers are configured using SLAAC, DHCP, or
DHCPv6-PD. DHCPv6-PD.
6.1. Common Link 6.1. Common Link
HNCP uses the concept of Common Link both in autonomic address HNCP uses the concept of Common Link both in autonomic address
configuration and naming and service discovery (Section 8). A Common configuration and naming and service discovery (Section 8). A Common
Link refers to the set of interfaces of nodes that see each other's Link refers to the set of interfaces of nodes that see each other's
traffic and presumably also the traffic of all hosts that may use the traffic and presumably also the traffic of all hosts that may use the
nodes to, e.g., forward traffic. Common Links are used, e.g., to nodes to, e.g., forward traffic. Common Links are used, e.g., to
determine where prefixes should be assigned or which peers determine where prefixes should be assigned or which peers
participate in the election of a DHCP server. The Common Link is participate in the election of a DHCP server. The Common Link is
computed separately for each local internal interface, and it always computed separately for each local internal interface, and it always
contains the local interface. Additionally, if the local interface contains the local interface. Additionally, if the local interface
is not set to ad-hoc category (see Section 5.1), it also contains the is not set to the Ad Hoc category (see Section 5.1), it also contains
set of interfaces that are bidirectionally reachable from the given the set of interfaces that are bidirectionally reachable from the
local interface, that is, every remote interface of a remote node given local interface; that is, every remote interface of a remote
meeting all of the following requirements: node meeting all of the following requirements:
o The local node publishes a Peer TLV with: o The local node publishes a Peer TLV with:
* Peer Node Identifier = remote node's node identifier * Peer Node Identifier = remote node's node identifier
* Peer Endpoint Identifier = remote interface's endpoint * Peer Endpoint Identifier = remote interface's endpoint
identifier identifier
* Endpoint Identifier = local interface's endpoint identifier * Endpoint Identifier = local interface's endpoint identifier
skipping to change at page 12, line 46 skipping to change at page 13, line 14
* Endpoint Identifier = remote interface's endpoint identifier * Endpoint Identifier = remote interface's endpoint identifier
A node MUST be able to detect whether two of its local internal A node MUST be able to detect whether two of its local internal
interfaces are connected, e.g., by detecting an identical remote interfaces are connected, e.g., by detecting an identical remote
interface being part of the Common Links of both local interfaces. interface being part of the Common Links of both local interfaces.
6.2. External Connections 6.2. External Connections
Each HNCP router MAY obtain external connection information such as Each HNCP router MAY obtain external connection information such as
address prefixes, DNS server addresses and DNS search paths from one address prefixes, DNS server addresses, and DNS search paths 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. Each individual external connection to be static configuration. Each individual external connection to be
shared in the network is represented by one External Connection TLV shared in the network is represented by one External-Connection TLV
(Section 10.2). (Section 10.2).
Announcements of individual external connections can consist of the Announcements of individual external connections can consist of the
following components: following components:
Delegated Prefixes: address space available for assignment to Delegated Prefixes: Address space available for assignment to
internal links announced using Delegated Prefix TLVs internal links announced using Delegated-Prefix TLVs
(Section 10.2.1). Some address spaces might have special (Section 10.2.1). Some address spaces might have special
properties which are necessary to understand in order to handle properties that are necessary to understand in order to handle
them (e.g., information similar to [RFC6603]). This information them (e.g., information similar to [RFC6603]). This information
is encoded using DHCPv6 Data TLVs (Section 10.2.2) inside the is encoded using DHCPv6-Data TLVs (Section 10.2.2) inside the
respective Delegated Prefix TLVs. respective Delegated-Prefix TLVs.
Auxiliary Information: information about services such as DNS or Auxiliary Information: Information about services such as DNS or
time synchronization regularly used by hosts in addition to time synchronization regularly used by hosts in addition to
addressing and routing information. This information is encoded addressing and routing information. This information is encoded
using DHCPv6 Data TLVs (Section 10.2.2) and DHCPv4 Data TLVs using DHCPv6-Data TLVs (Section 10.2.2) and DHCPv4-Data TLVs
(Section 10.2.3). (Section 10.2.3).
Whenever information about reserved parts (e.g., as specified in Whenever information about reserved parts (e.g., as specified in
[RFC6603]) is received for a delegated prefix, the reserved parts [RFC6603]) is received for a delegated prefix, the reserved parts
MUST be advertised using Assigned Prefix TLVs (Section 10.3) with the MUST be advertised using Assigned-Prefix TLVs (Section 10.3) with the
highest priority (i.e., 15), as if they were assigned to a Private greatest priority (i.e., 15), as if they were assigned to a Private
Link. Link.
Some connections or delegated prefixes may have a special meaning and Some connections or delegated prefixes may have a special meaning and
are not regularly used for internal or internet connectivity, instead are not regularly used for internal or Internet connectivity;
they may provide access to special services like VPNs, sensor instead, they may provide access to special services like VPNs,
networks, VoIP, IPTV, etc. Care must be taken that these prefixes sensor networks, Voice over IP (VoIP), IPTV, etc. Care must be taken
are properly integrated and dealt with in the network, in order to that these prefixes are properly integrated and dealt with in the
avoid breaking connectivity for devices who are not aware of their network, in order to avoid breaking connectivity for devices who are
special characteristics or to only selectively allow certain devices not aware of their special characteristics or to only selectively
to use them. Such prefixes are distinguished using Prefix Policy allow certain devices to use them. Such prefixes are distinguished
TLVs (Section 10.2.1.1). Their contents MAY be partly opaque to HNCP using Prefix-Policy TLVs (Section 10.2.1.1). Their contents MAY be
nodes, and their identification and usage depends on local policy. partly opaque to HNCP nodes, and their identification and usage
However the following general rules MUST be adhered to: depends on local policy. However, the following general rules MUST
be adhered to:
Special rules apply when making address assignments for prefixes Special rules apply when making address assignments for prefixes
with Prefix Policy TLVs with type 131, as described in with Prefix-Policy TLVs with type 131, as described in
Section 6.3.2 Section 6.3.2.
In presence of any type 1 to 128 Prefix Policy TLV the prefix is In the presence of any type 1 to 128 Prefix-Policy TLV, the prefix
specialized to reach destinations denoted by any such Prefix is specialized to reach destinations denoted by any such Prefix-
Policy TLV, i.e., in absence of a type 0 Prefix Policy TLV it is Policy TLV, i.e., in absence of a type 0 Prefix-Policy TLV, it is
not usable for general internet connectivity. An HNCP router MAY not usable for general Internet connectivity. An HNCP router MAY
enforce this restriction with appropriate packet filter rules. enforce this restriction with appropriate packet filter rules.
6.3. Prefix Assignment 6.3. Prefix Assignment
HNCP uses the Prefix Assignment Algorithm [RFC7695] in order to HNCP uses the prefix assignment algorithm [RFC7695] in order to
assign prefixes to HNCP internal links and uses some of the assign prefixes to HNCP internal links and uses some of the
terminology (Section 2) defined there. HNCP furthermore defines the terminology (Section 2) defined there. HNCP furthermore defines the
Assigned Prefix TLV (Section 10.3) which MUST be used to announce Assigned-Prefix TLV (Section 10.3), which MUST be used to announce
Published Assigned Prefixes. Published Assigned Prefixes.
6.3.1. Prefix Assignment Algorithm Parameters 6.3.1. Prefix Assignment Algorithm Parameters
All HNCP nodes running the prefix assignment algorithm use the All HNCP nodes running the prefix assignment algorithm use the
following values for its parameters: following values for its parameters:
Node IDs: HNCP node identifiers are used. The comparison operation Node IDs: HNCP node identifiers are used. The comparison operation
is defined as bit-wise comparison. is defined as bitwise comparison.
Set of Delegated Prefixes: The set of prefixes encoded in Delegated Set of Delegated Prefixes: The set of prefixes encoded in
Prefix TLVs which are not strictly included in prefixes encoded in Delegated-Prefix TLVs that are not strictly included in prefixes
other Delegated Prefix TLVs. Note that Delegated Prefix TLVs encoded in other Delegated-Prefix TLVs. Note that Delegated-
included in ignored External Connection TLVs are not considered. Prefix TLVs included in ignored External-Connection TLVs are not
It is dynamically updated as Delegated Prefix TLVs are added or considered. It is dynamically updated as Delegated-Prefix TLVs
removed. are added or removed.
Set of Shared Links: The set of Common Links associated with Set of Shared Links: The set of Common Links associated with
interfaces with internal, leaf, guest or ad-hoc category. It is interfaces with the Internal, Leaf, Guest, or Ad Hoc category. It
dynamically updated as interfaces are added, removed, or switch is dynamically updated as interfaces are added, removed, or
from one category to another. When multiple interfaces are switched from one category to another. When multiple interfaces
detected as belonging to the same Common Link, prefix assignment are detected as belonging to the same Common Link, prefix
is disabled on all of these interfaces except one. assignment is disabled on all of these interfaces except one.
Set of Private Links: This document defines Private Links Set of Private Links: This document defines Private Links as
representing DHCPv6-PD clients or as a mean to advertise prefixes representing DHCPv6-PD clients or as a mean to advertise prefixes
included in the DHCPv6 Exclude Prefix option. Other included in the DHCPv6 Exclude Prefix option. Other
implementation-specific Private Links may be defined whenever a implementation-specific Private Links may be defined whenever a
prefix needs to be assigned for a purpose that does not require a prefix needs to be assigned for a purpose that does not require a
consensus with other HNCP nodes. consensus with other HNCP nodes.
Set of Advertised Prefixes: The set of prefixes included in Set of Advertised Prefixes: The set of prefixes included in
Assigned Prefix TLVs advertised by other HNCP nodes (Prefixes Assigned-Prefix TLVs advertised by other HNCP nodes (prefixes
advertised by the local node are not in this set). The associated advertised by the local node are not in this set). The associated
Advertised Prefix Priority is the priority specified in the TLV. Advertised Prefix Priority is the priority specified in the TLV.
The associated Shared Link is determined as follows: The associated Shared Link is determined as follows:
* If the Link Identifier is zero, the Advertised Prefix is not * If the Link Identifier is 0, the Advertised Prefix is not
assigned on a Shared Link. assigned on a Shared Link.
* If the other node's interface identified by the Link Identifier * If the other node's interface identified by the Link Identifier
is included in one of the Common Links used for prefix is included in one of the Common Links used for prefix
assignment, it is considered as assigned on the given Common assignment, it is considered as assigned on the given Common
Link. Link.
* Otherwise, the Advertised Prefix is not assigned on a Shared * Otherwise, the Advertised Prefix is not assigned on a Shared
Link. Link.
Advertised Prefixes as well as their associated priorities and Advertised Prefixes as well as their associated priorities and
associated Shared Links MUST be updated as Assigned Prefix TLVs associated Shared Links MUST be updated as Assigned-Prefix TLVs
are added, updated or removed, and as Common Links are modified. are added, updated, or removed, and as Common Links are modified.
ADOPT_MAX_DELAY: The default value is 0 seconds (i.e., prefix ADOPT_MAX_DELAY: The default value is 0 seconds (i.e., prefix
adoption is done instantly). adoption is done instantly).
BACKOFF_MAX_DELAY: The default value is 4 seconds. BACKOFF_MAX_DELAY: The default value is 4 seconds.
RANDOM_SET_SIZE: The default value is 64. RANDOM_SET_SIZE: The default value is 64.
Flooding Delay: The default value is 5 seconds. Flooding Delay: The default value is 5 seconds.
Default Advertised Prefix Priority: When a new assignment is Default Advertised Prefix Priority: When a new assignment is
created or an assignment is adopted - as specified in the prefix created or an assignment is adopted -- as specified in the prefix
assignment algorithm routine - the default Advertised Prefix assignment algorithm routine -- the default Advertised Prefix
Priority to be used is 2. Priority to be used is 2.
6.3.2. Making New Assignments 6.3.2. Making New Assignments
Whenever the prefix assignment algorithm subroutine (Section 4.1 of Whenever the prefix assignment algorithm subroutine (Section 4.1 of
[RFC7695]) is run on a Common Link and whenever a new prefix may be [RFC7695]) is run on a Common Link, and whenever a new prefix may be
assigned (case 1 of the subroutine: no Best Assignment and no Current assigned (case 1 of the subroutine: no Best Assignment and no Current
Assignment), the decision of whether the assignment of a new prefix Assignment), the decision of whether the assignment of a new prefix
is desired MUST follow these rules in order: is desired MUST follow these rules in order:
If the Delegated Prefix TLV contains a DHCPv6 Data TLV, and the If the Delegated-Prefix TLV contains a DHCPv6-Data TLV, and the
meaning of one of the DHCP options is not understood by the HNCP meaning of one of the DHCP options is not understood by the HNCP
node, the creation of a new prefix is not desired. This rule node, the creation of a new prefix is not desired. This rule
applies to TLVs inside Delegated Prefix TLVs but not to those applies to TLVs inside Delegated-Prefix TLVs but not to those
inside External Connection TLVs. inside External-Connection TLVs.
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-zero preferred lifetime, the creation of a assignment with a non-zero preferred lifetime, the creation of a
new prefix is not desired. new prefix is not desired.
If the Delegated Prefix does not include a Prefix Policy TLV If the Delegated-Prefix TLV does not include a Prefix-Policy TLV
indicating restrictive assignment (type 131) or if local policy indicating restrictive assignment (type 131) or if local policy
exists to identify it based on, e.g., other Prefix Policy TLV exists to identify it based on, e.g., other Prefix-Policy TLV
values and allows assignment, the creation of a new prefix is values and allows assignment, the creation of a new prefix is
desired. desired.
Otherwise, the creation of a new prefix is not desired. Otherwise, the creation of a new prefix is not 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. In case no length 64 MUST be selected unless configured otherwise. In case no
prefix of length 64 would be available, a longer prefix MAY be prefix of length 64 would be available, a longer prefix MAY be
selected even without configuration. selected even without configuration.
If the considered delegated prefix is an IPv4 prefix (Section 6.5 If the considered delegated prefix is an IPv4 prefix (Section 6.5
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, an HNCP router making an assignment MUST support a In any case, an HNCP router making an assignment MUST support a
mechanism suitable to distribute addresses from the considered prefix mechanism suitable to distribute addresses from the considered prefix
if the link is intended to be used by clients. In this case a router if the link is intended to be used by clients. In this case, a
assigning an IPv4 prefix MUST announce the L-capability and a router router assigning an IPv4 prefix MUST announce the L-capability, and a
assigning an IPv6 prefix with a length greater than 64 MUST announce router assigning an IPv6 prefix with a length greater than 64 MUST
the H-capability as defined in Section 4. announce the H-capability as defined in Section 4.
6.3.3. Applying Assignments 6.3.3. 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 forward traffic destined to said prefix to the respective MUST forward traffic destined to said prefix to the respective
link. link.
MUST participate in the client configuration election as described MUST participate in the client configuration election as described
in Section 7, if the link is intended to be used by clients. in Section 7, if the link is intended to be used by clients.
MAY add an address from said prefix to the respective network MAY add an address from said prefix to the respective network
interface as described in Section 6.4, e.g., if it is to be used interface as described in Section 6.4, e.g., if it is to be used
as source for locally originating traffic. as source for locally originating traffic.
6.3.4. DHCPv6 Prefix Delegation 6.3.4. DHCPv6 Prefix Delegation
When an HNCP router announcing the P-Capability (Section 4) receives When an HNCP router announcing the P-Capability (Section 4) receives
a DHCPv6-PD request from a client, it SHOULD assign one prefix per a DHCPv6-PD request from a client, it SHOULD assign one prefix per
delegated prefix in the network. This set of assigned prefixes is delegated prefix in the network. This set of assigned prefixes is
then delegated to the client, after it has been applied as described then delegated to the client, after it has been applied as described
in the prefix assignment algorithm. Each DHCPv6-PD client MUST be in the prefix assignment algorithm. Each DHCPv6-PD client MUST be
considered as an independent Private Link and delegation MUST be considered as an independent Private Link, and delegation MUST be
based on the same set of Delegated Prefixes as the one used for based on the same set of delegated prefixes as the one used for
Common Link prefix assignments, however the prefix length to be Common Link prefix assignments; however, the prefix length to be
delegated MAY be smaller than 64. delegated MAY be smaller than 64.
The assigned prefixes MUST NOT be given to DHCPv6-PD clients before The assigned prefixes MUST NOT be given to DHCPv6-PD clients before
they are applied, and MUST be withdrawn whenever they are destroyed. they are applied and MUST be withdrawn whenever they are destroyed.
As an exception to this rule, in order to shorten delays of processed As an exception to this rule, in order to shorten delays of processed
requests, a router MAY prematurely give out a prefix which is requests, a router MAY prematurely give out a prefix that is
advertised but not yet applied if it does so with a valid lifetime of advertised but not yet applied if it does so with a valid lifetime of
not more than 30 seconds and ensures removal or correction of not more than 30 seconds and ensures removal or correction of
lifetimes as soon as possible. lifetimes as soon as possible.
6.4. Node Address Assignment 6.4. 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 from any use. Nodes MAY, at any time, try to reserve a new address from any
Applied Assigned Prefix. Each HNCP node SHOULD announce an IPv6 Applied Assigned Prefix. Each HNCP node SHOULD announce an IPv6
address and - if it supports IPv4 - MUST announce an IPv4 address, address and -- if it supports IPv4 -- MUST announce an IPv4 address,
whenever matching prefixes are assigned to at least one of its Common whenever matching prefixes are assigned to at least one of its Common
Links. These addresses are published using Node Address TLVs and Links. These addresses are published using Node-Address TLVs and
used to locally reach HNCP nodes for other services. Nodes SHOULD used to locally reach HNCP nodes for other services. Nodes SHOULD
NOT create and announce more than one assignment per IP version to NOT create and announce more than one assignment per IP version to
avoid cluttering the node data with redundant information unless a avoid cluttering the node data with redundant information unless a
special use case requires it. special use case requires it.
Stateless assignment based on Semantically Opaque Interface Stateless assignment based on Semantically Opaque Interface
Identifiers [RFC7217] SHOULD be used for address assignment whenever Identifiers [RFC7217] SHOULD be used for address assignment whenever
possible (e.g., the prefix length is 64), otherwise (e.g., for IPv4 possible (e.g., the prefix length is 64), otherwise (e.g., for IPv4
if supported) the following method MUST be used instead: For any if supported) the following method MUST be used instead: For any
assigned prefix for which stateless assignment is not used, the first assigned prefix for which stateless assignment is not used, the first
quarter of the addresses are reserved for HNCP based address quarter of the addresses are reserved for HNCP-based address
assignments, whereas the last three quarters are left to the DHCP assignments, whereas the last three quarters are left to the DHCP
elected router (Section 4 specifies the DHCP server election elected router (Section 4 specifies the DHCP server election
process). For example, if the prefix 192.0.2.0/24 is assigned and process). For example, if the prefix 192.0.2.0/24 is assigned and
applied to a Common Link, addresses included in 192.0.2.0/26 are applied to a Common Link, addresses included in 192.0.2.0/26 are
reserved for HNCP nodes and the remaining addresses are reserved for reserved for HNCP nodes, and the remaining addresses are reserved for
the elected DHCPv4 server. the elected DHCPv4 server.
HNCP nodes assign themselves addresses, and then (to ensure eventual HNCP nodes assign addresses to themselves and then (to ensure
lack of conflicting assignments) publish the assignments using the eventual lack of conflicting assignments) publish the assignments
Node Address TLV (Section 10.4). using the Node-Address TLV (Section 10.4).
The process of obtaining addresses is specified as follows: The process of obtaining addresses is specified as follows:
o A node MUST NOT start advertising an address if it is already o A node MUST NOT start advertising an address if it is already
advertised by another node. advertised by another node.
o An assigned address MUST be part of an assigned prefix currently o An assigned address MUST be part of an assigned prefix currently
applied on a Common Link which includes the interface specified by applied on a Common Link that includes the interface specified by
the endpoint identifier. 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 greatest node
identifier MUST be removed. identifier MUST be removed.
6.5. Local IPv4 and ULA Prefixes 6.5. Local IPv4 and ULA Prefixes
HNCP routers can create a Unique Local Address (ULA) or private IPv4 HNCP routers can create a Unique Local Address (ULA) or private IPv4
prefix to enable connectivity between local devices. These prefixes prefix to enable connectivity between local devices. These prefixes
are inserted in HNCP as if they were delegated prefixes of a are inserted in HNCP as if they were delegated prefixes of a
(virtual) external connection (Section 6.2). The following rules (virtual) external connection (Section 6.2). The following rules
apply: apply:
An HNCP router SHOULD create a ULA prefix if there is no other An HNCP router SHOULD create a ULA prefix if there is no other
IPv6 prefix with a preferred time greater than 0 in the network. IPv6 prefix with a preferred time greater than 0 in the network.
It MAY also do so, if there are other delegated IPv6 prefixes, but It MAY also do so if there are other delegated IPv6 prefixes, but
none of which is locally generated (i.e., without any Prefix none of which is locally generated (i.e., without any Prefix-
Policy TLV) and has a preferred time greater than 0. However, it Policy TLV) and has a preferred time greater than 0. However, it
MUST NOT do so otherwise. In case multiple locally generated ULA MUST NOT do so otherwise. In case multiple locally generated ULA
prefixes are present, only the one published by the node with the prefixes are present, only the one published by the node with the
highest node identifier is kept among those with a preferred time greatest node identifier is kept among those with a preferred time
greater than 0 - if there is any. greater than 0 -- if there is any.
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, only the one published by the node with prefixes are announced, only the one published by the node with
the highest node identifier is kept among those with a Prefix the greatest node identifier is kept among those with a Prefix-
Policy of type 0 - if there is any. The router publishing a Policy TLV of type 0 -- if there is any. The router publishing a
prefix with internet connectivity MUST forward IPv4 traffic to the prefix with Internet connectivity MUST forward IPv4 traffic to the
internet and perform NAT on behalf of the network as long as it Internet and perform NAT on behalf of the network as long as it
publishes the prefix, other routers in the network MAY choose not publishes the prefix; other routers in the network MAY choose not
to. to.
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 time span between 0 and 10 seconds in which the router MUST scan for
others trying to do the same. others 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, a Since DHCP clients can usually only bind to one server at a time, a
per-link and per-service 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 4 in therefore indicate its capabilities as specified in Section 4 in
order to participate as a candidate in the election. order to participate as a candidate in the election.
7.1. IPv6 Addressing and Configuration 7.1. IPv6 Addressing and Configuration
In general Stateless Address Autoconfiguration [RFC4861] is used for In general, Stateless Address Autoconfiguration [RFC4861] is used for
client configuration for its low overhead and fast renumbering client configuration for its low overhead and fast renumbering
capabilities. Therefore each HNCP router sends Router Advertisements capabilities. Therefore, each HNCP router sends Router
on interfaces which are intended to be used by clients and MUST at Advertisements on interfaces that are intended to be used by clients
least include a Prefix Information Option for each Applied Assigned and MUST at least include a Prefix Information Option for each
Prefix which it assigned to the respective link in every such Applied Assigned Prefix that it assigned to the respective link in
advertisement. However, stateful DHCPv6 can be used in addition by every such advertisement. However, stateful DHCPv6 can be used in
administrative choice, to, e.g., collect hostnames and use them to addition by administrative choice to, e.g., collect hostnames and use
provide naming services or whenever stateless configuration is not them to provide naming services or whenever stateless configuration
applicable. is not applicable.
The designated stateful DHCPv6 server for a Common Link (Section 6.1) The designated stateful DHCPv6 server for a Common Link (Section 6.1)
is elected based on the capabilities described in Section 4. The is elected based on the capabilities described in Section 4. The
winner is the router (connected to the Common Link) advertising the winner is the router (connected to the Common Link) advertising the
greatest H-capability. In case of a tie, Capability Values greatest H-capability. In case of a tie, Capability Values
(Section 4) are compared, and the router with the greatest value is (Section 4) are compared, and the router with the greatest value is
elected. In case of another tie, the router with the highest node elected. In case of another tie, the router with the greatest node
identifier is elected among the routers with tied Capability Values. identifier is elected among the routers with tied Capability Values.
The elected router MUST serve stateful DHCPv6 and SHOULD provide The elected router MUST serve stateful DHCPv6 and SHOULD provide
naming services for acquired hostnames as outlined in Section 8, all naming services for acquired hostnames as outlined in Section 8; all
others nodes MUST NOT. Stateful addresses SHOULD be assigned in a other nodes MUST NOT. Stateful addresses SHOULD be assigned in a way
way not hindering fast renumbering even if the DHCPv6 server or that does not hinder fast renumbering even if the DHCPv6 server or
client do not support the DHCPv6 reconfigure mechanism, e.g., by only client do not support the DHCPv6 reconfigure mechanism, e.g., by only
handing out leases from locally-generated (ULA) prefixes and prefixes handing out leases from locally generated (ULA) prefixes and prefixes
with a length different from 64, and by using low renew and rebind with a length different from 64 and by using low renew and rebind
times (i.e., not longer than 5 minutes). In case no router was times (i.e., not longer than 5 minutes). In case no router was
elected, stateful DHCPv6 is not provided. Routers which cease to be elected, stateful DHCPv6 is not provided. Routers that cease to be
elected DHCP servers SHOULD - when applicable - invalidate remaining elected DHCP servers SHOULD -- when applicable -- invalidate
existing bindings in order to trigger client reconfiguration. remaining existing bindings in order to trigger client
reconfiguration.
7.2. DHCPv6 for Prefix Delegation 7.2. DHCPv6 for Prefix Delegation
The designated DHCPv6 server for prefix-delegation on a Common Link The designated DHCPv6 server for prefix delegation on a Common Link
is elected based on the capabilities described in Section 4. The is elected based on the capabilities described in Section 4. The
winner is the router (connected to the Common Link) advertising the winner is the router (connected to the Common Link) advertising the
greatest P-capability. In case of a tie, Capability Values greatest P-capability. In case of a tie, Capability Values
(Section 4) are compared, and the router with the greatest value is (Section 4) are compared, and the router with the greatest value is
elected. In case of another tie, the router with the highest node elected. In case of another tie, the router with the greatest node
identifier is elected among the routers with tied Capability Values. identifier is elected among the routers with tied Capability Values.
The elected router MUST provide prefix-delegation services [RFC3633] The elected router MUST provide prefix delegation services [RFC3633]
on the given link (and follow the rules in Section 6.3.4), all other on the given link (and follow the rules in Section 6.3.4); all other
nodes MUST NOT. nodes MUST NOT.
7.3. DHCPv4 for Addressing and Configuration 7.3. DHCPv4 for Addressing and Configuration
The designated DHCPv4 server on a Common Link (Section 6.1) is The designated DHCPv4 server on a Common Link (Section 6.1) is
elected based on the capabilities described in Section 4. The winner elected based on the capabilities described in Section 4. The winner
is the router (connected to the Common Link) advertising the greatest is the router (connected to the Common Link) advertising the greatest
L-capability. In case of a tie, Capability Values (Section 4) are L-capability. In case of a tie, Capability Values (Section 4) are
compared, and the router with the greatest value is elected. In case compared, and the router with the greatest value is elected. In case
of another tie, the router with the highest node identifier is of another tie, the router with the greatest node identifier is
elected among the routers with tied Capability Values. elected among the routers with tied Capability Values.
The elected router MUST provide DHCPv4 services on the given link, The elected router MUST provide DHCPv4 services on the given link;
all other nodes MUST NOT. The elected router MUST provide IP all other nodes MUST NOT. The elected router MUST provide IP
addresses from the pool defined in Section 6.4 and MUST announce addresses from the pool defined in Section 6.4 and MUST announce
itself as router [RFC2132] to clients. itself as router [RFC2132] to clients.
DHCPv4 lifetimes renew and rebind times (T1 and T2) SHOULD be short DHCPv4 lifetimes renew and rebind times (T1 and T2) SHOULD be short
(i.e., not longer than 5 minutes) in order to provide reasonable (i.e., not longer than 5 minutes) in order to provide reasonable
response times to changes. Routers which cease to be elected DHCP response times to changes. Routers that cease to be elected DHCP
servers SHOULD - when applicable - invalidate remaining existing servers SHOULD -- when applicable -- invalidate remaining existing
bindings in order to trigger client reconfiguration. bindings in order to trigger client reconfiguration.
7.4. Multicast DNS Proxy 7.4. Multicast DNS Proxy
The designated MDNS [RFC6762] proxy on a Common Link is elected based The designated Multicast DNS (mDNS) [RFC6762] proxy on a Common Link
on the capabilities described in Section 4. The winner is the router is elected based on the capabilities described in Section 4. The
(connected to the Common Link) advertising the greatest M-capability. winner is the router (connected to the Common Link) advertising the
In case of a tie, Capability Values (Section 4) are compared, and the greatest M-capability. In case of a tie, Capability Values
router with the greatest value is elected. In case of another tie, (Section 4) are compared, and the router with the greatest value is
the router with the highest node identifier is elected among the elected. In case of another tie, the router with the greatest node
routers with tied Capability Values. identifier is elected among the routers with tied Capability Values.
The elected router MUST provide an MDNS-proxy on the given link and The elected router MUST provide an mDNS proxy on the given link and
announce it as described in Section 8. 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 a network. The following mechanism provides user friendliness of a network. The following mechanism provides
means to setup and delegate naming and service discovery across means to setup and delegate naming and service discovery across
multiple HNCP routers. multiple HNCP routers.
Each HNCP router SHOULD provide and advertise a recursive name Each HNCP router SHOULD provide and advertise a recursive name
resolving server to clients which honors the announcements made in resolving server to clients that honor the announcements made in
Delegated Zone TLVs (Section 10.5), Domain Name TLVs (Section 10.6) Delegated-Zone TLVs (Section 10.5), Domain-Name TLVs (Section 10.6),
and Node Name TLVs (Section 10.7), i.e., delegate queries to the and Node-Name TLVs (Section 10.7), i.e., delegate queries to the
designated name servers and hand out appropriate A, AAAA and PTR designated name servers and hand out appropriate A, AAAA, and PTR
records according to the mentioned TLVs. records according to the mentioned TLVs.
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 6.1) for user-configured name for each internal Common Link (Section 6.1) for
which it is the designated DHCPv4, stateful DHCPv6 server, MDNS which it is the designated DHCPv4, stateful DHCPv6 server, mDNS
proxy, or for which it provides forward or reverse DNS services on proxy, or for which it provides forward or reverse DNS services on
behalf of connected devices. This announcement is done using behalf of connected devices. This announcement is done using
Delegated Zone TLVs (Section 10.5) and MUST be unique in the whole Delegated-Zone TLVs (Section 10.5) and MUST be unique in the whole
network. In case of a conflict the announcement of the node with the network. In case of a conflict, the announcement of the node with
highest node identifier takes precedence and all other nodes MUST the greatest node identifier takes precedence, and all other nodes
cease to announce the conflicting TLV. HNCP routers providing MUST cease to announce the conflicting TLV. HNCP routers providing
recursive name resolving services MUST use the included DNS server recursive name resolving services MUST use the included DNS server
address within the TLV to resolve names belonging to the zone as if address within the TLV to resolve names belonging to the zone as if
there was an NS record. there was an NS record.
Each HNCP node SHOULD announce a node name for itself to be easily Each HNCP node SHOULD announce a node name for itself to be easily
reachable and MAY announce names on behalf of other devices. reachable and MAY announce names on behalf of other devices.
Announcements are made using Node Name TLVs (Section 10.7) and the Announcements are made using Node-Name TLVs (Section 10.7), and the
announced names MUST be unique in the whole network. In case of a announced names MUST be unique in the whole network. In case of a
conflict the announcement of the node with the highest node conflict, the announcement of the node with the greatest node
identifier takes precedence and all other nodes MUST cease to identifier takes precedence, and all other nodes MUST cease to
announce the conflicting TLV. HNCP routers providing recursive name announce the conflicting TLV. HNCP routers providing recursive name
resolving services as described above MUST resolve such announced resolving services as described above MUST resolve such announced
names to their respective IP addresses as if there were corresponding names to their respective IP addresses as if there were corresponding
A/AAAA records. A/AAAA records.
Names and unqualified zones are used in an HNCP network to provide Names and unqualified zones are used in an HNCP network to provide
naming and service discovery with local significance. A network-wide naming and service discovery with local significance. A network-wide
zone is appended to all single labels or unqualified zones in order zone is appended to all single labels or unqualified zones in order
to qualify them. ".home" is the default, however an administrator MAY to qualify them. ".home" is the default; however, an administrator
configure announcing of a Domain Name TLV (Section 10.6) for the MAY configure the announcement of a Domain-Name TLV (Section 10.6)
network to use a different one. In case multiple are announced, the for the network to use a different one. In case multiple are
domain of the node with the greatest node identifier takes announced, the domain of the node with the greatest node identifier
precedence. takes precedence.
9. Securing Third-Party Protocols 9. Securing Third-Party Protocols
Pre-shared keys (PSKs) are often required to secure (for example) PSKs are often required to secure (for example) IGPs and other
IGPs and other protocols which lack support for asymmetric security. protocols that lack support for asymmetric security. The following
The following mechanism manages PSKs using HNCP to enable mechanism manages PSKs using HNCP to enable bootstrapping of such
bootstrapping of such third-party protocols. The scheme SHOULD NOT third-party protocols. The scheme SHOULD NOT be used unless it's in
be used unless in conjunction with secured HNCP unicast transport conjunction with secured HNCP unicast transport (i.e., DTLS), as
(i.e., DTLS), as transferring the PSK in plain-text anywhere in the transferring the PSK in plaintext anywhere in the network is a
network is a potential risk, especially as the originator may not potential risk, especially as the originator may not know about
know about security (and use of DNCP security) on all links. The security (and use of DNCP security) on all links. The following
following rules define how such a PSK is managed and used: rules define how such a PSK is managed and used:
o If no Managed PSK TLV (Section 10.8) is currently being announced, o If no Managed-PSK TLV (Section 10.8) is currently being announced,
an HNCP node using this mechanism MUST create one after a random an HNCP node using this mechanism MUST create one after a random
delay of 0 to 10 seconds with a 32 bytes long random key and add delay of 0 to 10 seconds with a 32 bytes long random key and add
it to its node data. it to its node data.
o In case multiple nodes announce such a TLV at the same time, all o In case multiple nodes announce such a TLV at the same time, all
but the one with the greatest 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 node currently advertising the Managed PSK TLV MUST generate o The node 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
removed from the DNCP topology as described in the Section 4.6 of removed from the DNCP topology as described in Section 4.6 of
[I-D.ietf-homenet-dncp]. [RFC7787].
PSKs for individual protocols SHOULD be derived from the random PSK PSKs for individual protocols SHOULD be derived from the random PSK
using a suitable one-way hashing algorithm (e.g., by using HMAC- using a suitable one-way hashing algorithm (e.g., by using the HMAC-
SHA256 based HKDF [RFC6234] with the particular protocol name in the based Key Derivation Function (HKDF) based on HMAC-SHA256 [RFC6234]
info field) so that disclosure of any derived key does not impact with the particular protocol name in the info field) so that
other users of the managed PSK. Furthermore derived PSKs MUST be disclosure of any derived key does not impact other users of the
updated whenever the managed PSK changes. managed PSK. Furthermore, derived PSKs MUST be updated whenever the
managed PSK changes.
10. Type-Length-Value Objects 10. Type-Length-Value Objects
HNCP defines the following TLVs in addition to those defined by DNCP. HNCP defines the following TLVs in addition to those defined by DNCP.
The same general rules and defaults for encoding as noted in The same general rules and defaults for encoding as noted in
Section 7 of [I-D.ietf-homenet-dncp] apply. Note that most HNCP Section 7 of [RFC7787] apply. Note that most HNCP variable-length
variable-length TLVs also support optional nested TLVs, and they are TLVs also support optional nested TLVs, and they are encoded after
encoded after the variable length content, followed by the zero the variable-length content, followed by the zero padding of the
padding of the variable length content to the next 32-bit boundary. variable-length content to the next 32-bit boundary.
TLVs defined here are only valid when appearing in their designated TLVs defined here are only valid when appearing in their designated
context, i.e., only directly within container TLVs mentioned in their context, i.e., only directly within container TLVs mentioned in their
definition, or - absent any mentions - only as top-level TLVs within definition or -- absent any mentions -- only as top-level TLVs within
the node data set. TLVs appearing outside their designated context the node data set. TLVs appearing outside their designated context
MUST be ignored. MUST be ignored.
TLVs encoding IP addresses or prefixes allow encoding both IPv6 and TLVs encoding IP addresses or prefixes allow encoding both IPv6 and
IPv4 addresses and prefixes. IPv6 information is encoded as is, IPv4 addresses and prefixes. IPv6 information is encoded as is,
whereas for IPv4 IPv4-mapped IPv6 addresses format [RFC4291] is used whereas for IPv4, the IPv4-mapped IPv6 addresses format [RFC4291] is
and prefix lengths are encoded as original IPv4 prefix length used, and prefix lengths are encoded as the original IPv4 prefix
increased by 96. length increased by 96.
10.1. HNCP Version TLV 10.1. HNCP-Version 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: HNCP-VERSION (32) | Length: >= 5 | | Type: HNCP-Version (32) | Length: >= 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | M | P | H | L | | Reserved | M | P | H | L |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-agent | | User-agent |
This TLV is used to indicate the supported version and router This TLV is used to indicate the supported version and router
capabilities of an HNCP node as described in Section 4. capabilities of an HNCP node as described in Section 4.
Reserved: Bits are reserved for future use. They MUST be set to Reserved: Bits are reserved for future use. They MUST be set to 0
zero when creating this TLV, and their value MUST be ignored when when creating this TLV, and their value MUST be ignored when
processing the TLV. 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 0 if the router is not capable [RFC6762] proxy. It MUST be set to 0 if the router is not capable
of proxying MDNS, otherwise it SHOULD be set to 4 but MAY be set of proxying mDNS, otherwise it SHOULD be set to 4 but MAY be set
to any value from 1 to 7 to indicate a non-default priority. The to any value from 1 to 7 to indicate a non-default priority. The
values 8-15 are reserved for future use. values 8-15 are reserved for future 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 0 if the router is not capable of server. It MUST be set to 0 if the router is not capable of
providing prefixes through DHCPv6-PD (Section 6.3.4), otherwise it providing prefixes through DHCPv6-PD (Section 6.3.4), otherwise it
SHOULD be set to 4 but MAY be set to any value from 1 to 7 to SHOULD be set to 4 but MAY be set to any value from 1 to 7 to
indicate a non-default priority. The values 8-15 are reserved for indicate a non-default priority. The values 8-15 are reserved for
future use. future use.
skipping to change at page 24, line 4 skipping to change at page 24, line 29
server offering non-temporary addresses. It MUST be set to 0 if server offering non-temporary addresses. It MUST be set to 0 if
the router is not capable of providing such addresses, otherwise the router is not capable of providing such addresses, otherwise
it SHOULD be set to 4 but MAY be set to any value from 1 to 7 to it SHOULD be set to 4 but MAY be set to any value from 1 to 7 to
indicate a non-default priority. The values 8-15 are reserved for indicate a non-default priority. The values 8-15 are reserved for
future use. 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 0 if the router is not capable of server. It MUST be set to 0 if the router is not capable of
running a legacy DHCPv4 server offering IPv4 addresses to clients, running a legacy DHCPv4 server offering IPv4 addresses to clients,
otherwise it SHOULD be set to 4 but MAY be set to any value from 1 otherwise it SHOULD be set to 4 but MAY be set to any value from 1
to 7 to indicate a non-default priority. The values 8-15 are to 7 to indicate a non-default priority. The values 8-15 are
reserved for future use. reserved for future use.
User-Agent: The user-agent is a human-readable UTF-8 string that User-Agent: The user-agent is a human-readable UTF-8 string that
describes the name and version of the current HNCP implementation. describes the name and version of the current HNCP implementation.
10.2. External Connection TLV 10.2. 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: EXTERNAL-CONNECTION (33)| Length | | Type: External-Connection (33)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) | | (Optional nested TLVs) |
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 (Section 6.2) to be shared across the HNCP network. A connection (Section 6.2) to be shared across the HNCP network. A
node MAY publish an arbitrary number of instances of this TLV to node MAY publish an arbitrary number of instances of this TLV to
share the desired number of external connections. Upon reception, share the desired number of external connections. Upon reception,
the information transmitted in any nested TLVs is used for the the information transmitted in any nested TLVs is used for the
purposes of prefix assignment (Section 6.3) and host configuration purposes of prefix assignment (Section 6.3) and host configuration
(Section 7). (Section 7).
10.2.1. Delegated Prefix TLV 10.2.1. Delegated-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: DELEGATED-PREFIX (34) | Length: >= 9 | | Type: Delegated-Prefix (34) | Length: >= 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime Since Origination | | Valid Lifetime Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime Since Origination | | Preferred Lifetime Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | | | Prefix Length | |
+-+-+-+-+-+-+-+-+ Prefix + +-+-+-+-+-+-+-+-+ Prefix +
... ...
| | 0-pad if any | | | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) | | (Optional nested TLVs) |
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 can be used for prefixes that are allocated to the whole network and can be used for
prefix assignment. Delegated Prefix TLVs are only valid inside prefix assignment. Delegated-Prefix TLVs are only valid inside
External Connection TLVs and their prefixes MUST NOT overlap with External-Connection TLVs, and their prefixes MUST NOT overlap with
those of other such TLVs in the same container. those of other such TLVs in the same container.
Valid Lifetime Since Origination: The time in seconds the delegated Valid Lifetime Since Origination: The time in seconds the delegated
prefix was valid for at the origination time of the node data prefix was valid for at the origination time of the node data
containing this TLV. The value MUST be updated whenever the node containing this TLV. The value MUST be updated whenever the node
republishes its Node State TLV. republishes its Node-State TLV.
Preferred Lifetime Since Origination: The time in seconds the Preferred Lifetime Since Origination: The time in seconds the
delegated prefix was preferred for at the origination time of the delegated prefix was preferred for at the origination time of the
node data containing this TLV. The value MUST be updated whenever node data containing this TLV. The value MUST be updated whenever
the node republishes its Node State TLV. the node republishes its Node-State 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 zeros up to the
next byte boundary. next byte boundary.
10.2.1.1. Prefix Policy TLV 10.2.1.1. Prefix-Policy 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: PREFIX-POLICY (43) | Length: >= 1 | | Type: Prefix-Policy (43) | Length: >= 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy Type | | | Policy Type | |
+-+-+-+-+-+-+-+-+ Value + +-+-+-+-+-+-+-+-+ Value +
| | | |
The Prefix Policy TLV contains information about the policy or The Prefix-Policy TLV contains information about the policy or
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 usecase (e.g., local determine whether prefixes for a certain use case (e.g., local
reachability, internet connectivity) do exist or are to be acquired reachability, Internet connectivity) do exist or are to be acquired
and to make decisions about assigning prefixes to certain links or to and to make decisions about assigning prefixes to certain links or to
fine-tune border firewalls. See Section 6.2 for a more in-depth fine-tune border firewalls. See Section 6.2 for a more in-depth
discussion. This TLV is only valid inside a Delegated Prefix TLV. discussion. This TLV is only valid inside a Delegated-Prefix TLV.
Policy Type: The type of the policy identifier. Policy Type: The type of the policy identifier.
0 : Internet connectivity (no Value). 0: Internet connectivity (no value).
1-128 : Explicit destination prefix with the Policy Type being 1-128: Explicit destination prefix with the Policy Type being
the actual length of the prefix and the Value containing the actual length of the prefix and the value containing
significant bits of the destination prefix padded with zeroes significant bits of the destination prefix padded with
up to the next byte boundary. zeros up to the next byte boundary.
129 : DNS Domain. The Value contains an RFC 1035 [RFC1035] 129: DNS domain. The value contains a DNS label sequence
encoded DNS label sequence. Compression MUST NOT be used. The encoded per [RFC1035]. Compression MUST NOT be used.
label sequence MUST end with an empty label. The label sequence MUST end with an empty label.
130 : Opaque UTF-8 string (e.g., for administrative purposes). 130: Opaque UTF-8 string (e.g., for administrative purposes).
131 : Restrictive Assignment (no Value). 131: Restrictive assignment (no value).
132-255: Reserved for future additions. 132-255: Reserved for future additions.
Value: A variable length identifier of the given type. Value: A variable-length identifier of the given type.
10.2.2. DHCPv6 Data TLV 10.2.2. DHCPv6-Data 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: DHCPV6-DATA (37) | Length: > 0 | | Type: DHCPv6-Data (37) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv6 option stream | | DHCPv6 option stream |
This TLV is used to encode auxiliary IPv6 configuration information This TLV is used to encode auxiliary IPv6 configuration information
(e.g., recursive DNS servers) encoded as a stream of DHCPv6 options. (e.g., recursive DNS servers) encoded as a stream of DHCPv6 options.
It is only valid in an External Connection TLV or a Delegated Prefix It is only valid in an External-Connection TLV or a Delegated-Prefix
TLV encoding an IPv6 prefix and MUST NOT occur more than once in any TLV encoding an IPv6 prefix and MUST NOT occur more than once in any
single container. When included in an External Connection TLV, it single container. When included in an External-Connection TLV, it
contains DHCPv6 options relevant to the External Connection as a contains DHCPv6 options relevant to the external connection as a
whole. When included in a Delegated Prefix, it contains options whole. When included in a delegated prefix, it contains options
mandatory to handle said prefix. mandatory to handle said prefix.
DHCPv6 option stream: DHCPv6 options encoded as specified in DHCPv6 option stream: DHCPv6 options encoded as specified in
[RFC3315]. [RFC3315].
10.2.3. DHCPv4 Data TLV 10.2.3. DHCPv4-Data 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: DHCPV4-DATA (38) | Length: > 0 | | Type: DHCPv4-Data (38) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv4 option stream | | DHCPv4 option stream |
This TLV is used to encode auxiliary IPv4 configuration information This TLV is used to encode auxiliary IPv4 configuration information
(e.g., recursive DNS servers) encoded as a stream of DHCPv4 options. (e.g., recursive DNS servers) encoded as a stream of DHCPv4 options.
It is only valid in an External Connection TLV and MUST NOT occur It is only valid in an External-Connection TLV and MUST NOT occur
more than once in any single container. It contains DHCPv4 options more than once in any single container. It contains DHCPv4 options
relevant to the External Connection as a whole. relevant to the external connection as a whole.
DHCPv4 option stream: DHCPv4 options encoded as specified in DHCPv4 option stream: DHCPv4 options encoded as specified in
[RFC2131]. [RFC2131].
10.3. Assigned Prefix TLV 10.3. Assigned-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 +
... ...
| | 0-pad if any | | | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) | | (Optional nested TLVs) |
This TLV is used to announce Published Assigned Prefixes for the This TLV is used to announce Published Assigned Prefixes for the
purposes of prefix assignment (Section 6.3). purposes of prefix assignment (Section 6.3).
Endpoint Identifier: The endpoint identifier of the local interface Endpoint Identifier: The endpoint identifier of the local interface
the prefix is assigned to, or 0 if it is assigned to a Private the prefix is assigned to, or 0 if it is assigned to a Private
Link (e.g., when the prefix is assigned for downstream prefix Link (e.g., when the prefix is assigned for downstream prefix
delegation). delegation).
Rsv.: Bits are reserved for future use. They MUST be set to zero Rsv.: Bits are reserved for future use. They MUST be set to 0 when
when creating this TLV, and their value MUST be ignored when creating this TLV, and their value MUST be ignored when processing
processing the TLV. 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
configured otherwise. 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
static or dynamic configuration (e.g., for excluding a prefix on static or dynamic configuration (e.g., for excluding a
based on DHCPv6-PD Prefix Exclude Option [RFC6603]). prefix based on the 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 zeros up to
the next byte boundary. the next byte boundary.
10.4. Node Address TLV 10.4. 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 |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) | | (Optional nested TLVs) |
This TLV is used to announce addresses assigned to an HNCP node as This TLV is used to announce addresses assigned to an HNCP node as
described in Section 6.4. described in Section 6.4.
Endpoint Identifier: The endpoint identifier of the local interface Endpoint Identifier: The endpoint identifier of the local interface
the prefix is assigned to, or 0 if it is not assigned on an HNCP the prefix is assigned to, or 0 if it is not assigned on an HNCP
enabled link. 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].
10.5. DNS Delegated Zone TLV 10.5. DNS-Delegated-Zone 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: 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) |
... ...
| | 0-pad if any | | | 0-pad if any |
skipping to change at page 29, line 4 skipping to change at page 30, line 23
| IP Address | | IP Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserved |L|B|S| | |Reserved |L|B|S| |
+-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) | +-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) |
... ...
| | 0-pad if any | | | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) | | (Optional nested TLVs) |
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. Details are specified in an NS and A/AAAA record for said zone. Details are specified in
Section 8. Section 8.
IP Address : The IPv6 address of the authoritative DNS server for IP Address: The IPv6 address of the authoritative DNS server for the
the zone; IPv4 addresses are represented as IPv4-mapped addresses zone; IPv4 addresses are represented as IPv4-mapped addresses
[RFC4291]. The special value of :: (all-zero) means the [RFC4291]. The special value of :: (all zeros) means the
delegation is available in the global DNS-hierarchy. delegation is available in the global DNS hierarchy.
Reserved : Those bits MUST be set to zero when creating the TLV and Reserved: Those bits MUST be set to 0 when creating the TLV and
ignored when parsing it unless defined in a later specification. ignored when parsing it unless defined in a later specification.
L-bit : DNS-SD [RFC6763] Legacy-Browse, indicates that this L-bit: (DNS-based Service Discovery (DNS-SD) [RFC6763] Legacy-
delegated zone SHOULD be included in the network's DNS-SD legacy Browse) indicates that this delegated zone SHOULD be included in
browse list of domains at lb._dns- sd._udp.(DOMAIN-NAME). Local the network's DNS-SD legacy browse list of domains at
forward zones SHOULD have this bit set, reverse zones SHOULD NOT. lb._dns-sd._udp.(DOMAIN-NAME). Local forward zones SHOULD have
this bit set; reverse zones SHOULD NOT.
B-bit : (DNS-SD [RFC6763] Browse) indicates that this delegated zone 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
have this bit set, reverse zones SHOULD NOT. 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
this delegated zone consists of a fully-qualified DNS-SD domain, delegated zone consists of a fully qualified DNS-SD domain, which
which should be used as base for DNS-SD domain enumeration, i.e., should be used as the 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 a DNS
path to hosts for non-local services (such as those provided by an search path to hosts for non-local services (such as those
ISP, or other manually configured service providers). Zones with provided by an ISP or other manually configured service
this flag SHOULD be added to the search domains advertised to providers). Zones with this flag SHOULD be added to the search
clients. domains advertised to clients.
Zone : The label sequence encoded according to [RFC1035]. Zone: The label sequence encoded according to [RFC1035].
Compression MUST NOT be used. The label sequence MUST end with an Compression MUST NOT be used. The label sequence MUST end with an
empty label. empty label.
10.6. Domain Name TLV 10.6. Domain-Name 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: DOMAIN-NAME (40) | Length: > 0 | | Type: Domain-Name (40) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain (DNS label sequence - variable length) | | Domain (DNS label sequence - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used to indicate the base domain name for the network as This TLV is used to indicate the base domain name for the network as
specified in Section 8. This TLV MUST NOT be announced unless the specified in Section 8. This TLV MUST NOT be announced unless the
domain name was explicitly configured by an administrator. domain name was explicitly configured by an administrator.
Domain: The label sequence encoded according to [RFC1035]. Domain: The label sequence encoded according to [RFC1035].
Compression MUST NOT be used. The label sequence MUST end with an Compression MUST NOT be used. The label sequence MUST end with an
empty label. empty label.
10.7. Node Name TLV 10.7. Node-Name 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: > 17 | | Type: Node-Name (41) | Length: > 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IP Address | | IP Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Name | | Length | Name |
... ...
| (not null-terminated, variable length) | 0-pad if any | | (not null-terminated, variable length) | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 30, line 40 skipping to change at page 32, line 12
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 as specified in Section 8. certain IP address as specified in Section 8.
IP Address: The IP address associated with the name. IPv4 IP Address: The IP address associated with the name. IPv4
addresses are encoded using IPv4-mapped IPv6 addresses. addresses are encoded using IPv4-mapped IPv6 addresses.
Length: The length of the name (0-63). Length: The length of the name (0-63).
Name: The name of the node as a single DNS label. Name: The name of the node as a single DNS label.
10.8. Managed PSK TLV 10.8. Managed-PSK TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: MANAGED-PSK (42) | Length: 32 | | Type: Managed-PSK (42) | Length: 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| | | |
| Random 256-bit PSK | | Random 256-bit PSK |
| | | |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) | | (Optional nested TLVs) |
This TLV is used to announce a PSK for securing third-party protocols This TLV is used to announce a PSK for securing third-party protocols
exclusively supporting symmetric cryptography as specified in exclusively supporting symmetric cryptography as specified in
Section 9. Section 9.
11. General Requirements for HNCP Nodes 11. General Requirements for HNCP Nodes
Each node implementing HNCP is subject to the following requirements: Each node implementing HNCP is subject to the following requirements:
o It MUST implement HNCP-Versioning (Section 4) and Interface o It MUST implement HNCP versioning (Section 4) and interface
Classification (Section 5). classification (Section 5).
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 (Section 9) whenever it uses the security mechanism of protocols (Section 9) whenever it uses the security mechanism of
HNCP. HNCP.
If the node is acting as a router, then the following requirements If the node is acting as a router, then the following requirements
apply in addition: apply in addition:
o It MUST support Autonomous Address Configuration (Section 6) and o It MUST support Autonomous Address Configuration (Section 6) and
Configuration of Hosts and non-HNCP Routers (Section 7). configuration of hosts and non-HNCP routers (Section 7).
o It SHOULD implement support for the Service Discovery and Naming o It SHOULD implement support for naming and service discovery
(Section 8) as defined in this document. (Section 8) as defined in this document.
o It MAY 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 (Section 6.3.4). using DHCPv6-PD (Section 6.3.4).
o In addition, normative language of Basic Requirements for IPv6 o In addition, the normative language of "Basic Requirements for
Customer Edge Routers [RFC7084] applies with the following IPv6 Customer Edge Routers" [RFC7084] applies with the following
adjustments: adjustments:
* The generic requirements G-4 and G-5 are relaxed such that any * The generic requirements G-4 and G-5 are relaxed such that any
known default router on any interface is sufficient for a known default router on any interface is sufficient for a
router to announce itself as default router, similarly only the router to announce itself as the default router; similarly,
loss of all such default routers results in self-invalidation. only the loss of all such default routers results in self-
invalidation.
* The section "WAN-Side Configuration" applies to interfaces * "WAN-Side Configuration" (Section 4.2) applies to interfaces
classified as external. classified as external.
* If the CE sends a size-hint as indicated in WPD-2, the hint * If the Customer Edge (CE) sends a size hint as indicated in
MUST NOT be determined by the number of LAN-interfaces of the WPD-2, the hint MUST NOT be determined by the number of LAN
CE, but SHOULD instead be large enough to at least accommodate interfaces of the CE but SHOULD instead be large enough to at
prefix assignments announced for existing delegated or ULA- least accommodate prefix assignments announced for existing
prefixes, if such prefixes exist and unless explicitly delegated or ULA prefixes, if such prefixes exist and unless
configured otherwise. explicitly configured otherwise.
* The dropping of packets with a destination address belonging to * The dropping of packets with a destination address belonging to
a delegated prefix mandated in WPD-5 MUST NOT be applied to a delegated prefix mandated in WPD-5 MUST NOT be applied to
destinations that are part of any prefix announced using an destinations that are part of any prefix announced using an
Assigned Prefix TLV by any HNCP router in the network. Assigned-Prefix TLV by any HNCP router in the network.
* The section "LAN-Side Configuration" applies to interfaces not * "LAN-Side Configuration" (Section 4.3) applies to interfaces
classified as external. not classified as external.
* The requirement L-2 to assign a separate /64 to each LAN * The requirement L-2 to assign a separate /64 to each LAN
interface is replaced by the participation in the prefix interface is replaced by the participation in the prefix
assignment mechanism (Section 6.3) for each such interface. assignment mechanism (Section 6.3) for each such interface.
* The requirement L-9 is modified, in that the M flag MUST be set * The requirement L-9 is modified, in that the M flag MUST be set
if and only if a router connected to the respective Common Link if and only if a router connected to the respective Common Link
is advertising a non-zero H-capability. The O flag SHOULD is advertising a non-zero H-capability. The O flag SHOULD
always be set. always be set.
* The requirement L-12 to make DHCPv6 options available is * The requirement L-12 to make DHCPv6 options available is
adapted, in that a CER SHOULD publish the subset of options adapted, in that Canonical Encoding Rules (CER) SHOULD publish
using the DHCPv6 Data TLV in an External Connection TLV. the subset of options using the DHCPv6-Data TLV in an External-
Similarly it SHOULD do the same for DHCPv4 options in a DHCPv4 Connection TLV. Similarly, it SHOULD do the same for DHCPv4
Data TLV. DHCPv6 options received inside an OPTION_IAPREFIX options in a DHCPv4-Data TLV. DHCPv6 options received inside
[RFC3633] MUST be published using a DHCPv6 Data TLV inside the an OPTION_IAPREFIX [RFC3633] MUST be published using a
respective Delegated Prefix TLV. HNCP routers SHOULD make DHCPv6-Data TLV inside the respective Delegated-Prefix TLV.
relevant DHCPv6 and DHCPv4 options available to clients, i.e., HNCP routers SHOULD make relevant DHCPv6 and DHCPv4 options
options contained in External Connection TLVs that also include available to clients, i.e., options contained in External-
delegated prefixes from which a subset is assigned to the Connection TLVs that also include delegated prefixes from which
respective link. a subset is assigned to the respective link.
* The requirement L-13 to deprecate prefixes is applied to all * The requirement L-13 to deprecate prefixes is applied to all
delegated prefixes in the network from which assignments have delegated prefixes in the network from which assignments have
been made on the respective interface. Furthermore the Prefix been made on the respective interface. Furthermore, the Prefix
Information Options indicating deprecation MUST be included in Information Options indicating deprecation MUST be included in
Router Advertisements for the remainder of the prefixes' Router Advertisements for the remainder of the prefixes'
respective valid lifetime, but MAY be omitted after at least 2 respective valid lifetime but MAY be omitted after at least 2
hours have passed. hours have passed.
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
for the security of HNCP itself. scope for the security of HNCP itself.
HNCP is a DNCP-based state synchronization mechanism carrying HNCP is a DNCP-based state synchronization mechanism carrying
information with varying threat potential. For this consideration information with varying threat potential. For this consideration,
the payloads defined in DNCP and this document are reviewed: the payloads defined in DNCP and this document are 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 nodes. customized names for individual links and nodes.
12.1. Interface Classification 12.1. Interface Classification
As described in Section 5.3, an HNCP node determines the internal or As described in Section 5.3, an HNCP node determines the internal or
external state on a per-interface basis. A firewall perimeter is set external state on a per-interface basis. A firewall perimeter is set
up for the external interfaces, and for internal interfaces, HNCP up for the external interfaces, and for internal interfaces, HNCP
traffic is allowed, with the exception of leaf and guest sub- traffic is allowed, with the exception of the Leaf and Guest
categories. subcategories.
Threats concerning automatic interface classification cannot be Threats concerning automatic interface classification cannot be
mitigated by encrypting or authenticating HNCP traffic itself since mitigated by encrypting or authenticating HNCP traffic itself since
external routers do not participate in the protocol and often cannot external routers do not participate in the protocol and often cannot
be authenticated by other means. These threats include propagation be authenticated by other means. These threats include propagation
of forged uplinks in the homenet in order to, e.g., redirect traffic of forged uplinks in the homenet in order to, e.g., redirect traffic
destined to external locations and forged internal status by external destined to external locations and forged internal status by external
routers to, e.g., circumvent the perimeter firewall. routers to, e.g., circumvent the perimeter firewall.
It is therefore imperative to either secure individual links on the It is therefore imperative to either secure individual links on the
physical or link-layer or preconfigure the adjacent interfaces of physical or link layer or preconfigure the adjacent interfaces of
HNCP routers to an appropriate fixed category in order to secure the HNCP routers to an appropriate fixed category in order to secure the
homenet border. Depending on the security of the external link homenet border. Depending on the security of the external link,
eavesdropping, man-in-the-middle and similar attacks on external eavesdropping, man-in-the-middle, and similar attacks on external
traffic can still happen between a homenet border router and the ISP, traffic can still happen between a homenet border router and the ISP;
however these cannot be mitigated from inside the homenet. For however, these cannot be mitigated from inside the homenet. For
example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4 example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4
messages, but this is very rarely implemented in large or small messages, but this is very rarely implemented in large or small
networks. Further, while PPP can provide secure authentication of networks. Further, while PPP can provide secure authentication of
both sides of a point to point link, it is most often deployed with both sides of a point-to-point link, it is most often deployed with
one-way authentication of the subscriber to the ISP, not the ISP to one-way authentication of the subscriber to the ISP, not the ISP to
the subscriber. the subscriber.
12.2. Security of Unicast Traffic 12.2. Security of Unicast Traffic
Once the homenet border has been established there are several ways Once the homenet border has been established, there are several ways
to secure HNCP against internal threats like manipulation or to secure HNCP against internal threats like manipulation or
eavesdropping by compromised devices on a link which is enabled for eavesdropping by compromised devices on a link that is enabled for
HNCP traffic. If left unsecured, attackers may perform arbitrary HNCP traffic. If left unsecured, attackers may perform arbitrary
traffic redirection, eavesdropping, spoofing or denial of service traffic redirection, eavesdropping, spoofing, or denial-of-service
attacks on HNCP services such as address assignment or service attacks on HNCP services such as address assignment or service
discovery, and the protocols secured using HNCP-derived keys such as discovery, and the protocols are secured using HNCP-derived keys such
routing protocols. as routing protocols.
Detailed interface categories like "leaf" or "guest" can be used to Detailed interface categories like "Leaf" or "Guest" can be used to
integrate not fully trusted devices to various degrees into the integrate not fully trusted devices to various degrees into the
homenet by not exposing them to HNCP traffic or by using firewall homenet by not exposing them to HNCP traffic or by using firewall
rules to prevent them from reaching homenet-internal resources. rules to prevent them from reaching homenet-internal resources.
On links where this is not practical and lower layers do not provide On links where this is not practical and lower layers do not provide
adequate protection from attackers, DTLS-based secure unicast adequate protection from attackers, DTLS-based secure unicast
transport MUST be used to secure traffic. transport MUST be used to secure traffic.
12.3. Other Protocols in the Home 12.3. Other Protocols in the Home
IGPs and other protocols are usually run alongside HNCP therefore the IGPs and other protocols are usually run alongside HNCP; therefore,
individual security aspects of the respective protocols must be the individual security aspects of the respective protocols must be
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 should set up a registry for the (decimal values within range IANA has set up a registry for the (decimal values within range
32-511) "HNCP TLV Types" under "Distributed Node Consensus Protocol 32-511) "HNCP TLV Types" under "Distributed Node Consensus Protocol
(DNCP)", with the following initial contents: (DNCP)". The registration procedures is 'RFC Required' [RFC5226].
The initial contents are:
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 35, line 35 skipping to change at page 36, line 41
39: DNS-Delegated-Zone 39: DNS-Delegated-Zone
40: Domain-Name 40: Domain-Name
41: Node-Name 41: Node-Name
42: Managed-PSK 42: Managed-PSK
43: Prefix-Policy 43: Prefix-Policy
44-511: Free - policy of 'RFC required' [RFC5226] should be used. 44-511: Unassigned.
The range reserved by DNCP for Private Use (768-1023) is used by 768-1023: Reserved for Private Use. This range is used by HNCP
HNCP for per-implementation experimentation. How collisions are for per-implementation experimentation. How collisions are
avoided is out of the scope of this document. avoided is outside the scope of this document.
HNCP requires allocation of well-known UDP port numbers HNCP-UDP-PORT IANA has registered the UDP port numbers 8231 (service name: hncp-
(service name: hncp-udp-port, description: HNCP) and HNCP-DTLS-PORT udp-port, description: HNCP) and 8232 (service name: hncp-dtls-port,
(service name: hncp-dtls-port, description: HNCP over DTLS), as well description: HNCP over DTLS), as well as an IPv6 link-local multicast
as an IPv6 link-local multicast address All-Homenet-Nodes. address FF02:0:0:0:0:0:0:11 (description: All-Homenet-Nodes).
14. References 14. References
14.1. Normative references 14.1. Normative References
[I-D.ietf-homenet-dncp]
Stenberg, M. and S. Barth, "Distributed Node Consensus
Protocol", draft-ietf-homenet-dncp-12 (work in progress),
November 2015.
[RFC7695] Pfister, P., Paterson, B., and J. Arkko, "Distributed [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
Prefix Assignment Algorithm", RFC 7695, DOI 10.17487/ DOI 10.17487/RFC1321, April 1992,
RFC7695, November 2015, <http://www.rfc-editor.org/info/rfc1321>.
<http://www.rfc-editor.org/info/rfc7695>.
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
IANA Considerations Section in RFCs", BCP 26, RFC 5226, RFC 2131, DOI 10.17487/RFC2131, March 1997,
DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc2131>.
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O.
Troan, "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012,
<http://www.rfc-editor.org/info/rfc6603>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
March 2011, <http://www.rfc-editor.org/info/rfc6206>. <http://www.rfc-editor.org/info/rfc2132>.
[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, DOI 10.17487/RFC3004, November 2000, DHCP", RFC 3004, DOI 10.17487/RFC3004, November 2000,
<http://www.rfc-editor.org/info/rfc3004>. <http://www.rfc-editor.org/info/rfc3004>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003, DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>. <http://www.rfc-editor.org/info/rfc3633>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<http://www.rfc-editor.org/info/rfc1321>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<http://www.rfc-editor.org/info/rfc2132>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>. <http://www.rfc-editor.org/info/rfc4193>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Interface Identifiers with IPv6 Stateless Address Architecture", RFC 4291, DOI 10.17487/RFC4291, February
Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/ 2006, <http://www.rfc-editor.org/info/rfc4291>.
RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <http://www.rfc-editor.org/info/rfc4861>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
Capabilities in Customer Premises Equipment (CPE) for Capabilities in Customer Premises Equipment (CPE) for
Providing Residential IPv6 Internet Service", RFC 6092, Providing Residential IPv6 Internet Service", RFC 6092,
DOI 10.17487/RFC6092, January 2011, DOI 10.17487/RFC6092, January 2011,
<http://www.rfc-editor.org/info/rfc6092>. <http://www.rfc-editor.org/info/rfc6092>.
14.2. Informative references [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC3118] Droms, R. and W. Arbaugh., Ed., "Authentication for DHCP [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
<http://www.rfc-editor.org/info/rfc3118>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O.
and E. Lear, "Address Allocation for Private Internets", Troan, "Prefix Exclude Option for DHCPv6-based Prefix
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012,
<http://www.rfc-editor.org/info/rfc1918>. <http://www.rfc-editor.org/info/rfc6603>.
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Weil, "IPv6 Home Networking Architecture Principles", RFC Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
7368, DOI 10.17487/RFC7368, October 2014, <http://www.rfc-editor.org/info/rfc6763>.
<http://www.rfc-editor.org/info/rfc7368>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
[RFC7695] Pfister, P., Paterson, B., and J. Arkko, "Distributed
Prefix Assignment Algorithm", RFC 7695,
DOI 10.17487/RFC7695, November 2015,
<http://www.rfc-editor.org/info/rfc7695>.
[RFC7787] Stenberg, M. and S. Barth, "Distributed Node Consensus
Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016,
<http://www.rfc-editor.org/info/rfc7787>.
14.2. Informative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC3118] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for
DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,
<http://www.rfc-editor.org/info/rfc3118>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI (SHA and SHA-based HMAC and HKDF)", RFC 6234,
10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>. <http://www.rfc-editor.org/info/rfc6234>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[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,
DOI 10.17487/RFC7084, November 2013, DOI 10.17487/RFC7084, November 2013,
<http://www.rfc-editor.org/info/rfc7084>. <http://www.rfc-editor.org/info/rfc7084>.
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
Weil, "IPv6 Home Networking Architecture Principles",
RFC 7368, DOI 10.17487/RFC7368, October 2014,
<http://www.rfc-editor.org/info/rfc7368>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <http://www.rfc-editor.org/info/rfc7525>.
Appendix A. Changelog [RFC Editor: please remove] Acknowledgments
draft-ietf-homenet-hncp-10: Mainly IESG review based changes, no real
content change.
draft-ietf-homenet-hncp-09: Added nested TLV definitions for variable
length TLVs. NOTE: Node name TLV encoding includes now length byte.
Version TLV now itself indicates version.
draft-ietf-homenet-hncp-08: Editorial reorganization.
draft-ietf-homenet-hncp-07: Using version 1 instead of version 0, as
existing implementations already use it.
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".
Changed single IPv4 uplink election from MUST to MAY. Added explicit
indication to distinguish (IPv4)-PDs for local connectivity and ones
with uplink connectivity allowing, e.g., better local-only
IPv4-connectivity.
draft-ietf-homenet-hncp-04: Change the responsibility for sending RAs
to the router assigning the prefix.
draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP
(homenet profile).
draft-ietf-homenet-hncp-02: Removed any built-in security. Relying
on IPsec. Reorganized interface categories, added requirements
languages, made manual border configuration a MUST-support.
Redesigned routing protocol election to consider non-router devices.
draft-ietf-homenet-hncp-01: Added (MAY) guest, ad-hoc, hybrid
categories for interfaces. Removed old hnetv2 reference, and now
pointing just to OpenWrt + github. Fixed synchronization algorithm
to spread also same update number, but different data hash case.
Made purge step require bidirectional connectivity between nodes when
traversing the graph. Edited few other things to be hopefully
slightly clearer without changing their meaning.
draft-ietf-homenet-hncp-00: Added version TLV to allow for TLV
content changes pre-RFC without changing IDs. Added link id to
assigned address TLV.
Appendix B. Draft source [RFC Editor: please remove]
This draft is available at https://github.com/fingon/ietf-drafts/ in
source format. Issues and pull requests are welcome.
Appendix C. Implementation [RFC Editor: please remove]
A GPLv2-licensed implementation of HNCP is currently under
development at https://github.com/sbyx/hnetd/ and binaries are
available in the OpenWrt package repositories (
http://www.openwrt.org ). See http://www.homewrt.org/
doku.php?id=run-conf for more information. Feedback and
contributions are welcome.
Appendix D. Acknowledgments
Thanks to Ole Troan, Mark Baugher, Mark Townsley, Juliusz Chroboczek Thanks to Ole Troan, Mark Baugher, Mark Townsley, Juliusz Chroboczek,
and Thomas Clausen for their contributions to the draft. and Thomas Clausen for their contributions to the document.
Thanks to Eric Kline for the original border discovery work. Thanks to Eric Kline for the original border discovery work.
Authors' Addresses Authors' Addresses
Markus Stenberg Markus Stenberg
Independent Independent
Helsinki 00930 Helsinki 00930
Finland Finland
 End of changes. 273 change blocks. 
682 lines changed or deleted 631 lines changed or added

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