draft-ietf-homenet-hncp-06.txt   draft-ietf-homenet-hncp-07.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: December 19, 2015 Expires: January 6, 2016
P. Pfister P. Pfister
Cisco Systems Cisco Systems
June 17, 2015 July 5, 2015
Home Networking Control Protocol Home Networking Control Protocol
draft-ietf-homenet-hncp-06 draft-ietf-homenet-hncp-07
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 December 19, 2015. This Internet-Draft will expire on January 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
6.1.1. External Connection TLV . . . . . . . . . . . . . . . 7 6.1.1. External Connection TLV . . . . . . . . . . . . . . . 7
6.1.2. Delegated Prefix TLV . . . . . . . . . . . . . . . . 8 6.1.2. Delegated Prefix TLV . . . . . . . . . . . . . . . . 8
6.1.3. Prefix Domain TLV . . . . . . . . . . . . . . . . . . 9 6.1.3. Prefix Domain TLV . . . . . . . . . . . . . . . . . . 9
6.1.4. DHCP Data TLVs . . . . . . . . . . . . . . . . . . . 10 6.1.4. DHCP Data TLVs . . . . . . . . . . . . . . . . . . . 10
6.2. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 11 6.2. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 11
6.2.1. Prefix Assignment Algorithm Parameters . . . . . . . 11 6.2.1. Prefix Assignment Algorithm Parameters . . . . . . . 11
6.2.2. Assigned Prefix TLV . . . . . . . . . . . . . . . . . 12 6.2.2. Assigned Prefix TLV . . . . . . . . . . . . . . . . . 12
6.2.3. Making New Assignments . . . . . . . . . . . . . . . 13 6.2.3. Making New Assignments . . . . . . . . . . . . . . . 13
6.2.4. Applying Assignments . . . . . . . . . . . . . . . . 14 6.2.4. Applying Assignments . . . . . . . . . . . . . . . . 14
6.2.5. DHCPv6-PD Excluded Prefix Support . . . . . . . . . . 14 6.2.5. DHCPv6-PD Excluded Prefix Support . . . . . . . . . . 14
6.2.6. Downstream Prefix Delegation Support . . . . . . . . 14 6.2.6. Downstream Prefix Delegation Support . . . . . . . . 15
6.3. Node Address Assignment . . . . . . . . . . . . . . . . . 15 6.3. Node Address Assignment . . . . . . . . . . . . . . . . . 15
6.4. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 16 6.4. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 16
7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 17 6.5. Special Purpose Prefixes . . . . . . . . . . . . . . . . 17
7.1. DHCPv6 for Addressing or Configuration . . . . . . . . . 17 7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 18
7.2. Sending Router Advertisements . . . . . . . . . . . . . . 17 7.1. DHCPv6 for Addressing or Configuration . . . . . . . . . 18
7.3. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 18 7.2. Sending Router Advertisements . . . . . . . . . . . . . . 19
7.4. DHCPv4 for Addressing and Configuration . . . . . . . . . 18 7.3. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 19
7.5. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 19 7.4. DHCPv4 for Addressing and Configuration . . . . . . . . . 20
8. Naming and Service Discovery . . . . . . . . . . . . . . . . 19 7.5. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 20
8.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 19 8. Naming and Service Discovery . . . . . . . . . . . . . . . . 20
8.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 21 8.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 21
8.3. Node Name TLV . . . . . . . . . . . . . . . . . . . . . . 21 8.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 22
9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 22 8.3. Node Name TLV . . . . . . . . . . . . . . . . . . . . . . 23
10. HNCP Versioning and Capabilities . . . . . . . . . . . . . . 22 9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 23
11. Requirements for HNCP Routers . . . . . . . . . . . . . . . . 24 10. HNCP Versioning and Capabilities . . . . . . . . . . . . . . 24
12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 11. Requirements for HNCP Routers . . . . . . . . . . . . . . . . 25
12.1. Border Determination . . . . . . . . . . . . . . . . . . 25 12. Security Considerations . . . . . . . . . . . . . . . . . . . 27
12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 26 12.1. Border Determination . . . . . . . . . . . . . . . . . . 27
12.3. Other Protocols in the Home . . . . . . . . . . . . . . 26 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 28
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
14.1. Normative references . . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
14.2. Informative references . . . . . . . . . . . . . . . . . 28 14.1. Normative references . . . . . . . . . . . . . . . . . . 29
Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 29 14.2. Informative references . . . . . . . . . . . . . . . . . 30
Appendix B. Draft source [RFC Editor: please remove] . . . . . . 30
Appendix C. Implementation [RFC Editor: please remove] . . . . . 30 Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 31
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 30 Appendix B. Draft source [RFC Editor: please remove] . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Appendix C. Implementation [RFC Editor: please remove] . . . . . 32
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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.
HNCP provides enough information for a routing protocol to operate HNCP provides enough information for a routing protocol to operate
without homenet-specific extensions. In homenet environments where without homenet-specific extensions. In homenet environments where
multiple IPv6 source-prefixes can be present, routing based on source multiple IPv6 source-prefixes can be present, routing based on source
and destination address is necessary [RFC7368]. and destination address is necessary [RFC7368].
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
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 (All-Homenet- link-local scoped IPv6, using unicast and multicast (All-Homenet-
Routers is the HNCP group address). Received datagrams with an Routers is the HNCP group address). Received datagrams with an
IPv6 source or destination address which is not link-local scoped IPv6 source or destination address which is not link-local scoped
MUST be ignored. Each node MUST be able to receive (and MUST be ignored. Unicast replies to multicast and unicast
messages MUST be sent to the IPv6 source address and port of the
original message. Each node MUST be able to receive (and
potentially reassemble) UDP datagrams with a payload of at least potentially reassemble) UDP datagrams with a payload of at least
4000 bytes. 4000 bytes.
o HNCP operates on multicast-capable interfaces only. HNCP routers o HNCP operates on multicast-capable interfaces only. HNCP routers
MUST assign a unique 32-bit endpoint identifier to each interface MUST assign a unique 32-bit endpoint identifier to each interface
for which HNCP is enabled. The value zero is reserved for for which HNCP is enabled. The value zero is reserved for
internal purposes. Implementations MAY use a value equivalent to internal purposes. Implementations MAY use a value equivalent to
the sin6_scope_id for the given interface. the sin6_scope_id for the given interface.
o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as
skipping to change at page 4, line 32 skipping to change at page 4, line 37
* 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 DNCP's keep-alive extension on all endpoints o HNCP nodes MUST use DNCP's keep-alive extension on all endpoints.
with the following parameters: The following parameters are suggested:
* The default keep-alive interval (DNCP_KEEPALIVE_INTERVAL) is 20 * Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20
seconds. seconds.
* The multiplier (DNCP_KEEPALIVE_MULTIPLIER) MUST be 2.1. * Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1.
* The grace-interval (DNCP_GRACE_INTERVAL) SHOULD be equal to
DNCP_KEEPALIVE_MULTIPLIER times DNCP_KEEPALIVE_INTERVAL.
4. Common Links 4. Common Links
HNCP uses the concept of Common Links for some of its applications. HNCP uses the concept of Common Links for some of its applications.
The Common Link is computed separately for each local interface, and A Common Link usually refers to a link layer broadcast domain with
it always contains the local interface. Additionally, if the local certain properties and is used, e.g., to determine where prefixes
interface is not in ad-hoc mode, it also contains the set of should be assigned or which neighboring nodes participate in the
interfaces that are bidirectionally reachable from the given local election of a DHCP(v6) server. The Common Link is computed
interface, i.e. every remote interface of a remote node meeting all separately for each local interface, and it always contains the local
of the following requirements: interface. Additionally, if the local interface is not in ad-hoc
mode, it also contains the set of interfaces that are bidirectionally
reachable from the given local interface, i.e. every remote interface
of a remote node meeting all of the following requirements:
o The local node publishes a Neighbor TLV with: o The local node publishes a Neighbor TLV with:
* Neighbor Node Identifier = remote node's node identifier * Neighbor Node Identifier = remote node's node identifier
* Neighbor Endpoint Identifier = remote interface's endpoint * Neighbor Endpoint Identifier = remote interface's endpoint
identifier identifier
* Endpoint Identifier = local interface's endpoint identifier * Endpoint Identifier = local interface's endpoint identifier
skipping to change at page 7, line 25 skipping to change at page 7, line 30
sections of this draft if the interface appears to be connected to an sections of this draft if the interface appears to be connected to an
external network. external network.
6. Autonomic Address Configuration 6. Autonomic Address Configuration
This section specifies how HNCP routers configure host and router This section specifies how HNCP routers configure host and router
addresses. At first border routers share information obtained from addresses. At first border routers share information obtained from
service providers or local configuration by publishing one or more service providers or local configuration by publishing one or more
External Connection TLVs. These contain other TLVs such as Delegated External Connection TLVs. These contain other TLVs such as Delegated
Prefix TLVs which are then used for prefix assignment. Finally, HNCP Prefix TLVs which are then used for prefix assignment. Finally, HNCP
routers obtain addresses using a stateless (SLAAC-like) procedure or routers obtain addresses either statelessly or using a specific
a specific stateful mechanism and hosts and legacy routers are stateful mechanism and hosts and legacy routers are configured using
configured using SLAAC or DHCP. SLAAC or DHCP.
In all TLVs specified in this section which include a prefix, IPv4 In all TLVs specified in this section which include a prefix, IPv4
prefixes are encoded using the IPv4-mapped IPv6 addresses format prefixes are encoded using the IPv4-mapped IPv6 addresses format
[RFC4291]. The prefix length of such IPv4 prefix is set to 96 plus [RFC4291]. The prefix length of such IPv4 prefix is set to 96 plus
the IPv4 prefix length. the IPv4 prefix length.
6.1. External Connections 6.1. External Connections
Each HNCP router MAY obtain external connection information from one Each HNCP router MAY obtain external connection information from one
or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or
skipping to change at page 9, line 41 skipping to change at page 9, line 41
* It MAY contain other TLVs for future use. Such additional TLVs * It MAY contain other TLVs for future use. Such additional TLVs
MUST be ignored. MUST be ignored.
6.1.3. Prefix Domain TLV 6.1.3. Prefix Domain TLV
The Prefix Domain TLV contains information about the origin and The Prefix Domain TLV contains information about the origin and
applicability of a delegated prefix. This information can be used to applicability of a delegated prefix. This information can be used to
determine whether prefixes for a certain domain (e.g. local determine whether prefixes for a certain domain (e.g. local
reachability, internet connectivity) do exist or should be acquired reachability, internet connectivity) do exist or should be acquired
and to make decisions about assigning prefixes to certain links or to and to make decisions about assigning prefixes to certain links or to
fine-tune border firewalls. fine-tune border firewalls. See Section 6.5 for a more in-depth
discussion.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: PREFIX-DOMAIN (43) | Length: >= 1 | | Type: PREFIX-DOMAIN (43) | Length: >= 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Type | | | Domain Type | |
+-+-+-+-+-+-+-+-+ Domain ID + +-+-+-+-+-+-+-+-+ Value +
| | | |
Domain Type: The type of the domain identifier. Domain Type: The type of the domain identifier.
0 : Internet connectivity (domain ID is empty). 0 : Internet connectivity (no Value).
1-128 : Explicit destination prefix with the Domain Type being 1-128 : Explicit destination prefix with the Domain Type being
the actual length of the prefix (Domain ID contains significant the actual length of the prefix (Value contains significant
bits of the destination prefix padded with zeroes up to the bits of the destination prefix padded with zeroes up to the
next byte boundary). next byte boundary).
129 : UTF-8 String (e.g. FQDN). 129 : DNS Zone (Value contains an RFC 1035 [RFC1035] encoded
DNS label sequence).
130-255: Reserved for future additions. 130 : Opaque UTF-8 string (e.g. for administrative purposes).
Domain Identifier: A variable length identifier of the given type. 131-255: Reserved for future additions.
Value: A variable length identifier of the given type.
6.1.4. DHCP Data TLVs 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.
skipping to change at page 13, line 36 skipping to change at page 13, line 42
6.2.3. Making New Assignments 6.2.3. Making New Assignments
Whenever the Prefix Assignment Algorithm subroutine is run on a Whenever the Prefix Assignment Algorithm subroutine is run on a
Common Link and whenever a new prefix may be assigned (case 1 of the Common Link and whenever a new prefix may be assigned (case 1 of the
subroutine), the decision of whether the assignment of a new prefix subroutine), the decision of whether the assignment of a new prefix
is desired MUST follow these rules: is 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.
This rule applies to TLVs inside Delegated Prefix TLVs but not to
those inside External Connection TLVs.
If the remaining preferred lifetime of the prefix is 0 and there If the remaining preferred lifetime of the prefix is 0 and there
is another delegated prefix of the same IP version used for prefix is another delegated prefix of the same IP version used for prefix
assignment with a non-null preferred lifetime, the creation of a assignment with a non-null preferred lifetime, the creation of a
new prefix is not desired. new prefix is not desired.
Otherwise, the creation of a new prefix is desired. Otherwise, the creation of a new prefix is desired, if the
Delegated Prefix is either locally generated (does not have any
Prefix Domain TLVs) or intended for internet access (has a Prefix
Domain TLV of type 0). Local desirability policies MAY override
or provide additional desirability rules for delegated prefixes,
e.g., by matching different Prefix Domain TLV values.
If the considered delegated prefix is an IPv6 prefix, and whenever If the considered delegated prefix is an IPv6 prefix, and whenever
there is at least one available prefix of length 64, a prefix of there is at least one available prefix of length 64, a prefix of
length 64 MUST be selected unless configured otherwise by an length 64 MUST be selected unless configured otherwise. In case no
administrator. In case no prefix of length 64 would be available, a prefix of length 64 would be available, a longer prefix MAY be
longer prefix MAY be selected. selected even without configuration.
If the considered delegated prefix is an IPv4 prefix (Section 6.4 If the considered delegated prefix is an IPv4 prefix (Section 6.4
details how IPv4 delegated prefixes are generated), a prefix of details how IPv4 delegated prefixes are generated), a prefix of
length 24 SHOULD be preferred. length 24 SHOULD be preferred.
In any case, a router MUST support a mechanism suitable to distribute In any case, a router MUST support a mechanism suitable to distribute
addresses from the considered prefix to clients on the link. addresses from the considered prefix if the link is intended to be
Otherwise it MUST NOT create or adopt it, i.e. a router assigning an used by clients. In this case a router assigning an IPv4 prefix MUST
IPv4 prefix MUST support the L-capability and a router assigning an support the L-capability and a router assigning an IPv6 prefix MUST
IPv6 prefix not suitable for Stateless Address Autoconfiguration MUST support serving router advertisements. In addition if an assigned
support the H-capability as defined in Section 10. IPv6 prefix is not suitable for Stateless Address Autoconfiguration
the router MUST also support 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 Common Link. When that happens each router connected the respective Common Link. When that happens each router connected
to said link: to said link:
MUST create an appropriate on-link route for said prefix and MUST create an appropriate route for said prefix, indicating it is
advertise it using the chosen routing protocol. directly reachable on the respective link and advertise said route
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, if the link is intended to be used by clients.
MAY add an address from said prefix to the respective network MAY add an address from said prefix to the respective network
interface as described in Section 6.3. interface as described in Section 6.3, e.g., if it is to be used
as source for locally originating traffic.
6.2.5. DHCPv6-PD Excluded Prefix Support 6.2.5. DHCPv6-PD Excluded Prefix Support
Whenever a DHCPv6 Prefix Exclude option [RFC6603] is received with a Whenever a DHCPv6 Prefix Exclude option [RFC6603] is received with a
delegated prefix, the excluded prefix MUST be advertised as assigned delegated prefix, the excluded prefix MUST be advertised as assigned
to a Private Link with the maximum priority (i.e. 15). to a Private Link with the maximum priority (i.e. 15).
The same procedure MAY be applied in order to exclude prefixes The same procedure MAY be applied in order to exclude prefixes
obtained by other means of configuration. obtained by other means of configuration.
6.2.6. Downstream Prefix Delegation Support 6.2.6. Downstream Prefix Delegation Support
When an HNCP router receives a request for prefix delegation, it When an HNCP router receives a request for prefix delegation, it
SHOULD assign one prefix per delegated prefix, wait for them to be SHOULD assign one prefix per delegated prefix in the network. This
applied, and delegate them to the client. Such assignment MUST be set of assigned prefix is then delegated to the client, after it has
done in accordance with the Prefix Assignment Algorithm. Each client been applied as described in the Prefix Assignment Algorithm. Each
MUST be considered as an independent Private Link and delegation MUST client MUST be considered as an independent Private Link and
be based on the same set of Delegated Prefixes as the one used for delegation MUST be based on the same set of Delegated Prefixes as the
Common Links prefixes assignment. one used for Common Link prefix assignments.
The assigned prefixes MUST NOT be given to clients before they are The assigned prefixes MUST NOT be given to clients before they are
applied, and MUST be withdrawn whenever they are destroyed. As an applied, and MUST be withdrawn whenever they are destroyed. As an
exception to this rule, in order to shorten delays of processed exception to this rule, in order to shorten delays of processed
requests, a router MAY prematurely give out a prefix which is requests, a router MAY prematurely give out a prefix which is
advertised but not yet applied if it does so with a valid lifetime of advertised but not yet applied if it does so with a valid lifetime of
not more than 30 seconds and ensures removal or correction of not more than 30 seconds and ensures removal or correction of
lifetimes as soon as possible. lifetimes as soon as possible.
6.3. Node Address Assignment 6.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 from any use. Nodes MAY, at any time, try to reserve a new address from any
applied Assigned Prefix. SLAAC SHOULD be used whenever possible. applied Assigned Prefix. Each HNCP router MUST announce at least one
The following method MUST be used otherwise. IPv6 address and - if it supports IPv4 - at least one IPv4 address,
whenever matching prefixes are assigned to at least one if its Common
Links. These addresses are published using Node Address TLVs and
used to locally reach HNCP nodes for other services. Nodes SHOULD
NOT create and announce more than one assignment per IP version to
avoid cluttering the node data with redundant information unless a
special use case requires it.
For any IPv6 prefix for which SLAAC cannot be used (resp. any IPv4 Stateless assignment based on Modified EUI64 interface identifiers
prefix) assigned to a Common Link, the first quarter of the addresses [RFC4291] SHOULD be used for address assignment whenever possible,
are reserved for routers HNCP based address assignments, whereas the otherwise (e.g., for IPv4) the following method MUST be used instead:
last three quarters are left to the DHCPv6 (resp. DHCPv4) elected For any assigned prefix for which SLAAC cannot be used, the first
router (Section 10 specifies the DHCP server election process). For quarter of the addresses are reserved for routers HNCP based address
instance, if the prefix 192.0.2.0/24 is assigned and applied to a assignments, whereas the last three quarters are left to the DHCPv6
Common Link, addresses included in 192.0.2.0/26 are reserved for HNCP (resp. DHCPv4) elected router (Section 10 specifies the DHCP server
nodes and the remaining addresses are reserved for the elected DHCPv4 election process). For instance, if the prefix 192.0.2.0/24 is
server. assigned and applied to a Common Link, addresses included in
192.0.2.0/26 are reserved for HNCP nodes and the remaining addresses
are reserved for the elected DHCPv4 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier | | Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 21 skipping to change at page 16, line 50
but the one advertised by the node with the highest node but the one advertised by the node with the highest node
identifier MUST be removed. identifier MUST be removed.
6.4. Local IPv4 and ULA Prefixes 6.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 a ULA prefix if there is no other An HNCP router SHOULD create a ULA prefix if there is no other
non-deprecated IPv6 prefix in the network. It MAY also do so if IPv6 prefix with a preferred time greater than 0 in the network.
there are other delegated IPv6 prefixes but none of which is It MAY also do so, if there are other delegated IPv6 prefixes, but
generated by an HNCP router (i.e., none of which is specified in a none of which is locally generated (i.e., without any Prefix
Delegated Prefix TLV which also includes a Prefix Domain TLV) but Domain TLV) and has a preferred time greater than 0. However, it
MUST NOT do so otherwise. Whenever it detects another non- MUST NOT do so otherwise. In case multiple locally generated ULA
deprecated IPv6 prefix generated by an HNCP router with a greater prefixes are present, only the one published by the node with the
HNCP identifier, it MUST cease to announce its own locally highest node identifier is kept among those with a preferred time
generated one. greater than 0 - if there is any.
An HNCP router MUST create a private IPv4 prefix [RFC1918] An HNCP router MUST create a private IPv4 prefix [RFC1918]
whenever it wishes to provide IPv4 internet connectivity to the whenever it wishes to provide IPv4 internet connectivity to the
network and no other private IPv4 prefix with internet network and no other private IPv4 prefix with internet
connectivity currently exists. It MAY also enable local IPv4 connectivity currently exists. It MAY also enable local IPv4
connectivity by creating a private IPv4 prefix if no IPv4 prefix connectivity by creating a private IPv4 prefix if no IPv4 prefix
exists but MUST NOT do so otherwise. In case multiple IPv4 exists but MUST NOT do so otherwise. In case multiple IPv4
prefixes are announced all but one MUST be removed while those prefixes are announced, only the one published by the node with
associated with a Prefix Domain TLV of type 0 take precedence over the highest node identifier is kept among those with a Prefix
those without and, in case of a tie, announcements by nodes with a Domain of type 0 - if there is any. The router publishing a
greater node identifier take precedence over those with a lower prefix with internet connectivity MUST announce an IPv4 default
one. The router publishing a prefix with internet connectivity route using the routing protocol and perform NAT on behalf of the
MUST announce an IPv4 default route using the routing protocol and network as long as it publishes the prefix, other routers in the
perform NAT on behalf of the network as long as it publishes the network MAY choose not to.
prefix, other routers in the 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].
6.5. Special Purpose Prefixes
Some prefixes may have a special meaning and are not regularly used
for internal or internet connectivity, instead they may provide
access to special services like VPNs, sensor networks, VoIP, IPTV,
etc. Care must be taken that these prefixes are properly integrated
and dealt with in the network, in order to avoid breaking
connectivity for devices who are not aware of their special
characteristics.
Special purpose prefixes are distinguished using Prefix Domain TLVs
(Section 6.1.3). Their contents MAY be partly opaque to HNCP nodes,
and their identification and usage depends on local policy. However
the following general rules MUST be adhered to:
Special rules apply when making address assignments for prefixes
with Prefix Domain TLVs other than type 0, as described in
Section 6.2.3
In presence of any type 1 to 128 Prefix Domain TLV the prefix is
specialized to reach destinations denoted by any such Prefix
Domain TLV, i.e. in abscence of a type 0 Prefix Domain TLV it is
not usable for general internet connectivity. An HNCP router MAY
enforce this restriction with appropriate packet filtering rules
to provide increased security.
The presence of a type 129 (DNS zone) Prefix Domain TLV indicates
that the delegated prefix or its associated external connection is
specialized to reach destinations within the given DNS zone. An
HNCP router providing name resolving services SHOULD prefer DNS
servers listed in the associated external connection's DHCPv4 or
DHCPv6 Data TLVs when resolving domains from that zone.
7. Configuration of Hosts and non-HNCP Routers 7. Configuration of Hosts and non-HNCP Routers
HNCP routers need to ensure that hosts and non-HNCP downstream HNCP routers need to ensure that hosts and non-HNCP downstream
routers on internal links are configured with addresses and routes. routers on internal links are configured with addresses and routes.
Since DHCP-clients can usually only bind to one server at a time, a Since DHCP-clients can usually only bind to one server at a time, a
per-link and per-service election takes place. per-link and per-service election takes place.
HNCP routers may have different capabilities for configuring HNCP routers may have different capabilities for configuring
downstream devices and providing naming services. Each router MUST downstream devices and providing naming services. Each router MUST
therefore indicate its capabilities as specified in Section 10 in therefore indicate its capabilities as specified in Section 10 in
skipping to change at page 19, line 32 skipping to change at page 20, line 46
M-capability. In case of a tie, Capability Values are compared, and M-capability. In case of a tie, Capability Values are compared, and
router with the greatest value is elected. In case of another tie, router with the greatest value is elected. In case of another tie,
the router with the highest node identifier is elected among the the router with the highest node identifier is elected among the
routers with tied Capability Values. The elected router MUST provide routers with tied Capability Values. The elected router MUST provide
an MDNS-proxy on the given link and announce it as described in an MDNS-proxy on the given link and announce it as described in
Section 8. 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 a network. The following mechanism provides
provides means to setup and delegate naming and service discovery means to setup and delegate naming and service discovery across
across multiple HNCP routers. 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 Common 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, MDNS
proxy and for which it provides DNS services on behalf of devices on proxy, or for which it provides forward or reverse DNS services on
said link. In addition it MAY provide reverse lookup services. behalf of connected devices. HNCP routers providing name resolving
services MUST use the included DNS server address to resolve names
belonging to the zone.
Each HNCP router SHOULD announce a node name for itself to be easily
reachable and MAY do so on behalf of other devices. HNCP routers
providing name resolving services MUST resolve these names to their
respective IP addresses.
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
This TLV is used to announce a forward or reverse DNS zone delegation This TLV is used to announce a forward or reverse DNS zone delegation
in the HNCP network. Its meaning is roughly equivalent to specifying in the HNCP network. Its meaning is roughly equivalent to specifying
an NS and A/AAAA record for said zone. There MUST NOT be more than 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 one delegation for the same zone in the whole DNCP network. In case
skipping to change at page 21, line 12 skipping to change at page 22, line 33
are encoded DNS messages as specified in [RFC1035]. The last are encoded DNS messages as specified in [RFC1035]. The last
label in the zone MUST be empty. label in the zone MUST be empty.
8.2. Domain Name TLV 8.2. Domain Name TLV
This TLV is used to indicate the base domain name for the network. 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 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 zones and node names. In case of conflicts the announced domain of
the node with the greatest node identifier takes precedence. By the node with the greatest node identifier takes precedence. By
default, i.e., if no node advertises such a TLV., ".home" is used. default, i.e., if no node advertises such a TLV., ".home" is used.
This TLV MUST NOT be announced unless the domain name was explicitly
configured by an administrator.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: DOMAIN-NAME (40) | Length: > 0 | | Type: DOMAIN-NAME (40) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain (DNS label sequence - variable length) | | Domain (DNS label sequence - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Domain: The label sequence encoded according to [RFC1035]. Domain: The label sequence encoded according to [RFC1035].
skipping to change at page 21, line 48 skipping to change at page 23, line 28
| IP Address | | IP Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name (not null-terminated - variable length) | | Name (not null-terminated - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address: The IP address associated with the name. IPv4 IP Address: The IP address associated with the name. IPv4
addresses are encoded using IPv4-mapped IPv6 addresses. addresses are encoded using IPv4-mapped IPv6 addresses.
Name: The name of the node as a DNS label. The length of the label Name: The name of the node as a single DNS label (up to 63
is the Length value of the TLV minus 16. characters, no leading length byte).
9. Securing Third-Party Protocols 9. Securing Third-Party Protocols
Pre-shared keys (PSKs) are often required to secure IGPs and other Pre-shared keys (PSKs) are often required to secure IGPs and other
protocols which lack support for asymmetric security. The following protocols which lack support for asymmetric security. The following
mechanism manages PSKs using HNCP to enable bootstrapping of such mechanism manages PSKs using HNCP to enable bootstrapping of such
third-party protocols and SHOULD therefore be used if such a need third-party protocols and SHOULD therefore be used if such a need
arises. The following rules define how such a PSK is managed and arises. The following rules define how such a PSK is managed and
used: used:
skipping to change at page 23, line 24 skipping to change at page 25, line 4
the bits as an integer, i.e. (M << 12 | P << 8 | H << 4 | L). 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: HNCP-VERSION (32) | Length: >= 5 | | Type: HNCP-VERSION (32) | Length: >= 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | M | P | H | L | | Version | Reserved | M | P | H | L |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-agent | | User-agent |
Version: Indicates which version of HNCP is currently in use by this Version: Indicates which version of HNCP is currently in use by this
particular node. It MUST be set to 0. Nodes with different particular node. It MUST be set to 1. Nodes with different
versions are considered incompatible. versions are considered incompatible.
Reserved: Bits are reserved for future use. They MUST be set to Reserved: Bits are reserved for future use. They MUST be set to
zero when creating this TLV, and their value MUST be ignored when zero when creating this TLV, and their value MUST be ignored when
processing the TLV. processing the TLV.
M-capability: Priority value used for electing the on-link MDNS M-capability: Priority value used for electing the on-link MDNS
[RFC6762] proxy. It MUST be set to some value between 1 and 7 [RFC6762] proxy. It MUST be set to some value between 1 and 7
included (4 is the default) if the router is capable of proxying included (4 is the default) if the router is capable of proxying
MDNS and 0 otherwise. The values 8-15 are reserved for future MDNS and 0 otherwise. The values 8-15 are reserved for future
skipping to change at page 24, line 39 skipping to change at page 26, line 21
and MUST correctly propagate those also for the external and MUST correctly propagate those also for the external
destinations that may have only implicit source-specific destinations that may have only implicit source-specific
information, such as a combination of a DHCPv6 PD-derived prefix information, such as a combination of a DHCPv6 PD-derived prefix
and a non-source-specific default route. and a non-source-specific default route.
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
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.
o It MAY be able to provide connectivity to IPv4-devices using o It MAY be able to provide connectivity to IPv4-devices using
DHCPv4. DHCPv4.
o It SHOULD be able to delegate prefixes to legacy IPv6 routers o It SHOULD be able to delegate prefixes to legacy IPv6 routers
using DHCPv6-PD. using DHCPv6-PD.
o In addition, normative language of Basic Requirements for IPv6
Customer Edge Routers [RFC7084] applies with the following
adjustments:
* The section "WAN-Side Configuration" applies to HNCP interfaces
classified as external.
* If the CE sends a size-hint as indicated in WPD-2, the hint
MUST NOT be determined by the number of LAN-interfaces of the
CE, but SHOULD instead be large enough to at least accommodate
prefix assignments announced for existing delegated or ULA-
prefixes, if such prefixes exist and unless explicitly
configured otherwise.
* The dropping of packets with a destination address belonging to
a delegated prefix mandated in WPD-5 MUST NOT be applied to
destinations that are part of any prefix announced using an
ASSIGNED-PREFIX TLV by any HNCP router in the network.
* The section "LAN-Side Configuration" applies to HNCP interfaces
classified as internal.
* The requirement L-2 to assign a separate /64 to each LAN
interface is replaced by the participation in the prefix
assignment mechanism (Section 6.2) for each such interface.
* The requirement L-12 to make DHCPv6 options available is
adapted, in that a CER SHOULD publish the subset of options
using the DHCPv6 Data TLV in an External Connection TLV.
Similarly it SHOULD do the same for DHCPv4 options in a DHCPv4
Data TLV. DHCPv6 options received inside an OPTION_IAPREFIX
[RFC3633] MUST be published using a DHCPv6 Data TLV inside the
respective Delegated Prefix TLV. HNCP routers SHOULD make
relevant DHCPv6 and DHCPv4 options available to clients, i.e.
options contained in External Connection TLVs that also include
delegated prefixes from which a subset is assigned to the
respective link.
12. Security Considerations 12. Security Considerations
HNCP enables self-configuring networks, requiring as little user HNCP enables self-configuring networks, requiring as little user
intervention as possible. However this zero-configuration goal intervention as possible. However this zero-configuration goal
usually conflicts with security goals and introduces a number of usually conflicts with security goals and introduces a number of
threats. threats.
General security issues for existing home networks are discussed in General security issues for existing home networks are discussed in
[RFC7368]. The protocols used to set up addresses and routes in such [RFC7368]. The protocols used to set up addresses and routes in such
networks to this day rarely have security enabled within the networks to this day rarely have security enabled within the
skipping to change at page 27, line 37 skipping to change at page 29, line 49
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-05 (work in progress), Protocol", draft-ietf-homenet-dncp-07 (work in progress),
June 2015. July 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.
skipping to change at page 29, line 33 skipping to change at page 31, line 46
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. Changelog [RFC Editor: please remove] Appendix A. Changelog [RFC Editor: please remove]
draft-ietf-homenet-hncp-07: Using version 1 instead of version 0, as
existing implementations already use it.
draft-ietf-homenet-hncp-06: Various edits based on feedback, draft-ietf-homenet-hncp-06: Various edits based on feedback,
hopefully without functional delta. hopefully without functional delta.
draft-ietf-homenet-hncp-05: Renamed "Adjacent Link" to "Common Link". draft-ietf-homenet-hncp-05: Renamed "Adjacent Link" to "Common Link".
Changed single IPv4 uplink election from MUST to MAY. Added explicit Changed single IPv4 uplink election from MUST to MAY. Added explicit
indication to distinguish (IPv4)-PDs for local connectivity and ones indication to distinguish (IPv4)-PDs for local connectivity and ones
with uplink connectivity allowing e.g. better local-only with uplink connectivity allowing e.g. better local-only
IPv4-connectivity. IPv4-connectivity.
draft-ietf-homenet-hncp-04: Change the responsibility for sending RAs draft-ietf-homenet-hncp-04: Change the responsibility for sending RAs
 End of changes. 44 change blocks. 
125 lines changed or deleted 223 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/