draft-ietf-homenet-hncp-04.txt   draft-ietf-homenet-hncp-05.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: September 6, 2015 Expires: December 4, 2015
P. Pfister P. Pfister
Cisco Systems Cisco Systems
March 5, 2015 June 2, 2015
Home Networking Control Protocol Home Networking Control Protocol
draft-ietf-homenet-hncp-04 draft-ietf-homenet-hncp-05
Abstract Abstract
This document describes the Home Networking Control Protocol (HNCP), This document describes the Home Networking Control Protocol (HNCP),
an extensible configuration protocol and a set of requirements for an extensible configuration protocol and a set of requirements for
home network devices on top of the Distributed Node Consensus home network devices on top of the Distributed Node Consensus
Protocol (DNCP). It enables automated configuration of addresses, Protocol (DNCP). It enables automated configuration of addresses,
naming, network borders and the seamless use of a routing protocol. naming, network borders and the seamless use of a routing protocol.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2015. This Internet-Draft will expire on December 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Adjacent Links . . . . . . . . . . . . . . . . . . . . . . . 4 4. Common Links . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Border Discovery . . . . . . . . . . . . . . . . . . . . . . 5 5. Border Discovery . . . . . . . . . . . . . . . . . . . . . . 5
6. Autonomic Address Configuration . . . . . . . . . . . . . . . 6 6. Autonomic Address Configuration . . . . . . . . . . . . . . . 6
6.1. External Connections . . . . . . . . . . . . . . . . . . 7 6.1. External Connections . . . . . . . . . . . . . . . . . . 7
6.1.1. External Connection TLV . . . . . . . . . . . . . . . 7 6.1.1. External Connection TLV . . . . . . . . . . . . . . . 7
6.1.2. Delegated Prefix TLV . . . . . . . . . . . . . . . . 7 6.1.2. Delegated Prefix TLV . . . . . . . . . . . . . . . . 7
6.1.3. DHCP Data TLVs . . . . . . . . . . . . . . . . . . . 8 6.1.3. Prefix Domain TLV . . . . . . . . . . . . . . . . . . 9
6.2. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 9 6.1.4. DHCP Data TLVs . . . . . . . . . . . . . . . . . . . 9
6.2.1. Assigned Prefix TLV . . . . . . . . . . . . . . . . . 9 6.2. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 10
6.2.2. Prefix Assignment Algorithm Parameters . . . . . . . 10 6.2.1. Assigned Prefix TLV . . . . . . . . . . . . . . . . . 10
6.2.2. Prefix Assignment Algorithm Parameters . . . . . . . 11
6.2.3. Making New Assignments . . . . . . . . . . . . . . . 12 6.2.3. Making New Assignments . . . . . . . . . . . . . . . 12
6.2.4. Applying Assignments . . . . . . . . . . . . . . . . 12 6.2.4. Applying Assignments . . . . . . . . . . . . . . . . 13
6.2.5. DHCPv6-PD Excluded Prefix Support . . . . . . . . . . 13 6.2.5. DHCPv6-PD Excluded Prefix Support . . . . . . . . . . 13
6.2.6. Downstream Prefix Delegation Support . . . . . . . . 13 6.2.6. Downstream Prefix Delegation Support . . . . . . . . 13
6.3. Node Address Assignment . . . . . . . . . . . . . . . . . 13 6.3. Node Address Assignment . . . . . . . . . . . . . . . . . 14
6.4. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 14 6.4. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 15
7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 15 7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 16
7.1. DHCPv6 for Addressing or Configuration . . . . . . . . . 15 7.1. DHCPv6 for Addressing or Configuration . . . . . . . . . 16
7.2. Sending Router Advertisements . . . . . . . . . . . . . . 16 7.2. Sending Router Advertisements . . . . . . . . . . . . . . 17
7.3. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 17 7.3. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 18
7.4. DHCPv4 for Adressing and Configuration . . . . . . . . . 17 7.4. DHCPv4 for Adressing and Configuration . . . . . . . . . 18
7.5. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 17 7.5. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 18
8. Naming and Service Discovery . . . . . . . . . . . . . . . . 18 8. Naming and Service Discovery . . . . . . . . . . . . . . . . 18
8.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 18 8.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 19
8.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 19 8.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 20
8.3. Node Name TLV . . . . . . . . . . . . . . . . . . . . . . 20 8.3. Node Name TLV . . . . . . . . . . . . . . . . . . . . . . 20
9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 20 9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 21
10. HNCP Versioning and Capabilities . . . . . . . . . . . . . . 21 10. HNCP Versioning and Capabilities . . . . . . . . . . . . . . 22
11. Requirements for HNCP Routers . . . . . . . . . . . . . . . . 22 11. Requirements for HNCP Routers . . . . . . . . . . . . . . . . 23
12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24
12.1. Border Determination . . . . . . . . . . . . . . . . . . 24 12.1. Border Determination . . . . . . . . . . . . . . . . . . 24
12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 24 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 25
12.3. Other Protocols in the Home . . . . . . . . . . . . . . 25 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 25
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.1. Normative references . . . . . . . . . . . . . . . . . . 26 14.1. Normative references . . . . . . . . . . . . . . . . . . 26
14.2. Informative references . . . . . . . . . . . . . . . . . 26 14.2. Informative references . . . . . . . . . . . . . . . . . 27
Appendix A. Some Outstanding Issues . . . . . . . . . . . . . . 28 Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 28
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 28 Appendix B. Draft source [RFC Editor: please remove] . . . . . . 29
Appendix C. Draft source . . . . . . . . . . . . . . . . . . . . 28 Appendix C. Implementation [RFC Editor: please remove] . . . . . 29
Appendix D. Implementation . . . . . . . . . . . . . . . . . . . 28 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 29
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
HNCP synchronizes state across a small site in order to allow HNCP synchronizes state across a small site in order to allow
automated network configuration. The protocol enables use of border automated network configuration. The protocol enables use of border
discovery, address prefix distribution discovery, address prefix distribution
[I-D.ietf-homenet-prefix-assignment], naming and other services [I-D.ietf-homenet-prefix-assignment], naming and other services
across multiple links. across multiple links.
skipping to change at page 3, line 37 skipping to change at page 3, line 37
3. DNCP Profile 3. DNCP Profile
HNCP is defined as a profile of DNCP [I-D.ietf-homenet-dncp] with the HNCP is defined as a profile of DNCP [I-D.ietf-homenet-dncp] with the
following parameters: following parameters:
o HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport over o HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport over
link-local scoped IPv6, using unicast and multicast (group All- link-local scoped IPv6, using unicast and multicast (group All-
Homenet-Routers). Received datagrams with an IPv6 source or Homenet-Routers). Received datagrams with an IPv6 source or
destination address which is not link-local scoped MUST be destination address which is not link-local scoped MUST be
ignored. IPv6 fragmentation and reassembly up to TBD bytes MUST ignored. Each node MUST be able to receive (and potentially
be supported by the stack of the node. reassemble) UDP datagrams with a payload of at least 4000 bytes.
o HNCP operates on multicast-capable interfaces only, thus every o HNCP operates on multicast-capable interfaces only, thus every
DNCP Connection Identifier MUST refer to one, except for the value DNCP Endpoint Identifier MUST refer to one, except for the value 0
0 which is reserved for internal purposes and MUST NOT be used for which is reserved for internal purposes and MUST NOT be used for
connection enumeration. Implementations MAY use a value endpoint enumeration. Implementations MAY use a value equivalent
equivalent to the sin6_scope_id for the given interface. to the sin6_scope_id for the given interface.
o HNCP unicast messages SHOULD be secured using DTLS [RFC6347] as o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as
described in DNCP if exchanged over unsecured links. UDP on port described in DNCP if exchanged over unsecured links. UDP on port
HNCP-DTLS-PORT is used for this purpose. A node implementing the HNCP-DTLS-PORT is used for this purpose. A node implementing the
security mechanism MUST support the DNCP Pre-Shared Key method, security mechanism MUST support the DNCP Pre-Shared Key method,
SHOULD support the DNCP Certificate Based Trust Consensus and MAY SHOULD support the DNCP Certificate Based Trust Consensus and MAY
support the PKI-based trust method. support the PKI-based trust method.
o HNCP uses opaque 32-bit node identifiers o HNCP uses opaque 32-bit node identifiers
(DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP (DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP
SHOULD generate and use a random node identifier. If it receives SHOULD generate and use a random node identifier. If it receives
a Node State TLV with the same node identifier and a higher update a Node State TLV with the same node identifier and a higher update
sequence number, it MUST immediately generate and use a new random sequence number, it MUST immediately generate and use a new random
node identifier which is not used by any other node. node identifier which is not used by any other node.
o HNCP nodes MUST treat all Long Network State Update messages o HNCP nodes MUST ignore all Node State TLVs received via multicast
received via multicast on a link which has DNCP security enabled 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.
o HNCP nodes use the following Trickle parameters: o HNCP nodes use the following Trickle parameters:
* k SHOULD be 1, given the timer reset on data updates and * k SHOULD be 1, given the timer reset on data updates and
retransmissions should handle packet loss. retransmissions should handle packet loss.
* Imin SHOULD be 200 milliseconds but MUST NOT be lower. Note: * Imin SHOULD be 200 milliseconds but MUST NOT be lower. Note:
Earliest transmissions may occur at Imin / 2. Earliest transmissions may occur at Imin / 2.
* Imax SHOULD be 7 doublings of Imin (i.e. 25.6 seconds) but MUST * Imax SHOULD be 7 doublings of Imin (i.e. 25.6 seconds) but MUST
NOT be lower. NOT be lower.
o HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP o HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP
non-cryptographic hash function H(x). non-cryptographic hash function H(x).
o HNCP nodes MUST use the keep-alive extension on all connections. o HNCP nodes MUST use the keep-alive extension on all endpoints.
The default keep-alive interval (DNCP_KEEPALIVE_INTERVAL) is 20 The default keep-alive interval (DNCP_KEEPALIVE_INTERVAL) is 20
seconds, the multiplier (DNCP_KEEPALIVE_MULTIPLIER) MUST be 2.1, seconds, the multiplier (DNCP_KEEPALIVE_MULTIPLIER) MUST be 2.1,
the grace-interval (DNCP_GRACE_INTERVAL) SHOULD be equal to the grace-interval (DNCP_GRACE_INTERVAL) SHOULD be equal to
DNCP_KEEPALIVE_MULTIPLIER times DNCP_KEEPALIVE_INTERVAL. DNCP_KEEPALIVE_MULTIPLIER times DNCP_KEEPALIVE_INTERVAL.
4. Adjacent Links 4. Common Links
HNCP uses the concept of Adjacent Links for some of its applications. HNCP uses the concept of Common Links for some of its applications.
This term is defined as follows: This term is defined as follows:
If the connection of a node is detected or configured to be an ad-hoc If the endpoint of a node is detected or configured to be an ad-hoc
interface the Adjacent Link only consists of said interface. interface the Common Link only consists of said interface.
Otherwise the Adjacent Link contains all interfaces bidirectionally Otherwise the Common Link contains all interfaces bidirectionally
reachable from a given local interface. An interface X of a node A 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 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 only if node A publishes a Neighbor TLV with the Neighbor Node
Identifier B, the Neighbor Connection Identifier Y and the Local Identifier B, the Neighbor Endpoint Identifier Y and the Local
Connection Identifier X and node B publishes a Neighbor TLV with the Endpoint Identifier X and node B publishes a Neighbor TLV with the
Neighbor Node Identifier A, a Neighbor Connection Identifier X and Neighbor Node Identifier A, a Neighbor Endpoint Identifier X and the
the Local Connection Identifier Y. In addition a node MUST be able Local Endpoint Identifier Y. In addition a node MUST be able to
to detect whether two of its local interfaces belong to the same detect whether two of its local interfaces belong to the same Common
Adjacent Link either by local means or by inferring that from the Link either by local means or by inferring that from the
bidirectional reachability between two different local interfaces and bidirectional reachability between two different local interfaces and
the same remote interface. the same remote interface.
5. Border Discovery 5. Border Discovery
HNCP associates each HNCP interface with a category (e.g., internal HNCP associates each HNCP interface with a category (e.g., internal
or external). This section defines the border discovery algorithm or external). This section defines the border discovery algorithm
derived from the edge router interactions described in the Basic derived from the edge router interactions described in the Basic
Requirements for IPv6 Customer Edge Routers [RFC7084]. This Requirements for IPv6 Customer Edge Routers [RFC7084]. This
algorithm is suitable for both IPv4 and IPv6 (single or dual-stack) algorithm is suitable for both IPv4 and IPv6 (single or dual-stack)
skipping to change at page 6, line 7 skipping to change at page 6, line 7
4. Otherwise the interface MUST be considered internal. 4. Otherwise the interface MUST be considered internal.
A router MUST allow setting a category of either auto-detected, A router MUST allow setting a category of either auto-detected,
internal or external for each interface which is suitable for both internal or external for each interface which is suitable for both
internal and external connections. In addition the following internal and external connections. In addition the following
specializations of the internal category are defined to modify the specializations of the internal category are defined to modify the
local router behavior: local router behavior:
Leaf category: This declares an interface used by client devices Leaf category: This declares an interface used by client devices
only. A router MUST consider such interface as internal but MUST only. A router MUST consider such interface as internal but MUST
NOT send nor receive HNCP messages on such interface. A router NOT send nor receive HNCP traffic on such interface. A router
SHOULD implement this category. SHOULD implement this category.
Guest category: This declares an interface used by untrusted client Guest category: This declares an interface used by untrusted client
devices only. In addition to the restrictions of the Leaf devices only. In addition to the restrictions of the Leaf
category, connected devices MUST NOT be able to reach other category, connected devices MUST NOT be able to reach other
devices inside the HNCP network nor query services advertised by devices inside the HNCP network nor query services advertised by
them unless explicitly allowed, instead they SHOULD only be able them unless explicitly allowed, instead they SHOULD only be able
to reach the internet. This category SHOULD be supported. to reach the internet. This category SHOULD be supported.
Ad-hoc category: This configures an interface to be ad-hoc Ad-hoc category: This configures an interface to be ad-hoc
skipping to change at page 8, line 39 skipping to change at page 8, line 39
Prefix Length: The number of significant bits in the Prefix. Prefix Length: The number of significant bits in the Prefix.
Prefix: Significant bits of the prefix padded with zeroes up to the Prefix: Significant bits of the prefix padded with zeroes up to the
next byte boundary. next byte boundary.
Nested TLVs: Other TLVs included in the Delegated Prefix TLV and Nested TLVs: Other TLVs included in the Delegated Prefix TLV and
starting at the next 32 bits boundary following the end of the starting at the next 32 bits boundary following the end of the
encoded prefix. encoded prefix.
Zero or more Prefix Domain TLVs. In abscence of any such TLV
the prefix is assumed to be generated by an HNCP-router and for
internal use only.
If the encoded prefix represents an IPv6 prefix, at most one If the encoded prefix represents an IPv6 prefix, at most one
DHCPv6 Data TLV MAY be included. DHCPv6 Data TLV MAY be included.
If the encoded prefix represents an IPv4-mapped IPv6 address, If the encoded prefix represents an IPv4-mapped IPv6 address,
at most one DHCPv4 Data TLV MAY be included. at most one DHCPv4 Data TLV MAY be included.
It MAY contain other TLVs for future use. It MAY contain other TLVs for future use.
6.1.3. DHCP Data TLVs 6.1.3. Prefix Domain TLV
The Prefix Domain TLV contains information about the origin and
applicability of a delegated prefix. This information can be used to
determine whether prefixes for a certain domain (e.g. local
reachability, internet connectivity) do exist or should be acquired
and to make decisions about assigning prefixes to certain links or
fine-tuning border firewalls.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: PREFIX-DOMAIN (43) | Length: >= 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Type | |
+-+-+-+-+-+-+-+-+ Domain ID +
| |
Domain Type: The type of the domain identifier.
0 : Internet connectivity (domain ID is empty)
1-128 : Explicit destination with given length (domain ID
contains significant bits of the destination prefix padded with
zeroes up to the next byte boundary.)
129 : Null-terminated UTF-8 String (e.g. FQDN)
130-255: reserved for future additions
Domain Identifier: A variable length identifier of the given type.
6.1.4. DHCP Data TLVs
Auxiliary connectivity information is encoded as a stream of DHCP Auxiliary connectivity information is encoded as a stream of DHCP
options. Such TLVs MUST only be present in an External Connection options. Such TLVs MUST only be present in an External Connection
TLV or a Delegated Prefix TLV. When included in an External TLV or a Delegated Prefix TLV. When included in an External
Connection TLV, they MUST contain DHCP options which are relevant to Connection TLV, they MUST contain DHCP options which are relevant to
the whole External Connection. When included in a Delegated Prefix, the whole External Connection. When included in a Delegated Prefix,
they MUST contain DHCP options which are specific to the Delegated they MUST contain DHCP options which are specific to the Delegated
Prefix. Prefix.
The DHCPv6 Data TLV uses the following format: The DHCPv6 Data TLV uses the following format:
skipping to change at page 10, line 10 skipping to change at page 10, line 43
6.2.1. Assigned Prefix TLV 6.2.1. Assigned Prefix TLV
Published Assigned Prefixes MUST be advertised using the Assigned Published Assigned Prefixes MUST be advertised using the Assigned
Prefix TLV: Prefix TLV:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: ASSIGNED-PREFIX (35) | Length: >= 6 | | Type: ASSIGNED-PREFIX (35) | Length: >= 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection Identifier | | Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsv. | Prty. | Prefix Length | | | Rsv. | Prty. | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +
| | | |
Connection Identifier: The DNCP Connection Identifier of the link Endpoint Identifier: The DNCP Endpoint Identifier of the link the
the prefix is assigned to, or 0 if the link is a Private Link. prefix is assigned to, or 0 if the link is a Private Link.
Rsv.: Bits reserved for future use. MUST be set to zero when Rsv.: Bits reserved for future use. MUST be set to zero when
creating this TLV and ignored when parsing it. creating this TLV and ignored when parsing it.
Prty: The Advertised Prefix Priority from 0 to 15. Prty: The Advertised Prefix Priority from 0 to 15.
0-1 : Low priorities. 0-1 : Low priorities.
2 : Default priority. 2 : Default priority.
skipping to change at page 11, line 30 skipping to change at page 12, line 16
Set of Advertised Prefixes: The set of prefixes included in Set of Advertised Prefixes: The set of prefixes included in
Assigned Prefix TLVs advertised by other HNCP routers. The Assigned Prefix TLVs advertised by other HNCP routers. The
associated Advertised Prefix Priority is the priority specified in associated Advertised Prefix Priority is the priority specified in
the TLV. The associated Shared Link is determined as follows: the TLV. The associated Shared Link is determined as follows:
* If the Link Identifier is zero, the Advertised Prefix is not * If the Link Identifier is zero, the Advertised Prefix is not
assigned on a Shared Link. assigned on a Shared Link.
* If the Link Identifier is not zero the Shared Link is equal to * If the Link Identifier is not zero the Shared Link is equal to
the Adjacent Link (Section 4). Advertised Prefixes as well as the Common Link (Section 4). Advertised Prefixes as well as
their associated priorities and associated Shared Links MUST be their associated priorities and associated Shared Links MUST be
updated as Assigned Prefix TLVs or Neighbor TLVs are added, updated as Assigned Prefix TLVs or Neighbor TLVs are added,
removed or updated. removed or updated.
ADOPT_MAX_DELAY: The default value is 0 seconds (i.e. prefix ADOPT_MAX_DELAY: The default value is 0 seconds (i.e. prefix
adoption MAY be done instantly). adoption MAY be done instantly).
BACKOFF_MAX_DELAY: The default value is 4 seconds. BACKOFF_MAX_DELAY: The default value is 4 seconds.
RANDOM_SET_SIZE: The default value is 64. RANDOM_SET_SIZE: The default value is 64.
Flooding Delay: The default value is 5 seconds. Flooding Delay: The default value is 5 seconds.
Default Advertised Prefix Priority: When a new assignment is Default Advertised Prefix Priority: When a new assignment is
created or an assignment is adopted - as specified in the prefix created or an assignment is adopted - as specified in the prefix
assignment algorithm routine - the default Advertised Prefix assignment algorithm routine - the default Advertised Prefix
Priority to be used is 2. Priority to be used is 2.
6.2.3. Making New Assignments 6.2.3. Making New Assignments
Whenever the Prefix Assignment Algorithm routine is run on an Whenever the Prefix Assignment Algorithm routine is run on an Common
Adjacent Link and whenever a new prefix may be assigned (case 1 of Link and whenever a new prefix may be assigned (case 1 of the
the routine), the decision of whether the assignment of a new prefix routine), the decision of whether the assignment of a new prefix is
is desired MUST follow these rules: desired MUST follow these rules:
If the Delegated Prefix TLV contains a DHCPv4 or DHCPv6 Data TLV, If the Delegated Prefix TLV contains a DHCPv4 or DHCPv6 Data TLV,
and the meaning of one of the DHCP options is not understood by and the meaning of one of the DHCP options is not understood by
the HNCP router, the creation of a new prefix is not desired. the HNCP router, the creation of a new prefix is not desired.
If the remaining preferred lifetime of the prefix is 0 and there If the remaining preferred lifetime of the prefix is 0 and there
is another delegated prefix of the same IP version used for prefix is another delegated prefix of the same IP version used for prefix
assignment with a non-null preferred lifetime, the creation of a assignment with a non-null preferred lifetime, the creation of a
new prefix is not desired. new prefix is not desired.
skipping to change at page 12, line 43 skipping to change at page 13, line 25
In any case, a router MUST support a mechanism suitable to distribute In any case, a router MUST support a mechanism suitable to distribute
addresses from the considered prefix to clients on the link. addresses from the considered prefix to clients on the link.
Otherwise it MUST NOT create or adopt it, i.e. a router assigning an Otherwise it MUST NOT create or adopt it, i.e. a router assigning an
IPv4 prefix MUST support the L-capability and a router assigning an IPv4 prefix MUST support the L-capability and a router assigning an
IPv6 prefix not suitable for stateless autoconfiguration MUST support IPv6 prefix not suitable for stateless autoconfiguration MUST support
the H-capability as defined in Section 10. the H-capability as defined in Section 10.
6.2.4. Applying Assignments 6.2.4. Applying Assignments
The prefix assignment algorithm indicates when a prefix is applied to The prefix assignment algorithm indicates when a prefix is applied to
the respective Adjacent Link. When that happens each router the respective Common Link. When that happens each router connected
connected to said link: to said link:
MUST create an appropriate on-link route for said prefix and MUST create an appropriate on-link route for said prefix and
advertise it using the chosen routing protocol. advertise it using the chosen routing protocol.
MUST participate in the client configuration election as described MUST participate in the client configuration election as described
in Section 7. in Section 7.
MAY add an address from said prefix to the respective network MAY add an address from said prefix to the respective network
interface as described in Section 6.3. interface as described in Section 6.3.
skipping to change at page 13, line 42 skipping to change at page 14, line 23
processed requests. processed requests.
6.3. Node Address Assignment 6.3. Node Address Assignment
This section specifies how HNCP nodes reserve addresses for their own This section specifies how HNCP nodes reserve addresses for their own
use. Nodes MAY, at any time, try to reserve a new address. SLAAC use. Nodes MAY, at any time, try to reserve a new address. SLAAC
SHOULD be used whenever possible. The following method MUST be used SHOULD be used whenever possible. The following method MUST be used
otherwise. otherwise.
For any IPv6 prefix longer than 64 bits (resp. any IPv4 prefix) For any IPv6 prefix longer than 64 bits (resp. any IPv4 prefix)
assigned to an Adjacent Link, the first quarter of the addresses are assigned to a Common Link, the first quarter of the addresses are
reserved for routers HNCP based assignments, whereas the last three reserved for routers HNCP based assignments, whereas the last three
quarters are left to the DHCPv6 (resp. DHCPv4) elected router quarters are left to the DHCPv6 (resp. DHCPv4) elected router
(Section 10 specifies the DHCP server election process). For (Section 10 specifies the DHCP server election process). For
instance, if the prefix 192.0.2.0/24 is assigned and applied to an instance, if the prefix 192.0.2.0/24 is assigned and applied to a
Adjacent Link, addresses included in 192.0.2.0/26 are reserved for Common Link, addresses included in 192.0.2.0/26 are reserved for HNCP
HNCP nodes and the remaining addresses are reserved for the elected nodes and the remaining addresses are reserved for the elected DHCPv4
DHCPv4 server. server.
HNCP routers assign themselves addresses using the Node Address TLV: HNCP routers assign themselves addresses using the Node Address TLV:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: NODE-ADDRESS (36) | Length: 20 | | Type: NODE-ADDRESS (36) | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection Identifier | | Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IP Address | | IP Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Connection Identifier: The DNCP Connection Identifier of the link Endpoint Identifier: The DNCP Endpoint Identifier of the link the
the address is assigned to, or 0 if it is not assigned on an HNCP address is assigned to, or 0 if it is not assigned on an HNCP
enabled link. enabled link.
IP Address: The IPv6 address, or the IPv4 address encoded as an IP Address: The globally scoped IPv6 address, or the IPv4 address
IPv4-mapped IPv6 address [RFC4291]. encoded as an IPv4-mapped IPv6 address [RFC4291].
The process of obtaining addresses is specified as follows: The process of obtaining addresses is specified as follows:
o A router MUST NOT start advertising an address if it is already o A router MUST NOT start advertising an address if it is already
advertised by another router. advertised by another router.
o An assigned address MUST be in the first quarter of an assigned o An assigned address MUST be in the first quarter of an assigned
prefix currently applied on the specified link. prefix currently applied on the specified link.
o An address MUST NOT be used unless it has been advertised for at o An address MUST NOT be used unless it has been advertised for at
skipping to change at page 14, line 50 skipping to change at page 15, line 33
identifier MUST be removed. identifier MUST be removed.
6.4. Local IPv4 and ULA Prefixes 6.4. Local IPv4 and ULA Prefixes
HNCP routers can create an ULA or private IPv4 prefix to enable HNCP routers can create an ULA or private IPv4 prefix to enable
connectivity between local devices. These prefixes are inserted in connectivity between local devices. These prefixes are inserted in
HNCP as if they were delegated prefixes. The following rules apply: HNCP as if they were delegated prefixes. The following rules apply:
An HNCP router SHOULD create an ULA prefix if there is no other An HNCP router SHOULD create an ULA prefix if there is no other
non-deprecated IPv6 prefix in the network. It MAY also do so if non-deprecated IPv6 prefix in the network. It MAY also do so if
there are other delegated IPv6 prefixes but none of which is a there are other delegated IPv6 prefixes but none of which is
non-deprecated ULA but MUST NOT do so otherwise. Whenever it generated by an HNCP router (i.e. not delegated by an external
detects another non-deprecated ULA being advertised it MUST cease entity) but MUST NOT do so otherwise. Whenever it detects another
to announce its locally generated one. It MAY also do so once it non-deprecated IPv6 prefix generated by an HNCP router it MUST
detects a non-deprecated non-ULA IPv6 delegated prefix. cease to announce its own locally generated one.
An HNCP router MUST create a non-deprecated private IPv4 prefix An HNCP router MUST create a private IPv4 prefix [RFC1918]
[RFC1918] whenever it wishes to provide external IPv4 connectivity whenever it wishes to provide IPv4 internet connectivity to the
to the network and no other non-deprecated private IPv4 prefix network and no other private IPv4 prefix with internet
currently exists. It MAY also create a deprecated private IPv4 connectivity currently exists. It MAY also enable local IPv4
prefix if no IPv4 prefix exists and it wants to enable local IPv4 connectivity by creating a private IPv4 prefix if no IPv4 prefix
connectivity but MUST NOT do so otherwise. In case multiple IPv4 exists but MUST NOT do so otherwise. In case multiple IPv4
prefixes are announced all but one MUST be removed while non- prefixes are announced all but one MUST be removed while those
deprecated ones take precedence over deprecated ones and with internet connectivity take precedence over those without and
announcements by nodes with a higher node identifier take announcements by nodes with a higher node identifier take
precedence over those with a lower one. The router publishing the precedence over those with a lower one. The router publishing a
non-deprecated prefix MUST announce an IPv4 default route using prefix with internet connectivity MUST announce an IPv4 default
the routing protocol and perform NAT on behalf of the network as route using the routing protocol and perform NAT on behalf of the
long as it publishes the prefix, other routers in the network MUST network as long as it publishes the prefix, other routers in the
NOT. network MAY choose not to. Internet Connectivity is indicated
using a Prefix Domain TLV.
Creation of such ULA and IPv4 prefixes MUST be delayed by a random Creation of such ULA and IPv4 prefixes MUST be delayed by a random
timespan between 0 and 10 seconds in which the router MUST scan for timespan between 0 and 10 seconds in which the router MUST scan for
other nodes trying to do the same. other nodes trying to do the same.
When a new ULA prefix is created, the prefix is selected based on the When a new ULA prefix is created, the prefix is selected based on the
configuration, using the last non-deprecated ULA prefix, or generated configuration, using the last non-deprecated ULA prefix, or generated
based on [RFC4193]. based on [RFC4193].
7. Configuration of Hosts and non-HNCP Routers 7. Configuration of Hosts and non-HNCP Routers
skipping to change at page 16, line 4 skipping to change at page 16, line 37
7.1. DHCPv6 for Addressing or Configuration 7.1. DHCPv6 for Addressing or Configuration
In general stateless address configuration is preferred whenever In general stateless address configuration is preferred whenever
possible since it enables fast renumbering and low overhead, however possible since it enables fast renumbering and low overhead, however
stateful DHCPv6 can be useful in addition to collect hostnames and stateful DHCPv6 can be useful in addition to collect hostnames and
use them to provide naming services or if stateless configuration is use them to provide naming services or if stateless configuration is
not possible for the assigned prefix length. not possible for the assigned prefix length.
The designated stateful DHCPv6 server for a link is elected based on The designated stateful DHCPv6 server for a link is elected based on
the capabilities described in Section 10. The winner is the router the capabilities described in Section 10. The winner is the router
connected to the Adjacent Link (Section 4) advertising the greatest connected to the Common Link (Section 4) advertising the greatest
H-capability. In case of a tie, Capability Values and node H-capability. In case of a tie, Capability Values and node
identifiers are considered (greatest value is elected). The elected identifiers are considered (greatest value is elected). The elected
router MUST serve stateful DHCPv6 and Router Advertisements on the router MUST serve stateful DHCPv6 and Router Advertisements on the
given link. Furthermore it MUST provide naming services for acquired given link. Furthermore it MUST provide naming services for acquired
hostnames as outlined in Section 8. Stateful addresses being handed hostnames as outlined in Section 8. Stateful addresses being handed
out SHOULD have a low preferred lifetime (e.g. 1s) to not hinder fast 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 renumbering if either the DHCPv6 server or client do not support the
DHCPv6 reconfigure mechanism and the address is from a prefix for DHCPv6 reconfigure mechanism and the address is from a prefix for
which stateless autoconfiguration is supported as well. In case no which stateless autoconfiguration is supported as well. In case no
router was elected, stateful DHCPv6 is not provided and each router router was elected, stateful DHCPv6 is not provided and each router
skipping to change at page 17, line 22 skipping to change at page 18, line 9
network with the respective destination. network with the respective destination.
Every router sending Router Advertisements MUST immediately send an Every router sending Router Advertisements MUST immediately send an
updated Router Advertisement via multicast as soon as it notices a updated Router Advertisement via multicast as soon as it notices a
condition resulting in a change of any advertised information. condition resulting in a change of any advertised information.
7.3. DHCPv6 for Prefix Delegation 7.3. DHCPv6 for Prefix Delegation
The designated DHCPv6 server for prefix-delegation on a link is The designated DHCPv6 server for prefix-delegation on a link is
elected based on the capabilities described in Section 10. The elected based on the capabilities described in Section 10. The
winner is the router connected to the Adjacent Link (Section 4) winner is the router connected to the Common Link (Section 4)
advertising the greatest P-capability. In case of a tie, Capability advertising the greatest P-capability. In case of a tie, Capability
Values and Node Identifiers are considered (greatest value is Values and Node Identifiers are considered (greatest value is
elected). The elected router MUST provide prefix-delegation services elected). The elected router MUST provide prefix-delegation services
[RFC3633] on the given link and follow the rules in Section 6.2.6. [RFC3633] on the given link and follow the rules in Section 6.2.6.
7.4. DHCPv4 for Adressing and Configuration 7.4. DHCPv4 for Adressing and Configuration
The designated DHCPv4 server on a link is elected based on the The designated DHCPv4 server on a link is elected based on the
capabilities described in Section 10. The winner is the router capabilities described in Section 10. The winner is the router
connected to the Adjacent Link (Section 4) advertising the greatest connected to the Common Link (Section 4) advertising the greatest
L-capability. In case of a tie, Capability Values and node L-capability. In case of a tie, Capability Values and node
identifiers are considered (greatest value is elected). The elected identifiers are considered (greatest value is elected). The elected
router MUST provide DHCPv4 services on the given link. router MUST provide DHCPv4 services on the given link.
The DHCPv4 serving router MUST announce itself as router [RFC2132] to The DHCPv4 serving router MUST announce itself as router [RFC2132] to
clients if and only if there is an IPv4 default route known in the clients if and only if there is an IPv4 default route known in the
network. In addition the router SHOULD announce a Classless Static network. In addition the router SHOULD announce a Classless Static
Route Option [RFC3442] for each non-default IPv4 route advertised in Route Option [RFC3442] for each non-default IPv4 route advertised in
the routing protocol with an external destination. the routing protocol with an external destination.
skipping to change at page 18, line 15 skipping to change at page 18, line 50
described in Section 8. described in Section 8.
8. Naming and Service Discovery 8. Naming and Service Discovery
Network-wide naming and service discovery can greatly improve the Network-wide naming and service discovery can greatly improve the
user-friendliness of an IPv6 network. The following mechanism user-friendliness of an IPv6 network. The following mechanism
provides means to setup and delegate naming and service discovery provides means to setup and delegate naming and service discovery
across multiple HNCP routers. across multiple HNCP routers.
Each HNCP router SHOULD provide and announce an auto-generated or Each HNCP router SHOULD provide and announce an auto-generated or
user-configured name for each internal Adjacent Link (Section 4) for user-configured name for each internal Common Link (Section 4) for
which it is the designated DHCPv4, stateful DHCPv6 server or MDNS which it is the designated DHCPv4, stateful DHCPv6 server or MDNS
[RFC6762]-proxy and for which it provides DNS-services on behalf of [RFC6762]-proxy and for which it provides DNS-services on behalf of
devices on said link. In addition it MAY provide reverse lookup devices on said link. In addition it MAY provide reverse lookup
services. services.
The following TLVs are defined and MUST be supported by all nodes The following TLVs are defined and MUST be supported by all nodes
implementing naming and service discovery: implementing naming and service discovery:
8.1. DNS Delegated Zone TLV 8.1. DNS Delegated Zone TLV
skipping to change at page 23, line 8 skipping to change at page 23, line 38
o It MUST implement HNCP-Versioning, Border Discovery, Prefix o It MUST implement HNCP-Versioning, Border Discovery, Prefix
Assignment and Configuration of hosts and non-HNCP routers as Assignment and Configuration of hosts and non-HNCP routers as
defined in this document. defined in this document.
o It MUST implement and run the method for securing third-party o It MUST implement and run the method for securing third-party
protocols whenever it uses the security mechanism of HNCP. protocols whenever it uses the security mechanism of HNCP.
o It SHOULD implement support for the Service Discovery and Naming o It SHOULD implement support for the Service Discovery and Naming
TLVs as defined in this document. TLVs as defined in this document.
o It MUST implement and run the routing protocol $FOO with support o It MUST implement and run a routing protocol appropriate for the
for source-specific routes on all of the interfaces it sends and given link type and with support for source-specific routes on all
receives HNCP-messages on and MUST resort to announcing source- of the interfaces it sends and receives HNCP traffic on and MUST
specific routes for external destinations appropriately. resort to announcing source-specific routes for external
destinations appropriately.
o It MUST use adequate security mechanisms for the routing protocol o It MUST use adequate security mechanisms for the routing protocol
on any interface where it also uses the security mechanisms of on any interface where it also uses the security mechanisms of
HNCP. If the security mechanism is based on a PSK it MUST use a HNCP. If the security mechanism is based on a PSK it MUST use a
PSK derived from the Managed-PSK to secure the IGP. PSK derived from the Managed-PSK to secure the IGP.
o It MUST comply with the Basic Requirements for IPv6 Customer Edge o It MUST comply with the Basic Requirements for IPv6 Customer Edge
Routers [RFC7084] unless it would otherwise conflict with any Routers [RFC7084] unless it would otherwise conflict with any
requirements in this document (e.g. prefix assignment mandating a requirements in this document (e.g. prefix assignment mandating a
different prefix delegation and DHCP server election strategy). different prefix delegation and DHCP server election strategy).
skipping to change at page 23, line 50 skipping to change at page 24, line 33
[RFC7368]. The protocols used to set up addresses and routes in such [RFC7368]. The protocols used to set up addresses and routes in such
networks to this day rarely have security enabled within the networks to this day rarely have security enabled within the
configuration protocol itself. However these issues are out of scope configuration protocol itself. However these issues are out of scope
for the security of HNCP itself. for the security of HNCP itself.
HNCP is a DNCP [I-D.ietf-homenet-dncp]-based state synchronization HNCP is a DNCP [I-D.ietf-homenet-dncp]-based state synchronization
mechanism carrying information with varying threat potential. For mechanism carrying information with varying threat potential. For
this consideration the payloads defined in DNCP and this document are this consideration the payloads defined in DNCP and this document are
reviewed: reviewed:
o Network topology information such as HNCP nodes and their adjacent o Network topology information such as HNCP nodes and their common
links links
o Address assignment information such as delegated and assigned o Address assignment information such as delegated and assigned
prefixes for individual links prefixes for individual links
o Naming and service discovery information such as auto-generated or o Naming and service discovery information such as auto-generated or
customized names for individual links and routers customized names for individual links and routers
12.1. Border Determination 12.1. Border Determination
skipping to change at page 26, line 15 skipping to change at page 26, line 47
HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP- HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP-
DTLS-PORT, as well as an IPv6 link-local multicast address All- DTLS-PORT, as well as an IPv6 link-local multicast address All-
Homenet-Routers. Homenet-Routers.
14. References 14. References
14.1. Normative references 14.1. Normative references
[I-D.ietf-homenet-dncp] [I-D.ietf-homenet-dncp]
Stenberg, M. and S. Barth, "Distributed Node Consensus Stenberg, M. and S. Barth, "Distributed Node Consensus
Protocol", draft-ietf-homenet-dncp-01 (work in progress), Protocol", draft-ietf-homenet-dncp-04 (work in progress),
March 2015. June 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012. Delegation", RFC 6603, May 2012.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[I-D.ietf-homenet-prefix-assignment] [I-D.ietf-homenet-prefix-assignment]
Pfister, P., Paterson, B., and J. Arkko, "Distributed Pfister, P., Paterson, B., and J. Arkko, "Distributed
Prefix Assignment Algorithm", draft-ietf-homenet-prefix- Prefix Assignment Algorithm", draft-ietf-homenet-prefix-
assignment-03 (work in progress), February 2015. assignment-06 (work in progress), May 2015.
14.2. Informative references 14.2. Informative references
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013. November 2013.
[RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
A., Beser, B., and J. Privat, "The User Class Option for A., Beser, B., and J. Privat, "The User Class Option for
DHCP", RFC 3004, November 2000. DHCP", RFC 3004, November 2000.
skipping to change at page 28, line 11 skipping to change at page 28, line 44
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
14.3. URIs 14.3. URIs
[3] http://www.openwrt.org [3] http://www.openwrt.org
[4] http://www.homewrt.org/doku.php?id=run-conf [4] http://www.homewrt.org/doku.php?id=run-conf
Appendix A. Some Outstanding Issues Appendix A. Changelog [RFC Editor: please remove]
Should we define in-protocol fragmentation scheme or just use IPv6
fragmentation with 'big enough' minimum acceptable size allowed for
implementations? In the same sense should we use TCP over UDP?
How should we deal with stub-routers requiring reduced complexity draft-ietf-homenet-hncp-05: Renamed "Adjacent Link" to "Common Link".
versions? Stub IGPs? An HNCP-based solution? Even a stub-HNCP? Changed single IPv4 uplink election from MUST to MAY. Added explicit
indication to distinguish (IPv4)-PDs for local connectivity and ones
with uplink connectivity allowing e.g. better local-only
IPv4-connectivity.
Appendix B. Changelog draft-ietf-homenet-hncp-04: Change the responsibility for sending RAs
to the router assigning the prefix.
draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP
(homenet profile). (homenet profile).
draft-ietf-homenet-hncp-02: Removed any built-in security. Relying draft-ietf-homenet-hncp-02: Removed any built-in security. Relying
on IPsec. Reorganized interface categories, added requirements on IPsec. Reorganized interface categories, added requirements
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
skipping to change at page 28, line 42 skipping to change at page 29, line 28
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 C. Draft source Appendix B. Draft source [RFC Editor: please remove]
This draft is available at https://github.com/fingon/ietf-drafts/ in This draft is available at https://github.com/fingon/ietf-drafts/ in
source format. Issues and pull requests are welcome. source format. Issues and pull requests are welcome.
Appendix D. Implementation Appendix C. Implementation [RFC Editor: please remove]
A GPLv2-licensed implementation of HNCP is currently under A GPLv2-licensed implementation of HNCP is currently under
development at https://github.com/sbyx/hnetd/ and binaries are development at https://github.com/sbyx/hnetd/ and binaries are
available in the OpenWrt [3] package repositories. See [4] for more available in the OpenWrt [3] package repositories. See [4] for more
information. Feedback and contributions are welcome. information. Feedback and contributions are welcome.
Appendix E. Acknowledgements Appendix D. Acknowledgements
Thanks to Ole Troan, Mark Baugher, Mark Townsley and Juliusz Thanks to Ole Troan, Mark Baugher, Mark Townsley and Juliusz
Chroboczek for their contributions to the draft. 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 Halle 06114
Germany Germany
 End of changes. 54 change blocks. 
119 lines changed or deleted 154 lines changed or added

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