draft-ietf-homenet-hncp-08.txt   draft-ietf-homenet-hncp-09.txt 
Homenet Working Group M. Stenberg Homenet Working Group M. Stenberg
Internet-Draft S. Barth Internet-Draft S. Barth
Intended status: Standards Track Independent Intended status: Standards Track Independent
Expires: February 7, 2016 P. Pfister Expires: March 3, 2016 P. Pfister
Cisco Systems Cisco Systems
August 6, 2015 August 31, 2015
Home Networking Control Protocol Home Networking Control Protocol
draft-ietf-homenet-hncp-08 draft-ietf-homenet-hncp-09
Abstract Abstract
This document describes the Home Networking Control Protocol (HNCP), This document describes the Home Networking Control Protocol (HNCP),
an extensible configuration protocol and a set of requirements for an extensible configuration protocol and a set of requirements for
home network devices. HNCP is described as a profile of and home network devices. HNCP is described as a profile of and
extension to the Distributed Node Consensus Protocol (DNCP). HNCP extension to the Distributed Node Consensus Protocol (DNCP). HNCP
enables discovery of network borders, automated configuration of enables discovery of network borders, automated configuration of
addresses, name resolution, service discovery, and the use of any addresses, name resolution, service discovery, and the use of any
routing protocol which supports routing based on both source and routing protocol which supports routing based on both source and
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 7, 2016. This Internet-Draft will expire on March 3, 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 33 skipping to change at page 2, line 33
6.1. Common Link . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Common Link . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. External Connections . . . . . . . . . . . . . . . . . . 12 6.2. External Connections . . . . . . . . . . . . . . . . . . 12
6.3. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 13 6.3. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 13
6.3.1. Prefix Assignment Algorithm Parameters . . . . . . . 13 6.3.1. Prefix Assignment Algorithm Parameters . . . . . . . 13
6.3.2. Making New Assignments . . . . . . . . . . . . . . . 15 6.3.2. Making New Assignments . . . . . . . . . . . . . . . 15
6.3.3. Applying Assignments . . . . . . . . . . . . . . . . 16 6.3.3. Applying Assignments . . . . . . . . . . . . . . . . 16
6.3.4. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . 16 6.3.4. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . 16
6.4. Node Address Assignment . . . . . . . . . . . . . . . . . 16 6.4. Node Address Assignment . . . . . . . . . . . . . . . . . 16
6.5. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 17 6.5. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 17
7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 18 7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 18
7.1. DHCPv6 for Addressing or Configuration . . . . . . . . . 19 7.1. IPv6 Addressing and Configuration . . . . . . . . . . . . 19
7.2. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 19 7.2. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 19
7.3. DHCPv4 for Addressing and Configuration . . . . . . . . . 19 7.3. DHCPv4 for Addressing and Configuration . . . . . . . . . 20
7.4. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 20 7.4. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 20
8. Naming and Service Discovery . . . . . . . . . . . . . . . . 20 8. Naming and Service Discovery . . . . . . . . . . . . . . . . 20
9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 21 9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 21
10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 22 10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 22
10.1. HNCP Version TLV . . . . . . . . . . . . . . . . . . . . 22 10.1. HNCP Version TLV . . . . . . . . . . . . . . . . . . . . 22
10.2. External Connection TLV . . . . . . . . . . . . . . . . 23 10.2. External Connection TLV . . . . . . . . . . . . . . . . 23
10.2.1. Delegated Prefix TLV . . . . . . . . . . . . . . . . 23 10.2.1. Delegated Prefix TLV . . . . . . . . . . . . . . . . 24
10.2.2. DHCPv6 Data TLV . . . . . . . . . . . . . . . . . . 25 10.2.2. DHCPv6 Data TLV . . . . . . . . . . . . . . . . . . 25
10.2.3. DHCPv4 Data TLV . . . . . . . . . . . . . . . . . . 26 10.2.3. DHCPv4 Data TLV . . . . . . . . . . . . . . . . . . 26
10.3. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . 26 10.3. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . 26
10.4. Node Address TLV . . . . . . . . . . . . . . . . . . . . 27 10.4. Node Address TLV . . . . . . . . . . . . . . . . . . . . 27
10.5. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 27 10.5. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 28
10.6. Domain Name TLV . . . . . . . . . . . . . . . . . . . . 29 10.6. Domain Name TLV . . . . . . . . . . . . . . . . . . . . 29
10.7. Node Name TLV . . . . . . . . . . . . . . . . . . . . . 29 10.7. Node Name TLV . . . . . . . . . . . . . . . . . . . . . 29
10.8. Managed PSK TLV . . . . . . . . . . . . . . . . . . . . 30 10.8. Managed PSK TLV . . . . . . . . . . . . . . . . . . . . 30
11. General Requirements for HNCP Nodes . . . . . . . . . . . . . 30 11. General Requirements for HNCP Nodes . . . . . . . . . . . . . 31
12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32
12.1. Interface Classification . . . . . . . . . . . . . . . . 32 12.1. Interface Classification . . . . . . . . . . . . . . . . 33
12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 33 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 33
12.3. Other Protocols in the Home . . . . . . . . . . . . . . 33 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.1. Normative references . . . . . . . . . . . . . . . . . . 35 14.1. Normative references . . . . . . . . . . . . . . . . . . 35
14.2. Informative references . . . . . . . . . . . . . . . . . 35 14.2. Informative references . . . . . . . . . . . . . . . . . 36
Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 37 Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 37
Appendix B. Draft source [RFC Editor: please remove] . . . . . . 38 Appendix B. Draft source [RFC Editor: please remove] . . . . . . 38
Appendix C. Implementation [RFC Editor: please remove] . . . . . 38 Appendix C. Implementation [RFC Editor: please remove] . . . . . 38
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 38 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
HNCP is designed to facilitate sharing of state among home routers to HNCP is designed to facilitate sharing of state among home routers to
fulfill the needs of the IPv6 homenet architecture [RFC7368], which fulfill the needs of the IPv6 homenet architecture [RFC7368], which
assumes zero-configuration operation, multiple subnets, multiple home assumes zero-configuration operation, multiple subnets, multiple home
routers and (potentially) multiple upstream service providers routers and (potentially) multiple upstream service providers
providing (potentially) multiple prefixes to the home network. While providing (potentially) multiple prefixes to the home network. While
RFC7368 sets no requirements for IPv4 support, HNCP aims to support RFC7368 sets no requirements for IPv4 support, HNCP aims to support
dual-stack mode of operation, and therefore the functionality is dual-stack mode of operation, and therefore the functionality is
skipping to change at page 8, line 39 skipping to change at page 8, line 39
4. HNCP Versioning and Router Capabilities 4. HNCP Versioning and Router Capabilities
Multiple versions of HNCP based on compatible DNCP profiles may be Multiple versions of HNCP based on compatible DNCP profiles may be
present in the same network when transitioning between HNCP versions present in the same network when transitioning between HNCP versions
and for troubleshooting purposes it might be beneficial to identify and for troubleshooting purposes it might be beneficial to identify
the HNCP agent version running. Therefore each node MUST include an the HNCP agent version running. Therefore each node MUST include an
HNCP-Version TLV (Section 10.1) in its Node Data and MUST ignore HNCP-Version TLV (Section 10.1) in its Node Data and MUST ignore
(except for DNCP synchronization purposes) any TLVs with a type (except for DNCP synchronization purposes) any TLVs with a type
greater than 32 published by nodes not also publishing an HNCP- greater than 32 published by nodes not also publishing an HNCP-
Version TLV or publishing such a TLV with a different Version. Version TLV.
HNCP routers may also have different capabilities regarding HNCP routers may also have different capabilities regarding
interactions with hosts, e.g., for configuration or service interactions with hosts, e.g., for configuration or service
discovery. These are indicated by M, P, H and L values. The discovery. These are indicated by M, P, H and L values. The
combined "capability value" is a metric indicated by interpreting the combined "capability value" is a metric indicated by interpreting the
bits as an integer, i.e., (M << 12 | P << 8 | H << 4 | L). These bits as an integer, i.e., (M << 12 | P << 8 | H << 4 | L). These
values are used to elect certain servers on a Common Link, as values are used to elect certain servers on a Common Link, as
described in Section 7. Nodes that are not routers MUST announce the described in Section 7. Nodes that are not routers MUST announce the
value 0 for all capabilities and therefore do not take part in these value 0 for all capabilities. Any node announcing the value 0 is
elections. considered to not advertise the respective capability and thus does
not take part in the respective election.
5. Interface Classification 5. Interface Classification
5.1. Interface Categories 5.1. Interface Categories
HNCP specifies the following categories interfaces can be configured HNCP specifies the following categories interfaces can be configured
to be in: to be in:
Internal category: This declares an interfaces to be internal, i.e., Internal category: This declares an interfaces to be internal, i.e.,
within the borders of the HNCP network. HNCP traffic MUST be sent within the borders of the HNCP network. HNCP traffic MUST be sent
and received. Routers MUST forward traffic with appropriate and received. Routers MUST forward traffic with appropriate
source addresses between their internal interfaces and allow source addresses between their internal interfaces and allow
internal traffic to reach external networks. All nodes MUST internal traffic to reach external networks. All nodes MUST
implement this category and nodes not implementing any other implement this category and nodes not implementing any other
category implicitly use it as a fixed default. category implicitly use it as a fixed default.
External category: This declares an interface to be external, i.e., External category: This declares an interface to be external, i.e.,
not within the borders of the HNCP network. HNCP traffic MUST not within the borders of the HNCP network. HNCP traffic MUST
neither be sent nor received. HNCP routers SHOULD announce neither be sent nor received. Accessing internal resources from
acquired configuration information for use in the network as external interfaces is restricted, i.e., the use of [RFC6092] is
described in Section 6.2, if the interface appears to be connected RECOMMENDED. HNCP routers SHOULD announce acquired configuration
to an external network. HNCP routers MUST implement this information for use in the network as described in Section 6.2, if
category. the interface appears to be connected to an external network.
HNCP routers MUST implement this category.
Leaf category: This declares an interface used by client devices Leaf category: This declares an interface used by client devices
only. Such an interface uses the Internal category with the only. Such an interface uses the Internal category with the
exception that HNCP traffic MUST NOT be sent on the interface, and exception that HNCP traffic MUST NOT be sent on the interface, and
all such traffic received on the interface MUST be ignored. This all such traffic received on the interface MUST be ignored. This
category SHOULD be supported by HNCP routers. category SHOULD be supported by HNCP routers.
Guest category: This declares an interface used by untrusted client Guest category: This declares an interface used by untrusted client
devices only. In addition to the restrictions of the Leaf devices only. In addition to the restrictions of the Leaf
category, HNCP routers MUST filter traffic from and to the category, HNCP routers MUST filter traffic from and to the
skipping to change at page 19, line 5 skipping to change at page 19, line 5
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 4 in therefore indicate its capabilities as specified in Section 4 in
order to participate as a candidate in the election. order to participate as a candidate in the election.
7.1. DHCPv6 for Addressing or Configuration 7.1. IPv6 Addressing and Configuration
In general Stateless Address Autoconfiguration is used for client In general Stateless Address Autoconfiguration [RFC4861] is used for
configuration for its low overhead and fast renumbering capabilities, client configuration for its low overhead and fast renumbering
however stateful DHCPv6 can be used in addition by administrative capabilities. Therefore each HNCP router sends Router Advertisements
choice, to, e.g., collect hostnames and use them to provide naming on interfaces which are intended to be used by clients and MUST at
services or whenever stateless configuration is not applicable. least include a Prefix Information Option for each Applied Assigned
Prefix which it assigned to the respective link in every such
advertisement. However, stateful DHCPv6 can be used in addition by
administrative choice, to, e.g., collect hostnames and use them to
provide naming services or whenever stateless configuration is not
applicable.
The designated stateful DHCPv6 server for a Common Link (Section 6.1) The designated stateful DHCPv6 server for a Common Link (Section 6.1)
is elected based on the capabilities described in Section 4. The is elected based on the capabilities described in Section 4. The
winner is the router (connected to the Common Link) advertising the winner is the router (connected to the Common Link) advertising the
greatest H-capability. In case of a tie, Capability Values are greatest H-capability. In case of a tie, Capability Values
compared, and router with the greatest value is elected. In case of (Section 4) are compared, and the router with the greatest value is
another tie, the router with the highest node identifier is elected elected. In case of another tie, the router with the highest node
among the routers with tied Capability Values. identifier is elected among the routers with tied Capability Values.
The elected router MUST serve stateful DHCPv6 and SHOULD provide The elected router MUST serve stateful DHCPv6 and SHOULD provide
naming services for acquired hostnames as outlined in Section 8. naming services for acquired hostnames as outlined in Section 8, all
Stateful addresses SHOULD be assigned in a way not hindering fast others nodes MUST NOT. Stateful addresses SHOULD be assigned in a
renumbering even if the DHCPv6 server or client do not support the way not hindering fast renumbering even if the DHCPv6 server or
DHCPv6 reconfigure mechanism. In case no router was elected, client do not support the DHCPv6 reconfigure mechanism, e.g., by only
stateful DHCPv6 is not provided. handing out leases from locally-generated (ULA) prefixes and prefixes
with a length different from 64, and by using low renew and rebind
times (i.e., not longer than 5 minutes). In case no router was
elected, stateful DHCPv6 is not provided. Routers which cease to be
elected DHCP servers SHOULD - when applicable - invalidate remaining
existing bindings in order to trigger client reconfiguration.
7.2. DHCPv6 for Prefix Delegation 7.2. DHCPv6 for Prefix Delegation
The designated DHCPv6 server for prefix-delegation on a Common Link The designated DHCPv6 server for prefix-delegation on a Common Link
is elected based on the capabilities described in Section 4. The is elected based on the capabilities described in Section 4. The
winner is the router (connected to the Common Link) advertising the winner is the router (connected to the Common Link) advertising the
greatest P-capability. In case of a tie, Capability Values are greatest P-capability. In case of a tie, Capability Values
compared, and router with the greatest value is elected. In case of (Section 4) are compared, and the router with the greatest value is
another tie, the router with the highest node identifier is elected elected. In case of another tie, the router with the highest node
among the routers with tied Capability Values. identifier is elected among the routers with tied Capability Values.
The elected router MUST provide prefix-delegation services [RFC3633] The elected router MUST provide prefix-delegation services [RFC3633]
on the given link and follow the rules in Section 6.3.4. on the given link (and follow the rules in Section 6.3.4), all other
nodes MUST NOT.
7.3. DHCPv4 for Addressing and Configuration 7.3. DHCPv4 for Addressing and Configuration
The designated DHCPv4 server on a Common Link (Section 6.1) is The designated DHCPv4 server on a Common Link (Section 6.1) is
elected based on the capabilities described in Section 4. The winner elected based on the capabilities described in Section 4. The winner
is the router (connected to the Common Link) advertising the greatest is the router (connected to the Common Link) advertising the greatest
L-capability. In case of a tie, Capability Values are compared, and L-capability. In case of a tie, Capability Values (Section 4) are
router with the greatest value is elected. In case of another tie, compared, and the router with the greatest value is elected. In case
the router with the highest node identifier is elected among the of another tie, the router with the highest node identifier is
routers with tied Capability Values. elected among the routers with tied Capability Values.
The elected router MUST provide DHCPv4 services on the given link. The elected router MUST provide DHCPv4 services on the given link,
It MUST announce itself as router [RFC2132] to clients if and only if all other nodes MUST NOT. The elected router MUST provide IP
there is an IPv4 default route known in the network. If there is no addresses from the pool defined in Section 6.4 and MUST announce
default route, the elected router MUST announce a Classless Static itself as router [RFC2132] to clients.
Route Option [RFC3442] for the IPv4 prefix announced in the Delegated
Prefix TLV and MAY announce such an option for known reachable IPv4
destinations not within any local delegated prefix.
DHCPv4 lease times SHOULD be short (i.e., not longer than 5 minutes) DHCPv4 lifetimes renew and rebind times (T1 and T2) SHOULD be short
in order to provide reasonable response times to changes. (i.e., not longer than 5 minutes) in order to provide reasonable
response times to changes. Routers which cease to be elected DHCP
servers SHOULD - when applicable - invalidate remaining existing
bindings in order to trigger client reconfiguration.
7.4. Multicast DNS Proxy 7.4. Multicast DNS Proxy
The designated MDNS [RFC6762] proxy on a Common Link is elected based The designated MDNS [RFC6762] proxy on a Common Link is elected based
on the capabilities described in Section 4. The winner is the router on the capabilities described in Section 4. The winner is the router
(connected to the Common Link) advertising the greatest M-capability. (connected to the Common Link) advertising the greatest M-capability.
In case of a tie, Capability Values are compared, and router with the In case of a tie, Capability Values (Section 4) are compared, and the
greatest value is elected. In case of another tie, the router with router with the greatest value is elected. In case of another tie,
the highest node identifier is elected among the routers with tied the router with the highest node identifier is elected among the
Capability Values. routers with tied Capability Values.
The elected router MUST provide an MDNS-proxy on the given link and The elected router MUST provide an MDNS-proxy on the given link and
announce it as described in Section 8. announce it as described in Section 8.
8. Naming and Service Discovery 8. Naming and Service Discovery
Network-wide naming and service discovery can greatly improve the Network-wide naming and service discovery can greatly improve the
user-friendliness of a network. The following mechanism provides user-friendliness of a network. The following mechanism provides
means to setup and delegate naming and service discovery across means to setup and delegate naming and service discovery across
multiple HNCP routers. multiple HNCP routers.
Each HNCP router SHOULD provide a recursive name resolution server Each HNCP router SHOULD provide and advertise a recursive name
which honors the announcements made in Delegated Zone TLVs resolving server to clients which honors the announcements made in
(Section 10.5), Domain Name TLVs (Section 10.6) and Node Name TLVs Delegated Zone TLVs (Section 10.5), Domain Name TLVs (Section 10.6)
(Section 10.7), i.e., delegate queries to the designated name servers and Node Name TLVs (Section 10.7), i.e., delegate queries to the
and hand out appropriate A, AAAA and PTR records according to the designated name servers and hand out appropriate A, AAAA and PTR
mentioned TLVs. records according to the mentioned TLVs.
Each HNCP router SHOULD provide and announce an auto-generated or Each HNCP router SHOULD provide and announce an auto-generated or
user-configured name for each internal Common Link (Section 6.1) for user-configured name for each internal Common Link (Section 6.1) for
which it is the designated DHCPv4, stateful DHCPv6 server, MDNS which it is the designated DHCPv4, stateful DHCPv6 server, MDNS
proxy, or for which it provides forward or reverse DNS services on proxy, or for which it provides forward or reverse DNS services on
behalf of connected devices. This announcement is done using behalf of connected devices. This announcement is done using
Delegated Zone TLVs (Section 10.5) and MUST be unique in the whole Delegated Zone TLVs (Section 10.5) and MUST be unique in the whole
network. In case of a conflict the announcement of the node with the network. In case of a conflict the announcement of the node with the
highest node identifier takes precedence and all other nodes MUST highest node identifier takes precedence and all other nodes MUST
cease to announce the conflicting TLV. HNCP routers providing name cease to announce the conflicting TLV. HNCP routers providing
resolving services MUST use the included DNS server address within recursive name resolving services MUST use the included DNS server
the TLV to resolve names belonging to the zone as if there was an NS address within the TLV to resolve names belonging to the zone as if
record. there was an NS record.
Each HNCP node SHOULD announce a node name for itself to be easily Each HNCP node SHOULD announce a node name for itself to be easily
reachable and MAY do so on behalf of other devices. Announcements reachable and MAY do so on behalf of other devices. Announcements
are made using Node Name TLVs (Section 10.7) and MUST be unique in are made using Node Name TLVs (Section 10.7) and MUST be unique in
the whole network. In case of a conflict the announcement of the the whole network. In case of a conflict the announcement of the
node with the highest node identifier takes precedence and all other node with the highest node identifier takes precedence and all other
nodes MUST cease to announce the conflicting TLV. HNCP routers nodes MUST cease to announce the conflicting TLV. HNCP routers
providing name resolving services MUST resolve these names to their providing recursive name resolving services as described above MUST
respective IP addresses as if there were corresponding A/AAAA resolve such announced names to their respective IP addresses as if
records. there were corresponding A/AAAA records.
Names and unqualified zones are used in an HNCP network to provide Names and unqualified zones are used in an HNCP network to provide
naming and service discovery with local significance. A network-wide naming and service discovery with local significance. A network-wide
zone is appended to all single labels or unqualified zones in order zone is appended to all single labels or unqualified zones in order
to qualify them. ".home" is the default, however an administrator MAY to qualify them. ".home" is the default, however an administrator MAY
configure announcing of a Domain Name TLV (Section 10.6) for the configure announcing of a Domain Name TLV (Section 10.6) for the
network to use a different one. In case multiple are announced, the network to use a different one. In case multiple are announced, the
domain of the node with the greatest node identifier takes domain of the node with the greatest node identifier takes
precedence. precedence.
skipping to change at page 22, line 12 skipping to change at page 22, line 25
using a suitable one-way hashing algorithm (e.g., by using HMAC- using a suitable one-way hashing algorithm (e.g., by using HMAC-
SHA256 [RFC6234] with a per-protocol HMAC-key) so that disclosure of SHA256 [RFC6234] with a per-protocol HMAC-key) so that disclosure of
any derived key does not impact other users of the managed PSK. any derived key does not impact other users of the managed PSK.
Furthermore derived PSKs MUST be updated whenever the managed PSK Furthermore derived PSKs MUST be updated whenever the managed PSK
changes. changes.
10. Type-Length-Value Objects 10. Type-Length-Value Objects
HNCP defines the following TLVs in addition to those defined by DNCP. HNCP defines the following TLVs in addition to those defined by DNCP.
The same general rules and defaults for encoding as noted in The same general rules and defaults for encoding as noted in
Section 7 of [I-D.ietf-homenet-dncp] apply. Section 7 of [I-D.ietf-homenet-dncp] apply. Note that most HNCP
variable-length TLVs also support optional nested TLVs, and they are
encoded after the variable length content, followed by the zero
padding of the variable length content to the next 32-bit boundary.
TLVs defined here are only valid when appearing in their designated TLVs defined here are only valid when appearing in their designated
context, i.e., only directly within container TLVs mentioned in their context, i.e., only directly within container TLVs mentioned in their
definition, or - absent any mentions - only as top-level TLVs within definition, or - absent any mentions - only as top-level TLVs within
the node data set. TLVs appearing outside their designated context the node data set. TLVs appearing outside their designated context
MUST be ignored. MUST be ignored.
Unless specified otherwise, TLVs encoding IP addresses or prefixes TLVs encoding IP addresses or prefixes allow encoding both IPv6 and
allow encoding both IPv6 and IPv4 addresses and prefixes. IPv6 IPv4 addresses and prefixes. IPv6 information is encoded as is,
information is encoded as is, whereas for IPv4 IPv4-mapped IPv6 whereas for IPv4 IPv4-mapped IPv6 addresses format [RFC4291] is used
addresses format [RFC4291] is used and prefix lengths are encoded as and prefix lengths are encoded as original IPv4 prefix length
original IPv4 prefix length increased by 96. increased by 96.
10.1. HNCP Version TLV 10.1. HNCP Version TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: HNCP-VERSION (32) | Length: >= 5 | | Type: HNCP-VERSION (32) | Length: >= 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | M | P | H | L | | Reserved | M | P | H | L |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-agent | | User-agent |
This TLV is used to indicate the supported version and router This TLV is used to indicate the supported version and router
capabilities of an HNCP node as described in Section 4. capabilities of an HNCP node as described in Section 4.
Version: Indicates which version of HNCP is currently in use by this
particular node. It MUST be set to 1. Nodes with different
versions are considered incompatible.
Reserved: Bits are reserved for future use. They MUST be set to 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
use. use.
skipping to change at page 23, line 35 skipping to change at page 23, line 45
User-Agent: The user-agent is a human-readable UTF-8 string that User-Agent: The user-agent is a human-readable UTF-8 string that
describes the name and version of the current HNCP implementation. describes the name and version of the current HNCP implementation.
10.2. External Connection TLV 10.2. External Connection TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: EXTERNAL-CONNECTION (33)| Length | | Type: EXTERNAL-CONNECTION (33)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested TLVs | | (Optional nested TLVs) |
An External Connection TLV is a container TLV used to gather network An External Connection TLV is a container TLV used to gather network
configuration information associated with a single external configuration information associated with a single external
connection (Section 6.2) to be shared across the HNCP network. A connection (Section 6.2) to be shared across the HNCP network. A
node MAY publish an arbitrary number of instances of this TLV to node MAY publish an arbitrary number of instances of this TLV to
share the desired number of external connections. share the desired number of external connections. Upon reception,
the information transmitted in any nested TLVs is used for the
purposes of prefix assignment (Section 6.3) and host configuration
(Section 7).
10.2.1. Delegated Prefix TLV 10.2.1. Delegated 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: DELEGATED-PREFIX (34) | Length: >= 9 | | Type: DELEGATED-PREFIX (34) | Length: >= 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime Since Origination | | Valid Lifetime Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime Since Origination | | Preferred Lifetime Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | | | Prefix Length | |
skipping to change at page 24, line 14 skipping to change at page 24, line 20
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: DELEGATED-PREFIX (34) | Length: >= 9 | | Type: DELEGATED-PREFIX (34) | Length: >= 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime Since Origination | | Valid Lifetime Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime Since Origination | | Preferred Lifetime Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | | | Prefix Length | |
+-+-+-+-+-+-+-+-+ Prefix [+ nested TLVs] + +-+-+-+-+-+-+-+-+ Prefix +
| | ...
| | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
The Delegated Prefix TLV is used by HNCP routers to advertise The Delegated Prefix TLV is used by HNCP routers to advertise
prefixes which are allocated to the whole network and can be used for prefixes which are allocated to the whole network and can be used for
prefix assignment. Delegated Prefix TLVs are only valid inside prefix assignment. Delegated Prefix TLVs are only valid inside
External Connection TLVs and their prefixes MUST NOT overlap with External Connection TLVs and their prefixes MUST NOT overlap with
those of other such TLVs in the same container. those of other such TLVs in the same container.
Valid Lifetime Since Origination: The time in seconds the delegated Valid Lifetime Since Origination: The time in seconds the delegated
prefix was valid for at the origination time of the node data prefix was valid for at the origination time of the node data
containing this TLV. The value MUST be updated whenever the node containing this TLV. The value MUST be updated whenever the node
skipping to change at page 24, line 38 skipping to change at page 24, line 47
Preferred Lifetime Since Origination: The time in seconds the Preferred Lifetime Since Origination: The time in seconds the
delegated prefix was preferred for at the origination time of the delegated prefix was preferred for at the origination time of the
node data containing this TLV. The value MUST be updated whenever node data containing this TLV. The value MUST be updated whenever
the node republishes its Node State TLV. the node republishes its Node State TLV.
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
starting at the next 32-bit boundary following the end of the
encoded prefix.
10.2.1.1. Prefix Policy TLV 10.2.1.1. Prefix Policy 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: PREFIX-POLICY (43) | Length: >= 1 | | Type: PREFIX-POLICY (43) | Length: >= 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy Type | | | Policy Type | |
+-+-+-+-+-+-+-+-+ Value + +-+-+-+-+-+-+-+-+ Value +
| | | |
The Prefix Policy TLV contains information about the policy or The Prefix Policy TLV contains information about the policy or
applicability of a delegated prefix. This information can be used to applicability of a delegated prefix. This information can be used to
determine whether prefixes for a certain usecase (e.g., local determine whether prefixes for a certain usecase (e.g., local
reachability, internet connectivity) do exist or should be acquired reachability, internet connectivity) do exist or 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. See Section 6.2 for a more in-depth fine-tune border firewalls. See Section 6.2 for a more in-depth
discussion. This TLV is only valid inside a Delegated Prefix TLV. discussion. This TLV is only valid inside a Delegated Prefix TLV.
Policy Type: The type of the policy identifier. Policy Type: The type of the policy identifier.
skipping to change at page 26, line 34 skipping to change at page 26, line 44
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier | | Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsv. | Prty. | Prefix Length | | | Rsv. | Prty. | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +
| | ...
| | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
This TLV is used to announce Published Assigned Prefixes for the This TLV is used to announce Published Assigned Prefixes for the
purposes of prefix assignment (Section 6.3). purposes of prefix assignment (Section 6.3).
Endpoint Identifier: The endpoint identifier of the local interface Endpoint Identifier: The endpoint identifier of the local interface
the prefix is assigned to, or 0 if it is assigned to a Private the prefix is assigned to, or 0 if it is assigned to a Private
Link (e.g., when the prefix is assigned for downstream prefix Link (e.g., when the prefix is assigned for downstream prefix
delegation). delegation).
Rsv.: Bits are reserved for future use. They MUST be set to zero Rsv.: Bits are reserved for future use. They MUST be set to zero
skipping to change at page 27, line 36 skipping to change at page 27, line 51
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: NODE-ADDRESS (36) | Length: 20 | | Type: NODE-ADDRESS (36) | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier | | Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IP Address | | IP Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
This TLV is used to announce addresses assigned to an HNCP node as This TLV is used to announce addresses assigned to an HNCP node as
described in Section 6.4. described in Section 6.4.
Endpoint Identifier: The endpoint identifier of the local interface Endpoint Identifier: The endpoint identifier of the local interface
the prefix is assigned to, or 0 if it is not assigned on an HNCP the prefix is assigned to, or 0 if it is not assigned on an HNCP
enabled link. enabled link.
IP Address: The globally scoped IPv6 address, or the IPv4 address IP Address: The globally scoped IPv6 address, or the IPv4 address
encoded as an IPv4-mapped IPv6 address [RFC4291]. encoded as an IPv4-mapped IPv6 address [RFC4291].
skipping to change at page 28, line 16 skipping to change at page 28, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: DNS-DELEGATED-ZONE (39) | Length: >= 17 | | Type: DNS-DELEGATED-ZONE (39) | Length: >= 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IP Address | | IP Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserved |L|B|S| | |Reserved |L|B|S| |
+-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) | +-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) |
| | ...
| | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
This TLV is used to announce a forward or reverse DNS zone delegation This TLV is used to announce a forward or reverse DNS zone delegation
in the HNCP network. Its meaning is roughly equivalent to specifying in the HNCP network. Its meaning is roughly equivalent to specifying
an NS and A/AAAA record for said zone. Details are specified in an NS and A/AAAA record for said zone. Details are specified in
Section 8. Section 8.
IP Address : The IPv6 address of the authoritative DNS server for IP Address : The IPv6 address of the authoritative DNS server for
the zone; IPv4 addresses are represented as IPv4-mapped addresses the zone; IPv4 addresses are represented as IPv4-mapped addresses
[RFC4291]. The special value of :: (all-zero) means the [RFC4291]. The special value of :: (all-zero) means the
delegation is available in the global DNS-hierarchy. delegation is available in the global DNS-hierarchy.
skipping to change at page 29, line 28 skipping to change at page 30, line 4
This TLV is used to indicate the base domain name for the network as This TLV is used to indicate the base domain name for the network as
specified in Section 8. This TLV MUST NOT be announced unless the specified in Section 8. This TLV MUST NOT be announced unless the
domain name was explicitly configured by an administrator. domain name was explicitly configured by an administrator.
Domain: The label sequence encoded according to [RFC1035]. Domain: The label sequence encoded according to [RFC1035].
Compression MUST NOT be used. The zone MUST end with an empty Compression MUST NOT be used. The zone MUST end with an empty
label. label.
10.7. Node Name TLV 10.7. Node Name TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: NODE-NAME (41) | Length: > 16 | | Type: NODE-NAME (41) | Length: > 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IP Address | | IP Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name (not null-terminated - variable length) | | Length | Name |
...
| (not null-terminated, variable length) | 0-pad if any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
This TLV is used to assign the name of a node in the network to a This TLV is used to assign the name of a node in the network to a
certain IP address as specified in Section 8. certain IP address as specified in Section 8.
IP Address: The IP address associated with the name. IPv4 IP Address: The IP address associated with the name. IPv4
addresses are encoded using IPv4-mapped IPv6 addresses. addresses are encoded using IPv4-mapped IPv6 addresses.
Name: The name of the node as a single DNS label (up to 63 Length: The length of the name (0-63).
characters, no leading length byte).
Name: The name of the node as a single DNS label.
10.8. Managed PSK TLV 10.8. Managed PSK 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: MANAGED-PSK (42) | Length: 32 | | Type: MANAGED-PSK (42) | Length: 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| | | |
| Random 256-bit PSK | | Random 256-bit PSK |
| | | |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) |
This TLV is used to announce a PSK for securing third-party protocols This TLV is used to announce a PSK for securing third-party protocols
exclusively supporting symmetric cryptography as specified in exclusively supporting symmetric cryptography as specified in
Section 9. Section 9.
11. General Requirements for HNCP Nodes 11. General Requirements for HNCP Nodes
Each node implementing HNCP is subject to the following requirements: Each node implementing HNCP is subject to the following requirements:
o It MUST implement HNCP-Versioning (Section 4) and Interface o It MUST implement HNCP-Versioning (Section 4) and Interface
skipping to change at page 31, line 38 skipping to change at page 32, line 16
* The section "LAN-Side Configuration" applies to interfaces not * The section "LAN-Side Configuration" applies to interfaces not
classified as external. classified as external.
* The requirement L-2 to assign a separate /64 to each LAN * The requirement L-2 to assign a separate /64 to each LAN
interface is replaced by the participation in the prefix interface is replaced by the participation in the prefix
assignment mechanism (Section 6.3) for each such interface. assignment mechanism (Section 6.3) for each such interface.
* The requirement L-9 is modified, in that the M flag MUST be set * The requirement L-9 is modified, in that the M flag MUST be set
if and only if a router connected to the respective Common Link if and only if a router connected to the respective Common Link
is advertising a non-zero H-capability. is advertising a non-zero H-capability. The O flag SHOULD
always be set.
* The requirement L-12 to make DHCPv6 options available is * The requirement L-12 to make DHCPv6 options available is
adapted, in that a CER SHOULD publish the subset of options adapted, in that a CER SHOULD publish the subset of options
using the DHCPv6 Data TLV in an External Connection TLV. using the DHCPv6 Data TLV in an External Connection TLV.
Similarly it SHOULD do the same for DHCPv4 options in a DHCPv4 Similarly it SHOULD do the same for DHCPv4 options in a DHCPv4
Data TLV. DHCPv6 options received inside an OPTION_IAPREFIX Data TLV. DHCPv6 options received inside an OPTION_IAPREFIX
[RFC3633] MUST be published using a DHCPv6 Data TLV inside the [RFC3633] MUST be published using a DHCPv6 Data TLV inside the
respective Delegated Prefix TLV. HNCP routers SHOULD make respective Delegated Prefix TLV. HNCP routers SHOULD make
relevant DHCPv6 and DHCPv4 options available to clients, i.e., relevant DHCPv6 and DHCPv4 options available to clients, i.e.,
options contained in External Connection TLVs that also include options contained in External Connection TLVs that also include
skipping to change at page 34, line 8 skipping to change at page 34, line 32
run in the home (like IGPs) provide - to a certain extent - similar run in the home (like IGPs) provide - to a certain extent - similar
security mechanisms. Most of these protocols do not support security mechanisms. Most of these protocols do not support
encryption and only support authentication based on pre-shared keys encryption and only support authentication based on pre-shared keys
natively. This influences the effectiveness of any encryption-based natively. This influences the effectiveness of any encryption-based
security mechanism deployed by HNCP as homenet routing information is security mechanism deployed by HNCP as homenet routing information is
thus usually not encrypted. thus usually not encrypted.
13. IANA Considerations 13. IANA Considerations
IANA should set up a registry for the (decimal values within range IANA should set up a registry for the (decimal values within range
0-1023) "HNCP DNCP-profile TLV Types" under "Distributed Node 0-1023) "HNCP TLV Types" under "Distributed Node Consensus Protocol
Consensus Protocol (DNCP)", with the following initial contents: [TO (DNCP)", with the following initial contents:
BE REMOVED BY RFC-EDITOR: Ideally as http://www.iana.org/assignments/
hncp-registry]
0-31: Reserved - specified in the DNCP registry 0-31: Reserved - specified in the DNCP registry
32: HNCP-Version 32: HNCP-Version
33: External-Connection 33: External-Connection
34: Delegated-Prefix 34: Delegated-Prefix
35: Assigned-Prefix 35: Assigned-Prefix
skipping to change at page 34, line 30 skipping to change at page 35, line 4
35: Assigned-Prefix 35: Assigned-Prefix
36: Node-Address 36: Node-Address
37: DHCPv4-Data 37: DHCPv4-Data
38: DHCPv6-Data 38: DHCPv6-Data
39: DNS-Delegated-Zone 39: DNS-Delegated-Zone
40: Domain-Name 40: Domain-Name
41: Node-Name 41: Node-Name
42: Managed-PSK 42: Managed-PSK
43: Prefix-Policy 43: Prefix-Policy
44-512: Free - policy of 'standards action' should be used. 44-512: Free - policy of 'RFC required' should be used.
512-767: Reserved - specified in the DNCP registry 512-767: Reserved - specified in the DNCP registry
768-1023: Reserved - to be used for per-implementation 768-1023: Reserved - to be used for per-implementation
experimentation. How collision is avoided is out of scope of this experimentation. How collision is avoided is out of scope of this
document. document.
HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP- HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP-
DTLS-PORT, as well as an IPv6 link-local multicast address All- DTLS-PORT, as well as an IPv6 link-local multicast address All-
Homenet-Nodes. Homenet-Nodes.
skipping to change at page 35, line 27 skipping to change at page 35, line 46
[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.
[I-D.ietf-homenet-prefix-assignment] [I-D.ietf-homenet-prefix-assignment]
Pfister, P., Paterson, B., and J. Arkko, "Distributed Pfister, P., Paterson, B., and J. Arkko, "Distributed
Prefix Assignment Algorithm", draft-ietf-homenet-prefix- Prefix Assignment Algorithm", draft-ietf-homenet-prefix-
assignment-07 (work in progress), June 2015. assignment-08 (work in progress), August 2015.
14.2. Informative references 14.2. Informative references
[RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
A., Beser, B., and J. Privat, "The User Class Option for A., Beser, B., and J. Privat, "The User Class Option for
DHCP", RFC 3004, November 2000. DHCP", RFC 3004, November 2000.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
skipping to change at page 36, line 34 skipping to change at page 37, line 12
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, February 2013.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011. 6241, June 2011.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless
Static Route Option for Dynamic Host Configuration
Protocol (DHCP) version 4", RFC 3442, December 2002.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [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.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, April 2014. Autoconfiguration (SLAAC)", RFC 7217, April 2014.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
Capabilities in Customer Premises Equipment (CPE) for
Providing Residential IPv6 Internet Service", RFC 6092,
DOI 10.17487/RFC6092, January 2011,
<http://www.rfc-editor.org/info/rfc6092>.
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-09: Added nested TLV definitions for variable
length TLVs. NOTE: Node name TLV encoding includes now length byte.
Version TLV now itself indicates version.
draft-ietf-homenet-hncp-08: Editorial reorganization. draft-ietf-homenet-hncp-08: Editorial reorganization.
draft-ietf-homenet-hncp-07: Using version 1 instead of version 0, as draft-ietf-homenet-hncp-07: Using version 1 instead of version 0, as
existing implementations already use it. existing implementations already use it.
draft-ietf-homenet-hncp-06: Various edits based on feedback, draft-ietf-homenet-hncp-06: Various edits based on feedback,
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
 End of changes. 58 change blocks. 
112 lines changed or deleted 144 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/