diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc7788.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc7788.txt')
| -rw-r--r-- | doc/rfc/rfc7788.txt | 2243 |
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc7788.txt b/doc/rfc/rfc7788.txt new file mode 100644 index 0000000..77061c0 --- /dev/null +++ b/doc/rfc/rfc7788.txt @@ -0,0 +1,2243 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Stenberg +Request for Comments: 7788 S. Barth +Category: Standards Track Independent +ISSN: 2070-1721 P. Pfister + Cisco Systems + April 2016 + + + Home Networking Control Protocol + +Abstract + + This document describes the Home Networking Control Protocol (HNCP), + an extensible configuration protocol, and a set of requirements for + home network devices. HNCP is described as a profile of and + extension to the Distributed Node Consensus Protocol (DNCP). HNCP + enables discovery of network borders, automated configuration of + addresses, name resolution, service discovery, and the use of any + routing protocol that supports routing based on both the source and + destination address. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7788. + + + + + + + + + + + + + + + + + +Stenberg, et al. Standards Track [Page 1] + +RFC 7788 Home Networking Control Protocol April 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 7 + 3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4. HNCP Versioning and Router Capabilities . . . . . . . . . . . 9 + 5. Interface Classification . . . . . . . . . . . . . . . . . . 9 + 5.1. Interface Categories . . . . . . . . . . . . . . . . . . 9 + 5.2. DHCP-Aided Auto-Detection . . . . . . . . . . . . . . . . 10 + 5.3. Algorithm for Border Discovery . . . . . . . . . . . . . 11 + 6. Autonomous Address Configuration . . . . . . . . . . . . . . 12 + 6.1. Common Link . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.2. External Connections . . . . . . . . . . . . . . . . . . 13 + 6.3. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 14 + 6.3.1. Prefix Assignment Algorithm Parameters . . . . . . . 14 + 6.3.2. Making New Assignments . . . . . . . . . . . . . . . 16 + 6.3.3. Applying Assignments . . . . . . . . . . . . . . . . 17 + 6.3.4. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . 17 + 6.4. Node Address Assignment . . . . . . . . . . . . . . . . . 17 + 6.5. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 18 + 7. Configuration of Hosts and Non-HNCP Routers . . . . . . . . . 19 + 7.1. IPv6 Addressing and Configuration . . . . . . . . . . . . 19 + 7.2. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 20 + 7.3. DHCPv4 for Addressing and Configuration . . . . . . . . . 20 + 7.4. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 21 + 8. Naming and Service Discovery . . . . . . . . . . . . . . . . 21 + 9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 22 + + + + + + + +Stenberg, et al. Standards Track [Page 2] + +RFC 7788 Home Networking Control Protocol April 2016 + + + 10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 23 + 10.1. HNCP-Version TLV . . . . . . . . . . . . . . . . . . . . 23 + 10.2. External-Connection TLV . . . . . . . . . . . . . . . . 24 + 10.2.1. Delegated-Prefix TLV . . . . . . . . . . . . . . . . 25 + 10.2.2. DHCPv6-Data TLV . . . . . . . . . . . . . . . . . . 27 + 10.2.3. DHCPv4-Data TLV . . . . . . . . . . . . . . . . . . 27 + 10.3. Assigned-Prefix TLV . . . . . . . . . . . . . . . . . . 28 + 10.4. Node-Address TLV . . . . . . . . . . . . . . . . . . . . 29 + 10.5. DNS-Delegated-Zone TLV . . . . . . . . . . . . . . . . . 30 + 10.6. Domain-Name TLV . . . . . . . . . . . . . . . . . . . . 31 + 10.7. Node-Name TLV . . . . . . . . . . . . . . . . . . . . . 31 + 10.8. Managed-PSK TLV . . . . . . . . . . . . . . . . . . . . 32 + 11. General Requirements for HNCP Nodes . . . . . . . . . . . . . 32 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 + 12.1. Interface Classification . . . . . . . . . . . . . . . . 34 + 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 35 + 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 35 + 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 37 + 14.2. Informative References . . . . . . . . . . . . . . . . . 39 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 + +1. Introduction + + The Home Networking Control Protocol (HNCP) is designed to facilitate + the sharing of state among home routers to fulfill the needs of the + IPv6 homenet architecture [RFC7368], which assumes zero-configuration + operation, multiple subnets, multiple home routers, and (potentially) + multiple upstream service providers providing (potentially) multiple + prefixes to the home network. While RFC 7368 sets no requirements + for IPv4 support, HNCP aims to support the dual-stack mode of + operation, and therefore the functionality is designed with that in + mind. The state is shared as TLVs transported in the DNCP node state + among the routers (and potentially advanced hosts) to enable: + + o Autonomic discovery of network borders (Section 5.3) based on + Distributed Node Consensus Protocol (DNCP) topology. + + o Automated portioning of prefixes delegated by the service + providers as well as assigned prefixes to both HNCP and non-HNCP + routers (Section 6.3) using [RFC7695]. Prefixes assigned to HNCP + routers are used to: + + * Provide addresses to non-HNCP aware nodes (using Stateless + Address Autoconfiguration (SLAAC) and DHCP). + + + + +Stenberg, et al. Standards Track [Page 3] + +RFC 7788 Home Networking Control Protocol April 2016 + + + * Provide space in which HNCP nodes assign their own addresses + (Section 6.4). + + o Internal and external name resolution, as well as multi-link + service discovery (Section 8). + + o Other services not defined in this document that do need to share + state among homenet nodes and do not cause rapid and constant TLV + changes (see the following applicability section). + + HNCP is a protocol based on DNCP [RFC7787] and includes a DNCP + profile that defines transport and synchronization details for + sharing state across nodes defined in Section 3. The rest of the + document defines behavior of the services noted above, how the + required TLVs are encoded (Section 10), as well as additional + requirements on how HNCP nodes should behave (Section 11). + +1.1. Applicability + + While HNCP does not deal with routing protocols directly (except + potentially informing them about internal and external interfaces if + classification specified in Section 5.3 is used), in homenet + environments where multiple IPv6 source prefixes can be present, + routing based on the source and destination address is necessary + [RFC7368]. Ideally, the routing protocol is also zero configuration + (e.g., no need to configure identifiers or metrics), although HNCP + can also be used with a manually configured routing protocol. + + As HNCP uses DNCP as the actual state synchronization protocol, the + applicability statement of DNCP applies here as well; HNCP should not + be used for any data that changes rapidly and constantly. If such + data needs to be published in an HNCP network, 1) a more applicable + protocol should be used for those portions, and 2) locators to a + server of said protocol should be announced using HNCP instead. An + example for this is naming and service discovery (Section 8) for + which HNCP only transports DNS server addresses and no actual per- + name or per-service data of hosts. + + HNCP TLVs specified within this document, in steady state, stay + constant, with one exception: as Delegated-Prefix TLVs + (Section 10.2.1) do contain lifetimes, they force republishing of + that data every time the valid or preferred lifetimes of prefixes are + updated (significantly). Therefore, it is desirable for ISPs to + provide large enough valid and preferred lifetimes to avoid + unnecessary HNCP state churn in homes, but even given non-cooperating + ISPs, the state churn is proportional only to the number of + externally received delegated prefixes and not to the home network + size, and it should therefore be relatively low. + + + +Stenberg, et al. Standards Track [Page 4] + +RFC 7788 Home Networking Control Protocol April 2016 + + + HNCP assumes a certain level of control over host configuration + servers (e.g., DHCP [RFC2131]) on links that are managed by its + routers. Some HNCP functionality (such as border discovery or some + aspects of naming) might be affected by existing DHCP servers that + are not aware of the HNCP-managed network and thus might need to be + reconfigured to not result in unexpected behavior. + + While HNCP routers can provide configuration to and receive + configuration from non-HNCP routers, they are not able to traverse + such devices based solely on the protocol as defined in this + document, i.e., HNCP routers that are connected only by different + interfaces of a non-HNCP router will not be part of the same HNCP + network. + + While HNCP is designed to be used by (home) routers, it can also be + used by advanced hosts that want to do, e.g., their own address + assignment and routing. + + HNCP is link-layer agnostic; if a link supports IPv6 (link-local) + multicast and unicast, HNCP will work on it. Trickle retransmissions + and keep-alives will handle both packet loss and non-transitive + connectivity, ensuring eventual convergence. + +2. Terminology + + The following terms are used as they are defined in [RFC7695]: + + o Advertised Prefix Priority + + o Advertised Prefix + + o Assigned Prefix + + o Delegated Prefix + + o Prefix Adoption + + o Private Link + + o Published Assigned Prefix + + o Applied Assigned Prefix + + o Shared Link + + + + + + + +Stenberg, et al. Standards Track [Page 5] + +RFC 7788 Home Networking Control Protocol April 2016 + + + The following terms are used as they are defined in [RFC7787]: + + o DNCP profile + + o Node identifier + + o Link + + o Interface + + (HNCP) node a device implementing this specification. + + (HNCP) router a device implementing this specification, which + forwards traffic on behalf of other devices. + + Greatest node when comparing the DNCP node identifiers of + identifier multiple nodes, the one that has the greatest value + in a bitwise comparison. + + Border separation point between administrative domains; in + this case, between the home network and any other + network, i.e., usually an ISP network. + + Internal link a link that does not cross borders. + + Internal an interface that is connected to an internal link. + interface + + External an interface that is connected to a link that is + interface not an internal link. + + Interface a local configuration denoting the use of a + category particular interface. The Interface category + determines how an HNCP node should treat the + particular interface. The External and Internal + categories mark the interface as out of or within + the network border; there are also a number of + subcategories of Internal that further affect local + node behavior. See Section 5.1 for a list of + interface categories and how they behave. The + Internal or External category may also be auto- + detected (Section 5.3). + + Border router a router announcing external connectivity and + forwarding traffic across the network border. + + + + + + +Stenberg, et al. Standards Track [Page 6] + +RFC 7788 Home Networking Control Protocol April 2016 + + + Common Link a set of nodes on a link that share a common view + of it, i.e., they see each other's traffic and the + same set of hosts. Unless configured otherwise, + transitive connectivity is assumed. + + DHCPv4 refers to the Dynamic Host Configuration Protocol + [RFC2131] in this document. + + DHCPv6 refers to the Dynamic Host Configuration Protocol + for IPv6 (DHCPv6) [RFC3315] in this document. + + DHCP refers to cases that apply to both DHCPv4 and + DHCPv6 in this document. + +2.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + +3. DNCP Profile + + The DNCP profile for HNCP is defined as follows: + + o HNCP uses UDP datagrams on port 8231 as a transport over link- + local scoped IPv6, using unicast and multicast + (FF02:0:0:0:0:0:0:11 is the HNCP group address). Received + datagrams where either or both of the IPv6 source or destination + addresses are not link-local scoped MUST be ignored. Replies to + multicast and unicast messages MUST be sent to the IPv6 source + address and port of the original message. Each node MUST be able + to receive (and potentially reassemble) UDP datagrams with a + payload of at least 4000 bytes. + + o HNCP operates on multicast-capable interfaces only. HNCP nodes + MUST assign a non-zero 32-bit endpoint identifier to each + interface for which HNCP is enabled. The value 0 is not used in + DNCP TLVs but has a special meaning in HNCP TLVs (see Sections 6.4 + and 10.3). These identifiers MUST be locally unique within the + scope of the node, and using values equivalent to the IPv6 link- + local scope identifiers for the given interfaces are RECOMMENDED. + + o HNCP uses opaque 32-bit node identifiers + (DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP + SHOULD use a random node identifier. If there is a node + identifier collision (as specified in the Node-State TLV handling + of Section 4.4 of [RFC7787]), the node MUST immediately generate + + + +Stenberg, et al. Standards Track [Page 7] + +RFC 7788 Home Networking Control Protocol April 2016 + + + and use a new random node identifier that is not used by any other + node at the time, based on the current DNCP network state. + + o HNCP nodes MUST use the leading 64 bits of the MD5 message digest + [RFC1321] as the DNCP hash function H(x) used in building the DNCP + hash tree. + + o HNCP nodes MUST use DNCP's per-endpoint keep-alive extension on + all endpoints. The following parameters are suggested: + + * Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20 + seconds. + + * Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1 on virtually + lossless links works fine, as it allows for one lost keep- + alive. If used on a lossy link, a considerably higher + multiplier, such as 15, should be used instead. In that case, + an implementation might prefer shorter keep-alive intervals on + that link as well to ensure that the timeout (equal to + DNCP_KEEPALIVE_INTERVAL * DNCP_KEEPALIVE_MULTIPLIER) after + which entirely lost nodes time out is low enough. + + o HNCP nodes use the following Trickle parameters for the per- + interface Trickle instances: + + * k SHOULD be 1, as the timer reset when data is updated, and + further retransmissions should handle packet loss. Even on a + non-transitive lossy link, the eventual per-endpoint keep- + alives should ensure status synchronization occurs. + + * Imin SHOULD be 200 milliseconds but MUST NOT be lower. Note: + earliest transmissions may occur at Imin / 2. + + * Imax SHOULD be 7 doublings of Imin [RFC6206] but MUST NOT be + lower. + + o HNCP unicast traffic SHOULD be secured using Datagram Transport + Layer Security (DTLS) [RFC6347] as described in DNCP if exchanged + over unsecured links. UDP on port 8232 is used for this purpose. + A node implementing HNCP security MUST support the DNCP Pre-Shared + Key (PSK) method, SHOULD support the PKI-based trust method, and + MAY support the DNCP certificate-based trust consensus method. + [RFC7525] provides guidance on how to securely utilize DTLS. + + o HNCP nodes MUST ignore all Node-State TLVs received via multicast + on a link that has DNCP security enabled in order to prevent + spoofing of node state changes. + + + + +Stenberg, et al. Standards Track [Page 8] + +RFC 7788 Home Networking Control Protocol April 2016 + + +4. HNCP Versioning and Router Capabilities + + Multiple versions of HNCP based on compatible DNCP profiles may be + present in the same network when transitioning between HNCP versions, + and for troubleshooting purposes, it might be beneficial to identify + the HNCP agent version running. Therefore, each node MUST include an + HNCP-Version TLV (Section 10.1) indicating the currently supported + version in its node data and MUST ignore (except for DNCP + synchronization purposes) any TLVs that have a type greater than 32 + and that are published by nodes that didn't also publish an HNCP- + Version TLV. + + HNCP routers may also have different capabilities regarding + interactions with hosts, e.g., for configuration or service + discovery. These are indicated by M, P, H, and L values. The + combined "capability value" is a metric indicated by interpreting the + bits as an integer, i.e., (M << 12 | P << 8 | H << 4 | L). These + values are used to elect certain servers on a Common Link, as + described in Section 7. Nodes that are not routers MUST announce the + value 0 for all capabilities. Any node announcing the value 0 for a + capability is considered to not advertise said capability and thus + does not take part in the respective election. + +5. Interface Classification + +5.1. Interface Categories + + HNCP specifies the following categories that interfaces can be + configured to be in: + + Internal category: This declares an interface to be internal, i.e., + within the borders of the HNCP network. The interface MUST + operate as a DNCP endpoint. Routers MUST forward traffic with + appropriate source addresses between their internal interfaces and + allow internal traffic to reach external networks. All nodes MUST + implement this category, and nodes not implementing any other + category implicitly use it as a fixed default. + + External category: This declares an interface to be external, i.e., + not within the borders of the HNCP network. The interface MUST + NOT operate as a DNCP endpoint. Accessing internal resources from + external interfaces is restricted, i.e., the use of Recommended + Simple Security Capabilities in Customer Premises Equipments + (CPEs) [RFC6092] is RECOMMENDED. HNCP routers SHOULD announce + acquired configuration information for use in the network as + described in Section 6.2, if the interface appears to be connected + to an external network. HNCP routers MUST implement this + category. + + + +Stenberg, et al. Standards Track [Page 9] + +RFC 7788 Home Networking Control Protocol April 2016 + + + Leaf category: This declares an interface used by client devices + only. Such an interface uses the Internal category with the + exception that it MUST NOT operate as a DNCP endpoint. This + category SHOULD be supported by HNCP routers. + + Guest category: This declares an interface used by untrusted client + devices only. In addition to the restrictions of the Leaf + category, HNCP routers MUST filter traffic from and to the + interface such that connected devices are unable to reach other + devices inside the HNCP network or query services advertised by + them unless explicitly allowed. This category SHOULD be supported + by HNCP routers. + + Ad Hoc category: This configures an interface to use the Internal + category, but no assumption is made about the link's transitivity. + All other interface categories assume transitive connectivity. + This affects the Common Link (Section 6.1) definition. Support + for this category is OPTIONAL. + + Hybrid category: This declares an interface to use the Internal + category while still trying to acquire (external) configuration + information on it, e.g., by running DHCP clients. This is useful, + e.g., if the link is shared with a non-HNCP router under control + and still within the borders of the same network. Detection of + this category automatically in addition to manual configuration is + out of scope of this document. Support for this category is + OPTIONAL. + +5.2. DHCP-Aided Auto-Detection + + Auto-detection of interface categories is possible based on + interaction with DHCPv4 [RFC2131] and DHCPv6 Prefix Delegation + (DHCPv6-PD) [RFC3633] servers on connected links. HNCP defines + special DHCP behavior to differentiate its internal servers from + external ones in order to achieve this. Therefore, all internal + devices (including HNCP nodes) running DHCP servers on links where + auto-detection is used by any HNCP node MUST use the following + mechanism based on "The User Class Option for DHCP" [RFC3004] and its + DHCPv6 counterpart [RFC3315]: + + o The device MUST ignore or reject DHCP-Requests containing a DHCP + user class consisting of the ASCII string "HOMENET". + + Not following this rule (e.g., running unmodified DHCP servers) might + lead to false positives when auto-detection is used, i.e., HNCP nodes + assume an interface to not be internal, even though it was intended + to be. + + + + +Stenberg, et al. Standards Track [Page 10] + +RFC 7788 Home Networking Control Protocol April 2016 + + +5.3. Algorithm for Border Discovery + + This section defines the interface classification algorithm. It is + suitable for both IPv4 and IPv6 (single or dual stack) and detects + the category of an interface either automatically or based on a fixed + configuration. By determining the category for all interfaces, the + network borders are implicitly defined, i.e., all interfaces not + belonging to the External category are considered to be within the + borders of the network; all others are not. + + The following algorithm MUST be implemented by any node implementing + HNCP. However, if the node does not implement auto-detection, only + the first and last step are required. The algorithm works as + follows, with evaluation stopping at first match: + + 1. If a fixed category is configured for an interface, it is used. + + 2. If a delegated prefix could be acquired by running a DHCPv6 + client, it is considered external. The DHCPv6 client MUST have + included a DHCPv6 user class consisting of the ASCII string + "HOMENET" in all of its requests. + + 3. If an IPv4 address could be acquired by running a DHCPv4 client + on the interface, it is considered external. The DHCPv4 client + MUST have included a DHCP user class consisting of the ASCII + string "HOMENET" in all of its requests. + + 4. The interface is considered internal. + + Note that as other HNCP nodes will ignore the client due to the User + Class option, any server that replies is clearly external (or a + malicious internal node). + + An HNCP router SHOULD allow setting the fixed category for each + interface that may be connected to either an internal or external + device (e.g., an Ethernet port that can be connected to a modem, + another HNCP router, or a client). Note that all fixed categories + except internal and external cannot be auto-detected and can only be + selected using manual configuration. + + An HNCP router using auto-detection on an interface MUST run the + appropriately configured DHCP clients as long as the interface + without a fixed category is active (including states where auto- + detection considers it to be internal) and rerun the algorithm above + to react to conditions resulting in a different interface category. + The router SHOULD wait for a reasonable time period (5 seconds as a + + + + + +Stenberg, et al. Standards Track [Page 11] + +RFC 7788 Home Networking Control Protocol April 2016 + + + default), during which the DHCP clients can acquire a lease, before + treating a newly activated or previously external interface as + internal. + +6. Autonomous Address Configuration + + This section specifies how HNCP nodes configure host and node + addresses. At first, border routers share information obtained from + service providers or local configuration by publishing one or more + External-Connection TLVs (Section 10.2). These contain other TLVs + such as Delegated-Prefix TLVs (Section 10.2.1) that are then used for + prefix assignment. Finally, HNCP nodes obtain addresses either + statelessly or using a specific stateful mechanism (Section 6.4). + Hosts and non-HNCP routers are configured using SLAAC, DHCP, or + DHCPv6-PD. + +6.1. Common Link + + HNCP uses the concept of Common Link both in autonomic address + configuration and naming and service discovery (Section 8). A Common + Link refers to the set of interfaces of nodes that see each other's + traffic and presumably also the traffic of all hosts that may use the + nodes to, e.g., forward traffic. Common Links are used, e.g., to + determine where prefixes should be assigned or which peers + participate in the election of a DHCP server. The Common Link is + computed separately for each local internal interface, and it always + contains the local interface. Additionally, if the local interface + is not set to the Ad Hoc category (see Section 5.1), it also contains + the set of interfaces that are bidirectionally reachable from the + given local interface; that is, every remote interface of a remote + node meeting all of the following requirements: + + o The local node publishes a Peer TLV with: + + * Peer Node Identifier = remote node's node identifier + + * Peer Endpoint Identifier = remote interface's endpoint + identifier + + * Endpoint Identifier = local interface's endpoint identifier + + o The remote node publishes a Peer TLV with: + + * Peer Node Identifier = local node's node identifier + + * Peer Endpoint Identifier = local interface's endpoint + identifier + + + + +Stenberg, et al. Standards Track [Page 12] + +RFC 7788 Home Networking Control Protocol April 2016 + + + * Endpoint Identifier = remote interface's endpoint identifier + + A node MUST be able to detect whether two of its local internal + interfaces are connected, e.g., by detecting an identical remote + interface being part of the Common Links of both local interfaces. + +6.2. External Connections + + Each HNCP router MAY obtain external connection information such as + address prefixes, DNS server addresses, and DNS search paths from one + or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241], or + static configuration. Each individual external connection to be + shared in the network is represented by one External-Connection TLV + (Section 10.2). + + Announcements of individual external connections can consist of the + following components: + + Delegated Prefixes: Address space available for assignment to + internal links announced using Delegated-Prefix TLVs + (Section 10.2.1). Some address spaces might have special + properties that are necessary to understand in order to handle + them (e.g., information similar to [RFC6603]). This information + is encoded using DHCPv6-Data TLVs (Section 10.2.2) inside the + respective Delegated-Prefix TLVs. + + Auxiliary Information: Information about services such as DNS or + time synchronization regularly used by hosts in addition to + addressing and routing information. This information is encoded + using DHCPv6-Data TLVs (Section 10.2.2) and DHCPv4-Data TLVs + (Section 10.2.3). + + Whenever information about reserved parts (e.g., as specified in + [RFC6603]) is received for a delegated prefix, the reserved parts + MUST be advertised using Assigned-Prefix TLVs (Section 10.3) with the + greatest priority (i.e., 15), as if they were assigned to a Private + Link. + + Some connections or delegated prefixes may have a special meaning and + are not regularly used for internal or Internet connectivity; + instead, they may provide access to special services like VPNs, + sensor networks, Voice over IP (VoIP), IPTV, etc. Care must be taken + that these prefixes are properly integrated and dealt with in the + network, in order to avoid breaking connectivity for devices who are + not aware of their special characteristics or to only selectively + allow certain devices to use them. Such prefixes are distinguished + using Prefix-Policy TLVs (Section 10.2.1.1). Their contents MAY be + + + + +Stenberg, et al. Standards Track [Page 13] + +RFC 7788 Home Networking Control Protocol April 2016 + + + partly opaque to HNCP nodes, and their identification and usage + depends on local policy. However, the following general rules MUST + be adhered to: + + Special rules apply when making address assignments for prefixes + with Prefix-Policy TLVs with type 131, as described in + Section 6.3.2. + + In the presence of any type 1 to 128 Prefix-Policy TLV, the prefix + is specialized to reach destinations denoted by any such Prefix- + Policy TLV, i.e., in absence of a type 0 Prefix-Policy TLV, it is + not usable for general Internet connectivity. An HNCP router MAY + enforce this restriction with appropriate packet filter rules. + +6.3. Prefix Assignment + + HNCP uses the prefix assignment algorithm [RFC7695] in order to + assign prefixes to HNCP internal links and uses some of the + terminology (Section 2) defined there. HNCP furthermore defines the + Assigned-Prefix TLV (Section 10.3), which MUST be used to announce + Published Assigned Prefixes. + +6.3.1. Prefix Assignment Algorithm Parameters + + All HNCP nodes running the prefix assignment algorithm use the + following values for its parameters: + + Node IDs: HNCP node identifiers are used. The comparison operation + is defined as bitwise comparison. + + Set of Delegated Prefixes: The set of prefixes encoded in + Delegated-Prefix TLVs that are not strictly included in prefixes + encoded in other Delegated-Prefix TLVs. Note that Delegated- + Prefix TLVs included in ignored External-Connection TLVs are not + considered. It is dynamically updated as Delegated-Prefix TLVs + are added or removed. + + Set of Shared Links: The set of Common Links associated with + interfaces with the Internal, Leaf, Guest, or Ad Hoc category. It + is dynamically updated as interfaces are added, removed, or + switched from one category to another. When multiple interfaces + are detected as belonging to the same Common Link, prefix + assignment is disabled on all of these interfaces except one. + + + + + + + + +Stenberg, et al. Standards Track [Page 14] + +RFC 7788 Home Networking Control Protocol April 2016 + + + Set of Private Links: This document defines Private Links as + representing DHCPv6-PD clients or as a mean to advertise prefixes + included in the DHCPv6 Exclude Prefix option. Other + implementation-specific Private Links may be defined whenever a + prefix needs to be assigned for a purpose that does not require a + consensus with other HNCP nodes. + + Set of Advertised Prefixes: The set of prefixes included in + Assigned-Prefix TLVs advertised by other HNCP nodes (prefixes + advertised by the local node are not in this set). The associated + Advertised Prefix Priority is the priority specified in the TLV. + The associated Shared Link is determined as follows: + + * If the Link Identifier is 0, the Advertised Prefix is not + assigned on a Shared Link. + + * If the other node's interface identified by the Link Identifier + is included in one of the Common Links used for prefix + assignment, it is considered as assigned on the given Common + Link. + + * Otherwise, the Advertised Prefix is not assigned on a Shared + Link. + + Advertised Prefixes as well as their associated priorities and + associated Shared Links MUST be updated as Assigned-Prefix TLVs + are added, updated, or removed, and as Common Links are modified. + + ADOPT_MAX_DELAY: The default value is 0 seconds (i.e., prefix + adoption is done instantly). + + BACKOFF_MAX_DELAY: The default value is 4 seconds. + + RANDOM_SET_SIZE: The default value is 64. + + Flooding Delay: The default value is 5 seconds. + + Default Advertised Prefix Priority: When a new assignment is + created or an assignment is adopted -- as specified in the prefix + assignment algorithm routine -- the default Advertised Prefix + Priority to be used is 2. + + + + + + + + + + +Stenberg, et al. Standards Track [Page 15] + +RFC 7788 Home Networking Control Protocol April 2016 + + +6.3.2. Making New Assignments + + Whenever the prefix assignment algorithm subroutine (Section 4.1 of + [RFC7695]) is run on a Common Link, and whenever a new prefix may be + assigned (case 1 of the subroutine: no Best Assignment and no Current + Assignment), the decision of whether the assignment of a new prefix + is desired MUST follow these rules in order: + + If the Delegated-Prefix TLV contains a DHCPv6-Data TLV, and the + meaning of one of the DHCP options is not understood by the HNCP + node, 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 + is another delegated prefix of the same IP version used for prefix + assignment with a non-zero preferred lifetime, the creation of a + new prefix is not desired. + + If the Delegated-Prefix TLV does not include a Prefix-Policy TLV + indicating restrictive assignment (type 131) or if local policy + exists to identify it based on, e.g., other Prefix-Policy TLV + values and allows assignment, the creation of a new prefix is + desired. + + Otherwise, the creation of a new prefix is not desired. + + If the considered delegated prefix is an IPv6 prefix, and whenever + there is at least one available prefix of length 64, a prefix of + length 64 MUST be selected unless configured otherwise. In case no + prefix of length 64 would be available, a longer prefix MAY be + selected even without configuration. + + If the considered delegated prefix is an IPv4 prefix (Section 6.5 + details how IPv4-delegated prefixes are generated), a prefix of + length 24 SHOULD be preferred. + + In any case, an HNCP router making an assignment MUST support a + mechanism suitable to distribute addresses from the considered prefix + if the link is intended to be used by clients. In this case, a + router assigning an IPv4 prefix MUST announce the L-capability, and a + router assigning an IPv6 prefix with a length greater than 64 MUST + announce the H-capability as defined in Section 4. + + + + + + + + +Stenberg, et al. Standards Track [Page 16] + +RFC 7788 Home Networking Control Protocol April 2016 + + +6.3.3. Applying Assignments + + The prefix assignment algorithm indicates when a prefix is applied to + the respective Common Link. When that happens, each router connected + to said link: + + MUST forward traffic destined to said prefix to the respective + link. + + MUST participate in the client configuration election as described + in Section 7, if the link is intended to be used by clients. + + MAY add an address from said prefix to the respective network + interface as described in Section 6.4, e.g., if it is to be used + as source for locally originating traffic. + +6.3.4. DHCPv6 Prefix Delegation + + When an HNCP router announcing the P-Capability (Section 4) receives + a DHCPv6-PD request from a client, it SHOULD assign one prefix per + delegated prefix in the network. This set of assigned prefixes is + then delegated to the client, after it has been applied as described + in the prefix assignment algorithm. Each DHCPv6-PD client MUST be + considered as an independent Private Link, and delegation MUST be + based on the same set of delegated prefixes as the one used for + Common Link prefix assignments; however, the prefix length to be + delegated MAY be smaller than 64. + + The assigned prefixes MUST NOT be given to DHCPv6-PD clients before + they are applied and MUST be withdrawn whenever they are destroyed. + As an exception to this rule, in order to shorten delays of processed + requests, a router MAY prematurely give out a prefix that is + advertised but not yet applied if it does so with a valid lifetime of + not more than 30 seconds and ensures removal or correction of + lifetimes as soon as possible. + +6.4. Node Address Assignment + + 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 + Applied Assigned Prefix. Each HNCP node SHOULD announce an IPv6 + address and -- if it supports IPv4 -- MUST announce an IPv4 address, + whenever matching prefixes are assigned to at least one of 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. + + + +Stenberg, et al. Standards Track [Page 17] + +RFC 7788 Home Networking Control Protocol April 2016 + + + Stateless assignment based on Semantically Opaque Interface + Identifiers [RFC7217] SHOULD be used for address assignment whenever + possible (e.g., the prefix length is 64), otherwise (e.g., for IPv4 + if supported) the following method MUST be used instead: For any + assigned prefix for which stateless assignment is not used, the first + quarter of the addresses are reserved for HNCP-based address + assignments, whereas the last three quarters are left to the DHCP + elected router (Section 4 specifies the DHCP server election + process). For example, if the prefix 192.0.2.0/24 is 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 nodes assign addresses to themselves and then (to ensure + eventual lack of conflicting assignments) publish the assignments + using the Node-Address TLV (Section 10.4). + + The process of obtaining addresses is specified as follows: + + o A node MUST NOT start advertising an address if it is already + advertised by another node. + + o An assigned address MUST be part of an assigned prefix currently + applied on a Common Link that includes the interface specified by + the endpoint identifier. + + o An address MUST NOT be used unless it has been advertised for at + least ADDRESS_APPLY_DELAY consecutive seconds and is still + currently being advertised. The default value for + ADDRESS_APPLY_DELAY is 3 seconds. + + o Whenever the same address is advertised by more than one node, all + but the one advertised by the node with the greatest node + identifier MUST be removed. + +6.5. Local IPv4 and ULA Prefixes + + HNCP routers can create a Unique Local Address (ULA) or private IPv4 + prefix to enable connectivity between local devices. These prefixes + are inserted in HNCP as if they were delegated prefixes of a + (virtual) external connection (Section 6.2). The following rules + apply: + + An HNCP router SHOULD create a ULA prefix if there is no other + IPv6 prefix with a preferred time greater than 0 in the network. + It MAY also do so if there are other delegated IPv6 prefixes, but + none of which is locally generated (i.e., without any Prefix- + Policy TLV) and has a preferred time greater than 0. However, it + + + +Stenberg, et al. Standards Track [Page 18] + +RFC 7788 Home Networking Control Protocol April 2016 + + + MUST NOT do so otherwise. In case multiple locally generated ULA + prefixes are present, only the one published by the node with the + greatest node identifier is kept among those with a preferred time + greater than 0 -- if there is any. + + An HNCP router MUST create a private IPv4 prefix [RFC1918] + whenever it wishes to provide IPv4 Internet connectivity to the + network and no other private IPv4 prefix with Internet + connectivity currently exists. It MAY also enable local IPv4 + connectivity by creating a private IPv4 prefix if no IPv4 prefix + exists but MUST NOT do so otherwise. In case multiple IPv4 + prefixes are announced, only the one published by the node with + the greatest node identifier is kept among those with a Prefix- + Policy TLV of type 0 -- if there is any. The router publishing a + prefix with Internet connectivity MUST forward IPv4 traffic to the + Internet and perform NAT on behalf of the network as long as it + publishes the prefix; other routers in the network MAY choose not + to. + + Creation of such ULA and IPv4 prefixes MUST be delayed by a random + time span between 0 and 10 seconds in which the router MUST scan for + others trying to do the same. + + When a new ULA prefix is created, the prefix is selected based on the + configuration, using the last non-deprecated ULA prefix, or generated + based on [RFC4193]. + +7. Configuration of Hosts and Non-HNCP Routers + + HNCP routers need to ensure that hosts and non-HNCP downstream + routers on internal links are configured with addresses and routes. + Since DHCP clients can usually only bind to one server at a time, a + per-link and per-service election takes place. + + HNCP routers may have different capabilities for configuring + downstream devices and providing naming services. Each router MUST + therefore indicate its capabilities as specified in Section 4 in + order to participate as a candidate in the election. + +7.1. IPv6 Addressing and Configuration + + In general, Stateless Address Autoconfiguration [RFC4861] is used for + client configuration for its low overhead and fast renumbering + capabilities. Therefore, each HNCP router sends Router + Advertisements on interfaces that are intended to be used by clients + and MUST at least include a Prefix Information Option for each + Applied Assigned Prefix that it assigned to the respective link in + every such advertisement. However, stateful DHCPv6 can be used in + + + +Stenberg, et al. Standards Track [Page 19] + +RFC 7788 Home Networking Control Protocol April 2016 + + + 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) + is elected based on the capabilities described in Section 4. The + winner is the router (connected to the Common Link) advertising the + greatest H-capability. In case of a tie, Capability Values + (Section 4) are compared, and the router with the greatest value is + elected. In case of another tie, the router with the greatest node + identifier is elected among the routers with tied Capability Values. + + The elected router MUST serve stateful DHCPv6 and SHOULD provide + naming services for acquired hostnames as outlined in Section 8; all + other nodes MUST NOT. Stateful addresses SHOULD be assigned in a way + that does not hinder fast renumbering even if the DHCPv6 server or + client do not support the DHCPv6 reconfigure mechanism, e.g., by only + 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 that 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 + + The designated DHCPv6 server for prefix delegation on a Common Link + is elected based on the capabilities described in Section 4. The + winner is the router (connected to the Common Link) advertising the + greatest P-capability. In case of a tie, Capability Values + (Section 4) are compared, and the router with the greatest value is + elected. In case of another tie, the router with the greatest node + identifier is elected among the routers with tied Capability Values. + + The elected router MUST provide prefix delegation services [RFC3633] + 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 + + The designated DHCPv4 server on a Common Link (Section 6.1) is + elected based on the capabilities described in Section 4. The winner + is the router (connected to the Common Link) advertising the greatest + L-capability. In case of a tie, Capability Values (Section 4) are + compared, and the router with the greatest value is elected. In case + of another tie, the router with the greatest node identifier is + elected among the routers with tied Capability Values. + + + +Stenberg, et al. Standards Track [Page 20] + +RFC 7788 Home Networking Control Protocol April 2016 + + + The elected router MUST provide DHCPv4 services on the given link; + all other nodes MUST NOT. The elected router MUST provide IP + addresses from the pool defined in Section 6.4 and MUST announce + itself as router [RFC2132] to clients. + + DHCPv4 lifetimes renew and rebind times (T1 and T2) SHOULD be short + (i.e., not longer than 5 minutes) in order to provide reasonable + response times to changes. Routers that cease to be elected DHCP + servers SHOULD -- when applicable -- invalidate remaining existing + bindings in order to trigger client reconfiguration. + +7.4. Multicast DNS Proxy + + The designated Multicast DNS (mDNS) [RFC6762] proxy on a Common Link + is elected based on the capabilities described in Section 4. The + winner is the router (connected to the Common Link) advertising the + greatest M-capability. In case of a tie, Capability Values + (Section 4) are compared, and the router with the greatest value is + elected. In case of another tie, the router with the greatest node + identifier is elected among the routers with tied Capability Values. + + The elected router MUST provide an mDNS proxy on the given link and + announce it as described in Section 8. + +8. Naming and Service Discovery + + Network-wide naming and service discovery can greatly improve the + user friendliness of a network. The following mechanism provides + means to setup and delegate naming and service discovery across + multiple HNCP routers. + + Each HNCP router SHOULD provide and advertise a recursive name + resolving server to clients that honor the announcements made in + Delegated-Zone TLVs (Section 10.5), Domain-Name TLVs (Section 10.6), + and Node-Name TLVs (Section 10.7), i.e., delegate queries to the + designated name servers and hand out appropriate A, AAAA, and PTR + records according to the mentioned TLVs. + + Each HNCP router SHOULD provide and announce an auto-generated or + user-configured name for each internal Common Link (Section 6.1) for + which it is the designated DHCPv4, stateful DHCPv6 server, mDNS + proxy, or for which it provides forward or reverse DNS services on + behalf of connected devices. This announcement is done using + 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 greatest node identifier takes precedence, and all other nodes + MUST cease to announce the conflicting TLV. HNCP routers providing + recursive name resolving services MUST use the included DNS server + + + +Stenberg, et al. Standards Track [Page 21] + +RFC 7788 Home Networking Control Protocol April 2016 + + + address within the TLV to resolve names belonging to the zone as if + there was an NS record. + + Each HNCP node SHOULD announce a node name for itself to be easily + reachable and MAY announce names on behalf of other devices. + Announcements are made using Node-Name TLVs (Section 10.7), and the + announced names MUST be unique in the whole network. In case of a + conflict, the announcement of the node with the greatest node + identifier takes precedence, and all other nodes MUST cease to + announce the conflicting TLV. HNCP routers providing recursive name + resolving services as described above MUST resolve such announced + names to their respective IP addresses as if there were corresponding + A/AAAA records. + + Names and unqualified zones are used in an HNCP network to provide + naming and service discovery with local significance. A network-wide + zone is appended to all single labels or unqualified zones in order + to qualify them. ".home" is the default; however, an administrator + MAY configure the announcement of a Domain-Name TLV (Section 10.6) + for the network to use a different one. In case multiple are + announced, the domain of the node with the greatest node identifier + takes precedence. + +9. Securing Third-Party Protocols + + PSKs are often required to secure (for example) IGPs and other + protocols that lack support for asymmetric security. The following + mechanism manages PSKs using HNCP to enable bootstrapping of such + third-party protocols. The scheme SHOULD NOT be used unless it's in + conjunction with secured HNCP unicast transport (i.e., DTLS), as + transferring the PSK in plaintext anywhere in the network is a + potential risk, especially as the originator may not know about + security (and use of DNCP security) on all links. The following + rules define how such a PSK is managed and used: + + o If no Managed-PSK TLV (Section 10.8) is currently being announced, + an HNCP node using this mechanism MUST create one after a random + delay of 0 to 10 seconds with a 32 bytes long random key and add + it to its node data. + + o In case multiple nodes announce such a TLV at the same time, all + but the one with the greatest node identifier stop advertising it + and adopt the remaining one. + + o The node currently advertising the Managed-PSK TLV MUST generate + and advertise a new random one whenever an unreachable node is + removed from the DNCP topology as described in Section 4.6 of + [RFC7787]. + + + +Stenberg, et al. Standards Track [Page 22] + +RFC 7788 Home Networking Control Protocol April 2016 + + + PSKs for individual protocols SHOULD be derived from the random PSK + using a suitable one-way hashing algorithm (e.g., by using the HMAC- + based Key Derivation Function (HKDF) based on HMAC-SHA256 [RFC6234] + with the particular protocol name in the info field) so that + disclosure of any derived key does not impact other users of the + managed PSK. Furthermore, derived PSKs MUST be updated whenever the + managed PSK changes. + +10. Type-Length-Value Objects + + HNCP defines the following TLVs in addition to those defined by DNCP. + The same general rules and defaults for encoding as noted in + Section 7 of [RFC7787] 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 + context, i.e., only directly within container TLVs mentioned in their + definition or -- absent any mentions -- only as top-level TLVs within + the node data set. TLVs appearing outside their designated context + MUST be ignored. + + TLVs encoding IP addresses or prefixes allow encoding both IPv6 and + IPv4 addresses and prefixes. IPv6 information is encoded as is, + whereas for IPv4, the IPv4-mapped IPv6 addresses format [RFC4291] is + used, and prefix lengths are encoded as the original IPv4 prefix + length increased by 96. + +10.1. HNCP-Version TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: HNCP-Version (32) | Length: >= 5 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | M | P | H | L | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | User-agent | + + This TLV is used to indicate the supported version and router + capabilities of an HNCP node as described in Section 4. + + Reserved: Bits are reserved for future use. They MUST be set to 0 + when creating this TLV, and their value MUST be ignored when + processing the TLV. + + + + + +Stenberg, et al. Standards Track [Page 23] + +RFC 7788 Home Networking Control Protocol April 2016 + + + M-capability: Priority value used for electing the on-link mDNS + [RFC6762] proxy. It MUST be set to 0 if the router is not capable + of proxying mDNS, otherwise it SHOULD be set to 4 but MAY be set + to any value from 1 to 7 to indicate a non-default priority. The + values 8-15 are reserved for future use. + + P-capability: Priority value used for electing the on-link DHCPv6-PD + server. It MUST be set to 0 if the router is not capable of + providing prefixes through DHCPv6-PD (Section 6.3.4), otherwise it + SHOULD be set to 4 but MAY be set to any value from 1 to 7 to + indicate a non-default priority. The values 8-15 are reserved for + future use. + + H-capability: Priority value used for electing the on-link DHCPv6 + server offering non-temporary addresses. It MUST be set to 0 if + the router is not capable of providing such addresses, otherwise + it SHOULD be set to 4 but MAY be set to any value from 1 to 7 to + indicate a non-default priority. The values 8-15 are reserved for + future use. + + L-capability: Priority value used for electing the on-link DHCPv4 + server. It MUST be set to 0 if the router is not capable of + running a legacy DHCPv4 server offering IPv4 addresses to clients, + otherwise it SHOULD be set to 4 but MAY be set to any value from 1 + + to 7 to indicate a non-default priority. The values 8-15 are + reserved for future use. + + User-Agent: The user-agent is a human-readable UTF-8 string that + describes the name and version of the current HNCP implementation. + +10.2. External-Connection TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: External-Connection (33)| Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (Optional nested TLVs) | + + An External-Connection TLV is a container TLV used to gather network + configuration information associated with a single external + connection (Section 6.2) to be shared across the HNCP network. A + node MAY publish an arbitrary number of instances of this TLV to + share the desired number of external connections. 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). + + + +Stenberg, et al. Standards Track [Page 24] + +RFC 7788 Home Networking Control Protocol April 2016 + + +10.2.1. Delegated-Prefix TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: Delegated-Prefix (34) | Length: >= 9 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Valid Lifetime Since Origination | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preferred Lifetime Since Origination | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Prefix Length | | + +-+-+-+-+-+-+-+-+ Prefix + + ... + | | 0-pad if any | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (Optional nested TLVs) | + + The Delegated-Prefix TLV is used by HNCP routers to advertise + prefixes that are allocated to the whole network and can be used for + prefix assignment. Delegated-Prefix TLVs are only valid inside + External-Connection TLVs, and their prefixes MUST NOT overlap with + those of other such TLVs in the same container. + + Valid Lifetime Since Origination: The time in seconds the delegated + prefix was valid for at the origination time of the node data + containing this TLV. The value MUST be updated whenever the node + republishes its Node-State TLV. + + Preferred Lifetime Since Origination: The time in seconds the + delegated prefix was preferred for at the origination time of the + node data containing this TLV. The value MUST be updated whenever + the node republishes its Node-State TLV. + + Prefix Length: The number of significant bits in the prefix. + + Prefix: Significant bits of the prefix padded with zeros up to the + next byte boundary. + + + + + + + + + + + + + +Stenberg, et al. Standards Track [Page 25] + +RFC 7788 Home Networking Control Protocol April 2016 + + +10.2.1.1. Prefix-Policy TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: Prefix-Policy (43) | Length: >= 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Policy Type | | + +-+-+-+-+-+-+-+-+ Value + + | | + + The Prefix-Policy TLV contains information about the policy or + applicability of a delegated prefix. This information can be used to + determine whether prefixes for a certain use case (e.g., local + reachability, Internet connectivity) do exist or are to be acquired + and to make decisions about assigning prefixes to certain links or to + fine-tune border firewalls. See Section 6.2 for a more in-depth + discussion. This TLV is only valid inside a Delegated-Prefix TLV. + + Policy Type: The type of the policy identifier. + + 0: Internet connectivity (no value). + + 1-128: Explicit destination prefix with the Policy Type being + the actual length of the prefix and the value containing + significant bits of the destination prefix padded with + zeros up to the next byte boundary. + + 129: DNS domain. The value contains a DNS label sequence + encoded per [RFC1035]. Compression MUST NOT be used. + The label sequence MUST end with an empty label. + + 130: Opaque UTF-8 string (e.g., for administrative purposes). + + 131: Restrictive assignment (no value). + + 132-255: Reserved for future additions. + + Value: A variable-length identifier of the given type. + + + + + + + + + + + + +Stenberg, et al. Standards Track [Page 26] + +RFC 7788 Home Networking Control Protocol April 2016 + + +10.2.2. DHCPv6-Data TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: DHCPv6-Data (37) | Length: > 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DHCPv6 option stream | + + This TLV is used to encode auxiliary IPv6 configuration information + (e.g., recursive DNS servers) encoded as a stream of DHCPv6 options. + It is only valid in an External-Connection TLV or a Delegated-Prefix + TLV encoding an IPv6 prefix and MUST NOT occur more than once in any + single container. When included in an External-Connection TLV, it + contains DHCPv6 options relevant to the external connection as a + whole. When included in a delegated prefix, it contains options + mandatory to handle said prefix. + + DHCPv6 option stream: DHCPv6 options encoded as specified in + [RFC3315]. + +10.2.3. DHCPv4-Data TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: DHCPv4-Data (38) | Length: > 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DHCPv4 option stream | + + This TLV is used to encode auxiliary IPv4 configuration information + (e.g., recursive DNS servers) encoded as a stream of DHCPv4 options. + It is only valid in an External-Connection TLV and MUST NOT occur + more than once in any single container. It contains DHCPv4 options + relevant to the external connection as a whole. + + DHCPv4 option stream: DHCPv4 options encoded as specified in + [RFC2131]. + + + + + + + + + + + + + +Stenberg, et al. Standards Track [Page 27] + +RFC 7788 Home Networking Control Protocol April 2016 + + +10.3. Assigned-Prefix TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: Assigned-Prefix (35) | Length: >= 6 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Endpoint Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Rsv. | Prty. | Prefix Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix + + ... + | | 0-pad if any | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (Optional nested TLVs) | + + This TLV is used to announce Published Assigned Prefixes for the + purposes of prefix assignment (Section 6.3). + + Endpoint Identifier: The endpoint identifier of the local interface + the prefix is assigned to, or 0 if it is assigned to a Private + Link (e.g., when the prefix is assigned for downstream prefix + delegation). + + Rsv.: Bits are reserved for future use. They MUST be set to 0 when + creating this TLV, and their value MUST be ignored when processing + the TLV. + + Prty: The Advertised Prefix Priority from 0 to 15. + + 0-1: Low priorities. + + 2: Default priority. + + 3-7: High priorities. + + 8-11: Administrative priorities. MUST NOT be used unless + configured otherwise. + + 12-14: Reserved for future use. + + 15: Provider priorities. MAY only be used by the router + advertising the corresponding delegated prefix and based + on static or dynamic configuration (e.g., for excluding a + prefix based on the DHCPv6-PD Prefix Exclude Option + [RFC6603]). + + + + + +Stenberg, et al. Standards Track [Page 28] + +RFC 7788 Home Networking Control Protocol April 2016 + + + Prefix Length: The number of significant bits in the Prefix field. + + Prefix: The significant bits of the prefix padded with zeros up to + the next byte boundary. + +10.4. Node-Address TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: Node-Address (36) | Length: 20 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Endpoint Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | IP Address | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (Optional nested TLVs) | + + This TLV is used to announce addresses assigned to an HNCP node as + described in Section 6.4. + + Endpoint Identifier: The endpoint identifier of the local interface + the prefix is assigned to, or 0 if it is not assigned on an HNCP + enabled link. + + IP Address: The globally scoped IPv6 address, or the IPv4 address + encoded as an IPv4-mapped IPv6 address [RFC4291]. + + + + + + + + + + + + + + + + + + + + + +Stenberg, et al. Standards Track [Page 29] + +RFC 7788 Home Networking Control Protocol April 2016 + + +10.5. DNS-Delegated-Zone TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: DNS-Delegated-Zone (39) | Length: >= 17 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | IP Address | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Reserved |L|B|S| | + +-+-+-+-+-+-+-+-+ 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 + in the HNCP network. Its meaning is roughly equivalent to specifying + an NS and A/AAAA record for said zone. Details are specified in + Section 8. + + IP Address: The IPv6 address of the authoritative DNS server for the + zone; IPv4 addresses are represented as IPv4-mapped addresses + [RFC4291]. The special value of :: (all zeros) means the + delegation is available in the global DNS hierarchy. + + Reserved: Those bits MUST be set to 0 when creating the TLV and + ignored when parsing it unless defined in a later specification. + + L-bit: (DNS-based Service Discovery (DNS-SD) [RFC6763] Legacy- + Browse) indicates that this delegated zone SHOULD be included in + the network's DNS-SD legacy browse list of domains at + lb._dns-sd._udp.(DOMAIN-NAME). Local forward zones SHOULD have + this bit set; reverse zones SHOULD NOT. + + B-bit: (DNS-SD [RFC6763] Browse) indicates that this delegated zone + SHOULD be included in the network's DNS-SD browse list of domains + at b._dns-sd._udp.(DOMAIN-NAME). Local forward zones SHOULD have + this bit set; reverse zones SHOULD NOT. + + S-bit: (Fully qualified DNS-SD [RFC6763] domain) indicates that this + delegated zone consists of a fully qualified DNS-SD domain, which + should be used as the base for DNS-SD domain enumeration, i.e., + _dns-sd._udp.(Zone) exists. Forward zones MAY have this bit set; + reverse zones MUST NOT. This can be used to provision a DNS + + + +Stenberg, et al. Standards Track [Page 30] + +RFC 7788 Home Networking Control Protocol April 2016 + + + search path to hosts for non-local services (such as those + provided by an ISP or other manually configured service + providers). Zones with this flag SHOULD be added to the search + domains advertised to clients. + + Zone: The label sequence encoded according to [RFC1035]. + Compression MUST NOT be used. The label sequence MUST end with an + empty label. + +10.6. Domain-Name TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: Domain-Name (40) | Length: > 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Domain (DNS label sequence - variable length) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This TLV is used to indicate the base domain name for the network as + specified in Section 8. This TLV MUST NOT be announced unless the + domain name was explicitly configured by an administrator. + + Domain: The label sequence encoded according to [RFC1035]. + Compression MUST NOT be used. The label sequence MUST end with an + empty label. + +10.7. Node-Name TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: Node-Name (41) | Length: > 17 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | IP Address | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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 + certain IP address as specified in Section 8. + + + + +Stenberg, et al. Standards Track [Page 31] + +RFC 7788 Home Networking Control Protocol April 2016 + + + IP Address: The IP address associated with the name. IPv4 + addresses are encoded using IPv4-mapped IPv6 addresses. + + Length: The length of the name (0-63). + + Name: The name of the node as a single DNS label. + +10.8. Managed-PSK TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: Managed-PSK (42) | Length: 32 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | | + | | + | Random 256-bit PSK | + | | + | | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (Optional nested TLVs) | + + This TLV is used to announce a PSK for securing third-party protocols + exclusively supporting symmetric cryptography as specified in + Section 9. + +11. General Requirements for HNCP Nodes + + Each node implementing HNCP is subject to the following requirements: + + o It MUST implement HNCP versioning (Section 4) and interface + classification (Section 5). + + o It MUST implement and run the method for securing third-party + protocols (Section 9) whenever it uses the security mechanism of + HNCP. + + If the node is acting as a router, then the following requirements + apply in addition: + + o It MUST support Autonomous Address Configuration (Section 6) and + configuration of hosts and non-HNCP routers (Section 7). + + o It SHOULD implement support for naming and service discovery + (Section 8) as defined in this document. + + + +Stenberg, et al. Standards Track [Page 32] + +RFC 7788 Home Networking Control Protocol April 2016 + + + o It MAY be able to provide connectivity to IPv4 devices using + DHCPv4. + + o It SHOULD be able to delegate prefixes to legacy IPv6 routers + using DHCPv6-PD (Section 6.3.4). + + o In addition, the normative language of "Basic Requirements for + IPv6 Customer Edge Routers" [RFC7084] applies with the following + adjustments: + + * The generic requirements G-4 and G-5 are relaxed such that any + known default router on any interface is sufficient for a + router to announce itself as the default router; similarly, + only the loss of all such default routers results in self- + invalidation. + + * "WAN-Side Configuration" (Section 4.2) applies to interfaces + classified as external. + + * If the Customer Edge (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. + + * "LAN-Side Configuration" (Section 4.3) applies to interfaces + not classified as external. + + * 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.3) for each such interface. + + * The requirement L-9 is modified, in that the M flag MUST be set + if and only if a router connected to the respective Common Link + is advertising a non-zero H-capability. The O flag SHOULD + always be set. + + * The requirement L-12 to make DHCPv6 options available is + adapted, in that Canonical Encoding Rules (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 + + + +Stenberg, et al. Standards Track [Page 33] + +RFC 7788 Home Networking Control Protocol April 2016 + + + 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. + + * The requirement L-13 to deprecate prefixes is applied to all + delegated prefixes in the network from which assignments have + been made on the respective interface. Furthermore, the Prefix + Information Options indicating deprecation MUST be included in + Router Advertisements for the remainder of the prefixes' + respective valid lifetime but MAY be omitted after at least 2 + hours have passed. + +12. Security Considerations + + HNCP enables self-configuring networks, requiring as little user + intervention as possible. However, this zero-configuration goal + usually conflicts with security goals and introduces a number of + threats. + + General security issues for existing home networks are discussed in + [RFC7368]. The protocols used to set up addresses and routes in such + networks to this day rarely have security enabled within the + configuration protocol itself. However, these issues are out of + scope for the security of HNCP itself. + + HNCP is a DNCP-based state synchronization mechanism carrying + information with varying threat potential. For this consideration, + the payloads defined in DNCP and this document are reviewed: + + o Network topology information such as HNCP nodes and their common + links. + + o Address assignment information such as delegated and assigned + prefixes for individual links. + + o Naming and service discovery information such as auto-generated or + customized names for individual links and nodes. + +12.1. Interface Classification + + As described in Section 5.3, an HNCP node determines the internal or + external state on a per-interface basis. A firewall perimeter is set + up for the external interfaces, and for internal interfaces, HNCP + traffic is allowed, with the exception of the Leaf and Guest + subcategories. + + + +Stenberg, et al. Standards Track [Page 34] + +RFC 7788 Home Networking Control Protocol April 2016 + + + Threats concerning automatic interface classification cannot be + mitigated by encrypting or authenticating HNCP traffic itself since + external routers do not participate in the protocol and often cannot + be authenticated by other means. These threats include propagation + of forged uplinks in the homenet in order to, e.g., redirect traffic + destined to external locations and forged internal status by external + routers to, e.g., circumvent the perimeter firewall. + + It is therefore imperative to either secure individual links on the + physical or link layer or preconfigure the adjacent interfaces of + HNCP routers to an appropriate fixed category in order to secure the + homenet border. Depending on the security of the external link, + eavesdropping, man-in-the-middle, and similar attacks on external + traffic can still happen between a homenet border router and the ISP; + however, these cannot be mitigated from inside the homenet. For + example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4 + messages, but this is very rarely implemented in large or small + networks. Further, while PPP can provide secure authentication of + both sides of a point-to-point link, it is most often deployed with + one-way authentication of the subscriber to the ISP, not the ISP to + the subscriber. + +12.2. Security of Unicast Traffic + + Once the homenet border has been established, there are several ways + to secure HNCP against internal threats like manipulation or + eavesdropping by compromised devices on a link that is enabled for + HNCP traffic. If left unsecured, attackers may perform arbitrary + traffic redirection, eavesdropping, spoofing, or denial-of-service + attacks on HNCP services such as address assignment or service + discovery, and the protocols are secured using HNCP-derived keys such + as routing protocols. + + Detailed interface categories like "Leaf" or "Guest" can be used to + integrate not fully trusted devices to various degrees into the + homenet by not exposing them to HNCP traffic or by using firewall + rules to prevent them from reaching homenet-internal resources. + + On links where this is not practical and lower layers do not provide + adequate protection from attackers, DTLS-based secure unicast + transport MUST be used to secure traffic. + +12.3. Other Protocols in the Home + + IGPs and other protocols are usually run alongside HNCP; therefore, + the individual security aspects of the respective protocols must be + considered. It can, however, be summarized that many protocols to be + run in the home (like IGPs) provide -- to a certain extent -- similar + + + +Stenberg, et al. Standards Track [Page 35] + +RFC 7788 Home Networking Control Protocol April 2016 + + + security mechanisms. Most of these protocols do not support + encryption and only support authentication based on Pre-Shared Keys + natively. This influences the effectiveness of any encryption-based + security mechanism deployed by HNCP as homenet routing information is + thus usually not encrypted. + +13. IANA Considerations + + IANA has set up a registry for the (decimal values within range + 32-511) "HNCP TLV Types" under "Distributed Node Consensus Protocol + (DNCP)". The registration procedures is 'RFC Required' [RFC5226]. + The initial contents are: + + 32: HNCP-Version + + 33: External-Connection + + 34: Delegated-Prefix + + 35: Assigned-Prefix + + 36: Node-Address + + 37: DHCPv4-Data + + 38: DHCPv6-Data + + 39: DNS-Delegated-Zone + + 40: Domain-Name + + 41: Node-Name + + 42: Managed-PSK + + 43: Prefix-Policy + + 44-511: Unassigned. + + 768-1023: Reserved for Private Use. This range is used by HNCP + for per-implementation experimentation. How collisions are + avoided is outside the scope of this document. + + IANA has registered the UDP port numbers 8231 (service name: hncp- + udp-port, description: HNCP) and 8232 (service name: hncp-dtls-port, + description: HNCP over DTLS), as well as an IPv6 link-local multicast + address FF02:0:0:0:0:0:0:11 (description: All-Homenet-Nodes). + + + + +Stenberg, et al. Standards Track [Page 36] + +RFC 7788 Home Networking Control Protocol April 2016 + + +14. References + +14.1. Normative References + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + DOI 10.17487/RFC1321, April 1992, + <http://www.rfc-editor.org/info/rfc1321>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, DOI 10.17487/RFC2131, March 1997, + <http://www.rfc-editor.org/info/rfc2131>. + + [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, + <http://www.rfc-editor.org/info/rfc2132>. + + [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, + A., Beser, B., and J. Privat, "The User Class Option for + DHCP", RFC 3004, DOI 10.17487/RFC3004, November 2000, + <http://www.rfc-editor.org/info/rfc3004>. + + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July + 2003, <http://www.rfc-editor.org/info/rfc3315>. + + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic + Host Configuration Protocol (DHCP) version 6", RFC 3633, + DOI 10.17487/RFC3633, December 2003, + <http://www.rfc-editor.org/info/rfc3633>. + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, + <http://www.rfc-editor.org/info/rfc4193>. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, DOI 10.17487/RFC4291, February + 2006, <http://www.rfc-editor.org/info/rfc4291>. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + DOI 10.17487/RFC4861, September 2007, + <http://www.rfc-editor.org/info/rfc4861>. + + + +Stenberg, et al. Standards Track [Page 37] + +RFC 7788 Home Networking Control Protocol April 2016 + + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [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>. + + [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, + "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, + March 2011, <http://www.rfc-editor.org/info/rfc6206>. + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, <http://www.rfc-editor.org/info/rfc6347>. + + [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. + Troan, "Prefix Exclude Option for DHCPv6-based Prefix + Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, + <http://www.rfc-editor.org/info/rfc6603>. + + [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, + <http://www.rfc-editor.org/info/rfc6763>. + + [RFC7217] Gont, F., "A Method for Generating Semantically Opaque + Interface Identifiers with IPv6 Stateless Address + Autoconfiguration (SLAAC)", RFC 7217, + DOI 10.17487/RFC7217, April 2014, + <http://www.rfc-editor.org/info/rfc7217>. + + [RFC7695] Pfister, P., Paterson, B., and J. Arkko, "Distributed + Prefix Assignment Algorithm", RFC 7695, + DOI 10.17487/RFC7695, November 2015, + <http://www.rfc-editor.org/info/rfc7695>. + + [RFC7787] Stenberg, M. and S. Barth, "Distributed Node Consensus + Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016, + <http://www.rfc-editor.org/info/rfc7787>. + + + + + + + + + +Stenberg, et al. Standards Track [Page 38] + +RFC 7788 Home Networking Control Protocol April 2016 + + +14.2. Informative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, <http://www.rfc-editor.org/info/rfc1035>. + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + and E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, + <http://www.rfc-editor.org/info/rfc1918>. + + [RFC3118] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for + DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001, + <http://www.rfc-editor.org/info/rfc3118>. + + [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms + (SHA and SHA-based HMAC and HKDF)", RFC 6234, + DOI 10.17487/RFC6234, May 2011, + <http://www.rfc-editor.org/info/rfc6234>. + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + <http://www.rfc-editor.org/info/rfc6241>. + + [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, + DOI 10.17487/RFC6762, February 2013, + <http://www.rfc-editor.org/info/rfc6762>. + + [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic + Requirements for IPv6 Customer Edge Routers", RFC 7084, + DOI 10.17487/RFC7084, November 2013, + <http://www.rfc-editor.org/info/rfc7084>. + + [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. + Weil, "IPv6 Home Networking Architecture Principles", + RFC 7368, DOI 10.17487/RFC7368, October 2014, + <http://www.rfc-editor.org/info/rfc7368>. + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May + 2015, <http://www.rfc-editor.org/info/rfc7525>. + + + + + + + +Stenberg, et al. Standards Track [Page 39] + +RFC 7788 Home Networking Control Protocol April 2016 + + +Acknowledgments + + Thanks to Ole Troan, Mark Baugher, Mark Townsley, Juliusz Chroboczek, + and Thomas Clausen for their contributions to the document. + + Thanks to Eric Kline for the original border discovery work. + +Authors' Addresses + + Markus Stenberg + Independent + Helsinki 00930 + Finland + + Email: markus.stenberg@iki.fi + + + Steven Barth + Independent + Halle 06114 + Germany + + Email: cyrus@openwrt.org + + + Pierre Pfister + Cisco Systems + Paris + France + + Email: pierre.pfister@darou.fr + + + + + + + + + + + + + + + + + + + + +Stenberg, et al. Standards Track [Page 40] + |