draft-ietf-homenet-hncp-09.txt   draft-ietf-homenet-hncp-10.txt 
Homenet Working Group M. Stenberg Homenet Working Group M. Stenberg
Internet-Draft S. Barth Internet-Draft S. Barth
Intended status: Standards Track Independent Intended status: Standards Track Independent
Expires: March 3, 2016 P. Pfister Expires: May 30, 2016 P. Pfister
Cisco Systems Cisco Systems
August 31, 2015 November 27, 2015
Home Networking Control Protocol Home Networking Control Protocol
draft-ietf-homenet-hncp-09 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 which supports routing based on both source and
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 3, 2016. This Internet-Draft will expire on May 30, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . 8
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 . . . . . . . . . . . . . 10
6. Autonomous Address Configuration . . . . . . . . . . . . . . 11 6. Autonomous Address Configuration . . . . . . . . . . . . . . 11
6.1. Common Link . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Common Link . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. External Connections . . . . . . . . . . . . . . . . . . 12 6.2. External Connections . . . . . . . . . . . . . . . . . . 12
6.3. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 13 6.3. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 14
6.3.1. Prefix Assignment Algorithm Parameters . . . . . . . 13 6.3.1. Prefix Assignment Algorithm Parameters . . . . . . . 14
6.3.2. Making New Assignments . . . . . . . . . . . . . . . 15 6.3.2. Making New Assignments . . . . . . . . . . . . . . . 15
6.3.3. Applying Assignments . . . . . . . . . . . . . . . . 16 6.3.3. Applying Assignments . . . . . . . . . . . . . . . . 16
6.3.4. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . 16 6.3.4. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . 16
6.4. Node Address Assignment . . . . . . . . . . . . . . . . . 16 6.4. Node Address Assignment . . . . . . . . . . . . . . . . . 17
6.5. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 17 6.5. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 18
7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 18 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 . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . 20
8. Naming and Service Discovery . . . . . . . . . . . . . . . . 20 8. Naming and Service Discovery . . . . . . . . . . . . . . . . 21
9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 21 9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 22
10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 22 10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 22
10.1. HNCP Version TLV . . . . . . . . . . . . . . . . . . . . 22 10.1. HNCP Version TLV . . . . . . . . . . . . . . . . . . . . 23
10.2. External Connection TLV . . . . . . . . . . . . . . . . 23 10.2. External Connection TLV . . . . . . . . . . . . . . . . 24
10.2.1. Delegated Prefix TLV . . . . . . . . . . . . . . . . 24 10.2.1. Delegated Prefix TLV . . . . . . . . . . . . . . . . 24
10.2.2. DHCPv6 Data TLV . . . . . . . . . . . . . . . . . . 25 10.2.2. DHCPv6 Data TLV . . . . . . . . . . . . . . . . . . 26
10.2.3. DHCPv4 Data TLV . . . . . . . . . . . . . . . . . . 26 10.2.3. DHCPv4 Data TLV . . . . . . . . . . . . . . . . . . 26
10.3. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . 26 10.3. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . 27
10.4. Node Address TLV . . . . . . . . . . . . . . . . . . . . 27 10.4. Node Address TLV . . . . . . . . . . . . . . . . . . . . 28
10.5. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 28 10.5. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 28
10.6. Domain Name TLV . . . . . . . . . . . . . . . . . . . . 29 10.6. Domain Name TLV . . . . . . . . . . . . . . . . . . . . 29
10.7. Node Name TLV . . . . . . . . . . . . . . . . . . . . . 29 10.7. Node Name TLV . . . . . . . . . . . . . . . . . . . . . 30
10.8. Managed PSK TLV . . . . . . . . . . . . . . . . . . . . 30 10.8. Managed PSK TLV . . . . . . . . . . . . . . . . . . . . 30
11. General Requirements for HNCP Nodes . . . . . . . . . . . . . 31 11. General Requirements for HNCP Nodes . . . . . . . . . . . . . 31
12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33
12.1. Interface Classification . . . . . . . . . . . . . . . . 33 12.1. Interface Classification . . . . . . . . . . . . . . . . 33
12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 33 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 34
12.3. Other Protocols in the Home . . . . . . . . . . . . . . 34 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.1. Normative references . . . . . . . . . . . . . . . . . . 35 14.1. Normative references . . . . . . . . . . . . . . . . . . 35
14.2. Informative references . . . . . . . . . . . . . . . . . 36 14.2. Informative references . . . . . . . . . . . . . . . . . 37
Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 37 Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 38
Appendix B. Draft source [RFC Editor: please remove] . . . . . . 38 Appendix B. Draft source [RFC Editor: please remove] . . . . . . 39
Appendix C. Implementation [RFC Editor: please remove] . . . . . 38 Appendix C. Implementation [RFC Editor: please remove] . . . . . 39
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 38 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
HNCP is designed to facilitate sharing of state among home routers to Home Networking Control Protocol (HNCP) is designed to facilitate
fulfill the needs of the IPv6 homenet architecture [RFC7368], which sharing of state among home routers to fulfill the needs of the IPv6
assumes zero-configuration operation, multiple subnets, multiple home homenet architecture [RFC7368], which assumes zero-configuration
routers and (potentially) multiple upstream service providers operation, multiple subnets, multiple home routers and (potentially)
providing (potentially) multiple prefixes to the home network. While multiple upstream service providers providing (potentially) multiple
RFC7368 sets no requirements for IPv4 support, HNCP aims to support prefixes to the home network. While RFC7368 sets no requirements for
dual-stack mode of operation, and therefore the functionality is IPv4 support, HNCP aims to support dual-stack mode of operation, and
designed with that in mind. The state is shared as TLVs among the therefore the functionality is designed with that in mind. The state
is shared as TLVs transported in the DNCP node state among the
routers (and potentially advanced hosts) to enable: routers (and potentially advanced hosts) to enable:
o Autonomic discovery of network borders (Section 5.3) based on DNCP o Autonomic discovery of network borders (Section 5.3) based on
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 [I-D.ietf-homenet-prefix-assignment]. routers (Section 6.3) using [RFC7695]. Prefixes assigned to HNCP
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 SLAAC and
DHCP). 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).
skipping to change at page 4, line 24 skipping to change at page 4, line 24
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 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 can
be used also with a manually configured routing protocol. be used also 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 can be used here as well; HNCP should applicability statement of DNCP applies here as well; HNCP should not
not be used for any data that changes rapidly and constantly, and be used for any data that changes rapidly and constantly. If such
locators to find such services should be published using it instead. data needs to be published in an HNCP network, a more applicable
This is why the naming and service discovery (Section 8) TLVs contain protocol should be used for those portions and locators to a server
only DNS server addresses, and no actual per-name or per-service data of said protocol can be announced using HNCP instead. An example for
of hosts. this is naming and service discovery (Section 8) for which HNCP only
transports DNS server addresses, and no actual per-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 re-publishing 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 the home network size,
and should therefore be relatively low. and 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 not
aware of the HNCP-managed network and thus might need to be 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
configuration from non-HNCP routers, they are not able to traverse
such devices based solely on the protocol as defined in this
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
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 The following terms are used as they are defined in [RFC7695]:
[I-D.ietf-homenet-prefix-assignment]:
o Advertised Prefix Priority o Advertised Prefix Priority
o Advertised Prefix o Advertised Prefix
o Assigned Prefix o Assigned Prefix
o Delegated Prefix o Delegated Prefix
o Prefix Adoption o Prefix Adoption
skipping to change at page 6, line 7 skipping to change at page 6, line 7
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) node A device implementing this specification.
(HNCP) router A device implementing this specification, which (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
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 which is
interface not an internal link. interface not an internal link.
skipping to change at page 7, line 7 skipping to change at page 7, line 14
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 of 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 HNCP-UDP-PORT as a transport over
link-local scoped IPv6, using unicast and multicast (All-Homenet- link-local scoped IPv6, using unicast and multicast (All-Homenet-
Nodes is the HNCP group address). Received datagrams where either Nodes is the HNCP group address). Received datagrams where either
or both of the IPv6 source or destination address is not link- or both of the IPv6 source or destination address is not link-
local scoped MUST be ignored. Replies to multicast and unicast local scoped MUST be ignored. Replies to multicast and unicast
messages MUST be sent to the IPv6 source address and port of the messages MUST be sent to the IPv6 source address and port of the
original message. Each node MUST be able to receive (and original message. Each node MUST be able to receive (and
potentially reassemble) UDP datagrams with a payload of at least potentially reassemble) UDP datagrams with a payload of at least
4000 bytes. 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 locally unique non-zero 32-bit endpoint identifier MUST assign a non-zero 32-bit endpoint identifier to each
to each interface for which HNCP is enabled. The value zero it is interface for which HNCP is enabled. The value zero is not used
not used in DNCP TLVs, but it has a special meaning in HNCP TLVs in DNCP TLVs, but has a special meaning in HNCP TLVs (see
(see Section 10.3 and Section 6.4). Implementations MAY use a Section 10.3 and Section 6.4). These identifiers MUST be locally
value equivalent to the IPv6 link-local scope identifier for the unique within the scope of the node and using values equivalent to
given interface. the IPv6 link-local scope identifiers for the given interfaces are
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 [I-D.ietf-homenet-dncp]), the node MUST
immediately generate and use a new random node identifier which is immediately generate and use a new random node identifier which is
not used by any other node at the time, based on the current DNCP not used by any other node at the time, based on the current DNCP
network state. network state.
o HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP o HNCP nodes MUST use the leading 64 bits of the MD5 message digest
non-cryptographic hash function H(x). [RFC1321] as the DNCP hash function H(x) used in building the DNCP
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-alive.
If used on a lossy link, considerably higher multiplier, such If used on a lossy link, considerably higher multiplier, such
skipping to change at page 8, line 16 skipping to change at page 8, line 25
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 (i.e., 25.6 seconds) but * Imax SHOULD be 7 doublings of Imin [RFC6206] but MUST NOT be
MUST NOT be lower. lower.
o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as
described in DNCP if exchanged over unsecured links. UDP on port described in DNCP if exchanged over unsecured links. UDP on port
HNCP-DTLS-PORT is used for this purpose. A node implementing HNCP HNCP-DTLS-PORT is used for this purpose. A node implementing HNCP
security MUST support the DNCP Pre-Shared Key method, SHOULD security MUST support the DNCP Pre-Shared Key method, SHOULD
support the DNCP Certificate Based Trust Consensus and MAY support support the PKI-based trust method and MAY support the DNCP
the PKI-based trust method. Certificate Based Trust Consensus method. [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 which 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) in its Node Data and MUST ignore HNCP-Version TLV (Section 10.1) indicating the currently supported
(except for DNCP synchronization purposes) any TLVs with a type version in its Node Data and MUST ignore (except for DNCP
greater than 32 published by nodes not also publishing an HNCP- synchronization purposes) any TLVs with a type greater than 32
Version TLV. published by nodes not also publishing 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 is value 0 for all capabilities. Any node announcing the value 0 for a
considered to not advertise the respective capability and thus does capability is considered to not advertise said capability and thus
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 interfaces can be configured
to be in: to be in:
Internal category: This declares an interfaces to be internal, i.e., Internal category: This declares an interfaces to be internal, i.e.,
within the borders of the HNCP network. HNCP traffic MUST be sent within the borders of the HNCP network. The interface MUST
and received. Routers MUST forward traffic with appropriate operate as a DNCP endpoint. Routers MUST forward traffic with
source addresses between their internal interfaces and allow appropriate source addresses between their internal interfaces and
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. HNCP traffic MUST not within the borders of the HNCP network. The interface MUST
neither be sent nor received. Accessing internal resources from NOT operate as a DNCP endpoint. Accessing internal resources from
external interfaces is restricted, i.e., the use of [RFC6092] is external interfaces is restricted, i.e., the use of Recommended
RECOMMENDED. HNCP routers SHOULD announce acquired configuration Simple Security Capabilities in CPEs [RFC6092] is RECOMMENDED.
information for use in the network as described in Section 6.2, if HNCP routers SHOULD announce acquired configuration information
the interface appears to be connected to an external network. for use in the network as described in Section 6.2, if the
HNCP routers MUST implement this category. interface appears to be connected 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 HNCP traffic MUST NOT be sent on the interface, and exception that it MUST NOT operate as a DNCP endpoint This
all such traffic received on the interface MUST be ignored. 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.
skipping to change at page 10, line 40 skipping to change at page 10, line 51
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 step is required. The algorithm works as follows, with the first and last step are required. The algorithm works as
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
skipping to change at page 11, line 16 skipping to change at page 11, line 26
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 which 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). another HNCP router or a client). Note that all fixed categories
except internal and external cannot be auto-detected and can only be
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.
skipping to change at page 12, line 39 skipping to change at page 13, line 5
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 may 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 which 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.
skipping to change at page 13, line 38 skipping to change at page 14, line 7
Section 6.3.2 Section 6.3.2
In presence of any type 1 to 128 Prefix Policy TLV the prefix is In presence of any type 1 to 128 Prefix Policy TLV the prefix is
specialized to reach destinations denoted by any such Prefix 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 HNCP uses the Prefix Assignment Algorithm [RFC7695] in order to
[I-D.ietf-homenet-prefix-assignment] in order to assign prefixes to assign prefixes to HNCP internal links and uses some of the
HNCP internal links and uses some of the terminology (Section 2) terminology (Section 2) defined there. HNCP furthermore defines the
defined there. HNCP furthermore defines the Assigned Prefix TLV Assigned Prefix TLV (Section 10.3) which MUST be used to announce
(Section 10.3) which MUST be used to announce Published Assigned Published Assigned Prefixes.
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 bit-wise comparison.
Set of Delegated Prefixes: The set of prefixes encoded in Delegated Set of Delegated Prefixes: The set of prefixes encoded in Delegated
skipping to change at page 14, line 48 skipping to change at page 15, line 15
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 MAY be 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
[I-D.ietf-homenet-prefix-assignment]) is run on a Common Link and [RFC7695]) is run on a Common Link and whenever a new prefix may be
whenever a new prefix may be assigned (case 1 of the subroutine: no assigned (case 1 of the subroutine: no Best Assignment and no Current
Best Assignment and no Current Assignment), the decision of whether Assignment), the decision of whether the assignment of a new prefix
the assignment of a new prefix is desired MUST follow these rules in is desired MUST follow these rules in order:
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
skipping to change at page 17, line 46 skipping to change at page 18, line 16
least ADDRESS_APPLY_DELAY consecutive seconds, and is still least ADDRESS_APPLY_DELAY consecutive seconds, and is still
currently being advertised. The default value for currently being advertised. The default value for
ADDRESS_APPLY_DELAY is 3 seconds. ADDRESS_APPLY_DELAY is 3 seconds.
o Whenever the same address is advertised by more than one node, all o Whenever the same address is advertised by more than one node, all
but the one advertised by the node with the highest node but the one advertised by the node with the highest node
identifier MUST be removed. identifier MUST be removed.
6.5. Local IPv4 and ULA Prefixes 6.5. Local IPv4 and ULA Prefixes
HNCP routers can create a ULA or private IPv4 prefix to enable HNCP routers can create a Unique Local Address (ULA) or private IPv4
connectivity between local devices. These prefixes are inserted in prefix to enable connectivity between local devices. These prefixes
HNCP as if they were delegated prefixes of a (virtual) external are inserted in HNCP as if they were delegated prefixes of a
connection (Section 6.2). The following rules apply: (virtual) external connection (Section 6.2). The following rules
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 highest node identifier is kept among those with a preferred time
greater than 0 - if there is any. greater than 0 - if there is any.
skipping to change at page 21, line 19 skipping to change at page 21, line 33
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 the
highest node identifier takes precedence and all other nodes MUST highest node identifier takes precedence and all other nodes MUST
cease to announce the conflicting TLV. HNCP routers providing 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 do so on behalf of other devices. Announcements reachable and MAY announce names on behalf of other devices.
are made using Node Name TLVs (Section 10.7) and MUST be unique in Announcements are made using Node Name TLVs (Section 10.7) and the
the whole network. In case of a conflict the announcement of the announced names MUST be unique in the whole network. In case of a
node with the highest node identifier takes precedence and all other conflict the announcement of the node with the highest node
nodes MUST cease to announce the conflicting TLV. HNCP routers identifier takes precedence and all other nodes MUST cease to
providing recursive name resolving services as described above MUST announce the conflicting TLV. HNCP routers providing recursive name
resolve such announced names to their respective IP addresses as if resolving services as described above MUST resolve such announced
there were corresponding A/AAAA records. names to their respective IP addresses as if there were corresponding
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 MAY
configure announcing of a Domain Name TLV (Section 10.6) for the configure announcing of a Domain Name TLV (Section 10.6) for the
network to use a different one. In case multiple are announced, the network to use a different one. In case multiple are announced, the
domain of the node with the greatest node identifier takes domain of the node with the greatest node identifier takes
precedence. precedence.
9. Securing Third-Party Protocols 9. Securing Third-Party Protocols
Pre-shared keys (PSKs) are often required to secure (for example) Pre-shared keys (PSKs) are often required to secure (for example)
IGPs and other protocols which lack support for asymmetric security. IGPs and other protocols which lack support for asymmetric security.
The following mechanism manages PSKs using HNCP to enable The following mechanism manages PSKs using HNCP to enable
bootstrapping of such third-party protocols. The scheme SHOULD be bootstrapping of such third-party protocols. The scheme SHOULD NOT
used only in conjunction with secured HNCP unicast transport (=DTLS), be used unless in conjunction with secured HNCP unicast transport
as transferring the PSK in plain-text anywhere in the network is a (i.e., DTLS), as transferring the PSK in plain-text anywhere in the
potential risk, especially as the originator may not know about network is a potential risk, especially as the originator may not
security (and use of DNCP security) on all links. The following know about security (and use of DNCP security) on all links. The
rules define how such a PSK is managed and used: following 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 the Section 4.6 of
[I-D.ietf-homenet-dncp]. [I-D.ietf-homenet-dncp].
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 HMAC-
SHA256 [RFC6234] with a per-protocol HMAC-key) so that disclosure of SHA256 based HKDF [RFC6234] with the particular protocol name in the
any derived key does not impact other users of the managed PSK. info field) so that disclosure of any derived key does not impact
Furthermore derived PSKs MUST be updated whenever the managed PSK other users of the managed PSK. Furthermore derived PSKs MUST be
changes. 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 [I-D.ietf-homenet-dncp] apply. Note that most HNCP
variable-length TLVs also support optional nested TLVs, and they are variable-length TLVs also support optional nested TLVs, and they are
encoded after the variable length content, followed by the zero encoded after the variable length content, followed by the zero
padding of the variable length content to the next 32-bit boundary. padding of the variable length content to the next 32-bit boundary.
skipping to change at page 23, line 4 skipping to change at page 23, line 21
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
zero when creating this TLV, and their value MUST be ignored when zero 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 some value between 1 and 7 [RFC6762] proxy. It MUST be set to 0 if the router is not capable
included (4 is the default) if the router is capable of proxying of proxying MDNS, otherwise it SHOULD be set to 4 but MAY be set
MDNS and 0 otherwise. The values 8-15 are reserved for future to any value from 1 to 7 to indicate a non-default priority. The
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 some value between 1 and 7 included (4 server. It MUST be set to 0 if the router is not capable of
is the default) if the router is capable of providing prefixes providing prefixes through DHCPv6-PD (Section 6.3.4), otherwise it
through DHCPv6-PD (Section 6.3.4) and 0 otherwise. The values SHOULD be set to 4 but MAY be set to any value from 1 to 7 to
8-15 are reserved for future use. indicate a non-default priority. The values 8-15 are reserved for
future use.
H-capability: Priority value used for electing the on-link DHCPv6 H-capability: Priority value used for electing the on-link DHCPv6
server offering non-temporary addresses. It MUST be set to some server offering non-temporary addresses. It MUST be set to 0 if
value between 1 and 7 included (4 is the default) if the router is the router is not capable of providing such addresses, otherwise
capable of providing such addresses and 0 otherwise. The values it SHOULD be set to 4 but MAY be set to any value from 1 to 7 to
8-15 are reserved for future use. indicate a non-default priority. The values 8-15 are reserved for
future use.
L-capability: Priority value used for electing the on-link DHCPv4 L-capability: Priority value used for electing the on-link DHCPv4
server. It MUST be set to some value between 1 and 7 included (4 server. It MUST be set to 0 if the router is not capable of
is the default) if the router is capable of running a legacy running a legacy DHCPv4 server offering IPv4 addresses to clients,
DHCPv4 server offering IPv4 addresses to clients and 0 otherwise. otherwise it SHOULD be set to 4 but MAY be set to any value from 1
The values 8-15 are reserved for future use. to 7 to indicate a non-default priority. The values 8-15 are
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 |
skipping to change at page 25, line 16 skipping to change at page 25, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 usecase (e.g., local
reachability, internet connectivity) do exist or should 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 (Value contains significant the actual length of the prefix and the Value containing
bits of the destination prefix padded with zeroes up to the significant bits of the destination prefix padded with zeroes
next byte boundary). up to the next byte boundary.
129 : DNS Zone (Value contains an RFC 1035 [RFC1035] encoded 129 : DNS Domain. The Value contains an RFC 1035 [RFC1035]
DNS label sequence). encoded DNS label sequence. Compression MUST NOT be used. 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
skipping to change at page 28, line 27 skipping to change at page 28, line 47
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (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 zone; IPv4 addresses are represented as IPv4-mapped addresses the zone; IPv4 addresses are represented as IPv4-mapped addresses
[RFC4291]. The special value of :: (all-zero) means the [RFC4291]. The special value of :: (all-zero) means the
delegation is available in the global DNS-hierarchy. delegation is available in the global DNS-hierarchy.
skipping to change at page 28, line 47 skipping to change at page 29, line 18
IP Address : The IPv6 address of the authoritative DNS server for IP Address : The IPv6 address of the authoritative DNS server for
the zone; IPv4 addresses are represented as IPv4-mapped addresses the zone; IPv4 addresses are represented as IPv4-mapped addresses
[RFC4291]. The special value of :: (all-zero) means the [RFC4291]. The special value of :: (all-zero) means the
delegation is available in the global DNS-hierarchy. delegation is available in the global DNS-hierarchy.
Reserved : Those bits MUST be set to zero when creating the TLV and Reserved : Those bits MUST be set to zero 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-SD [RFC6763] Legacy-Browse, indicates that this
delegated zone should be included in the network's DNS-SD legacy delegated zone SHOULD be included in the network's DNS-SD legacy
browse list of domains at lb._dns- sd._udp.(DOMAIN-NAME). Local browse list of domains at lb._dns- sd._udp.(DOMAIN-NAME). Local
forward zones SHOULD have this bit set, reverse zones SHOULD NOT. forward zones SHOULD have this bit set, reverse zones SHOULD NOT.
B-bit : (DNS-SD [RFC6763] Browse) indicates that this delegated zone B-bit : (DNS-SD [RFC6763] Browse) indicates that this delegated zone
should be included in the network's DNS-SD browse list of domains SHOULD be included in the network's DNS-SD browse list of domains
at b._dns-sd._udp. (DOMAIN-NAME). Local forward zones SHOULD at b._dns-sd._udp. (DOMAIN-NAME). Local forward zones SHOULD
have this bit set, reverse zones SHOULD NOT. have this bit set, reverse zones SHOULD NOT.
S-bit : (fully-qualified DNS-SD [RFC6763] domain) indicates that S-bit : (fully-qualified DNS-SD [RFC6763] domain) indicates that
this delegated zone consists of a fully-qualified DNS-SD domain, this delegated zone consists of a fully-qualified DNS-SD domain,
which should be used as base for DNS-SD domain enumeration, i.e., which should be used as base for DNS-SD domain enumeration, i.e.,
_dns-sd._udp.(Zone) exists. Forward zones MAY have this bit set, _dns-sd._udp.(Zone) exists. Forward zones MAY have this bit set,
reverse zones MUST NOT. This can be used to provision DNS search reverse zones MUST NOT. This can be used to provision DNS search
path to hosts for non-local services (such as those provided by an path to hosts for non-local services (such as those provided by an
ISP, or other manually configured service providers). Zones with ISP, or other manually configured service providers). Zones with
this flag SHOULD be added to the search domains advertised to this flag SHOULD be added to the search domains advertised to
clients. clients.
Zone : The label sequence of the zone, encoded as the domain names Zone : The label sequence encoded according to [RFC1035].
are encoded DNS messages as specified in [RFC1035]. The last Compression MUST NOT be used. The label sequence MUST end with an
label in the zone MUST be empty. 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 29, line 33 skipping to change at page 30, line 4
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 zone MUST end with an empty Compression MUST NOT be used. The label sequence MUST end with an
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 |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 34, line 5 skipping to change at page 34, line 27
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 which is enabled for
HNCP traffic. If left unsecured, attackers may perform arbitrary HNCP traffic. If left unsecured, attackers may perform arbitrary
eavesdropping, spoofing or denial of service attacks on HNCP services traffic redirection, eavesdropping, spoofing or denial of service
such as address assignment or service discovery. attacks on HNCP services such as address assignment or service
discovery, and the protocols secured using HNCP-derived keys such 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, DNCP secure mode MUST be used to adequate protection from attackers, DTLS-based secure unicast
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 the
individual security aspects of the respective protocols must be 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 should set up a registry for the (decimal values within range
0-1023) "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)", with the following initial contents:
0-31: Reserved - specified in the DNCP registry
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 4 skipping to change at page 35, line 26
35: Assigned-Prefix 35: Assigned-Prefix
36: Node-Address 36: Node-Address
37: DHCPv4-Data 37: DHCPv4-Data
38: DHCPv6-Data 38: DHCPv6-Data
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-512: Free - policy of 'RFC required' should be used. 44-511: Free - policy of 'RFC required' [RFC5226] should be used.
512-767: Reserved - specified in the DNCP registry
768-1023: Reserved - to be used for per-implementation The range reserved by DNCP for Private Use (768-1023) is used by
experimentation. How collision is avoided is out of scope of this HNCP for per-implementation experimentation. How collisions are
document. avoided is out of the scope of this document.
HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP- HNCP requires allocation of well-known UDP port numbers HNCP-UDP-PORT
DTLS-PORT, as well as an IPv6 link-local multicast address All- (service name: hncp-udp-port, description: HNCP) and HNCP-DTLS-PORT
Homenet-Nodes. (service name: hncp-dtls-port, description: HNCP over DTLS), as well
as an IPv6 link-local multicast address All-Homenet-Nodes.
14. References 14. References
14.1. Normative references 14.1. Normative references
[I-D.ietf-homenet-dncp] [I-D.ietf-homenet-dncp]
Stenberg, M. and S. Barth, "Distributed Node Consensus Stenberg, M. and S. Barth, "Distributed Node Consensus
Protocol", draft-ietf-homenet-dncp-09 (work in progress), Protocol", draft-ietf-homenet-dncp-12 (work in progress),
August 2015. November 2015.
[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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Security Version 1.2", RFC 6347, January 2012. IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
"Prefix Exclude Option for DHCPv6-based Prefix Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
Delegation", RFC 6603, May 2012. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[I-D.ietf-homenet-prefix-assignment] [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O.
Pfister, P., Paterson, B., and J. Arkko, "Distributed Troan, "Prefix Exclude Option for DHCPv6-based Prefix
Prefix Assignment Algorithm", draft-ietf-homenet-prefix- Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012,
assignment-08 (work in progress), August 2015. <http://www.rfc-editor.org/info/rfc6603>.
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>.
[RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
A., Beser, B., and J. Privat, "The User Class Option for A., Beser, B., and J. Privat, "The User Class Option for
DHCP", RFC 3004, November 2000. DHCP", RFC 3004, DOI 10.17487/RFC3004, November 2000,
<http://www.rfc-editor.org/info/rfc3004>.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
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,
December 2003. DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"IPv6 Home Networking Architecture Principles", RFC 7368,
October 2014.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. DOI 10.17487/RFC1321, April 1992,
<http://www.rfc-editor.org/info/rfc1321>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. 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, October 2005. Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, April 2014. Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/
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,
September 2007. DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[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.3. URIs 14.2. Informative references
[3] http://www.openwrt.org [RFC3118] Droms, R. and W. Arbaugh., Ed., "Authentication for DHCP
Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,
<http://www.rfc-editor.org/info/rfc3118>.
[4] http://www.homewrt.org/doku.php?id=run-conf [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>.
[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>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI
10.17487/RFC6234, May 2011,
<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.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013,
<http://www.rfc-editor.org/info/rfc7084>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
Appendix A. Changelog [RFC Editor: please remove] Appendix A. Changelog [RFC Editor: please remove]
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 draft-ietf-homenet-hncp-09: Added nested TLV definitions for variable
length TLVs. NOTE: Node name TLV encoding includes now length byte. length TLVs. NOTE: Node name TLV encoding includes now length byte.
Version TLV now itself indicates version. Version TLV now itself indicates version.
draft-ietf-homenet-hncp-08: Editorial reorganization. draft-ietf-homenet-hncp-08: Editorial reorganization.
draft-ietf-homenet-hncp-07: Using version 1 instead of version 0, as draft-ietf-homenet-hncp-07: Using version 1 instead of version 0, as
existing implementations already use it. existing implementations already use it.
draft-ietf-homenet-hncp-06: Various edits based on feedback, draft-ietf-homenet-hncp-06: Various edits based on feedback,
skipping to change at page 38, line 43 skipping to change at page 39, line 51
Appendix B. Draft source [RFC Editor: please remove] Appendix B. Draft source [RFC Editor: please remove]
This draft is available at https://github.com/fingon/ietf-drafts/ in This draft is available at https://github.com/fingon/ietf-drafts/ in
source format. Issues and pull requests are welcome. source format. Issues and pull requests are welcome.
Appendix C. Implementation [RFC Editor: please remove] Appendix C. Implementation [RFC Editor: please remove]
A GPLv2-licensed implementation of HNCP is currently under A GPLv2-licensed implementation of HNCP is currently under
development at https://github.com/sbyx/hnetd/ and binaries are development at https://github.com/sbyx/hnetd/ and binaries are
available in the OpenWrt [3] package repositories. See [4] for more available in the OpenWrt package repositories (
information. Feedback and contributions are welcome. http://www.openwrt.org ). See http://www.homewrt.org/
doku.php?id=run-conf for more information. Feedback and
contributions are welcome.
Appendix D. Acknowledgements 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 draft.
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
 End of changes. 93 change blocks. 
230 lines changed or deleted 290 lines changed or added

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