draft-ietf-homenet-hncp-02.txt   draft-ietf-homenet-hncp-03.txt 
Homenet Working Group M. Stenberg Homenet Working Group M. Stenberg
Internet-Draft Internet-Draft
Intended status: Standards Track S. Barth Intended status: Standards Track S. Barth
Expires: April 30, 2015 Expires: July 10, 2015
October 27, 2014 P. Pfister
Cisco Systems
January 6, 2015
Home Networking Control Protocol Home Networking Control Protocol
draft-ietf-homenet-hncp-02 draft-ietf-homenet-hncp-03
Abstract Abstract
This document describes the Home Networking Control Protocol (HNCP), This document describes the Home Networking Control Protocol (HNCP),
a minimalist state synchronization protocol for homenet routers. an extensible configuration protocol and a set of requirements for
home network devices on top of the Distributed Node Consensus
Protocol (DNCP). It enables automated configuration of addresses,
naming, network borders and the seamless use of a routing protocol.
Status of This Memo 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 April 30, 2015. This Internet-Draft will expire on July 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3
3. Data model . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Adjacent Links . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Trickle-Driven Status Updates . . . . . . . . . . . . . . 4 5. Border Discovery . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 4 6. Autonomic Address Configuration . . . . . . . . . . . . . . . 6
4.2.1. Network State Update (NetState) . . . . . . . . . . . 5 6.1. External Connections . . . . . . . . . . . . . . . . . . 7
4.2.2. Network State Request, (NetState-Req) . . . . . . . . 5 6.1.1. External Connection TLV . . . . . . . . . . . . . . . 7
4.2.3. Node Data Request (Node-Req) . . . . . . . . . . . . 5 6.1.2. Delegated Prefix TLV . . . . . . . . . . . . . . . . 7
4.2.4. Network and Node State Reply (NetNode-Reply) . . . . 6 6.1.3. DHCP Data TLVs . . . . . . . . . . . . . . . . . . . 8
4.3. HNCP Protocol Message Processing . . . . . . . . . . . . 6 6.2. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 9
4.4. Adding and Removing Neighbors . . . . . . . . . . . . . . 7 6.2.1. Assigned Prefix TLV . . . . . . . . . . . . . . . . . 9
4.5. Purging Unreachable Nodes . . . . . . . . . . . . . . . . 8 6.2.2. Prefix Assignment Algorithm Parameters . . . . . . . 10
5. Type-Length-Value objects . . . . . . . . . . . . . . . . . . 8 6.2.3. Making New Assignments . . . . . . . . . . . . . . . 12
5.1. Request TLVs (for use within unicast requests) . . . . . 8 6.2.4. Applying Assignments . . . . . . . . . . . . . . . . 12
5.1.1. Request Network State TLV . . . . . . . . . . . . . . 9 6.2.5. DHCPv6-PD Excluded Prefix Support . . . . . . . . . . 13
5.1.2. Request Node Data TLV . . . . . . . . . . . . . . . . 9 6.2.6. Downstream Prefix Delegation Support . . . . . . . . 13
5.2. Data TLVs (for use in both multi- and unicast data) . . . 9 6.3. Node Address Assignment . . . . . . . . . . . . . . . . . 13
5.2.1. Node Link TLV . . . . . . . . . . . . . . . . . . . . 9 6.4. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 14
5.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 9 7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 15
5.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 10 7.1. DHCPv6 for Addressing or Configuration . . . . . . . . . 15
5.2.4. Node Data TLV . . . . . . . . . . . . . . . . . . . . 11 7.2. Sending Router Advertisements . . . . . . . . . . . . . . 16
5.2.5. Neighbor TLV (within Node Data TLV) . . . . . . . . . 11 7.3. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 17
5.3. Custom TLV (within/without Node Data TLV) . . . . . . . . 11 7.4. DHCPv4 for Adressing and Configuration . . . . . . . . . 17
5.4. Version TLV (within Node Data TLV) . . . . . . . . . . . 12 7.5. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 17
6. Border Discovery and Prefix Assignment . . . . . . . . . . . 12 8. Naming and Service Discovery . . . . . . . . . . . . . . . . 18
7. DNS-based Service Discovery . . . . . . . . . . . . . . . . . 17 8.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 18
7.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 17 8.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 19
7.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 18 8.3. Node Name TLV . . . . . . . . . . . . . . . . . . . . . . 20
7.3. Router Name TLV . . . . . . . . . . . . . . . . . . . . . 18 9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 20
8. Routing support . . . . . . . . . . . . . . . . . . . . . . . 18 10. HNCP Versioning and Capabilities . . . . . . . . . . . . . . 21
8.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 18 11. Requirements for HNCP Routers . . . . . . . . . . . . . . . . 22
8.2. Announcement . . . . . . . . . . . . . . . . . . . . . . 18 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8.3. Protocol Selection . . . . . . . . . . . . . . . . . . . 19 12.1. Border Determination . . . . . . . . . . . . . . . . . . 24
8.4. Fallback Mechanism . . . . . . . . . . . . . . . . . . . 20 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative references . . . . . . . . . . . . . . . . . . 22 14.1. Normative references . . . . . . . . . . . . . . . . . . 26
11.2. Informative references . . . . . . . . . . . . . . . . . 23 14.2. Informative references . . . . . . . . . . . . . . . . . 26
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 28
Appendix A. Some Outstanding Issues . . . . . . . . . . . . . . 24 Appendix B. Draft source . . . . . . . . . . . . . . . . . . . . 28
Appendix B. Some Obvious Questions and Answers . . . . . . . . . 24 Appendix C. Implementation . . . . . . . . . . . . . . . . . . . 28
Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 25 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 28
Appendix D. Draft source . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
HNCP is designed to synchronize state across a homenet (or other HNCP synchronizes state across a small site in order to allow
small site) in order to facilitate automated configuration within the automated network configuration. The protocol enables use of border
site. The design supports border discovery, IP prefix distribution discovery, address prefix distribution
[I-D.ietf-homenet-prefix-assignment], and service discovery across [I-D.ietf-homenet-prefix-assignment], naming and other services
multiple links[I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf]. across multiple links.
HNCP is designed to provide enough information for a routing protocol
to operate without homenet-specific extensions. In homenet
environments where multiple IPv6 prefixes are present, routing based
on source and destination address is necessary
[I-D.troan-homenet-sadr]. Routing protocol requirements for source
and destination routing are described in section 3 of
[I-D.baker-rtgwg-src-dst-routing-use-cases].
A GPLv2-licensed implementation of the HNCP protocol is currently HNCP provides enough information for a routing protocol to operate
under development at https://github.com/sbyx/hnetd/ and the binaries without homenet-specific extensions. In homenet environments where
are available in the routing feed of OpenWrt [2] trunk release. Some multiple IPv6 source-prefixes can be present, routing based on source
information how to get started with it is available at [3]. Comments and destination address is necessary [RFC7368].
and/or pull requests are welcome.
2. Requirements language 2. Requirements language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Data model 3. DNCP Profile
The data model of the HNCP protocol is simple: Every participating
node has (and also knows for every other participating node):
A unique node identifier. It may be a public key, unique hardware
ID, or some other unique blob of binary data which HNCP can run a
hash upon to obtain a node identifier that is very likely unique
among the set of routers in the homenet.
A set of Type-Length-Value (TLV) data it wants to share with other
routers. The set of TLVs have a well-defined order based on
ascending binary content that is used to quickly identify changes
in the set as they occur.
Latest update sequence number. A 32 bit number that is
incremented anytime TLV data changes are detected.
Relative time, in milliseconds, since last publishing of the
current TLV data set. It is also 32 bit number on the wire.
4. Operation
HNCP is designed to run on UDP port IANA-UDP-PORT, using both link-
local scoped IPv6 unicast and link-local scoped IPv6 multicast
messages to address IANA-MULTICAST-ADDRESS for transport. The
protocol consists of Trickle [RFC6206] driven multicast status
messages to indicate changes in shared TLV data, and unicast state
synchronization message exchanges when the Trickle state is found to
be inconsistent.
4.1. Trickle-Driven Status Updates
Each node MUST send link-local multicast NetState Messages HNCP is defined as a profile of DNCP [I-D.ietf-homenet-dncp] with the
(Section 4.2.1) each time the Trickle algorithm [RFC6206] indicates following parameters:
they should on each link the protocol is active on. When the locally
stored network state hash changes (either by a local node event that
affects the TLV data, or upon receipt of more recent data from
another node), all Trickle instances MUST be reset. Trickle state
MUST be maintained separately for each link.
Trickle algorithm has 3 parameters; Imin, Imax and k. Imin and Imax o HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport over
represent minimum and maximum values for I, which is the time link-local scoped IPv6, using unicast and multicast (group All-
interval during which at least k Trickle updates must be seen on a Homenet-Routers). Received datagrams with an IPv6 source or
link to prevent local state transmission. Bounds for recommended destination address which is not link-local scoped MUST be
Trickle values are described below. ignored.
k=1 SHOULD be used, as given the timer reset on data updates, o HNCP operates on multicast-capable interfaces only, thus every
retransmissions should handle packet loss. DNCP Connection Identifier MUST refer to one, except for the value
0 which is reserved for internal purposes and MUST NOT be used for
connection enumeration. Implementations MAY use a value
equivalent to the sin6_scope_id for the given interface.
Imax MUST be at least one minute. o HNCP unicast messages SHOULD be secured using DTLS [RFC6347] as
described in DNCP if exchanged over unsecured links. UDP on port
HNCP-DTLS-PORT is used for this purpose. A node implementing the
security mechanism MUST support the DNCP Pre-Shared Key method,
SHOULD support the DNCP Certificate Based Trust Consensus and MAY
support the PKI-based trust method.
Imin MUST be at least 200 milliseconds (earliest transmissions may o HNCP uses opaque 32-bit node identifiers
occur at Imin/2 = 100 milliseconds given minimum values as per the (DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP
Trickle algorithm). SHOULD generate and use a random node identifier. If it receives
a Node State TLV with the same node identifier and a higher update
sequence number, it MUST immediately generate and use a new random
node identifier which is not used by any other node.
4.2. Protocol Messages o HNCP nodes MUST treat all Long Network State Update messages
received via multicast on a link which has DNCP security enabled
as if they were Short Network State Update messages, i.e. they
MUST ignore all contained Node State TLVs.
Protocol messages are encoded as purely as a sequence of TLV objects o HNCP nodes use the following Trickle parameters:
(Section 5). This section describes which set of TLVs MUST or MAY be
present in a given message.
In order to facilitate fast comparing of local state with that in a * k SHOULD be 1, given the timer reset on data updates and
received message update, all TLVs in every encoding scope (either retransmissions should handle packet loss.
root level, within the message itself, or within a container TLV)
MUST be placed in ascending order based on the binary comparison of
both TLV header and value. By design, the TLVs which MUST be present
have the lowest available type values, ensuring they will naturally
occur at the start of the Protocol Message, resembling a fixed format
preamble.
4.2.1. Network State Update (NetState) * Imin SHOULD be 200 milliseconds but MUST NOT be lower. Note:
Earliest transmissions may occur at Imin / 2.
This Message SHOULD be sent as a multicast message. * Imax SHOULD be 7 doublings of Imin (i.e. 25.6 seconds) but MUST
NOT be lower.
The following TLVs MUST be present at the start of the message: o HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP
non-cryptographic hash function H(x).
Node Link TLV (Section 5.2.1). o HNCP nodes MUST use the keep-alive extension on all connections.
The default keep-alive interval (DNCP_KEEPALIVE_INTERVAL) is 20
seconds, the multiplier (DNCP_KEEPALIVE_MULTIPLIER) MUST be 2.1,
the grace-interval (DNCP_GRACE_INTERVAL) SHOULD be equal to
DNCP_KEEPALIVE_MULTIPLIER times DNCP_KEEPALIVE_INTERVAL.
Network State TLV (Section 5.2.2). 4. Adjacent Links
The NetState Message MAY contain Node State TLV(s) (Section 5.2.3). HNCP uses the concept of Adjacent Links for some of its applications.
If so, either all Node State TLVs are included (referred to as a This term is defined as follows:
"long" NetState Message), or none are included (referred to as a
"short" NetState Message). The NetState Message MUST NOT contain
only a portion of Node State TLVs as this could cause problems with
the Protocol Message Processing (Section 4.3) algorithm. Finally, if
the long version of the NetState message would exceed the minimum
IPv6 MTU when sent, the short version of the NetState message MUST be
used instead.
4.2.2. Network State Request, (NetState-Req) If the connection of a node is detected or configured to be an ad-hoc
interface the Adjacent Link only consists of said interface.
This Message MUST be sent as a unicast message. Otherwise the Adjacent Link contains all interfaces bidirectionally
reachable from a given local interface. An interface X of a node A
and an interface Y of a node B are bidirectionally reachable if and
only if node A publishes a Neighbor TLV with the Neighbor Node
Identifier B, the Neighbor Connection Identifier Y and the Local
Connection Identifier X and node B publishes a Neighbor TLV with the
Neighbor Node Identifier A, a Neighbor Connection Identifier X and
the Local Connection Identifier Y. In addition a node MUST be able
to detect whether two of its local interfaces belong to the same
Adjacent Link either by local means or by inferring that from the
bidirectional reachability between two different local interfaces and
the same remote interface.
The following TLVs MUST be present at the start of the message: 5. Border Discovery
Node Link TLV (Section 5.2.1). HNCP associates each HNCP interface with a category (e.g., internal
or external). This section defines the border discovery algorithm
derived from the edge router interactions described in the Basic
Requirements for IPv6 Customer Edge Routers [RFC7084]. This
algorithm is suitable for both IPv4 and IPv6 (single or dual-stack)
and determines whether an HNCP interface is internal, external, or
uses another fixed category. This algorithm MUST be implemented by
any router implementing HNCP.
Request Network State TLV (Section 5.1.1). In order to avoid conflicts between border discovery and homenet
routers running DHCPv4 [RFC2131] or DHCPv6-PD [RFC3633] servers, each
router MUST implement the following mechanism based on The User Class
Option for DHCPv4 [RFC3004] and its DHCPv6 counterpart [RFC3315]:
4.2.3. Node Data Request (Node-Req) o An HNCP router running a DHCP client on a homenet interface MUST
include a DHCP User-Class consisting of the ASCII-String
"HOMENET".
This Message MUST be sent as a unicast message. o An HNCP router running a DHCP server on a homenet interface MUST
ignore or reject DHCP-Requests containing a DHCP User-Class
consisting of the ASCII-String "HOMENET".
MUST be present: The border discovery auto-detection algorithm works as follows, with
evaluation stopping at first match:
Node Link TLV (Section 5.2.1). 1. If a fixed category is configured for the interface, it MUST be
used.
one or more Request Node Data TLVs (Section 5.1.2). 2. If a delegated prefix could be acquired by running a DHCPv6
client on the interface, it MUST be considered external.
4.2.4. Network and Node State Reply (NetNode-Reply) 3. If an IPv4 address could be acquired by running a DHCPv4 client
on the interface it MUST be considered external.
This Message MUST be sent as a unicast message. 4. Otherwise the interface MUST be considered internal.
MUST be present: A router MUST allow setting a category of either auto-detected,
internal or external for each interface which is suitable for both
internal and external connections. In addition the following
specializations of the internal category are defined to modify the
local router behavior:
Node Link TLV (Section 5.2.1). Leaf category: This declares an interface used by client devices
only. A router MUST consider such interface as internal but MUST
NOT send nor receive HNCP messages on such interface. A router
SHOULD implement this category.
Network State TLV (Section 5.2.2) and Node State TLV Guest category: This declares an interface used by untrusted client
(Section 5.2.3) for every known node by the sender, or devices only. In addition to the restrictions of the Leaf
category, connected devices MUST NOT be able to reach other
devices inside the HNCP network nor query services advertised by
them unless explicitly allowed, instead they SHOULD only be able
to reach the internet. This category SHOULD be supported.
one or more combinations of Node State and Node Data TLVs Ad-hoc category: This configures an interface to be ad-hoc
(Section 5.2.4). (Section 4) and MAY be implemented.
4.3. HNCP Protocol Message Processing Hybrid category: This declares an interface to be internal while
still using external connections on it. It is assumed that the
link is under control of a legacy, trustworthy non-HNCP router,
still within the same network. Detection of this category
automatically in addition to manual configuration is out of scope
for this document. This category MAY be implemented.
The majority of status updates among known nodes are handled via the Each router MUST continuously scan each active interface that does
Trickle-driven updates (Section 4.1). This section describes not have a fixed category in order to dynamically reclassify it if
processing of messages as received, along with associated actions or necessary. The router therefore runs an appropriately configured
responses. 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.
HNCP is designed to operate between directly connected neighbors on a 6. Autonomic Address Configuration
shared link using link-local IPv6 addresses. If the source address
of a received HNCP packet is not an IPv6 link-local unicast address,
the packet SHOULD be dropped. Similarly, if the destination address
is not IPv6 link-local unicast or IPv6 link-local multicast address,
packet SHOULD be dropped.
Upon receipt of: This section specifies how HNCP routers configure host and router
addresses. At first border routers share information obtained from
service providers or local configuration by publishing one or more
External Connection TLVs. These contain other TLVs such as Delegated
Prefix TLVs which are then used for prefix assignment. Finally, HNCP
routers obtain addresses using a stateless (SLAAC-like) procedure or
a specific stateful mechanism and hosts and legacy routers are
configured using SLAAC or DHCP.
NetState Message (Section 4.2.1): If the network state hash within In all TLVs specified in this section which include a prefix, IPv4
the message matches the hash of the locally stored network state, prefixes are encoded using the IPv4-mapped IPv6 addresses format
consider Trickle state as consistent with no further processing [RFC4291]. The prefix length of such prefix is set to 96 plus the
required. If the hashes do not match, consider Trickle state as IPv4 prefix length.
inconsistent. In this case, if the message is "short" (contains
zero Node State TLVs), reply with a NetState-Req Message
(Section 4.2.2). If the message was in long format (contained all
Node State TLVs), reply with NodeState-Req (Section 4.2.3) for any
nodes for which local information is outdated (local update number
is lower than that within the message), potentially incorrect
(local update number is same and the hash of node data TLV
differs) or missing. Note that if local information is more
recent than that of the neighbor, there is no need to send a
message.
NetState-Req (Section 4.2.2): Provide requested data in a NetNode- 6.1. External Connections
Reply Message containing Network State TLV and all Node State
TLVs.
NodeState-Req (Section 4.2.3): Provide requested data in a Each HNCP router MAY obtain external connection information from one
NetNode-Reply containing Node State and Node Data TLVs. or more sources, e.g. DHCPv6-PD [RFC3633], NETCONF [RFC6241] or
static configuration. This section specifies how such information is
encoded and advertised.
State-Reply (Section 4.2.4): If the message contains Node State 6.1.1. External Connection TLV
TLVs that are more recent than local state (higher update number,
different node data TLV hash, or we lack the node data
altogether), and if the message also contains corresponding Node
Data TLVs, update local state and reset Trickle. If the message
is lacking Node Data TLVs for some Node State TLVs which are more
recent than local state, reply with a NodeState-Req
(Section 4.2.3) for the corresponding nodes.
Each node is responsible for publishing a valid set of data TLVs. An External Connection TLV is a container-TLV used to gather network
When there is a change in a node's set of data TLVs, the update configuration information associated with a single external
number MUST be incremented accordingly. connection. A node MAY publish zero, one or more instances of this
TLV.
If a message containing Node State TLVs (Section 5.2.3) is received 0 1 2 3
via unicast or multicast with the node's own node identifier and a 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
higher update number than current local value, or the same update +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
number and different hash, there is an error somewhere. A | Type: EXTERNAL-CONNECTION (33)| Length: > 0 |
recommended default way to handle this is to attempt to assert local +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
state by increasing the local update number to a value higher than | Nested TLVs |
that received and republish node data using the same node identifier.
If this happens more than 3 times in 60 seconds and the local node
identifier is not globally unique, there may be more than one router
with the same node identifier on the network. If there is no global
guarantee of unique node identifier, a new node identifier SHOULD be
generated and node data republished accordingly.
In all cases, if node data for any node changes, all Trickle The External Connection TLV is a container which:
instances MUST be considered inconsistent (I=Imin + timer reset).
4.4. Adding and Removing Neighbors o MAY contain zero, one or more Delegated Prefix TLVs.
Whenever multicast message or unicast reply is received on a link o MUST NOT contain multiple Delegated Prefix TLVs with the same
from another node, the node should be added as Neighbor TLV prefix. In such a situation, the container MUST be ignored.
(Section 5.2.5) for current node. If nothing (for example - no
router advertisements, no HNCP traffic) is received from that
neighbor in Imax seconds and the neighbor is not in neighbor
discovery cache, and no layer 2 indication of presence is available,
at least 3 attempts to ping it with request network state message
(Section 4.2.2) SHOULD be sent with increasing timeouts (e.g. 1, 2, 4
seconds). If even after suitable period after the last message
nothing is received, the Neighbor TLV MUST be removed so that there
are no dangling neighbors. As an alternative, if there is a layer 2
unreachability notification of some sort available for either whole
link or for individual neighbor, it MAY be used to immediately
trigger removal of corresponding Neighbor TLV(s).
4.5. Purging Unreachable Nodes o MAY contain at most one DHCPv6 Data TLV and at most one DHCPv4
Data TLV encoding options associated with the External Connection
but MUST NOT contain more than one of each otherwise the whole
External Connection TLV MUST be ignored.
When node data has changed, the neighbor graph SHOULD be traversed o MAY contain other TLVs for future use.
for each node following the bidirectional neighbor relationships.
These are identified by looking for neighbor TLVs on both nodes, that
have the remote node's identifier hash as h(neighbor node
identifier), and local and neighbor link identifiers swapped. After
the traverse, unreachable nodes SHOULD be purged after some grace
period. During the grace period, the unreachable nodes MUST NOT be
used for calculation of network state hash, or even be provided to
any applications that need to use the whole TLV graph.
5. Type-Length-Value objects 6.1.2. Delegated Prefix TLV
Every TLV is encoded as 2 octet type, followed by 2 octet length (of The Delegated Prefix TLV is used by HNCP routers to advertise
the whole TLV, including header; 4 means no value), and then the prefixes which are allocated to the whole network and will be used
value itself (if any). The actual length of TLV MUST be always for prefix assignment. All Delegated Prefix TLVs MUST be nested in
divisible by 4; if the length of the value is not, zeroed padding an External Connection TLV.
bytes MUST be inserted at the end of TLV. The padding bytes MUST NOT
be included in the length field.
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 | Length | | Type: DELEGATED-PREFIX (34) | Length: >= 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Valid Lifetime |
| (variable # of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | |
+-+-+-+-+-+-+-+-+ Prefix [+ nested TLVs] +
| |
Encoding of type=123 (0x7b) TLV with value 'x' (120 = 0x78): 007B Valid Lifetime: The time in seconds the delegated prefix is valid.
0005 7800 0000 The value is relative to the point in time the Node-Data TLV was
last published. It MUST be updated whenever the node republishes
Notation: its Node-Data TLV.
.. = octet string concatenation operation Preferred Lifetime: The time in seconds the delegated prefix is
preferred. The value is relative to the point in time the Node-
Data TLV was last published. It MUST be updated whenever the node
republishes its Node-Data TLV.
H(x) = MD5 hash of x Prefix Length: The number of significant bits in the Prefix.
H-64(x) = H(x) truncated by taking just first 64 bits of the Prefix: Significant bits of the prefix padded with zeroes up to the
result. next byte boundary.
5.1. Request TLVs (for use within unicast requests) Nested TLVs: Other TLVs included in the Delegated Prefix TLV and
5.1.1. Request Network State TLV starting at the next 32 bits boundary following the end of the
encoded prefix.
0 1 2 3 If the encoded prefix represents an IPv6 prefix, at most one
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 DHCPv6 Data TLV MAY be included.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: REQ-NETWORK-STATE (2) | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.2. Request Node Data TLV If the encoded prefix represents an IPv4-mapped IPv6 address,
at most one DHCPv4 Data TLV MAY be included.
0 1 2 3 It MAY contain other TLVs for future use.
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: REQ-NODE-DATA (3) | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. Data TLVs (for use in both multi- and unicast data) 6.1.3. DHCP Data TLVs
5.2.1. Node Link TLV Auxiliary connectivity information is encoded as a stream of DHCP
options. Such TLVs MUST only be present in an External Connection
TLV or a Delegated Prefix TLV. When included in an External
Connection TLV, they MUST contain DHCP options which are relevant to
the whole External Connection. When included in a Delegated Prefix,
they MUST contain DHCP options which are specific to the Delegated
Prefix.
0 1 2 3 The DHCPv6 Data TLV uses the following format:
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-LINK (1) | Length: 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.2. Network State 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: NETWORK-STATE (4) | Length: 20 | | Type: DHCPV6-DATA (37) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(H(node data TLV 1) .. H(node data TLV N)) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv6 option stream |
The Node Data TLVs are ordered for hashing by octet comparison of the DHCPv6 option stream: DHCPv6 options encoded as specified in
corresponding node identifier hashes in ascending order. [RFC3315].
5.2.3. Node State TLV The DHCPv4 Data TLV uses the following format:
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-STATE (5) | Length: 44 | | Type: DHCPV4-DATA (38) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Milliseconds since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node data TLV) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv4 option stream |
The whole network should have roughly the same idea about the time DHCPv4 option stream: DHCPv4 options encoded as specified in
since origination, i.e. even the originating router should increment [RFC2131].
the time whenever it needs to send a new Node State TLV regarding
itself without changing the corresponding Node Data TLV. This age
value is not included within the Node Data TLV, however, as that is
immutable and potentially signed by the originating node at the time
of origination.
5.2.4. Node Data TLV
0 1 2 3 6.2. Prefix Assignment
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-DATA (6) | Length: >= 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested TLVs containing node information |
5.2.5. Neighbor TLV (within Node Data TLV) HNCP uses the Distributed Prefix Assignment Algorithm specified in
[I-D.ietf-homenet-prefix-assignment] in order to assign prefixes to
HNCP internal links and uses the terminology defined there.
0 1 2 3 6.2.1. Assigned Prefix TLV
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: NEIGHBOR (8) | Length: 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(neighbor node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV indicates that the node in question vouches that the Published Assigned Prefixes MUST be advertised using the Assigned
specified neighbor is reachable by it on the local link id given. Prefix TLV:
This reachability may be unidirectional (if no unicast exchanges have
been performed with the neighbor). The presence of this TLV at least
guarantees that the node publishing it has received traffic from the
neighbor recently. For guaranteed bidirectional reachability,
existence of both nodes' matching Neighbor TLVs should be checked.
5.3. Custom TLV (within/without Node 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: CUSTOM-DATA (9) | Length: >= 12 | | Type: ASSIGNED-PREFIX (35) | Length: >= 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H-64(URI) | | Connection Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Data | | Rsv. | Prty. | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +
| |
This TLV can be used to contain anything; the URI used should be Connection Identifier: The DNCP Connection Identifier of the link
under control of the author of that specification. For example: the prefix is assigned to, or 0 if the link is a Private Link.
V=H-64('http://example.com/author/json-for-hncp') .. '{"cool": "json Rsv.: Bits reserved for future use. MUST be set to zero when
extension!"}' creating this TLV and ignored when parsing it.
or Prty: The Advertised Prefix Priority from 0 to 15.
V=H-64('mailto:author@example.com') .. '{"cool": "json extension!"}' 0-1 : Low priorities.
5.4. Version TLV (within Node Data TLV) 2 : Default priority.
0 1 2 3 3-7 : High priorities.
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: VERSION (10) | Length: >= 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-agent |
This TLV indicates which version of HNCP TLV binary structures is in 8-11 : Administrative priorities. MUST NOT be used unless
use by this particular node. All TLVs within node data from nodes specified in the router's configuration.
that do not publish version TLV, or with different Version value than
locally supported one MUST be ignored (but forwarded). The user-
agent is an optional human-readable UTF-8 string that can describe
e.g. current HNCP implementation version. This draft describes
Version=1 TLVs.
6. Border Discovery and Prefix Assignment 12-14: Reserved for future use.
This section defines border discovery algorithm derived from the edge 15 : Provider priorities. MAY only be used by the router
router interactions described in the Basic Requirements for IPv6 advertising the corresponding delegated prefix and based on
Customer Edge Routers [RFC7084]. The algorithm is designed to work static or dynamic configuration (e.g., for excluding a prefix
for both IPv4 and IPv6 (single or dual-stack). based on DHCPv6-PD Prefix Exclude Option [RFC6603]).
In order to avoid conflicts between border discovery and homenet Prefix Length: The number of significant bits in the Prefix field.
routers running DHCP [RFC2131] or DHCPv6-PD [RFC3633] servers each
router MUST implement the following mechanism based on The User Class
Option for DHCP [RFC3004] or its DHCPv6 counterpart [RFC3315]
respectively into its DHCP and DHCPv6-logic:
A homenet router running a DHCP-client on a homenet-interface MUST Prefix: The significant bits of the prefix padded with zeroes up to
include a DHCP User-Class consisting of the ASCII-String the next byte boundary.
"HOMENET".
A homenet router running a DHCP-server on a homenet-interface MUST 6.2.2. Prefix Assignment Algorithm Parameters
ignore or reject DHCP-Requests containing a DHCP User-Class
consisting of the ASCII-String "HOMENET".
The border discovery auto-detection algorithm works as follows, with All HNCP nodes running the prefix assignment algorithm MUST use the
evaluation stopping at first match: following parameters:
1. If a fixed category is set for an interface, it MUST be used. Node IDs: DNCP Node Identifiers are used. The comparison operation
is defined as bit-wise comparison.
2. Any of the following conditions indicate an interface MUST be Set of Delegated Prefixes: The set of prefixes encoded in Delegated
considered external: Prefix TLVs which are not strictly included in prefixes encoded in
other Delegated Prefix TLVs. Note that Delegated Prefix TLVs
included in ignored External Connection TLVs are not considered.
It is dynamically updated as Delegated Prefix TLVs are added or
removed.
1. A delegated prefix could be acquired by running a Set of Shared Links: The set of HNCP internal, leaf, guest or
DHCPv6-client on the interface. hybrid links. It is dynamically updated as HNCP links are added,
removed, become internal or cease to be.
2. An IPv4-address could be acquired by running a DHCP-client on Set of Private Links: This document defines Private Links
the interface. representing DHCPv6-PD clients or as a mean to advertise prefixes
included in the DHCPv6 Exclude Prefix option. Other
implementation-specific Private Links may exist.
3. As default fallback, interface MUST be considered internal. Set of Advertised Prefixes: The set of prefixes included in
Assigned Prefix TLVs advertised by other HNCP routers. The
associated Advertised Prefix Priority is the priority specified in
the TLV. The associated Shared Link is determined as follows:
A router MUST allow setting a category of either auto-detected, * If the Link Identifier is zero, the Advertised Prefix is not
internal or external for each interface which is suitable for both assigned on a Shared Link.
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 clients only. A * If the Link Identifier is not zero the Shared Link is equal to
router SHOULD implement this category and MUST NOT send nor accept the Adjacent Link (Section 4). Advertised Prefixes as well as
HNCP messages on these interfaces. their associated priorities and associated Shared Links MUST be
updated as Assigned Prefix TLVs or Neighbor TLVs are added,
removed or updated.
Guest category: This declares an interface used by untrusted ADOPT_MAX_DELAY: The default value is 0 seconds (i.e. prefix
clients only. In addition to the restrictions of the leaf adoption MAY be done instantly).
category, clients connected to these interfaces MUST NOT be able
to reach devices inside the home network by default and instead
SHOULD only be able to reach the internet. This category SHOULD
be also supported.
Ad-hoc category: This declares an interface to be in ad-hoc mode. BACKOFF_MAX_DELAY: The default value is 4 seconds.
This indicates to HNCP applications such as prefix assignment that
links on this interface are potentially non-transitive. This
category MAY be implemented.
Hybrid category: This allows the router to still accepts external RANDOM_SET_SIZE: The default value is 64.
connections but does not do border discovery. It is assumed that
the link is under control of a legacy, trustworthy non-HNCP
router, still within the same home network. Detection of this
category automatically in addition to manual configuration is out
of scope for this document. This category MAY be implemented.
A homenet router SHOULD provide basic connectivity to legacy CERs Flooding Delay: The default value is 5 seconds.
[RFC7084] connected to internal interfaces in order to allow
coexistence with existing devices.
Each router MUST continuously scan each active interface that does Default Advertised Prefix Priority: When a new assignment is
not have a fixed category in order to dynamically reclassify it if created or an assignment is adopted - as specified in the prefix
necessary. The router therefore runs an appropriately configured assignment algorithm routine - the default Advertised Prefix
DHCP and DHCPv6-client as long as the interface is active including Priority to be used is 2.
states where it considers the interface to be internal. The router
SHOULD wait for a reasonable time period (5 seconds as a possible
default) in 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. Once a router detects an interface to be external it MUST
stop any previously enabled internal forwarding. In addition it
SHOULD announce the acquired information for use in the homenet as
described in later sections of this draft if the interface appears to
be connected to an external network.
To distribute an external connection in the homenet an edge router 6.2.3. Making New Assignments
announces one or more delegated prefixes and associated DHCP(v6)-
encoded auxiliary information like recursive DNS-servers. Each
external connection is announced using one container-TLV as follows:
0 1 2 3 Whenever the Prefix Assignment Algorithm routine is run on an
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 Adjacent Link and whenever a new prefix may be assigned (case 1 of
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the routine), the decision of whether the assignment of a new prefix
| Type: EXTERNAL-CONNECTION (41)| Length: > 4 | is desired MUST follow these rules:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested TLVs |
Auxiliary connectivity information is encoded as a stream of If the Delegated Prefix TLV contains a DHCPv4 or DHCPv6 Data TLV,
DHCPv6-attributes or DHCP-attributes placed inside a TLV of type and the meaning of one of the DHCP options is not understood by
EXTERNAL-CONNECTION or DELEGATED-PREFIX (for IPv6 prefix-specific the HNCP router, the creation of a new prefix is not desired.
information). There MUST NOT be more than one instance of this TLV
inside a container and the order of the DHCP(v6)-attributes contained
within it MUST be preserved as long as the information contained does
not change. The TLVs are encoded as follows:
0 1 2 3 If the remaining preferred lifetime of the prefix is 0 and there
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 is another delegated prefix of the same IP version used for prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ assignment with a non-null preferred lifetime, the creation of a
| Type: DHCPV6-DATA (45) | Length: > 4 | new prefix is not desired.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv6 attribute stream |
and Otherwise, the creation of a new prefix is desired.
0 1 2 3 If the considered delegated prefix is an IPv6 prefix, and whenever
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 there is at least one available prefix of length 64, a prefix of
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ length 64 MUST be selected unless configured otherwise by an
| Type: DHCP-DATA (44) | Length: > 4 | administrator. In case no prefix of length 64 would be available, a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ longer prefix MAY be selected.
| DHCP attribute stream |
Each delegated prefix is encoded using one TLV inside an EXTERNAL- If the considered delegated prefix is an IPv4 prefix ( Section 6.4
CONNECTION TLV. For external IPv4 connections the prefix is encoded details how IPv4 delegated prefixes are generated), a prefix of
in the form of an IPv4-mapped address [RFC4291] and is usually from a length 24 SHOULD be preferred.
private address range [RFC1918]. The related TLV is defined as
follows.
0 1 2 3 In any case, a router MUST support a mechanism suitable to distribute
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 addresses from the considered prefix to clients on the link.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Otherwise it MUST NOT create or adopt it, i.e. a router assigning an
| Type: DELEGATED-PREFIX (42) | Length: >= 13 | IPv4 prefix MUST support the L-capability and a router assigning an
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 prefix not suitable for stateless autoconfiguration MUST support
| Valid until (milliseconds) | the H-capability as defined in Section 10.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred until (milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | |
+-+-+-+-+-+-+-+-+ Prefix Address [+ nested TLVs] +
| |
Valid until is the time in milliseconds the delegated prefix is 6.2.4. Applying Assignments
valid. The value is relative to the point in time the TLV is
first announced.
Preferred until is the time in milliseconds the delegated prefix The prefix assignment algorithm indicates when a prefix is applied to
is preferred. The value is relative to the point in time the TLV the respective Adjacent Link. When that happens each router
is first announced. connected to said link:
Prefix length specifies the number of significant bits in the MUST create an appropriate on-link route for said prefix and
prefix. advertise it using the chosen routing protocol.
Prefix address is of variable length and contains the significant MUST participate in the client configuration election as described
bits of the prefix padded with zeroes up to the next byte in Section 7.
boundary.
Nested TLVs might contain prefix-specific information like MAY add an address from said prefix to the respective network
DHCPv6-options. interface as described in Section 6.3.
In order for routers to use the distributed information, prefixes and 6.2.5. DHCPv6-PD Excluded Prefix Support
addresses have to be assigned to the interior links of the homenet.
A router MUST therefore implement the algorithm defined in Prefix and
Address Assignment in a Home Network
[I-D.ietf-homenet-prefix-assignment]. In order to announce the
assigned prefixes the following TLVs are defined.
Each assigned prefix is given to an interior link and is encoded Whenever a DHCPv6 Prefix Exclude option [RFC6603] is received with a
using one TLVs. Assigned IPv4 prefixes are stored as mapped delegated prefix, the excluded prefix MUST be advertised as assigned
IPv4-addresses. The TLV is defined as follows: to a Private Link with the maximum priority (i.e. 15).
0 1 2 3 The same procedure MAY be applied in order to exclude prefixes
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 obtained by other means of configuration.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: ASSIGNED-PREFIX (43) | Length: >= 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R. |A| Pref. | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix Address +
| |
Link Identifier is the local HNCP identifier of the link the 6.2.6. Downstream Prefix Delegation Support
prefix is assigned to.
R. is reserved for future additions and MUST be set to 0 when When an HNCP router receives a request for prefix delegation, it
creating TLVs and ignored when parsing them. SHOULD assign one prefix per delegated prefix, wait for them to be
applied, and delegate them to the client. Such assignment MUST be
done in accordance with the Prefix Assignment Algorithm. Each client
MUST be considered as an independent Private Link and delegation MUST
be based on the same set of Delegated Prefixes.
A is the authoritative flag which indicates that an assignment is The assigned prefixes MUST NOT be given to clients before they are
enforced and ignores usual collision detection rules. applied, and MUST be withdrawn whenever they are destroyed. As an
exception to this rule a router MAY prematurely give out a prefix
which is advertised but not yet applied if it does so with a valid
lifetime of not more than 30 seconds and ensures removal or
correction of lifetimes as soon as possible to shorten delays of
processed requests.
Pref. describes the preference of the assignment and can be used 6.3. Node Address Assignment
to differentiate the importance of a given assignment over others.
Prefix length specifies the number of significant bits in the This section specifies how HNCP nodes reserve addresses for their own
prefix. use. Nodes MAY, at any time, try to reserve a new address. SLAAC
SHOULD be used whenever possible. The following method MUST be used
otherwise.
Prefix address is of variable length and contains the significant For any IPv6 prefix longer than 64 bits (resp. any IPv4 prefix)
bits of the prefix padded with zeroes up to the next byte assigned to an Adjacent Link, the first quarter of the addresses are
boundary. reserved for routers HNCP based assignments, whereas the last three
quarters are left to the DHCPv6 (resp. DHCPv4) elected router
(Section 10 specifies the DHCP server election process). For
instance, if the prefix 192.0.2.0/24 is assigned and applied to an
Adjacent Link, addresses included in 192.0.2.0/26 are reserved for
HNCP nodes and the remaining addresses are reserved for the elected
DHCPv4 server.
In some cases (e.g. IPv4) the set of addresses is very limited and HNCP routers assign themselves addresses using the Node Address TLV:
stateless mechanisms are not really suitable for address assignment.
Therefore HNCP can manage router address in these cases by itself.
Each router assigning an address to one of its interfaces announces
one TLV of the following kind:
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: ROUTER-ADDRESS (46) | Length: 24 | | Type: NODE-ADDRESS (36) | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier | | Connection Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Router Address | | IP Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Identifier is the local HNCP identifier of the link the Connection Identifier: The DNCP Connection Identifier of the link
address is assigned to. the address is assigned to, or 0 if it is not assigned on an HNCP
enabled link.
Router Address is the address assigned to one of the router IP Address: The IPv6 address, or the IPv4 address encoded as an
interfaces. IPv4-mapped IPv6 address [RFC4291].
7. DNS-based Service Discovery The process of obtaining addresses is specified as follows:
Service discovery is generally limited to a local link. o A router MUST NOT start advertising an address if it is already
[I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf] defines a advertised by another router.
mechanism to automatically extended DNS-based service discovery
across multiple links within the home automatically. Following TLVs
MAY be used to provide transport for that specification.
7.1. DNS Delegated Zone TLV o An assigned address MUST be in the first quarter of an assigned
prefix currently applied on the specified link.
o An address MUST NOT be used unless it has been advertised for at
least ADDRESS_APPLY_DELAY consecutive seconds, and is still
currently being advertised. The default value for
ADDRESS_APPLY_DELAY is 3 seconds.
o Whenever the same address is advertised by more than one node all
but the one advertised by the node with the highest node
identifier MUST be removed.
6.4. Local IPv4 and ULA Prefixes
HNCP routers can create an ULA or private IPv4 prefix to enable
connectivity between local devices. These prefixes are inserted in
HNCP as if they were delegated prefixes. The following rules apply:
An HNCP router SHOULD create an ULA prefix if there is no other
non-deprecated IPv6 prefix in the network. It MAY also do so if
there are other delegated IPv6 prefixes but none of which is a
non-deprecated ULA but MUST NOT do so otherwise. Whenever it
detects another non-deprecated ULA being advertised it MUST cease
to announce its locally generated one. It MAY also do so once it
detects a non-deprecated non-ULA IPv6 delegated prefix.
An HNCP router MUST create a non-deprecated private IPv4 prefix
[RFC1918] whenever it wishes to provide external IPv4 connectivity
to the network and no other non-deprecated private IPv4 prefix
currently exists. It MAY also create a deprecated private IPv4
prefix if no IPv4 prefix exists and it wants to enable local IPv4
connectivity but MUST NOT do so otherwise. In case multiple IPv4
prefixes are announced all but one MUST be removed while non-
deprecated ones take precedence over deprecated ones and
announcements by nodes with a higher node identifier take
precedence over those with a lower one. The router publishing the
non-deprecated prefix MUST announce an IPv4 default route using
the routing protocol and perform NAT on behalf of the network as
long as it publishes the prefix, other routers in the network MUST
NOT.
Creation of such ULA and IPv4 prefixes MUST be delayed by a random
timespan between 0 and 10 seconds in which the router MUST scan for
other nodes trying to do the same.
When a new ULA prefix is created, the prefix is selected based on the
configuration, using the last non-deprecated ULA prefix, or generated
based on [RFC4193].
7. Configuration of Hosts and non-HNCP Routers
HNCP routers need to ensure that hosts and non-HNCP downstream
routers on internal links are configured with addresses and routes.
Since DHCP-clients can usually only bind to one server at a time an
election takes place.
HNCP routers may have different capabilities for configuring
downstream devices and providing naming services. Each router MUST
therefore indicate its capabilities as specified in Section 10 in
order to participate as a candidate in the election.
7.1. DHCPv6 for Addressing or Configuration
In general stateless address configuration is preferred whenever
possible since it enables fast renumbering and low overhead, however
stateful DHCPv6 can be useful in addition to collect hostnames and
use them to provide naming services or if stateless configuration is
not possible for the assigned prefix length.
The designated stateful DHCPv6 server for a link is elected based on
the capabilities described in Section 10. The winner is the router
connected to the Adjacent Link (Section 4) advertising the greatest
H-capability. In case of a tie, Capability Values and node
identifiers are considered (greatest value is elected). The elected
router MUST serve stateful DHCPv6 and Router Advertisements on the
given link. Furthermore it MUST provide naming services for acquired
hostnames as outlined in Section 8. Stateful addresses being handed
out SHOULD have a low preferred lifetime (e.g. 1s) to not hinder fast
renumbering if either the DHCPv6 server or client do not support the
DHCPv6 reconfigure mechanism and the address is from a prefix for
which stateless autoconfiguration is supported as well. In case no
router was elected, stateful DHCPv6 is not provided and each router
assigning IPv6 prefixes on said link MUST serve Router Advertisements
and stateless DHCPv6.
7.2. Sending Router Advertisements
The HNCP router being elected as DHCPv6 server for addressing or
configuration MUST send Router Advertisements periodically via
multicast and via unicast in response to Router Solicitations. In
addition other routers on the link MAY announce Router
Advertisements. This might result in a more optimal routing decision
for clients. The following rules MUST be followed when sending
Router Advertisements:
The "Managed address configuration" flag MUST be set whenever a
router connected to the link is advertising a non-null
H-capability and MUST NOT be set otherwise. The "Other
configuration" flag MUST always be set.
The default Router Lifetime MUST be set to an appropriate non-null
value whenever an IPv6 default route is known in the HNCP network
and MUST be set to zero otherwise.
A Prefix Information Option MUST be added for each assigned and
applied IPv6 prefix on the given link. The autonomous address-
configuration flag MUST be set whenever the prefix is suitable for
stateless configuration. The preferred and valid lifetimes MUST
be smaller than the preferred and valid lifetimes of the delegated
prefix the prefix is from. When a prefix is removed, it MUST be
deprecated as specified in [RFC7084].
A Route Information Option [RFC4191] MUST be added for each
delegated IPv6 prefix known in the HNCP network. Additional ones
SHOULD be added for each non-default IPv6 route with an external
destination advertised by the routing protocol.
A Recursive DNS Server Option and a DNS Search List Option MUST be
included with appropriate contents.
To allow for optimized routing decisions for clients on the local
link routers SHOULD adjust their Default Router Preference and
Route Preferences [RFC4191] so that the priority is set to low if
the next hop of the default or more specific route is on the same
interface as the Route Advertisement being sent on. Similarly the
router MAY use the high priority if it is certain it has the best
metric of all routers on the link for all routes known in the
network with the respective destination.
Every router sending Router Advertisements MUST immediately send an
updated Router Advertisement via multicast as soon as it notices a
condition resulting in a change of any advertised information.
7.3. DHCPv6 for Prefix Delegation
The designated DHCPv6 server for prefix-delegation on a link is
elected based on the capabilities described in Section 10. The
winner is the router connected to the Adjacent Link (Section 4)
advertising the greatest P-capability. In case of a tie, Capability
Values and Node Identifiers are considered (greatest value is
elected). The elected router MUST provide prefix-delegation services
[RFC3633] on the given link and follow the rules in Section 6.2.6.
7.4. DHCPv4 for Adressing and Configuration
The designated DHCPv4 server on a link is elected based on the
capabilities described in Section 10. The winner is the router
connected to the Adjacent Link (Section 4) advertising the greatest
L-capability. In case of a tie, Capability Values and node
identifiers are considered (greatest value is elected). The elected
router MUST provide DHCPv4 services on the given link.
The DHCPv4 serving router MUST announce itself as router [RFC2132] to
clients if and only if there is an IPv4 default route known in the
network. In addition the router SHOULD announce a Classless Static
Route Option [RFC3442] for each non-default IPv4 route advertised in
the routing protocol with an external destination.
DHCPv4 lease times SHOULD be short (i.e. not longer than 5 minutes)
in order to provide reasonable response times to changes.
7.5. Multicast DNS Proxy
The designated MDNS [RFC6762]-proxy on a link is elected based on the
capabilities described in Section 10. The winner is the router with
the highest Node Identifier among those with the highest Capability
Value on the link that support the M-capability. The elected router
MUST provide an MDNS-proxy on the given link and announce it as
described in Section 8.
8. Naming and Service Discovery
Network-wide naming and service discovery can greatly improve the
user-friendliness of an IPv6 network. The following mechanism
provides means to setup and delegate naming and service discovery
across multiple HNCP routers.
Each HNCP router SHOULD provide and announce an auto-generated or
user-configured name for each internal Adjacent Link (Section 4) for
which it is the designated DHCPv4, stateful DHCPv6 server or MDNS
[RFC6762]-proxy and for which it provides DNS-services on behalf of
devices on said link. In addition it MAY provide reverse lookup
services.
The following TLVs are defined and MUST be supported by all nodes
implementing naming and service discovery:
8.1. DNS Delegated Zone TLV
This TLV is used to announce a forward or reverse DNS zone delegation
in the HNCP network. Its meaning is roughly equivalent to specifying
an NS and A/AAAA record for said zone. There MUST NOT be more than
one delegation for the same zone in the whole DNCP network. In case
of a conflict the announcement of the node with the highest node
identifier takes precedence and all other nodes MUST cease to
announce the conflicting TLV.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: DNS-DELEGATED-ZONE (50) | Length: >= 21 | | Type: DNS-DELEGATED-ZONE (39) | Length: >= 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | IP Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |S|B| | |reserved |L|B|S| |
+-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) | +-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) |
| | | |
7.2. Domain Name TLV IP Address is the IPv6 address of the authoritative DNS server for
the zone; IPv4 addresses are represented as IPv4-mapped addresses
[RFC4291]. The special value of :: (all-zero) means the
delegation is available in the global DNS-hierarchy.
reserved bits MUST be zero when creating and ignored when parsing
this TLV.
L-bit (DNS-SD [RFC6763] Legacy-Browse) indicates that this
delegated zone should be included in the network's DNS-SD legacy
browse list of domains at lb._dns- sd._udp.(DOMAIN-NAME). Local
forward zones SHOULD have this bit set, reverse zones SHOULD NOT.
B-bit (DNS-SD [RFC6763] Browse) indicates that this delegated zone
should be included in the network's DNS-SD browse list of domains
at b._dns-sd._udp. (DOMAIN-NAME). Local forward zones SHOULD
have this bit set, reverse zones SHOULD NOT.
S-bit (fully-qualified DNS-SD [RFC6763] -domain) indicates that
this delegated zone consists of a fully-qualified DNS-SD domain,
which should be used as base for DNS-SD domain enumeration, i.e.
_dns-sd._udp.(Zone) exists. Forward zones MAY have this bit set,
reverse zones MUST NOT. This can be used to provision DNS search
path to hosts for non-local services (such as those provided by an
ISP, or other manually configured service providers). Zones with
this flag SHOULD be added to the search domains advertised to
clients.
Zone is the label sequence of the zone, encoded according to
[RFC1035]. Compression MUST NOT be used. The zone MUST end with
an empty label.
8.2. Domain Name TLV
This TLV is used to indicate the base domain name for the network.
It is the zone used as a base for all non fully-qualified delegated
zones and node names. In case of conflicts the announced domain of
the node with the highest node identifier takes precedence. By
default ".home" is used, i.e. if no node advertises such a TLV.
0 1 2 3 0 1 2 3
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 (51) | Length: >= 4 | | Type: DOMAIN-NAME (40) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain (DNS label sequence - variable length) | | Domain (DNS label sequence - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.3. Router Name TLV Domain is the label sequence encoded according to [RFC1035].
Compression MUST NOT be used. The zone MUST end with an empty
label.
8.3. Node Name TLV
This TLV is used to assign the name of a node in the network to a
certain IP address. In case of conflicts the announcement of the
node with the highest node identifier for a name takes precedence and
all other nodes MUST cease to announce the conflicting TLV.
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: ROUTER-NAME (52) | Length: >= 4 | | Type: NODE-NAME (41) | Length: > 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name (not null-terminated - variable length) | | Name (not null-terminated - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8. Routing support 9. Securing Third-Party Protocols
8.1. Protocol Requirements 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:
In order to be advertised for use within the homenet, a routing o If no Managed-PSK-TLV is currently being announced, an HNCP router
protocol MUST: MUST create one with a 32 bytes long random key and add it to its
node data.
Comply with Requirements and Use Cases for Source/Destination o In case multiple routers announce such a TLV at the same time, all
Routing [I-D.baker-rtgwg-src-dst-routing-use-cases]. but the one with the highest node identifier stop advertising it
and adopt the remaining one.
Be configured with suitable defaults or have an auto-configuration o The router currently advertising the Managed-PSK-TLV must generate
mechanism (e.g. [I-D.acee-ospf-ospfv3-autoconfig]) such that it and advertise a new random one whenever an unreachable node is
will run in a homenet without requiring specific configuration purged as described in DNCP.
from the home user.
A router MUST NOT announce that it supports a certain routing 0 1 2 3
protocol if its implementation of the routing protocol does not meet 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
these requirements, e.g. it does not implement extensions that are +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
necessary for compliance. | Type: Managed-PSK (42) | Length: 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| Random PSK |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.2. Announcement PSKs for individual protocols are derived from the random PSK through
the use of HMAC-SHA256 [RFC6234] with a pre-defined per-protocol
HMAC-key in ASCII-format. The following HMAC-keys are currently
defined to derive PSKs for the respective protocols:
Each router SHOULD announce all routing protocols that it is capable "ROUTING": to be used for IGPs
of supporting in the homenet. It MUST announce at least one protocol
or the fallback mechanism to be considered for protocol selection and
MAY omit announcing the fallback mechanism if it announces at least
one other routing protocol. It SHOULD assign a preference value for
each protocol that indicates its desire to use said protocol over
other protocols it supports and SHOULD make these values
configurable.
Each router includes one HNCP TLV of type ROUTING-PROTOCOL for every 10. HNCP Versioning and Capabilities
such routing protocol. This TLV is defined as follows:
Multiple versions of HNCP based on compatible DNCP
[I-D.ietf-homenet-dncp] profiles may be present in the same network
when transitioning between HNCP versions and HNCP routers may have
different capabilities to support clients. The following mechanism
describes a way to announce the currently active version and User-
agent of a node. Each node MUST include an HNCP-Version-TLV in its
Node Data and MUST ignore (except for DNCP synchronization purposes)
any TLVs with a type greater than 32 of nodes not publishing an HNCP-
Version TLV or publishing such a TLV with a different Version number.
Capabilities are indicated by setting M, P, H and L fields in the
TLV. The "capability value" is a metric indicated by interpreting
the bits as an integer, i.e. (M << 12 | P << 8 | H << 4 | L).
0 1 2 3 0 1 2 3
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: ROUTING-PROTOCOL (60) | Length: 6 | | Type: HNCP-VERSION (32) | Length: >= 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | Preference | | Version | Reserved | M | P | H | L |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-agent |
Protocol ID is one of: Version: Version indicates which version of HNCP is currently in use
by this particular node. It MUST be set to 0. Nodes with
0 = Fallback (explicit announcement) different versions are considered incompatible.
1 = Babel (dual-stack) Reserved: Bits reserved for future use. MUST be set to zero when
creating this TLV and ignored when parsing it.
2 = OSPFv3 (dual-stack) 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.
3 = IS-IS (dual-stack) 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.
4 = RIP (dual-stack) 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.
Preference is a value from 0 to 255. If a router is neutral about L-capability: Priority value used for electing the on-link DHCPv4
a routing protocol it SHOULD use the value 128, otherwise a lower server. It MUST be set to some value between 1 and 7 included (4
value indicating lower preference or a higher value indicating is the default) if the router is capable of running a legacy
higher preference respectively. DHCPv4 server offering IPv4 addresses to clients and 0 otherwise.
The values 8-15 are reserved for future use.
8.3. Protocol Selection User-Agent: The user-agent is a null-terminated human-readable UTF-8
string that describes the name and version of the current HNCP
implementation.
When HNCP detects that a device has joined or left the homenet it 11. Requirements for HNCP Routers
MUST examine all advertised routing protocols and preference values
from all devices announcing at least one ROUTING-PROTOCOL-TLV in
order to find the one routing protocol which:
1. Is understood by all routers in the homenet Each router implementing HNCP is subject to the following
requirements:
2. Has the highest preference value among all routers (calculated as o It MUST implement HNCP-Versioning, Border Discovery, Prefix
sum of preference values) Assignment and Configuration of hosts and non-HNCP routers as
defined in this document.
3. Has the highest protocol ID among those with the highest o It MUST implement and run the method for securing third-party
preference protocols whenever it uses the security mechanism of HNCP.
If the router protocol selection results in the need to change from o It SHOULD implement support for the Service Discovery and Naming
one routing protocol to another on the homenet, the router MUST stop TLVs as defined in this document.
the previously running protocol, remove associated routes, and start
the new protocol in a graceful manner. If there is no common routing
protocol available among all homenet routers, routers MUST utilize
the Fallback Mechanism (Section 8.4).
8.4. Fallback Mechanism o It MUST implement and run the routing protocol $FOO with support
for source-specific routes on all of the interfaces it sends and
receives HNCP-messages on and MUST resort to announcing source-
specific routes for external destinations appropriately.
In cases where there is no commonly supported routing protocol o It MUST use adequate security mechanisms for the routing protocol
available the following fallback algorithm is run to setup routing on any interface where it also uses the security mechanisms of
and preserve interoperability among the homenet. While not intended HNCP. If the security mechanism is based on a PSK it MUST use a
to replace a routing protocol, this mechanism provides a valid - but PSK derived from the Managed-PSK to secure the IGP.
not necessarily optimal - routing topology. This algorithm uses the
node and neighbor state already synchronized by HNCP, and therefore
does not require any additional protocol message exchange.
1. Interpret the neighbor information received via HNCP as a graph o It MUST comply with the Basic Requirements for IPv6 Customer Edge
of connected routers. Routers [RFC7084] unless it would otherwise conflict with any
requirements in this document (e.g. prefix assignment mandating a
different prefix delegation and DHCP server election strategy).
In general "WAN interface requirements" shall apply to external
interfaces and "LAN interface requirements" to internal interfaces
respectively.
2. Use breadth-first traversal to determine the next-hop and hop- o It SHOULD be able to provide connectivity to IPv4-devices using
count in the path to each router in the homenet: DHCPv4.
1. Start the traversal with the immediate neighbors of the o It SHOULD be able to delegate prefixes to legacy IPv6 routers
router running the algorithm. using DHCPv6-PD.
2. Always visit the immediate neighbors of a router in ascending 12. Security Considerations
order of their router ID.
3. Never visit a router more often than once. HNCP enables self-configuring networks, requiring as little user
intervention as possible. However this zero-configuration goal
usually conflicts with security goals and introduces a number of
threats.
3. For each delegated prefix P of any router R in the homenet: General security issues for existing home networks are discussed in
Create a default route via the next-hop for R acquired in #2. [RFC7368]. The protocols used to set up addresses and routes in such
Each such route MUST be source-restricted to only apply to networks to this day rarely have security enabled within the
traffic with a source address within P and its metric MUST configuration protocol itself. However these issues are out of scope
reflect the hop-count to R. for the security of HNCP itself.
4. For each assigned prefix A of a router R: Create a route to A via HNCP is a DNCP [I-D.ietf-homenet-dncp]-based state synchronization
the next-hop for R acquired in #2. Each such route MUST NOT be mechanism carrying information with varying threat potential. For
source-restricted. this consideration the payloads defined in DNCP and this document are
reviewed:
5. For the first router R visited in the traversal announcing an o Network topology information such as HNCP nodes and their adjacent
IPv4-uplink: Create a default IPv4-route via the next-hop for R links
acquired in #2.
6. For each assigned IPv4-prefix A of a router R: Create an o Address assignment information such as delegated and assigned
IPv4-route to A via the next-hop for R acquired in #2. prefixes for individual links
9. Security Considerations o Naming and service discovery information such as auto-generated or
customized names for individual links and routers
General security issues for home networks are discussed at length in 12.1. Border Determination
[RFC7368]. The protocols used to set up IP in home networks today
have rarely security enabled within the control protocol itself. For
example, DHCP has defined [RFC3118] to authenticate DHCP messages,
but this is very rarely implemented in large or small networks.
Further, while PPP can provide secure authentication of both sides of
a point to point link, it is most often deployed with one-way
authentication of the subscriber to the ISP, not the ISP to the
subscriber.
HNCP itself sends messages as clear text which is as secure, or As described in Section 5, an HNCP router determines the internal or
insecure, as the security of the link it runs on. As HNCP messages external state on a per-link basis. A firewall perimeter is set up
are sent over IPv6 UDP, IPsec may be used for confidentiality or for the external links, and for internal links, HNCP and IGP traffic
message authentication. This requires manually keyed IPsec per-port is allowed.
granularity for port IANA-UDP-PORT UDP traffic, and a pre-shared key
has to be utilized in this case given IKE cannot be used with
multicast traffic. This seems acceptable, though, as most routing
protocols also operate based on pre-shared keys, and the homenet
architecture draft explicitly allows their use for securing
them[RFC7368]. Other traffic security mechanisms are out of scope
for this specification. There is ongoing work
[I-D.barth-homenet-hncp-security-trust] to define a mechanism that
can be used with HNCP and be more user-friendly than pre-shared keys.
10. IANA Considerations Threats concerning automatic border discovery cannot be mitigated by
encrypting or authenticating HNCP traffic itself since external
routers do not participate in the protocol and often cannot be
authenticated by other means. These threats include propagation of
forged uplinks in the homenet in order to e.g. redirect traffic
destined to external locations and forged internal status by external
routers to e.g. circumvent the perimeter firewall.
IANA should set up a registry (policy TBD) for HNCP TLV types, with It is therefore imperative to either secure individual links on the
following initial contents: physical or link-layer or preconfigure the adjacent interfaces of
HNCP routers to an adequate fixed-category in order to secure the
homenet border. Depending on the security of the external link
eavesdropping, man-in-the-middle and similar attacks on external
traffic can still happen between a homenet border router and the ISP,
however these cannot be mitigated from inside the homenet. For
example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4
messages, but this is very rarely implemented in large or small
networks. Further, while PPP can provide secure authentication of
both sides of a point to point link, it is most often deployed with
one-way authentication of the subscriber to the ISP, not the ISP to
the subscriber.
0: Reserved (should not happen on wire) 12.2. Security of Unicast Traffic
1: Node link Once the homenet border has been established there are several ways
to secure HNCP against internal threats like manipulation or
eavesdropping by compromised devices on a link which is enabled for
HNCP traffic. If left unsecured, attackers may perform arbitrary
eavesdropping, spoofing or denial of service attacks on HNCP services
such as address assignment or service discovery.
2: Request network state Detailed interface categories like "leaf" or "guest" can be used to
integrate not fully trusted devices to various degrees into the
homenet by not exposing them to HNCP and IGP traffic or by using
firewall rules to prevent them from reaching homenet-internal
resources.
3: Request node data On links where this is not practical and lower layers do not provide
adequate protection from attackers, DNCP secure mode MUST be used to
secure traffic.
4: Network state 12.3. Other Protocols in the Home
5: Node state IGPs and other protocols are usually run alongside HNCP therefore the
individual security aspects of the respective protocols must be
considered. It can however be summarized that many protocols to be
run in the home (like IGPs) provide - to a certain extent - similar
security mechanisms. Most of these protocols do not support
encryption and only support authentication based on pre-shared keys
natively. This influences the effectiveness of any encryption-based
security mechanism deployed by HNCP as homenet routing information is
thus usually not encrypted.
6: Node data 13. IANA Considerations
7: (unused - was node public key, but never implemented) IANA is requested to maintain a registry for HNCP TLV-Types.
8: Neighbor HNCP inherits the TLV-Types and allocation policy defined in DNCP
9: Custom [I-D.ietf-homenet-dncp]. In addition the following TLV-Types are
defined in this document:
10: Version 32: HNCP-Version
41: External connection 33: External-Connection
42: Delegated prefix 34: Delegated-Prefix
43: Assigned prefix 35: Assigned-Prefix
44: DHCP-data 36: Node-Address
45: DHCPv6-data 37: DHCPv4-Data
46: Router-address 38: DHCPv6-Data
50: DNS Delegated Zone 39: DNS-Delegated-Zone
51: Domain name 40: Domain-Name
52: Node name 41: Node-Name
60: Routing protocol 42: Managed-PSK
65535: Signature HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP-
DTLS-PORT, as well as an IPv6 link-local multicast address All-
Homenet-Routers.
HNCP will also require allocation of a UDP port number IANA-UDP-PORT, 14. References
as well as IPv6 link-local multicast address IANA-MULTICAST-ADDRESS.
11. References 14.1. Normative references
11.1. Normative references [I-D.ietf-homenet-dncp]
Stenberg, M. and S. Barth, "Distributed Node Consensus
Protocol", draft-ietf-homenet-dncp-00 (work in progress),
January 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.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
"The Trickle Algorithm", RFC 6206, March 2011. Security Version 1.2", RFC 6347, January 2012.
[I-D.ietf-homenet-prefix-assignment] [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
Pfister, P., Paterson, B., and J. Arkko, "Prefix and "Prefix Exclude Option for DHCPv6-based Prefix
Address Assignment in a Home Network", draft-ietf-homenet- Delegation", RFC 6603, May 2012.
prefix-assignment-01 (work in progress), October 2014.
[I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf] [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
Stenberg, M., "Auto-Configuration of a Network of Hybrid More-Specific Routes", RFC 4191, November 2005.
Unicast/Multicast DNS-Based Service Discovery Proxy
Nodes", draft-stenberg-homenet-dnssd-hybrid-proxy-
zeroconf-01 (work in progress), June 2014.
11.2. Informative references [I-D.ietf-homenet-prefix-assignment]
Pfister, P., Paterson, B., and J. Arkko, "Distributed
Prefix Assignment Algorithm", draft-ietf-homenet-prefix-
assignment-02 (work in progress), January 2015.
14.2. Informative references
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013. November 2013.
[RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
A., Beser, B., and J. Privat, "The User Class Option for A., Beser, B., and J. Privat, "The User Class Option for
DHCP", RFC 3004, November 2000. DHCP", RFC 3004, November 2000.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
skipping to change at page 23, line 46 skipping to change at page 27, line 24
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"IPv6 Home Networking Architecture Principles", RFC 7368, "IPv6 Home Networking Architecture Principles", RFC 7368,
October 2014. October 2014.
[I-D.troan-homenet-sadr] [RFC1035] Mockapetris, P., "Domain names - implementation and
Troan, O. and L. Colitti, "IPv6 Multihoming with Source specification", STD 13, RFC 1035, November 1987.
Address Dependent Routing (SADR)", draft-troan-homenet-
sadr-01 (work in progress), September 2013.
[I-D.baker-rtgwg-src-dst-routing-use-cases]
Baker, F., "Requirements and Use Cases for Source/
Destination Routing", draft-baker-rtgwg-src-dst-routing-
use-cases-01 (work in progress), October 2014.
[I-D.acee-ospf-ospfv3-autoconfig]
Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration",
draft-acee-ospf-ospfv3-autoconfig-03 (work in progress),
July 2012.
[I-D.barth-homenet-hncp-security-trust]
Barth, S., "HNCP - Security and Trust Management", draft-
barth-homenet-hncp-security-trust-01 (work in progress),
October 2014.
11.3. URIs
[2] http://www.openwrt.org
[3] http://www.homewrt.org/doku.php?id=run-conf
Appendix A. Some Outstanding Issues
Should we use MD5 hashes, or EUI-64 node identifier to identify
nodes?
Is there a case for non-link-local unicast? Currently explicitly
stating this is link-local only protocol.
Consider if using Trickle with k=1 really pays off, as we need to do
reachability checks if layer 2 does not provide them periodically in
any case. Using Trickle with k=inf would remove the need for unicast
reachability checks, but at cost of extra multicast traffic. On the
other hand, N*(N-1)/2 unicast reachability checks when lot of routers
share a link is not appealing either.
Valid and preferred are now 32 bit millisecond and you cannot even
represent a month in them; is this enough? Or should we switch to 32
bit seconds (or 64 bit milliseconds)?
Appendix B. Some Obvious Questions and Answers [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
Q: Why not use TCP? [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
A: It does not address the node discovery problem. It also leads to [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
N*(N-1)/2 connections when N nodes share a link, which is awkward. February 2013.
Q: Why not multicast-only? [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
A: It would require defining application level fragmentation scheme. Discovery", RFC 6763, February 2013.
Hopefully the data amounts used will stay small so we just trust
unicast UDP to handle 'big enough' packets to contain single node's
TLV data. On some link layers unicast is also much more reliable
than multicast, especially for large packets. Also on wireless,
multicast is much more power expensive than unicast.
Q: Why so long IDs? [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
A: Scalability of protocol is not really affected by using real [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
(=cryptographic) hash function. Extensions", RFC 2132, March 1997.
Q: Why trust IPv6 fragmentation in unicast case? Why not do L7 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless
fragmentation? Static Route Option for Dynamic Host Configuration
Protocol (DHCP) version 4", RFC 3442, December 2002.
A: Because it will be there for a while at least. And while PMTU et [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
al may be problems on open internet, in a home network environment Addresses", RFC 4193, October 2005.
UDP fragmentation should NOT be broken in the foreseeable future.
Q: Should there be nested container syntax that is actually self- 14.3. URIs
describing? (i.e. type flag that indicates container, no body except
sub-TLVs?)
A: Not for now, but perhaps valid design.. TBD. [3] http://www.openwrt.org
Q: Why not doing (performance thing X, Y or Z)? [4] http://www.homewrt.org/doku.php?id=run-conf
A: This is designed mostly to be minimal (only timers Trickle ones; Appendix A. Changelog
everything triggered by Trickle-driven messages or local state
changes). However, feel free to suggest better (even more minimal)
design which works.
Appendix C. Changelog draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP
(homenet profile).
draft-ietf-homenet-hncp-02: Removed any built-in security. Relying 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
languages, made manual border configuration a MUST-support. languages, made manual border configuration a MUST-support.
Redesigned routing protocol election to consider non-router devices. Redesigned routing protocol election to consider non-router devices.
draft-ietf-homenet-hncp-01: Added (MAY) guest, ad-hoc, hybrid draft-ietf-homenet-hncp-01: Added (MAY) guest, ad-hoc, hybrid
categories for interfaces. Removed old hnetv2 reference, and now categories for interfaces. Removed old hnetv2 reference, and now
pointing just to OpenWrt + github. Fixed synchronization algorithm pointing just to OpenWrt + github. Fixed synchronization algorithm
to spread also same update number, but different data hash case. to spread also same update number, but different data hash case.
Made purge step require bidirectional connectivity between nodes when Made purge step require bidirectional connectivity between nodes when
traversing the graph. Edited few other things to be hopefully traversing the graph. Edited few other things to be hopefully
slightly clearer without changing their meaning. slightly clearer without changing their meaning.
draft-ietf-homenet-hncp-00: Added version TLV to allow for TLV draft-ietf-homenet-hncp-00: Added version TLV to allow for TLV
content changes pre-RFC without changing IDs. Added link id to content changes pre-RFC without changing IDs. Added link id to
assigned address TLV. assigned address TLV.
Appendix D. Draft source Appendix B. Draft source
As usual, this draft is available at https://github.com/fingon/ietf- This draft is available at https://github.com/fingon/ietf-drafts/ in
drafts/ in source format (with nice Makefile too). Feel free to send source format. Issues and pull requests are welcome.
comments and/or pull requests if and when you have changes to it!
Appendix E. Acknowledgements Appendix C. Implementation
Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley and A GPLv2-licensed implementation of HNCP is currently under
Juliusz Chroboczek for their contributions to the draft. development at https://github.com/sbyx/hnetd/ and binaries are
available in the OpenWrt [3] package repositories. See [4] for more
information. Feedback and contributions are welcome.
Appendix D. Acknowledgements
Thanks to Ole Troan, Mark Baugher, Mark Townsley and Juliusz
Chroboczek for their contributions to the draft.
Thanks to Eric Kline for the original border discovery work. Thanks to Eric Kline for the original border discovery work.
Authors' Addresses Authors' Addresses
Markus Stenberg Markus Stenberg
Helsinki 00930 Helsinki 00930
Finland Finland
Email: markus.stenberg@iki.fi Email: markus.stenberg@iki.fi
Steven Barth Steven Barth
Halle 06114
Germany
Email: cyrus@openwrt.org Email: cyrus@openwrt.org
Pierre Pfister
Cisco Systems
Paris
France
Email: pierre.pfister@darou.fr
 End of changes. 235 change blocks. 
807 lines changed or deleted 944 lines changed or added

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