draft-ietf-homenet-hncp-07.txt   draft-ietf-homenet-hncp-08.txt 
Homenet Working Group M. Stenberg Homenet Working Group M. Stenberg
Internet-Draft Internet-Draft S. Barth
Intended status: Standards Track S. Barth Intended status: Standards Track Independent
Expires: January 6, 2016 Expires: February 7, 2016 P. Pfister
P. Pfister
Cisco Systems Cisco Systems
July 5, 2015 August 6, 2015
Home Networking Control Protocol Home Networking Control Protocol
draft-ietf-homenet-hncp-07 draft-ietf-homenet-hncp-08
Abstract Abstract
This document describes the Home Networking Control Protocol (HNCP), This document describes the Home Networking Control Protocol (HNCP),
an extensible configuration protocol and a set of requirements for an extensible configuration protocol and a set of requirements for
home network devices on top of the Distributed Node Consensus home network devices. HNCP is described as a profile of and
Protocol (DNCP). It enables automated configuration of addresses, extension to the Distributed Node Consensus Protocol (DNCP). HNCP
naming, network borders and the seamless use of a routing protocol. enables discovery of network borders, automated configuration of
addresses, name resolution, service discovery, and the use of any
routing protocol which supports routing based on both source and
destination address.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 6, 2016. This Internet-Draft will expire on February 7, 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
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
2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Common Links . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements language . . . . . . . . . . . . . . . . . . 6
5. Border Discovery . . . . . . . . . . . . . . . . . . . . . . 5 3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Autonomic Address Configuration . . . . . . . . . . . . . . . 7 4. HNCP Versioning and Router Capabilities . . . . . . . . . . . 8
6.1. External Connections . . . . . . . . . . . . . . . . . . 7 5. Interface Classification . . . . . . . . . . . . . . . . . . 9
6.1.1. External Connection TLV . . . . . . . . . . . . . . . 7 5.1. Interface Categories . . . . . . . . . . . . . . . . . . 9
6.1.2. Delegated Prefix TLV . . . . . . . . . . . . . . . . 8 5.2. DHCP Aided Auto-Detection . . . . . . . . . . . . . . . . 10
6.1.3. Prefix Domain TLV . . . . . . . . . . . . . . . . . . 9 5.3. Algorithm for Border Discovery . . . . . . . . . . . . . 10
6.1.4. DHCP Data TLVs . . . . . . . . . . . . . . . . . . . 10 6. Autonomous Address Configuration . . . . . . . . . . . . . . 11
6.2. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 11 6.1. Common Link . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.1. Prefix Assignment Algorithm Parameters . . . . . . . 11 6.2. External Connections . . . . . . . . . . . . . . . . . . 12
6.2.2. Assigned Prefix TLV . . . . . . . . . . . . . . . . . 12 6.3. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 13
6.2.3. Making New Assignments . . . . . . . . . . . . . . . 13 6.3.1. Prefix Assignment Algorithm Parameters . . . . . . . 13
6.2.4. Applying Assignments . . . . . . . . . . . . . . . . 14 6.3.2. Making New Assignments . . . . . . . . . . . . . . . 15
6.2.5. DHCPv6-PD Excluded Prefix Support . . . . . . . . . . 14 6.3.3. Applying Assignments . . . . . . . . . . . . . . . . 16
6.2.6. Downstream Prefix Delegation Support . . . . . . . . 15 6.3.4. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . 16
6.3. Node Address Assignment . . . . . . . . . . . . . . . . . 15 6.4. Node Address Assignment . . . . . . . . . . . . . . . . . 16
6.4. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 16 6.5. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 17
6.5. Special Purpose Prefixes . . . . . . . . . . . . . . . . 17
7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 18 7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 18
7.1. DHCPv6 for Addressing or Configuration . . . . . . . . . 18 7.1. DHCPv6 for Addressing or Configuration . . . . . . . . . 19
7.2. Sending Router Advertisements . . . . . . . . . . . . . . 19 7.2. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 19
7.3. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 19 7.3. DHCPv4 for Addressing and Configuration . . . . . . . . . 19
7.4. DHCPv4 for Addressing and Configuration . . . . . . . . . 20 7.4. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 20
7.5. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 20
8. Naming and Service Discovery . . . . . . . . . . . . . . . . 20 8. Naming and Service Discovery . . . . . . . . . . . . . . . . 20
8.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 21 9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 21
8.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 22 10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 22
8.3. Node Name TLV . . . . . . . . . . . . . . . . . . . . . . 23 10.1. HNCP Version TLV . . . . . . . . . . . . . . . . . . . . 22
9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 23 10.2. External Connection TLV . . . . . . . . . . . . . . . . 23
10. HNCP Versioning and Capabilities . . . . . . . . . . . . . . 24 10.2.1. Delegated Prefix TLV . . . . . . . . . . . . . . . . 23
11. Requirements for HNCP Routers . . . . . . . . . . . . . . . . 25 10.2.2. DHCPv6 Data TLV . . . . . . . . . . . . . . . . . . 25
12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10.2.3. DHCPv4 Data TLV . . . . . . . . . . . . . . . . . . 26
12.1. Border Determination . . . . . . . . . . . . . . . . . . 27 10.3. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . 26
12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 28 10.4. Node Address TLV . . . . . . . . . . . . . . . . . . . . 27
12.3. Other Protocols in the Home . . . . . . . . . . . . . . 28 10.5. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 27
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10.6. Domain Name TLV . . . . . . . . . . . . . . . . . . . . 29
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.7. Node Name TLV . . . . . . . . . . . . . . . . . . . . . 29
14.1. Normative references . . . . . . . . . . . . . . . . . . 29 10.8. Managed PSK TLV . . . . . . . . . . . . . . . . . . . . 30
14.2. Informative references . . . . . . . . . . . . . . . . . 30 11. General Requirements for HNCP Nodes . . . . . . . . . . . . . 30
12. Security Considerations . . . . . . . . . . . . . . . . . . . 32
Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 31 12.1. Interface Classification . . . . . . . . . . . . . . . . 32
Appendix B. Draft source [RFC Editor: please remove] . . . . . . 32 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 33
Appendix C. Implementation [RFC Editor: please remove] . . . . . 32 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 33
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 32 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.1. Normative references . . . . . . . . . . . . . . . . . . 35
14.2. Informative references . . . . . . . . . . . . . . . . . 35
Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 37
Appendix B. Draft source [RFC Editor: please remove] . . . . . . 38
Appendix C. Implementation [RFC Editor: please remove] . . . . . 38
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
HNCP synchronizes state across a small site in order to allow HNCP is designed to facilitate sharing of state among home routers to
automated network configuration. The protocol enables use of border fulfill the needs of the IPv6 homenet architecture [RFC7368], which
discovery, address prefix distribution assumes zero-configuration operation, multiple subnets, multiple home
[I-D.ietf-homenet-prefix-assignment], naming and other services routers and (potentially) multiple upstream service providers
across multiple links. providing (potentially) multiple prefixes to the home network. While
RFC7368 sets no requirements for IPv4 support, HNCP aims to support
dual-stack mode of operation, and therefore the functionality is
designed with that in mind. The state is shared as TLVs among the
routers (and potentially advanced hosts) to enable:
HNCP provides enough information for a routing protocol to operate o Autonomic discovery of network borders (Section 5.3) based on DNCP
without homenet-specific extensions. In homenet environments where topology.
multiple IPv6 source-prefixes can be present, routing based on source
and destination address is necessary [RFC7368].
2. Requirements language o Automated portioning of prefixes delegated by the service
providers as well as assigned prefixes to both HNCP and non-HNCP
routers (Section 6.3) using [I-D.ietf-homenet-prefix-assignment].
Prefixes assigned to HNCP routers are used to:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", * Provide addresses to non-HNCP aware nodes (using SLAAC and
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and DHCP).
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
3. DNCP Profile * Provide space in which HNCP nodes assign their own addresses
(Section 6.4).
HNCP is defined as a profile of DNCP [I-D.ietf-homenet-dncp] with the o Internal and external name resolution, as well as multi-link
following parameters: service discovery (Section 8).
o HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport over o Other services not defined in this document, that do need to share
link-local scoped IPv6, using unicast and multicast (All-Homenet- state among homenet nodes, and do not cause rapid and constant TLV
Routers is the HNCP group address). Received datagrams with an changes (see following applicability section).
IPv6 source or destination address which is not link-local scoped
MUST be ignored. Unicast replies to multicast and unicast
messages MUST be sent to the IPv6 source address and port of the
original message. Each node MUST be able to receive (and
potentially reassemble) UDP datagrams with a payload of at least
4000 bytes.
o HNCP operates on multicast-capable interfaces only. HNCP routers HNCP is a DNCP [I-D.ietf-homenet-dncp]-based protocol and includes a
MUST assign a unique 32-bit endpoint identifier to each interface DNCP profile which defines transport and synchronization details for
for which HNCP is enabled. The value zero is reserved for sharing state across nodes defined in Section 3. The rest of the
internal purposes. Implementations MAY use a value equivalent to document defines behavior of the services noted above, how the
the sin6_scope_id for the given interface. required TLVs are encoded (Section 10), as well as additional
requirements on how HNCP nodes should behave (Section 11).
o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as 1.1. Applicability
described in DNCP if exchanged over unsecured links. UDP on port
HNCP-DTLS-PORT is used for this purpose. A node implementing HNCP
security MUST support the DNCP Pre-Shared Key method, SHOULD
support the DNCP Certificate Based Trust Consensus and MAY support
the PKI-based trust method.
o HNCP uses opaque 32-bit node identifiers While HNCP does not deal with routing protocols directly (except
(DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP potentially informing them about internal and external interfaces if
SHOULD generate and use a random node identifier. If using a classification specified in Section 5.3 is used), in homenet
random node identifier and there is a node identifier collision, environments where multiple IPv6 source-prefixes can be present,
the node MUST immediately generate and use a new random node routing based on source and destination address is necessary
identifier which is not used by any other node. [RFC7368]. Ideally, the routing protocol is also zero-configuration
(e.g., no need to configure identifiers or metrics) although HNCP can
be used also with a manually configured routing protocol.
o HNCP nodes MUST ignore all Node State TLVs received via multicast As HNCP uses DNCP as the actual state synchronization protocol, the
on a link which has DNCP security enabled in order to prevent applicability statement of DNCP can be used here as well; HNCP should
spoofing of node state changes. not be used for any data that changes rapidly and constantly, and
locators to find such services should be published using it instead.
This is why the naming and service discovery (Section 8) TLVs contain
only DNS server addresses, and no actual per-name or per-service data
of hosts.
o HNCP nodes use the following Trickle parameters: HNCP TLVs specified within this document, in steady state, stay
constant, with one exception: as Delegated Prefix TLVs
(Section 10.2.1) do contain lifetimes, they force re-publishing of
that data every time the valid or preferred lifetimes of prefixes are
updated (significantly). Therefore, it is desirable for ISPs to
provide large enough valid and preferred lifetimes to avoid
unnecessary HNCP state churn in homes, but even given non-cooperating
ISPs, the state churn is proportional only to the number of
externally received delegated prefixes and not the home network size,
and should therefore be relatively low.
* k SHOULD be 1, as the timer reset when data is updated and HNCP assumes a certain level of control over host configuration
further retransmissions should handle packet loss. servers (e.g., DHCP [RFC2131]) on links that are managed by its
routers. Some HNCP functionality (such as border discovery or some
aspects of naming) might be affected by existing DHCP servers not
aware of the HNCP-managed network and thus might need to be
reconfigured to not result in unexpected behavior.
* Imin SHOULD be 200 milliseconds but MUST NOT be lower. Note: While HNCP is designed to be used by (home) routers, it can also be
Earliest transmissions may occur at Imin / 2. used by advanced hosts that want to do, e.g., their own address
assignment and routing.
* Imax SHOULD be 7 doublings of Imin (i.e. 25.6 seconds) but MUST HNCP is link layer agnostic; if a link supports IPv6 (link-local)
NOT be lower. multicast and unicast, HNCP will work on it. Trickle retransmissions
and keep-alives will handle both packet loss and non-transitive
connectivity, ensuring eventual convergence.
o HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP 2. Terminology
non-cryptographic hash function H(x).
o HNCP nodes MUST use DNCP's keep-alive extension on all endpoints. The following terms are used as they are defined in
The following parameters are suggested: [I-D.ietf-homenet-prefix-assignment]:
* Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20 o Advertised Prefix Priority
seconds.
* Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1. o Advertised Prefix
4. Common Links o Assigned Prefix
HNCP uses the concept of Common Links for some of its applications. o Delegated Prefix
A Common Link usually refers to a link layer broadcast domain with
certain properties and is used, e.g., to determine where prefixes
should be assigned or which neighboring nodes participate in the
election of a DHCP(v6) server. The Common Link is computed
separately for each local interface, and it always contains the local
interface. Additionally, if the local interface is not in ad-hoc
mode, it also contains the set of interfaces that are bidirectionally
reachable from the given local interface, i.e. every remote interface
of a remote node meeting all of the following requirements:
o The local node publishes a Neighbor TLV with: o Prefix Adoption
* Neighbor Node Identifier = remote node's node identifier o Private Link
* Neighbor Endpoint Identifier = remote interface's endpoint o Published Assigned Prefix
identifier
* Endpoint Identifier = local interface's endpoint identifier o Applied Assigned Prefix
o The remote node publishes a Neighbor TLV with: o Shared Link
* Neighbor Node Identifier = local node's node identifier The following terms are used as they are defined in
[I-D.ietf-homenet-dncp]:
* Neighbor Endpoint Identifier = local interface's endpoint o DNCP profile
identifier
* Endpoint Identifier = remote interface's endpoint identifier o Node identifier
A node MUST be able to detect whether two of its local interfaces are o Link
connected, e.g. by detecting an identical remote interface being part
of the Common Links of both local interfaces.
5. Border Discovery o Interface
(HNCP) node A device implementing this specification.
(HNCP) router A device implementing this specification, which
forwards traffic on behalf of other devices.
Border separation point between administrative domains; in
this case, between the home network and any other
network, i.e., usually an ISP network.
HNCP router's interfaces are either internal, external or of a Internal link a link that does not cross borders.
different category derived from the internal one. This section Internal an interface that is connected to an internal link.
defines the border discovery algorithm. It is suitable for both IPv4 interface
and IPv6 (single or dual-stack) and determines whether an HNCP
interface is internal, external, or uses another fixed category. The
algorithm is derived from the edge router interactions described in
the Basic Requirements for IPv6 Customer Edge Routers [RFC7084].
This algorithm MUST be implemented by any router implementing HNCP.
The border discovery auto-detection algorithm works as follows, with External an interface that is connected to a link which is
evaluation stopping at first match: interface not an internal link.
1. If a fixed category is configured for the interface, it MUST be Interface a local configuration denoting the use of a
used. category particular interface. The interface category
determines how a HNCP node should treat the
particular interface. External and internal
category mark the interface as out of or within the
network border; there are also a number of sub-
categories to internal that further affect local
node behavior. See Section 5.1 for a list of
interface categories and how they behave. The
internal or external categories may also be auto-
detected (Section 5.3).
2. If a delegated prefix could be acquired by running a DHCPv6 Border router a router announcing external connectivity and
client on the interface, it MUST be considered external. forwarding traffic across the network border.
3. If an IPv4 address could be acquired by running a DHCPv4 client Common Link a set of nodes on a link which share a common view
on the interface it MUST be considered external. of it, i.e., they see each other's traffic and the
same set of hosts. Unless configured otherwise
transitive connectivity is assumed.
4. Otherwise the interface MUST be considered internal. DHCPv4 refers to Dynamic Host Configuration Protocol
[RFC2131] in this document.
DHCPv6 refers to Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) [RFC3315] in this document.
DHCP refers to cases which apply to both DHCPv4 and
DHCPv6 in this document.
In order to avoid conflicts between border discovery and HNCP routers 2.1. Requirements language
running DHCPv4 [RFC2131] or DHCPv6-PD [RFC3633] servers, each router
MUST implement the following mechanism based on The User Class Option
for DHCPv4 [RFC3004] and its DHCPv6 counterpart [RFC3315]:
o An HNCP router running a DHCP client on an HNCP interface MUST The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
include a DHCP User-Class consisting of the ASCII-String "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"HOMENET". "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
o An HNCP router running a DHCP server on an HNCP interface MUST 3. DNCP Profile
ignore or reject DHCP-Requests containing a DHCP User-Class
consisting of the ASCII-String "HOMENET".
A router MUST allow setting a category of either auto-detected, The DNCP profile of HNCP is defined as follows:
internal or external for each interface which is suitable for both
internal and external connections. In addition the following
specializations of the internal category are defined to modify the
local router behavior:
Leaf category: This declares an interface used by client devices o HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport over
only. Such an interface acts as an internal interface with the link-local scoped IPv6, using unicast and multicast (All-Homenet-
exception that HNCP or routing protocol traffic MUST NOT be sent Nodes is the HNCP group address). Received datagrams where either
on the interface, and all such traffic received on the interface or both of the IPv6 source or destination address is not link-
MUST be ignored. This category SHOULD be supported. local scoped MUST be ignored. Replies to multicast and unicast
messages MUST be sent to the IPv6 source address and port of the
original message. Each node MUST be able to receive (and
potentially reassemble) UDP datagrams with a payload of at least
4000 bytes.
Guest category: This declares an interface used by untrusted client o HNCP operates on multicast-capable interfaces only. HNCP nodes
devices only. In addition to the restrictions of the Leaf MUST assign a locally unique non-zero 32-bit endpoint identifier
category, HNCP routers MUST enable firewalling rules such that to each interface for which HNCP is enabled. The value zero it is
connected devices are unable to reach other devices inside the not used in DNCP TLVs, but it has a special meaning in HNCP TLVs
HNCP network or query services advertised by them unless (see Section 10.3 and Section 6.4). Implementations MAY use a
explicitly allowed. This category SHOULD be supported. value equivalent to the IPv6 link-local scope identifier for the
given interface.
Ad-hoc category: This configures an interface to be ad-hoc o HNCP uses opaque 32-bit node identifiers
(Section 4). Ad-hoc interfaces are considered internal but no (DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP
assumption is made on the the link transitivity properties. SHOULD use a random node identifier. If there is a node
Support for this category is OPTIONAL. identifier collision (as specified in the Node State TLV handling
of Section 4.4 of [I-D.ietf-homenet-dncp]), the node MUST
immediately generate and use a new random node identifier which is
not used by any other node at the time, based on the current DNCP
network state.
Hybrid category: This declares an interface to be internal while o HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP
still running DHCPv4 and DHCPv6-PD clients on it. It is assumed non-cryptographic hash function H(x).
that the link is under control of a legacy, trustworthy non-HNCP
router, still within the same network. Detection of this category
automatically in addition to manual configuration is out of scope
of this document. Support for this category is OPTIONAL.
Each router MUST continuously scan each active interface that does o HNCP nodes MUST use DNCP's per-endpoint keep-alive extension on
not have a fixed category in order to dynamically reclassify it if all endpoints. The following parameters are suggested:
necessary. The router therefore runs an appropriately configured
DHCPv4 and DHCPv6 client as long as the interface is active including
states where it considers the interface to be internal. The router
SHOULD wait for a reasonable time period (5 seconds as a default),
during which the DHCP clients can acquire a lease, before treating a
newly activated or previously external interface as internal. Once
it treats a certain interface as internal it MUST start forwarding
traffic with appropriate source addresses between its internal
interfaces and allow internal traffic to reach external networks
according to the routes it publishes. Once a router detects an
interface transitioning to external it MUST stop any previously
enabled internal forwarding. In addition it SHOULD announce the
acquired information for use in the network as described in later
sections of this draft if the interface appears to be connected to an
external network.
6. Autonomic Address Configuration * Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20
seconds.
This section specifies how HNCP routers configure host and router * Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1 on virtually
addresses. At first border routers share information obtained from lossless links works fine as it allows for one lost keep-alive.
service providers or local configuration by publishing one or more If used on a lossy link, considerably higher multiplier, such
External Connection TLVs. These contain other TLVs such as Delegated as 15, should be used instead. In that case, an implementation
Prefix TLVs which are then used for prefix assignment. Finally, HNCP might prefer shorter keep-alive intervals on that link as well
routers obtain addresses either statelessly or using a specific to ensure that DNCP_KEEPALIVE_INTERVAL *
stateful mechanism and hosts and legacy routers are configured using DNCP_KEEPALIVE_MULTIPLIER timeout after which (entirely) lost
SLAAC or DHCP. nodes time out is low enough.
In all TLVs specified in this section which include a prefix, IPv4 o HNCP nodes use the following Trickle parameters for the per-
prefixes are encoded using the IPv4-mapped IPv6 addresses format interface Trickle instances:
[RFC4291]. The prefix length of such IPv4 prefix is set to 96 plus
the IPv4 prefix length.
6.1. External Connections * k SHOULD be 1, as the timer reset when data is updated and
further retransmissions should handle packet loss. Even on a
non-transitive lossy link, the eventual per-endpoint keep-
alives should ensure status synchronization occurs.
Each HNCP router MAY obtain external connection information from one * Imin SHOULD be 200 milliseconds but MUST NOT be lower. Note:
or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or Earliest transmissions may occur at Imin / 2.
static configuration. This section specifies how such information is
encoded and advertised.
6.1.1. External Connection TLV * Imax SHOULD be 7 doublings of Imin (i.e., 25.6 seconds) but
MUST NOT be lower.
An External Connection TLV is a container-TLV used to gather network o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as
configuration information associated with a single external described in DNCP if exchanged over unsecured links. UDP on port
connection. A node MAY publish an arbitrary number of instances of HNCP-DTLS-PORT is used for this purpose. A node implementing HNCP
this TLV. security MUST support the DNCP Pre-Shared Key method, SHOULD
support the DNCP Certificate Based Trust Consensus and MAY support
the PKI-based trust method.
0 1 2 3 o HNCP nodes MUST ignore all Node State TLVs received via multicast
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 on a link which has DNCP security enabled in order to prevent
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ spoofing of node state changes.
| Type: EXTERNAL-CONNECTION (33)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested TLVs |
The External Connection TLV is a container which: 4. HNCP Versioning and Router Capabilities
o MAY contain an arbitrary number of Delegated Prefix TLVs. Multiple versions of HNCP based on compatible DNCP profiles may be
present in the same network when transitioning between HNCP versions
and for troubleshooting purposes it might be beneficial to identify
the HNCP agent version running. Therefore each node MUST include an
HNCP-Version TLV (Section 10.1) in its Node Data and MUST ignore
(except for DNCP synchronization purposes) any TLVs with a type
greater than 32 published by nodes not also publishing an HNCP-
Version TLV or publishing such a TLV with a different Version.
o MUST NOT contain multiple Delegated Prefix TLVs with identical or HNCP routers may also have different capabilities regarding
overlapping prefixes. In such a situation, the External interactions with hosts, e.g., for configuration or service
Connection TLV MUST be ignored. discovery. These are indicated by M, P, H and L values. The
combined "capability value" is a metric indicated by interpreting the
bits as an integer, i.e., (M << 12 | P << 8 | H << 4 | L). These
values are used to elect certain servers on a Common Link, as
described in Section 7. Nodes that are not routers MUST announce the
value 0 for all capabilities and therefore do not take part in these
elections.
o MAY contain at most one DHCPv6 Data TLV and at most one DHCPv4 5. Interface Classification
Data TLV encoding options associated with the External Connection
but MUST NOT contain more than one of each otherwise the External
Connection TLV MUST be ignored.
o MAY contain other TLVs for future use. Such additional TLVs MUST 5.1. Interface Categories
be ignored.
6.1.2. Delegated Prefix TLV HNCP specifies the following categories interfaces can be configured
to be in:
The Delegated Prefix TLV is used by HNCP routers to advertise Internal category: This declares an interfaces to be internal, i.e.,
prefixes which are allocated to the whole network and will be used within the borders of the HNCP network. HNCP traffic MUST be sent
for prefix assignment. Any Delegated Prefix TLV MUST be nested in an and received. Routers MUST forward traffic with appropriate
External Connection TLV. source addresses between their internal interfaces and allow
internal traffic to reach external networks. All nodes MUST
implement this category and nodes not implementing any other
category implicitly use it as a fixed default.
0 1 2 3 External category: This declares an interface to be external, i.e.,
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 not within the borders of the HNCP network. HNCP traffic MUST
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ neither be sent nor received. HNCP routers SHOULD announce
| Type: DELEGATED-PREFIX (34) | Length: >= 9 | acquired configuration information for use in the network as
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ described in Section 6.2, if the interface appears to be connected
| Valid Lifetime | to an external network. HNCP routers MUST implement this
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ category.
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | |
+-+-+-+-+-+-+-+-+ Prefix [+ nested TLVs] +
| |
Valid Lifetime: The time in seconds the delegated prefix is valid. Leaf category: This declares an interface used by client devices
The value is relative to the point in time the Node-Data TLV was only. Such an interface uses the Internal category with the
last published. It MUST be updated whenever the node republishes exception that HNCP traffic MUST NOT be sent on the interface, and
its Node-Data TLV. all such traffic received on the interface MUST be ignored. This
category SHOULD be supported by HNCP routers.
Preferred Lifetime: The time in seconds the delegated prefix is Guest category: This declares an interface used by untrusted client
preferred. The value is relative to the point in time the Node- devices only. In addition to the restrictions of the Leaf
Data TLV was last published. It MUST be updated whenever the node category, HNCP routers MUST filter traffic from and to the
republishes its Node-Data TLV. interface such that connected devices are unable to reach other
devices inside the HNCP network or query services advertised by
them unless explicitly allowed. This category SHOULD be supported
by HNCP routers.
Prefix Length: The number of significant bits in the Prefix. Ad-hoc category: This configures an interface to use the Internal
category but no assumption is made about the the link's
transitivity. All other interface categories assume transitive
connectivity. This affects the Common Link (Section 6.1)
definition. Support for this category is OPTIONAL.
Prefix: Significant bits of the prefix padded with zeroes up to the Hybrid category: This declares an interface to use the Internal
next byte boundary. category while still trying to acquire (external) configuration
information on it, e.g., by running DHCP clients. This is useful,
e.g., if the link is shared with a non-HNCP router under control
and still within the borders of the same network. Detection of
this category automatically in addition to manual configuration is
out of scope of this document. Support for this category is
OPTIONAL.
Nested TLVs: Other TLVs included in the Delegated Prefix TLV and 5.2. DHCP Aided Auto-Detection
starting at the next 32-bit boundary following the end of the
encoded prefix:
* Zero or more Prefix Domain TLVs. In absence of any such TLV Auto-detection of interface categories is possible based on
the prefix is assumed to be generated by an HNCP-router and for interaction with DHCPv4 [RFC2131] and DHCPv6-PD [RFC3633] servers on
internal use only. connected links. HNCP defines special DHCP behavior to differentiate
its internal servers from external ones in order to achieve this.
Therefore all internal devices (including HNCP nodes) running DHCP
servers on links where auto-detection is used by any HNCP node MUST
use the following mechanism based on The User Class Option for DHCPv4
[RFC3004] and its DHCPv6 counterpart [RFC3315]:
* If the encoded prefix represents an IPv6 prefix, at most one o The device MUST ignore or reject DHCP-Requests containing a DHCP
DHCPv6 Data TLV MAY be included, and any included DHCPv4 Data User-Class consisting of the ASCII-String "HOMENET".
TLV MUST be ignored.
* If the prefix represents an IPv4 prefix (encoded as an Not following this rule (e.g., running unmodified DHCP servers) might
IPv4-mapped IPv6 prefix), at most one DHCPv4 Data TLV MAY be lead to false positives when auto-detection is used, i.e., HNCP nodes
included, and any included DHCPv6 Data TLV MUST be ignored. assume an interface to not be internal, even though it was intended
to be.
* It MAY contain other TLVs for future use. Such additional TLVs 5.3. Algorithm for Border Discovery
MUST be ignored.
6.1.3. Prefix Domain TLV This section defines the interface classification algorithm. It is
suitable for both IPv4 and IPv6 (single or dual-stack) and detects
the category of an interface either automatically or based on a fixed
configuration. By determining the category for all interfaces, the
network borders are implicitly defined, i.e., all interfaces not
belonging to the External category are considered to be within the
borders of the network, all others are not.
The Prefix Domain TLV contains information about the origin and The following algorithm MUST be implemented by any node implementing
applicability of a delegated prefix. This information can be used to HNCP. However, if the node does not implement auto-detection, only
determine whether prefixes for a certain domain (e.g. local the first step is required. The algorithm works as follows, with
reachability, internet connectivity) do exist or should be acquired evaluation stopping at first match:
and to make decisions about assigning prefixes to certain links or to
fine-tune border firewalls. See Section 6.5 for a more in-depth
discussion.
0 1 2 3 1. If a fixed category is configured for an interface, it is used.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: PREFIX-DOMAIN (43) | Length: >= 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Type | |
+-+-+-+-+-+-+-+-+ Value +
| |
Domain Type: The type of the domain identifier.
0 : Internet connectivity (no Value). 2. If a delegated prefix could be acquired by running a DHCPv6
client, it is considered external. The DHCPv6 client MUST have
included a DHCPv6 User-Class consisting of the ASCII-String
"HOMENET" in all of its requests.
1-128 : Explicit destination prefix with the Domain Type being 3. If an IPv4 address could be acquired by running a DHCPv4 client
the actual length of the prefix (Value contains significant on the interface, it is considered external. The DHCPv4 client
bits of the destination prefix padded with zeroes up to the MUST have included a DHCP User-Class consisting of the ASCII-
next byte boundary). String "HOMENET" in all of its requests.
129 : DNS Zone (Value contains an RFC 1035 [RFC1035] encoded 4. The interface is considered internal.
DNS label sequence).
130 : Opaque UTF-8 string (e.g. for administrative purposes). Note that as other HNCP nodes will ignore the client due to the user
class option, any server that replies is clearly external (or a
malicious internal node).
131-255: Reserved for future additions. An HNCP router SHOULD allow setting the fixed category for each
interface which may be connected to either an internal or external
device (e.g., an Ethernet port that can be connected to a modem,
another HNCP router or a client).
Value: A variable length identifier of the given type. An HNCP router using auto-detection on an interface MUST run the
appropriately configured DHCP clients as long as the interface
without a fixed category is active (including states where auto-
detection considers it to be internal) and rerun the algorithm above
to react to conditions resulting in a different interface category.
The router SHOULD wait for a reasonable time period (5 seconds as a
default), during which the DHCP clients can acquire a lease, before
treating a newly activated or previously external interface as
internal.
6.1.4. DHCP Data TLVs 6. Autonomous Address Configuration
Auxiliary connectivity information is encoded as a stream of DHCP This section specifies how HNCP nodes configure host and node
options. Such TLVs MUST only be present in an External Connection addresses. At first border routers share information obtained from
TLV or a Delegated Prefix TLV. When included in an External service providers or local configuration by publishing one or more
Connection TLV, they MUST contain DHCP options which are relevant to External Connection TLVs (Section 10.2). These contain other TLVs
the whole External Connection. When included in a Delegated Prefix, such as Delegated Prefix TLVs (Section 10.2.1) which are then used
they MUST contain DHCP options which are specific to the Delegated for prefix assignment. Finally, HNCP nodes obtain addresses either
Prefix. statelessly or using a specific stateful mechanism (Section 6.4).
Hosts and non-HNCP routers are configured using SLAAC, DHCP or
DHCPv6-PD.
The DHCPv6 Data TLV uses the following format: 6.1. Common Link
0 1 2 3 HNCP uses the concept of Common Link both in autonomic address
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 configuration and naming and service discovery (Section 8). A Common
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link refers to the set of interfaces of nodes that see each other's
| Type: DHCPV6-DATA (37) | Length: > 0 | 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
| DHCPv6 option stream | determine where prefixes should be assigned or which peers
participate in the election of a DHCP server. The Common Link is
computed separately for each local internal interface, and it always
contains the local interface. Additionally, if the local interface
is not set to ad-hoc category (see Section 5.1), it also contains the
set of interfaces that are bidirectionally reachable from the given
local interface, that is, every remote interface of a remote node
meeting all of the following requirements:
DHCPv6 option stream: DHCPv6 options encoded as specified in o The local node publishes a Peer TLV with:
[RFC3315].
The DHCPv4 Data TLV uses the following format: * Peer Node Identifier = remote node's node identifier
0 1 2 3 * Peer Endpoint Identifier = remote interface's endpoint
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 identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: DHCPV4-DATA (38) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv4 option stream |
DHCPv4 option stream: DHCPv4 options encoded as specified in
[RFC2131].
6.2. Prefix Assignment * Endpoint Identifier = local interface's endpoint identifier
HNCP uses the Distributed Prefix Assignment Algorithm specified in o The remote node publishes a Peer TLV with:
* Peer Node Identifier = local node's node identifier
* Peer Endpoint Identifier = local interface's endpoint
identifier
* Endpoint Identifier = remote interface's endpoint identifier
A node MUST be able to detect whether two of its local internal
interfaces are connected, e.g., by detecting an identical remote
interface being part of the Common Links of both local interfaces.
6.2. External Connections
Each HNCP router MAY obtain external connection information such as
address prefixes, DNS server addresses and DNS search paths from one
or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or
static configuration. Each individual external connection to be
shared in the network is represented by one External Connection TLV
(Section 10.2).
Announcements of individual external connections may consist of the
following components:
Delegated Prefixes: address space available for assignment to
internal links announced using Delegated Prefix TLVs
(Section 10.2.1). Some address spaces might have special
properties which are necessary to understand in order to handle
them (e.g., information similar to [RFC6603]). This information
is encoded using DHCPv6 Data TLVs (Section 10.2.2) inside the
respective Delegated Prefix TLVs.
Auxiliary Information: information about services such as DNS or
time synchronization regularly used by hosts in addition to
addressing and routing information. This information is encoded
using DHCPv6 Data TLVs (Section 10.2.2) and DHCPv4 Data TLVs
(Section 10.2.3).
Whenever information about reserved parts (e.g., as specified in
[RFC6603]) is received for a delegated prefix, the reserved parts
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
Link.
Some connections or delegated prefixes may have a special meaning and
are not regularly used for internal or internet connectivity, instead
they may provide access to special services like VPNs, sensor
networks, VoIP, IPTV, etc. Care must be taken that these prefixes
are properly integrated and dealt with in the network, in order to
avoid breaking connectivity for devices who are not aware of their
special characteristics or to only selectively allow certain devices
to use them. Such prefixes are distinguished using Prefix Policy
TLVs (Section 10.2.1.1). Their contents MAY be partly opaque to HNCP
nodes, and their identification and usage depends on local policy.
However the following general rules MUST be adhered to:
Special rules apply when making address assignments for prefixes
with Prefix Policy TLVs with type 131, as described in
Section 6.3.2
In presence of any type 1 to 128 Prefix Policy TLV the prefix is
specialized to reach destinations denoted by any such Prefix
Policy TLV, i.e., in absence of a type 0 Prefix Policy TLV it is
not usable for general internet connectivity. An HNCP router MAY
enforce this restriction with appropriate packet filter rules.
6.3. Prefix Assignment
HNCP uses the Prefix Assignment Algorithm
[I-D.ietf-homenet-prefix-assignment] in order to assign prefixes to [I-D.ietf-homenet-prefix-assignment] in order to assign prefixes to
HNCP internal links and uses the terminology defined there. HNCP internal links and uses some of the terminology (Section 2)
defined there. HNCP furthermore defines the Assigned Prefix TLV
(Section 10.3) which MUST be used to announce Published Assigned
Prefixes.
6.2.1. Prefix Assignment Algorithm Parameters 6.3.1. Prefix Assignment Algorithm Parameters
All HNCP nodes running the prefix assignment algorithm MUST use the All HNCP nodes running the prefix assignment algorithm use the
following 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
Prefix TLVs which are not strictly included in prefixes encoded in Prefix TLVs which are not strictly included in prefixes encoded in
other Delegated Prefix TLVs. Note that Delegated Prefix TLVs other Delegated Prefix TLVs. Note that Delegated Prefix TLVs
included in ignored External Connection TLVs are not considered. included in ignored External Connection TLVs are not considered.
It is dynamically updated as Delegated Prefix TLVs are added or It is dynamically updated as Delegated Prefix TLVs are added or
removed. removed.
Set of Shared Links: The set of Common Links associated with Set of Shared Links: The set of Common Links associated with
internal, leaf, guest or ad-hoc interfaces. It is dynamically interfaces with internal, leaf, guest or ad-hoc category. It is
updated as HNCP interfaces are added, removed, or switch from one dynamically updated as interfaces are added, removed, or switch
category to another. When multiple interfaces are detected as from one category to another. When multiple interfaces are
belonging to the same Common Link, prefix assignment is disabled detected as belonging to the same Common Link, prefix assignment
on all of these interfaces except one. 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
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 routers. 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 routers (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 zero, 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 MAY be done instantly). adoption MAY be 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.2.2. Assigned Prefix TLV 6.3.2. Making New Assignments
Published Assigned Prefixes MUST be advertised using the Assigned
Prefix TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: ASSIGNED-PREFIX (35) | Length: >= 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsv. | Prty. | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +
| |
Endpoint Identifier: The endpoint identifier of the local interface
that belongs to the Common Link the prefix is assigned to, or 0 if
the Common Link is a Private Link (e.g., when the prefix is
assigned for downstream prefix delegation).
Rsv.: Bits are reserved for future use. They MUST be set to zero
when creating this TLV, and their value MUST be ignored when
processing the TLV.
Prty: The Advertised Prefix Priority from 0 to 15.
0-1 : Low priorities.
2 : Default priority.
3-7 : High priorities.
8-11 : Administrative priorities. MUST NOT be used unless
configured otherwise.
12-14: Reserved for future use.
15 : Provider priorities. MAY only be used by the router
advertising the corresponding delegated prefix and based on
static or dynamic configuration (e.g., for excluding a prefix
based on DHCPv6-PD Prefix Exclude Option [RFC6603]).
Prefix Length: The number of significant bits in the Prefix field.
Prefix: The significant bits of the prefix padded with zeroes up to
the next byte boundary.
6.2.3. Making New Assignments
Whenever the Prefix Assignment Algorithm subroutine is run on a Whenever the prefix assignment algorithm subroutine (Section 4.1 of
Common Link and whenever a new prefix may be assigned (case 1 of the [I-D.ietf-homenet-prefix-assignment]) is run on a Common Link and
subroutine), the decision of whether the assignment of a new prefix whenever a new prefix may be assigned (case 1 of the subroutine: no
is desired MUST follow these rules: Best Assignment and no Current Assignment), the decision of whether
the assignment of a new prefix is desired MUST follow these rules in
order:
If the Delegated Prefix TLV contains a DHCPv4 or DHCPv6 Data TLV, If the Delegated Prefix TLV contains a DHCPv6 Data TLV, and the
and the meaning of one of the DHCP options is not understood by meaning of one of the DHCP options is not understood by the HNCP
the HNCP router, the creation of a new prefix is not desired. node, the creation of a new prefix is not desired. This rule
This rule applies to TLVs inside Delegated Prefix TLVs but not to applies to TLVs inside Delegated Prefix TLVs but not to those
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-null 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.
Otherwise, the creation of a new prefix is desired, if the If the Delegated Prefix does not include a Prefix Policy TLV
Delegated Prefix is either locally generated (does not have any indicating restrictive assignment (type 131) or if local policy
Prefix Domain TLVs) or intended for internet access (has a Prefix exists to identify it based on, e.g., other Prefix Policy TLV
Domain TLV of type 0). Local desirability policies MAY override values and allows assignment, the creation of a new prefix is
or provide additional desirability rules for delegated prefixes, desired.
e.g., by matching different Prefix Domain TLV values.
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.4 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, a router MUST support a mechanism suitable to distribute In any case, an HNCP router making an assignment MUST support a
addresses from the considered prefix if the link is intended to be mechanism suitable to distribute addresses from the considered prefix
used by clients. In this case a router assigning an IPv4 prefix MUST if the link is intended to be used by clients. In this case a router
support the L-capability and a router assigning an IPv6 prefix MUST assigning an IPv4 prefix MUST announce the L-capability and a router
support serving router advertisements. In addition if an assigned assigning an IPv6 prefix with a length greater than 64 MUST announce
IPv6 prefix is not suitable for Stateless Address Autoconfiguration the H-capability as defined in Section 4.
the router MUST also support the H-capability as defined in
Section 10.
6.2.4. 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 create an appropriate route for said prefix, indicating it is MUST forward traffic destined to said prefix to the respective
directly reachable on the respective link and advertise said route link.
using the chosen routing protocol.
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.3, 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.2.5. DHCPv6-PD Excluded Prefix Support 6.3.4. DHCPv6 Prefix Delegation
Whenever a DHCPv6 Prefix Exclude option [RFC6603] is received with a
delegated prefix, the excluded prefix MUST be advertised as assigned
to a Private Link with the maximum priority (i.e. 15).
The same procedure MAY be applied in order to exclude prefixes
obtained by other means of configuration.
6.2.6. Downstream Prefix Delegation Support
When an HNCP router receives a request for prefix delegation, it When an HNCP router announcing the P-Capability (Section 4) receives
SHOULD assign one prefix per delegated prefix in the network. This a DHCPv6-PD request from a client, it SHOULD assign one prefix per
set of assigned prefix is then delegated to the client, after it has delegated prefix in the network. This set of assigned prefixes is
been applied as described in the Prefix Assignment Algorithm. Each then delegated to the client, after it has been applied as described
client MUST be considered as an independent Private Link and in the prefix assignment algorithm. Each DHCPv6-PD client MUST be
delegation MUST be based on the same set of Delegated Prefixes as the considered as an independent Private Link and delegation MUST be
one used for Common Link prefix assignments. based on the same set of Delegated Prefixes as the one used for
Common Link prefix assignments, however the prefix length to be
delegated MAY be smaller than 64.
The assigned prefixes MUST NOT be given to clients before they are The assigned prefixes MUST NOT be given to DHCPv6-PD clients before
applied, and MUST be withdrawn whenever they are destroyed. As an they are applied, and MUST be withdrawn whenever they are destroyed.
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 which 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.3. 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 router MUST announce at least one Applied Assigned Prefix. Each HNCP node SHOULD announce an IPv6
IPv6 address and - if it supports IPv4 - at least one IPv4 address, address and - if it supports IPv4 - MUST announce an IPv4 address,
whenever matching prefixes are assigned to at least one if 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 Modified EUI64 interface identifiers Stateless assignment based on Semantically Opaque Interface
[RFC4291] SHOULD be used for address assignment whenever possible, Identifiers [RFC7217] SHOULD be used for address assignment whenever
otherwise (e.g., for IPv4) the following method MUST be used instead: possible (e.g., the prefix length is 64), otherwise (e.g., for IPv4
For any assigned prefix for which SLAAC cannot be used, the first if supported) the following method MUST be used instead: For any
quarter of the addresses are reserved for routers HNCP based address assigned prefix for which stateless assignment is not used, the first
assignments, whereas the last three quarters are left to the DHCPv6 quarter of the addresses are reserved for HNCP based address
(resp. DHCPv4) elected router (Section 10 specifies the DHCP server assignments, whereas the last three quarters are left to the DHCP
election process). For instance, if the prefix 192.0.2.0/24 is elected router (Section 4 specifies the DHCP server election
assigned and applied to a Common Link, addresses included in process). For example, if the prefix 192.0.2.0/24 is assigned and
192.0.2.0/26 are reserved for HNCP nodes and the remaining addresses applied to a Common Link, addresses included in 192.0.2.0/26 are
are reserved for the elected DHCPv4 server. reserved for HNCP nodes and the remaining addresses are reserved for
the elected DHCPv4 server.
HNCP routers assign themselves addresses using the Node Address TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: NODE-ADDRESS (36) | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Endpoint Identifier: The endpoint identifier of the local interface
that belongs to the Common Link the prefix is assigned to, or 0 if
it is not assigned on an HNCP enabled link.
IP Address: The globally scoped IPv6 address, or the IPv4 address HNCP nodes assign themselves addresses, and then (to ensure eventual
encoded as an IPv4-mapped IPv6 address [RFC4291]. lack of conflicting assignments) publish the assignments 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 router 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 router. advertised by another node.
o An assigned address MUST be in the first quarter of an assigned o An assigned address MUST be part of an assigned prefix currently
prefix currently applied on a Common Link which includes the applied on a Common Link which includes the interface specified by
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 highest node
identifier MUST be removed. identifier MUST be removed.
6.4. Local IPv4 and ULA Prefixes 6.5. Local IPv4 and ULA Prefixes
HNCP routers can create an ULA or private IPv4 prefix to enable HNCP routers can create a ULA or private IPv4 prefix to enable
connectivity between local devices. These prefixes are inserted in connectivity between local devices. These prefixes are inserted in
HNCP as if they were delegated prefixes. The following rules apply: HNCP as if they were delegated prefixes of a (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
Domain 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.
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 highest node identifier is kept among those with a Prefix
Domain of type 0 - if there is any. The router publishing a Policy of type 0 - if there is any. The router publishing a
prefix with internet connectivity MUST announce an IPv4 default prefix with internet connectivity MUST forward IPv4 traffic to the
route using the routing protocol and perform NAT on behalf of the internet and perform NAT on behalf of the network as long as it
network as long as it publishes the prefix, other routers in the publishes the prefix, other routers in the network MAY choose not
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 timespan between 0 and 10 seconds in which the router MUST scan for
other nodes 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].
6.5. Special Purpose Prefixes
Some prefixes may have a special meaning and are not regularly used
for internal or internet connectivity, instead they may provide
access to special services like VPNs, sensor networks, VoIP, IPTV,
etc. Care must be taken that these prefixes are properly integrated
and dealt with in the network, in order to avoid breaking
connectivity for devices who are not aware of their special
characteristics.
Special purpose prefixes are distinguished using Prefix Domain TLVs
(Section 6.1.3). Their contents MAY be partly opaque to HNCP nodes,
and their identification and usage depends on local policy. However
the following general rules MUST be adhered to:
Special rules apply when making address assignments for prefixes
with Prefix Domain TLVs other than type 0, as described in
Section 6.2.3
In presence of any type 1 to 128 Prefix Domain TLV the prefix is
specialized to reach destinations denoted by any such Prefix
Domain TLV, i.e. in abscence of a type 0 Prefix Domain TLV it is
not usable for general internet connectivity. An HNCP router MAY
enforce this restriction with appropriate packet filtering rules
to provide increased security.
The presence of a type 129 (DNS zone) Prefix Domain TLV indicates
that the delegated prefix or its associated external connection is
specialized to reach destinations within the given DNS zone. An
HNCP router providing name resolving services SHOULD prefer DNS
servers listed in the associated external connection's DHCPv4 or
DHCPv6 Data TLVs when resolving domains from that zone.
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 10 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. DHCPv6 for Addressing or Configuration 7.1. DHCPv6 for Addressing or Configuration
In general Stateless Address Autoconfiguration is used for client In general Stateless Address Autoconfiguration is used for client
configuration for its low overhead and fast renumbering capabilities, configuration for its low overhead and fast renumbering capabilities,
however stateful DHCPv6 can be used in addition by administrative however stateful DHCPv6 can be used in addition by administrative
choice, to e.g. collect hostnames and use them to provide naming choice, to, e.g., collect hostnames and use them to provide naming
services or whenever stateless configuration is not applicable. services or whenever stateless configuration is not applicable.
The designated stateful DHCPv6 server for a Common Link (Section 4) The designated stateful DHCPv6 server for a Common Link (Section 6.1)
is elected based on the capabilities described in Section 10. 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 and node greatest H-capability. In case of a tie, Capability Values are
identifiers are considered (greatest value is elected). The elected compared, and router with the greatest value is elected. In case of
router MUST serve stateful DHCPv6 and MUST provide naming services another tie, the router with the highest node identifier is elected
for acquired hostnames as outlined in Section 8. Stateful addresses among the routers with tied Capability Values.
SHOULD be assigned in a way not hindering fast renumbering even if
the DHCPv6 server or client do not support the DHCPv6 reconfigure
mechanism. In case no router was elected, stateful DHCPv6 is not
provided and each router assigning IPv6-prefixes on said link MUST
provide stateless DHCPv6 service.
7.2. Sending Router Advertisements
All HNCP routers MUST send Router Advertisements periodically via
multicast and via unicast in response to Router Solicitations.
o The "Managed address configuration" flag MUST be set whenever a
router connected to the link is advertising a non-null
H-capability and MUST NOT be set otherwise. The "Other
configuration" flag MUST always be set.
o The default Router Lifetime MUST be set to an appropriate non-null
value whenever an IPv6 default route is known in the HNCP network
and MUST be set to zero otherwise.
o A Prefix Information Option MUST be added for each assigned and
applied IPv6 prefix on the given link. The autonomous address-
configuration flag MUST be set whenever the prefix is suitable for
stateless configuration. The preferred and valid lifetimes MUST
be smaller than the preferred and valid lifetimes of the delegated
prefix the prefix is from. When a prefix is removed, it MUST be
deprecated as specified in [RFC7084].
o A Route Information Option [RFC4191] MUST be added for each
delegated IPv6 prefix known in the HNCP network. Additional ones
SHOULD be added for each non-default IPv6 route with an external
destination prefix advertised by the routing protocol.
o A Recursive DNS Server Option and a DNS Search List Option MUST be
included with appropriate contents.
o To allow for optimized routing decisions for clients on the local
link routers SHOULD adjust their Default Router Preference and
Route Preferences [RFC4191] so that the priority is set to low if
the next hop of the default or more specific route is on the same
interface as the Route Advertisement being sent on. Similarly the
router MAY use the high priority if it is certain it has the best
metric of all routers on the link for all routes known in the
network with the respective destination.
Every router sending Router Advertisements MUST immediately send an The elected router MUST serve stateful DHCPv6 and SHOULD provide
updated Router Advertisement via multicast as soon as it notices a naming services for acquired hostnames as outlined in Section 8.
condition resulting in a change of any advertised information. Stateful addresses SHOULD be assigned in a way not hindering fast
renumbering even if the DHCPv6 server or client do not support the
DHCPv6 reconfigure mechanism. In case no router was elected,
stateful DHCPv6 is not provided.
7.3. 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 10. 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 are greatest P-capability. In case of a tie, Capability Values are
compared, and router with the greatest value is elected. In case of compared, and router with the greatest value is elected. In case of
another tie, the router with the highest node identifier is elected another tie, the router with the highest node identifier is elected
among the routers with tied Capability Values. The elected router among the routers with tied Capability Values.
MUST provide prefix-delegation services [RFC3633] on the given link
and follow the rules in Section 6.2.6.
7.4. DHCPv4 for Addressing and Configuration The elected router MUST provide prefix-delegation services [RFC3633]
on the given link and follow the rules in Section 6.3.4.
The designated DHCPv4 server on a Common Link (Section 4) is elected 7.3. DHCPv4 for Addressing and Configuration
based on the capabilities described in Section 10. The winner is the
router (connected to the Common Link) advertising the greatest The designated DHCPv4 server on a Common Link (Section 6.1) is
elected based on the capabilities described in Section 4. The winner
is the router (connected to the Common Link) advertising the greatest
L-capability. In case of a tie, Capability Values are compared, and L-capability. In case of a tie, Capability Values are compared, and
router with the greatest value is elected. In case of another tie, router with the greatest value is elected. In case of another tie,
the router with the highest node identifier is elected among the the router with the highest node identifier is elected among the
routers with tied Capability Values. The elected router MUST provide routers with tied Capability Values.
DHCPv4 services on the given link.
The DHCPv4 serving router MUST announce itself as router [RFC2132] to The elected router MUST provide DHCPv4 services on the given link.
clients if and only if there is an IPv4 default route known in the It MUST announce itself as router [RFC2132] to clients if and only if
network. In addition, the router SHOULD announce a Classless Static there is an IPv4 default route known in the network. If there is no
Route Option [RFC3442] for each non-default IPv4 route advertised in default route, the elected router MUST announce a Classless Static
the routing protocol with an external destination. Route Option [RFC3442] for the IPv4 prefix announced in the Delegated
Prefix TLV and MAY announce such an option for known reachable IPv4
destinations not within any local delegated prefix.
DHCPv4 lease times SHOULD be short (i.e. not longer than 5 minutes) DHCPv4 lease times SHOULD be short (i.e., not longer than 5 minutes)
in order to provide reasonable response times to changes. in order to provide reasonable response times to changes.
7.5. Multicast DNS Proxy 7.4. Multicast DNS Proxy
The designated MDNS [RFC6762] proxy on a Common Link is elected based The designated MDNS [RFC6762] proxy on a Common Link is elected based
on the capabilities described in Section 10. The winner is the on the capabilities described in Section 4. The winner is the router
router (connected to the Common Link) advertising the greatest (connected to the Common Link) advertising the greatest M-capability.
M-capability. In case of a tie, Capability Values are compared, and In case of a tie, Capability Values are compared, and router with the
router with the greatest value is elected. In case of another tie, greatest value is elected. In case of another tie, the router with
the router with the highest node identifier is elected among the the highest node identifier is elected among the routers with tied
routers with tied Capability Values. The elected router MUST provide Capability Values.
an MDNS-proxy on the given link and announce it as described in
Section 8. The elected router MUST provide an MDNS-proxy on the given link and
announce it as described in Section 8.
8. Naming and Service Discovery 8. Naming and Service Discovery
Network-wide naming and service discovery can greatly improve the Network-wide naming and service discovery can greatly improve the
user-friendliness of 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 a recursive name resolution server
which honors the announcements made in 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 designated name servers
and hand out appropriate A, AAAA and PTR 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 4) 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. HNCP routers providing name resolving behalf of connected devices. This announcement is done using
services MUST use the included DNS server address to resolve names Delegated Zone TLVs (Section 10.5) and MUST be unique in the whole
belonging to the zone. network. In case of a conflict the announcement of the node with the
highest node identifier takes precedence and all other nodes MUST
cease to announce the conflicting TLV. HNCP routers providing name
resolving services MUST use the included DNS server address within
the TLV to resolve names belonging to the zone as if there was an NS
record.
Each HNCP router 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. HNCP routers reachable and MAY do so on behalf of other devices. Announcements
are made using Node Name TLVs (Section 10.7) and MUST be unique in
the whole network. In case of a conflict the announcement of the
node with the highest node identifier takes precedence and all other
nodes MUST cease to announce the conflicting TLV. HNCP routers
providing name resolving services MUST resolve these names to their providing name resolving services MUST resolve these names to their
respective IP addresses. respective IP addresses as if there were corresponding A/AAAA
records.
The following TLVs are defined and MUST be supported by all nodes Names and unqualified zones are used in an HNCP network to provide
implementing naming and service discovery: naming and service discovery with local significance. A network-wide
zone is appended to all single labels or unqualified zones in order
to qualify them. ".home" is the default, however an administrator MAY
configure announcing of a Domain Name TLV (Section 10.6) for the
network to use a different one. In case multiple are announced, the
domain of the node with the greatest node identifier takes
precedence.
8.1. DNS Delegated Zone TLV 9. Securing Third-Party Protocols
This TLV is used to announce a forward or reverse DNS zone delegation Pre-shared keys (PSKs) are often required to secure (for example)
in the HNCP network. Its meaning is roughly equivalent to specifying IGPs and other protocols which lack support for asymmetric security.
an NS and A/AAAA record for said zone. There MUST NOT be more than The following mechanism manages PSKs using HNCP to enable
one delegation for the same zone in the whole DNCP network. In case bootstrapping of such third-party protocols. The scheme SHOULD be
of a conflict the announcement of the node with the highest node used only in conjunction with secured HNCP unicast transport (=DTLS),
identifier takes precedence and all other nodes MUST cease to as transferring the PSK in plain-text anywhere in the network is a
announce the conflicting TLV. potential risk, especially as the originator may not know about
security (and use of DNCP security) on all links. The following
rules define how such a PSK is managed and used:
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
delay of 0 to 10 seconds with a 32 bytes long random key and add
it to its node data.
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
and adopt the remaining one.
o The node currently advertising the Managed PSK TLV must generate
and advertise a new random one whenever an unreachable node is
removed from the DNCP topology as described in the Section 4.6 of
[I-D.ietf-homenet-dncp].
PSKs for individual protocols SHOULD be derived from the random PSK
using a suitable one-way hashing algorithm (e.g., by using HMAC-
SHA256 [RFC6234] with a per-protocol HMAC-key) so that disclosure of
any derived key does not impact other users of the managed PSK.
Furthermore derived PSKs MUST be updated whenever the managed PSK
changes.
10. Type-Length-Value Objects
HNCP defines the following TLVs in addition to those defined by DNCP.
The same general rules and defaults for encoding as noted in
Section 7 of [I-D.ietf-homenet-dncp] apply.
TLVs defined here are only valid when appearing in their designated
context, i.e., only directly within container TLVs mentioned in their
definition, or - absent any mentions - only as top-level TLVs within
the node data set. TLVs appearing outside their designated context
MUST be ignored.
Unless specified otherwise, TLVs encoding IP addresses or prefixes
allow encoding both IPv6 and IPv4 addresses and prefixes. IPv6
information is encoded as is, whereas for IPv4 IPv4-mapped IPv6
addresses format [RFC4291] is used and prefix lengths are encoded as
original IPv4 prefix length increased by 96.
10.1. HNCP Version TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: HNCP-VERSION (32) | Length: >= 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | M | P | H | L |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-agent |
This TLV is used to indicate the supported version and router
capabilities of an HNCP node as described in Section 4.
Version: Indicates which version of HNCP is currently in use by this
particular node. It MUST be set to 1. Nodes with different
versions are considered incompatible.
Reserved: Bits are reserved for future use. They MUST be set to
zero when creating this TLV, and their value MUST be ignored when
processing the TLV.
M-capability: Priority value used for electing the on-link MDNS
[RFC6762] proxy. It MUST be set to some value between 1 and 7
included (4 is the default) if the router is capable of proxying
MDNS and 0 otherwise. The values 8-15 are reserved for future
use.
P-capability: Priority value used for electing the on-link DHCPv6-PD
server. It MUST be set to some value between 1 and 7 included (4
is the default) if the router is capable of providing prefixes
through DHCPv6-PD (Section 6.3.4) and 0 otherwise. The values
8-15 are reserved for future use.
H-capability: Priority value used for electing the on-link DHCPv6
server offering non-temporary addresses. It MUST be set to some
value between 1 and 7 included (4 is the default) if the router is
capable of providing such addresses and 0 otherwise. The values
8-15 are reserved for future use.
L-capability: Priority value used for electing the on-link DHCPv4
server. It MUST be set to some value between 1 and 7 included (4
is the default) if the router is capable of running a legacy
DHCPv4 server offering IPv4 addresses to clients and 0 otherwise.
The values 8-15 are reserved for future use.
User-Agent: The user-agent is a human-readable UTF-8 string that
describes the name and version of the current HNCP implementation.
10.2. External Connection TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: EXTERNAL-CONNECTION (33)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested TLVs |
An External Connection TLV is a container TLV used to gather network
configuration information associated with a single external
connection (Section 6.2) to be shared across the HNCP network. A
node MAY publish an arbitrary number of instances of this TLV to
share the desired number of external connections.
10.2.1. Delegated Prefix TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: DELEGATED-PREFIX (34) | Length: >= 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | |
+-+-+-+-+-+-+-+-+ Prefix [+ nested TLVs] +
| |
The Delegated Prefix TLV is used by HNCP routers to advertise
prefixes which are allocated to the whole network and can be used for
prefix assignment. Delegated Prefix TLVs are only valid inside
External Connection TLVs and their prefixes MUST NOT overlap with
those of other such TLVs in the same container.
Valid Lifetime Since Origination: The time in seconds the delegated
prefix was valid for at the origination time of the node data
containing this TLV. The value MUST be updated whenever the node
republishes its Node State TLV.
Preferred Lifetime Since Origination: The time in seconds the
delegated prefix was preferred for at the origination time of the
node data containing this TLV. The value MUST be updated whenever
the node republishes its Node State TLV.
Prefix Length: The number of significant bits in the Prefix.
Prefix: Significant bits of the prefix padded with zeroes up to the
next byte boundary.
Nested TLVs: Other TLVs included in the Delegated Prefix TLV
starting at the next 32-bit boundary following the end of the
encoded prefix.
10.2.1.1. Prefix Policy TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: PREFIX-POLICY (43) | Length: >= 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy Type | |
+-+-+-+-+-+-+-+-+ Value +
| |
The Prefix Policy TLV contains information about the policy or
applicability of a delegated prefix. This information can be used to
determine whether prefixes for a certain usecase (e.g., local
reachability, internet connectivity) do exist or should be acquired
and to make decisions about assigning prefixes to certain links or to
fine-tune border firewalls. See Section 6.2 for a more in-depth
discussion. This TLV is only valid inside a Delegated Prefix TLV.
Policy Type: The type of the policy identifier.
0 : Internet connectivity (no Value).
1-128 : Explicit destination prefix with the Policy Type being
the actual length of the prefix (Value contains significant
bits of the destination prefix padded with zeroes up to the
next byte boundary).
129 : DNS Zone (Value contains an RFC 1035 [RFC1035] encoded
DNS label sequence).
130 : Opaque UTF-8 string (e.g., for administrative purposes).
131 : Restrictive Assignment (no Value).
132-255: Reserved for future additions.
Value: A variable length identifier of the given type.
10.2.2. DHCPv6 Data TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: DHCPV6-DATA (37) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv6 option stream |
This TLV is used to encode auxiliary IPv6 configuration information
(e.g., recursive DNS servers) encoded as a stream of DHCPv6 options.
It is only valid in an External Connection TLV or a Delegated Prefix
TLV encoding an IPv6 prefix and MUST NOT occur more than once in any
single container. When included in an External Connection TLV, it
contains DHCPv6 options relevant to the External Connection as a
whole. When included in a Delegated Prefix, it contains options
mandatory to handle said prefix.
DHCPv6 option stream: DHCPv6 options encoded as specified in
[RFC3315].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv4 option stream |
This TLV is used to encode auxiliary IPv4 configuration information
(e.g., recursive DNS servers) encoded as a stream of DHCPv4 options.
It is only valid in an External Connection TLV and MUST NOT occur
more than once in any single container. It contains DHCPv4 options
relevant to the External Connection as a whole.
DHCPv4 option stream: DHCPv4 options encoded as specified in
[RFC2131].
10.3. Assigned Prefix TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: ASSIGNED-PREFIX (35) | Length: >= 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsv. | Prty. | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +
| |
This TLV is used to announce Published Assigned Prefixes for the
purposes of prefix assignment (Section 6.3).
Endpoint Identifier: The endpoint identifier of the local interface
the prefix is assigned to, or 0 if it is assigned to a Private
Link (e.g., when the prefix is assigned for downstream prefix
delegation).
Rsv.: Bits are reserved for future use. They MUST be set to zero
when creating this TLV, and their value MUST be ignored when
processing the TLV.
Prty: The Advertised Prefix Priority from 0 to 15.
0-1 : Low priorities.
2 : Default priority.
3-7 : High priorities.
8-11 : Administrative priorities. MUST NOT be used unless
configured otherwise.
12-14: Reserved for future use.
15 : Provider priorities. MAY only be used by the router
advertising the corresponding delegated prefix and based on
static or dynamic configuration (e.g., for excluding a prefix
based on DHCPv6-PD Prefix Exclude Option [RFC6603]).
Prefix Length: The number of significant bits in the Prefix field.
Prefix: The significant bits of the prefix padded with zeroes up to
the next byte boundary.
10.4. Node Address TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: NODE-ADDRESS (36) | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used to announce addresses assigned to an HNCP node as
described in Section 6.4.
Endpoint Identifier: The endpoint identifier of the local interface
the prefix is assigned to, or 0 if it is not assigned on an HNCP
enabled link.
IP Address: The globally scoped IPv6 address, or the IPv4 address
encoded as an IPv4-mapped IPv6 address [RFC4291].
10.5. DNS Delegated Zone TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: DNS-DELEGATED-ZONE (39) | Length: >= 17 | | 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) |
| | | |
This TLV is used to announce a forward or reverse DNS zone delegation
in the HNCP network. Its meaning is roughly equivalent to specifying
an NS and A/AAAA record for said zone. Details are specified in
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.
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 of the zone, encoded as the domain names
are encoded DNS messages as specified in [RFC1035]. The last are encoded DNS messages as specified in [RFC1035]. The last
label in the zone MUST be empty. label in the zone MUST be empty.
8.2. Domain Name TLV 10.6. Domain Name TLV
This TLV is used to indicate the base domain name for the network.
It is the zone used as a base for all non fully-qualified delegated
zones and node names. In case of conflicts the announced domain of
the node with the greatest node identifier takes precedence. By
default, i.e., if no node advertises such a TLV., ".home" is used.
This TLV MUST NOT be announced unless the domain name was explicitly
configured by an administrator.
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
specified in Section 8. This TLV MUST NOT be announced unless the
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 zone MUST end with an empty
label. label.
8.3. Node Name TLV 10.7. Node Name TLV
This TLV is used to assign the name of a node in the network to a
certain IP address. In case of conflicts the announcement of the
node with the greatest node identifier for a name takes precedence
and all other nodes MUST cease to announce the conflicting TLV.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: NODE-NAME (41) | Length: > 16 | | Type: NODE-NAME (41) | Length: > 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IP Address | | IP Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name (not null-terminated - variable length) | | Name (not null-terminated - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used to assign the name of a node in the network to a
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.
Name: The name of the node as a single DNS label (up to 63 Name: The name of the node as a single DNS label (up to 63
characters, no leading length byte). characters, no leading length byte).
9. Securing Third-Party Protocols 10.8. Managed PSK TLV
Pre-shared keys (PSKs) are often required to secure IGPs and other
protocols which lack support for asymmetric security. The following
mechanism manages PSKs using HNCP to enable bootstrapping of such
third-party protocols and SHOULD therefore be used if such a need
arises. The following rules define how such a PSK is managed and
used:
o If no Managed-PSK-TLV is currently being announced, an HNCP router
MUST create one after a random delay of 0 to 10 seconds with a 32
bytes long random key and add it to its node data.
o In case multiple routers announce such a TLV at the same time, all
but the one with the greatest node identifier stop advertising it
and adopt the remaining one.
o The router currently advertising the Managed-PSK-TLV must generate
and advertise a new random one whenever an unreachable node is
purged as described in DNCP.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Managed-PSK (42) | Length: 32 | | Type: MANAGED-PSK (42) | Length: 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| | | |
| Random PSK | | Random 256-bit PSK |
| | | |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PSKs for individual protocols are derived from the random PSK through This TLV is used to announce a PSK for securing third-party protocols
the use of HMAC-SHA256 [RFC6234] with a pre-defined per-protocol exclusively supporting symmetric cryptography as specified in
HMAC-key in ASCII-format. The following HMAC-keys are currently Section 9.
defined to derive PSKs for the respective protocols:
"ROUTING": to be used for IGPs
10. HNCP Versioning and Capabilities
Multiple versions of HNCP based on compatible DNCP profiles may be
present in the same network when transitioning between HNCP versions
and HNCP routers may have different capabilities to support clients.
The following mechanism describes a way to announce the currently
active version and User-agent of a node. Each node MUST include an
HNCP-Version-TLV in its Node Data and MUST ignore (except for DNCP
synchronization purposes) any TLVs with a type greater than 32
published by nodes not also publishing an HNCP-Version TLV or
publishing such a TLV with a different Version number.
Capabilities are indicated by setting M, P, H and L fields in the
TLV. The "capability value" is a metric indicated by interpreting
the bits as an integer, i.e. (M << 12 | P << 8 | H << 4 | L).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: HNCP-VERSION (32) | Length: >= 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | M | P | H | L |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-agent |
Version: Indicates which version of HNCP is currently in use by this
particular node. It MUST be set to 1. Nodes with different
versions are considered incompatible.
Reserved: Bits are reserved for future use. They MUST be set to
zero when creating this TLV, and their value MUST be ignored when
processing the TLV.
M-capability: Priority value used for electing the on-link MDNS
[RFC6762] proxy. It MUST be set to some value between 1 and 7
included (4 is the default) if the router is capable of proxying
MDNS and 0 otherwise. The values 8-15 are reserved for future
use.
P-capability: Priority value used for electing the on-link DHCPv6-PD
server. It MUST be set to some value between 1 and 7 included (4
is the default) if the router is capable of providing prefixes
through DHCPv6-PD (Section 6.2.6) and 0 otherwise. The values
8-15 are reserved for future use.
H-capability: Priority value used for electing the on-link DHCPv6
server offering non-temporary addresses. It MUST be set to some
value between 1 and 7 included (4 is the default) if the router is
capable of providing such addresses and 0 otherwise. The values
8-15 are reserved for future use.
L-capability: Priority value used for electing the on-link DHCPv4
server. It MUST be set to some value between 1 and 7 included (4
is the default) if the router is capable of running a legacy
DHCPv4 server offering IPv4 addresses to clients and 0 otherwise.
The values 8-15 are reserved for future use.
User-Agent: The user-agent is a human-readable UTF-8 string that
describes the name and version of the current HNCP implementation.
11. Requirements for HNCP Routers 11. General Requirements for HNCP Nodes
Each router implementing HNCP is subject to the following Each node implementing HNCP is subject to the following requirements:
requirements:
o It MUST implement HNCP-Versioning, Border Discovery, Prefix o It MUST implement HNCP-Versioning (Section 4) and Interface
Assignment and Configuration of hosts and non-HNCP routers as Classification (Section 5).
defined in this document.
o It MUST implement and run the method for securing third-party o It MUST implement and run the method for securing third-party
protocols whenever it uses the security mechanism of HNCP. protocols (Section 9) whenever it uses the security mechanism of
HNCP.
o It SHOULD implement support for the Service Discovery and Naming If the node is acting as a router, then the following requirements
TLVs as defined in this document. apply in addition:
o It MUST implement and run a routing protocol appropriate for the o It MUST support Autonomous Address Configuration (Section 6) and
given link type on all of the interfaces it sends and receives Configuration of Hosts and non-HNCP Routers (Section 7).
HNCP traffic on. The protocol MUST support source-specific routes
and MUST correctly propagate those also for the external
destinations that may have only implicit source-specific
information, such as a combination of a DHCPv6 PD-derived prefix
and a non-source-specific default route.
o It MUST use adequate security mechanisms for the routing protocol o It SHOULD implement support for the Service Discovery and Naming
on any interface where it also uses the security mechanisms of (Section 8) as defined in this document.
HNCP. If the security mechanism is based on a PSK it MUST use a
PSK derived from the Managed-PSK to secure the IGP.
o It 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. using DHCPv6-PD (Section 6.3.4).
o In addition, normative language of Basic Requirements for IPv6 o In addition, normative language of Basic Requirements for IPv6
Customer Edge Routers [RFC7084] applies with the following Customer Edge Routers [RFC7084] applies with the following
adjustments: adjustments:
* The section "WAN-Side Configuration" applies to HNCP interfaces * The generic requirements G-4 and G-5 are relaxed such that any
known default router on any interface is sufficient for a
router to announce itself as default router, similarly only the
loss of all such default routers results in self-invalidation.
* The section "WAN-Side Configuration" 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 CE sends a size-hint as indicated in WPD-2, the hint
MUST NOT be determined by the number of LAN-interfaces of the MUST NOT be determined by the number of LAN-interfaces of the
CE, but SHOULD instead be large enough to at least accommodate CE, but SHOULD instead be large enough to at least accommodate
prefix assignments announced for existing delegated or ULA- prefix assignments announced for existing delegated or ULA-
prefixes, if such prefixes exist and unless explicitly prefixes, if such prefixes exist and unless explicitly
configured otherwise. 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 HNCP interfaces * The section "LAN-Side Configuration" applies to interfaces not
classified as internal. 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.2) 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
if and only if a router connected to the respective Common Link
is advertising a non-zero H-capability.
* 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 a CER SHOULD publish the subset of options
using the DHCPv6 Data TLV in an External Connection TLV. using the DHCPv6 Data TLV in an External Connection TLV.
Similarly it SHOULD do the same for DHCPv4 options in a DHCPv4 Similarly it SHOULD do the same for DHCPv4 options in a DHCPv4
Data TLV. DHCPv6 options received inside an OPTION_IAPREFIX Data TLV. DHCPv6 options received inside an OPTION_IAPREFIX
[RFC3633] MUST be published using a DHCPv6 Data TLV inside the [RFC3633] MUST be published using a DHCPv6 Data TLV inside the
respective Delegated Prefix TLV. HNCP routers SHOULD make respective Delegated Prefix TLV. HNCP routers SHOULD make
relevant DHCPv6 and DHCPv4 options available to clients, i.e. relevant DHCPv6 and DHCPv4 options available to clients, i.e.,
options contained in External Connection TLVs that also include options contained in External Connection TLVs that also include
delegated prefixes from which a subset is assigned to the delegated prefixes from which a subset is assigned to the
respective link. respective link.
* The requirement L-13 to deprecate prefixes is applied to all
delegated prefixes in the network from which assignments have
been made on the respective interface. Furthermore the Prefix
Information Options indicating deprecation MUST be included in
Router Advertisements for the remainder of the prefixes'
respective valid lifetime, but MAY be omitted after at least 2
hours have passed.
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
skipping to change at page 27, line 41 skipping to change at page 32, line 37
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 routers. customized names for individual links and nodes.
12.1. Border Determination 12.1. Interface Classification
As described in Section 5, an HNCP router determines the internal or As described in Section 5.3, an HNCP node determines the internal or
external state on a per-link basis. A firewall perimeter is set up external state on a per-interface basis. A firewall perimeter is set
for the external links, and for internal links, HNCP and IGP traffic up for the external interfaces, and for internal interfaces, HNCP
is allowed. traffic is allowed, with the exception of leaf and guest sub-
categories.
Threats concerning automatic border discovery cannot be mitigated by Threats concerning automatic interface classification cannot be
encrypting or authenticating HNCP traffic itself since external mitigated by encrypting or authenticating HNCP traffic itself since
routers do not participate in the protocol and often cannot be external routers do not participate in the protocol and often cannot
authenticated by other means. These threats include propagation of be authenticated by other means. These threats include propagation
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 adequate 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.
skipping to change at page 28, line 34 skipping to change at page 33, line 32
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 eavesdropping, spoofing or denial of service attacks on HNCP services
such as address assignment or service discovery. such as address assignment or service discovery.
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 and IGP traffic or by using homenet by not exposing them to HNCP traffic or by using firewall
firewall rules to prevent them from reaching homenet-internal rules to prevent them from reaching homenet-internal resources.
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, DNCP secure mode MUST be used to
secure traffic. 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 is requested to maintain a registry for HNCP TLV-Types. This IANA should set up a registry for the (decimal values within range
registry inherits TLV-Types and allocation policy defined in DNCP 0-1023) "HNCP DNCP-profile TLV Types" under "Distributed Node
[I-D.ietf-homenet-dncp], but is independent with regard to all TLV- Consensus Protocol (DNCP)", with the following initial contents: [TO
Types not specified or reserved by DNCP. Particularly, other DNCP BE REMOVED BY RFC-EDITOR: Ideally as http://www.iana.org/assignments/
profile may have there own registries, using same TLV numbers. hncp-registry]
The following TLV-Types are defined in this document: 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 29, line 39 skipping to change at page 34, line 37
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
44-512: Free - policy of 'standards action' should be used.
512-767: Reserved - specified in the DNCP registry
768-1023: Reserved - to be used for per-implementation
experimentation. How collision is avoided is out of scope of this
document.
HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP- HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP-
DTLS-PORT, as well as an IPv6 link-local multicast address All- DTLS-PORT, as well as an IPv6 link-local multicast address All-
Homenet-Routers. Homenet-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-07 (work in progress), Protocol", draft-ietf-homenet-dncp-09 (work in progress),
July 2015. August 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012. Delegation", RFC 6603, May 2012.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[I-D.ietf-homenet-prefix-assignment] [I-D.ietf-homenet-prefix-assignment]
Pfister, P., Paterson, B., and J. Arkko, "Distributed Pfister, P., Paterson, B., and J. Arkko, "Distributed
Prefix Assignment Algorithm", draft-ietf-homenet-prefix- Prefix Assignment Algorithm", draft-ietf-homenet-prefix-
assignment-07 (work in progress), June 2015. assignment-07 (work in progress), June 2015.
14.2. Informative references 14.2. Informative references
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013.
[RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
A., Beser, B., and J. Privat, "The User Class Option for A., Beser, B., and J. Privat, "The User Class Option for
DHCP", RFC 3004, November 2000. DHCP", RFC 3004, November 2000.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. 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, March 1997.
skipping to change at page 31, line 38 skipping to change at page 36, line 41
[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, March 1997.
[RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless
Static Route Option for Dynamic Host Configuration Static Route Option for Dynamic Host Configuration
Protocol (DHCP) version 4", RFC 3442, December 2002. Protocol (DHCP) version 4", RFC 3442, December 2002.
[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, October 2005.
[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
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, April 2014.
14.3. URIs 14.3. URIs
[3] http://www.openwrt.org [3] http://www.openwrt.org
[4] http://www.homewrt.org/doku.php?id=run-conf [4] http://www.homewrt.org/doku.php?id=run-conf
Appendix A. Changelog [RFC Editor: please remove] Appendix A. Changelog [RFC Editor: please remove]
draft-ietf-homenet-hncp-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,
hopefully without functional delta. hopefully without functional delta.
draft-ietf-homenet-hncp-05: Renamed "Adjacent Link" to "Common Link". draft-ietf-homenet-hncp-05: Renamed "Adjacent Link" to "Common Link".
Changed single IPv4 uplink election from MUST to MAY. Added explicit Changed single IPv4 uplink election from MUST to MAY. Added explicit
indication to distinguish (IPv4)-PDs for local connectivity and ones indication to distinguish (IPv4)-PDs for local connectivity and ones
with uplink connectivity allowing e.g. better local-only with uplink connectivity allowing, e.g., better local-only
IPv4-connectivity. IPv4-connectivity.
draft-ietf-homenet-hncp-04: Change the responsibility for sending RAs draft-ietf-homenet-hncp-04: Change the responsibility for sending RAs
to the router assigning the prefix. to the router assigning the prefix.
draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP
(homenet profile). (homenet profile).
draft-ietf-homenet-hncp-02: Removed any built-in security. Relying draft-ietf-homenet-hncp-02: Removed any built-in security. Relying
on IPsec. Reorganized interface categories, added requirements on IPsec. Reorganized interface categories, added requirements
skipping to change at page 32, line 48 skipping to change at page 38, line 19
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 [3] package repositories. See [4] for more
information. Feedback and contributions are welcome. information. Feedback and contributions are welcome.
Appendix D. Acknowledgements Appendix D. Acknowledgements
Thanks to Ole Troan, Mark Baugher, Mark Townsley and Juliusz Thanks to Ole Troan, Mark Baugher, Mark Townsley, Juliusz Chroboczek
Chroboczek 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
Helsinki 00930 Helsinki 00930
Finland Finland
Email: markus.stenberg@iki.fi Email: markus.stenberg@iki.fi
Steven Barth Steven Barth
Independent
Halle 06114 Halle 06114
Germany Germany
Email: cyrus@openwrt.org Email: cyrus@openwrt.org
Pierre Pfister Pierre Pfister
Cisco Systems Cisco Systems
Paris Paris
France France
 End of changes. 199 change blocks. 
805 lines changed or deleted 1040 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/