Home Networking Control Protocol
draft-ietf-homenet-hncp-04
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7788.
|
|
---|---|---|---|
Authors | Markus Stenberg , Steven Barth , Pierre Pfister | ||
Last updated | 2015-03-05 | ||
Replaces | draft-stenberg-homenet-hncp | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
RTGDIR Early review
by Thomas Clausen
Not ready
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 7788 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-homenet-hncp-04
Homenet Working Group M. Stenberg Internet-Draft Intended status: Standards Track S. Barth Expires: September 6, 2015 P. Pfister Cisco Systems March 5, 2015 Home Networking Control Protocol draft-ietf-homenet-hncp-04 Abstract This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol and a set of requirements for home network devices on top of the Distributed Node Consensus Protocol (DNCP). It enables automated configuration of addresses, naming, network borders and the seamless use of a routing protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2015. Copyright Notice Copyright (c) 2015 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 Stenberg, et al. Expires September 6, 2015 [Page 1] Internet-Draft Home Networking Control Protocol March 2015 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 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Adjacent Links . . . . . . . . . . . . . . . . . . . . . . . 4 5. Border Discovery . . . . . . . . . . . . . . . . . . . . . . 5 6. Autonomic Address Configuration . . . . . . . . . . . . . . . 6 6.1. External Connections . . . . . . . . . . . . . . . . . . 7 6.1.1. External Connection TLV . . . . . . . . . . . . . . . 7 6.1.2. Delegated Prefix TLV . . . . . . . . . . . . . . . . 7 6.1.3. DHCP Data TLVs . . . . . . . . . . . . . . . . . . . 8 6.2. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 9 6.2.1. Assigned Prefix TLV . . . . . . . . . . . . . . . . . 9 6.2.2. Prefix Assignment Algorithm Parameters . . . . . . . 10 6.2.3. Making New Assignments . . . . . . . . . . . . . . . 12 6.2.4. Applying Assignments . . . . . . . . . . . . . . . . 12 6.2.5. DHCPv6-PD Excluded Prefix Support . . . . . . . . . . 13 6.2.6. Downstream Prefix Delegation Support . . . . . . . . 13 6.3. Node Address Assignment . . . . . . . . . . . . . . . . . 13 6.4. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 14 7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 15 7.1. DHCPv6 for Addressing or Configuration . . . . . . . . . 15 7.2. Sending Router Advertisements . . . . . . . . . . . . . . 16 7.3. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 17 7.4. DHCPv4 for Adressing and Configuration . . . . . . . . . 17 7.5. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 17 8. Naming and Service Discovery . . . . . . . . . . . . . . . . 18 8.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 18 8.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 19 8.3. Node Name TLV . . . . . . . . . . . . . . . . . . . . . . 20 9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 20 10. HNCP Versioning and Capabilities . . . . . . . . . . . . . . 21 11. Requirements for HNCP Routers . . . . . . . . . . . . . . . . 22 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 12.1. Border Determination . . . . . . . . . . . . . . . . . . 24 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 24 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 25 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 14.1. Normative references . . . . . . . . . . . . . . . . . . 26 14.2. Informative references . . . . . . . . . . . . . . . . . 26 Appendix A. Some Outstanding Issues . . . . . . . . . . . . . . 28 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 28 Stenberg, et al. Expires September 6, 2015 [Page 2] Internet-Draft Home Networking Control Protocol March 2015 Appendix C. Draft source . . . . . . . . . . . . . . . . . . . . 28 Appendix D. Implementation . . . . . . . . . . . . . . . . . . . 28 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction HNCP synchronizes state across a small site in order to allow automated network configuration. The protocol enables use of border discovery, address prefix distribution [I-D.ietf-homenet-prefix-assignment], naming and other services across multiple links. HNCP provides enough information for a routing protocol to operate without homenet-specific extensions. In homenet environments where multiple IPv6 source-prefixes can be present, routing based on source and destination address is necessary [RFC7368]. 2. Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. DNCP Profile HNCP is defined as a profile of DNCP [I-D.ietf-homenet-dncp] with the following parameters: o HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport over link-local scoped IPv6, using unicast and multicast (group All- Homenet-Routers). Received datagrams with an IPv6 source or destination address which is not link-local scoped MUST be ignored. IPv6 fragmentation and reassembly up to TBD bytes MUST be supported by the stack of the node. o HNCP operates on multicast-capable interfaces only, thus every DNCP Connection Identifier MUST refer to one, except for the value 0 which is reserved for internal purposes and MUST NOT be used for connection enumeration. Implementations MAY use a value equivalent to the sin6_scope_id for the given interface. o HNCP unicast messages SHOULD be secured using DTLS [RFC6347] as described in DNCP if exchanged over unsecured links. UDP on port HNCP-DTLS-PORT is used for this purpose. A node implementing the security mechanism MUST support the DNCP Pre-Shared Key method, SHOULD support the DNCP Certificate Based Trust Consensus and MAY support the PKI-based trust method. Stenberg, et al. Expires September 6, 2015 [Page 3] Internet-Draft Home Networking Control Protocol March 2015 o HNCP uses opaque 32-bit node identifiers (DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP SHOULD generate and use a random node identifier. If it receives a Node State TLV with the same node identifier and a higher update sequence number, it MUST immediately generate and use a new random node identifier which is not used by any other node. o HNCP nodes MUST treat all Long Network State Update messages received via multicast on a link which has DNCP security enabled as if they were Short Network State Update messages, i.e. they MUST ignore all contained Node State TLVs. o HNCP nodes use the following Trickle parameters: * k SHOULD be 1, given the timer reset on data updates and retransmissions should handle packet loss. * 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 (i.e. 25.6 seconds) but MUST NOT be lower. o HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP non-cryptographic hash function H(x). o HNCP nodes MUST use the keep-alive extension on all connections. The default keep-alive interval (DNCP_KEEPALIVE_INTERVAL) is 20 seconds, the multiplier (DNCP_KEEPALIVE_MULTIPLIER) MUST be 2.1, the grace-interval (DNCP_GRACE_INTERVAL) SHOULD be equal to DNCP_KEEPALIVE_MULTIPLIER times DNCP_KEEPALIVE_INTERVAL. 4. Adjacent Links HNCP uses the concept of Adjacent Links for some of its applications. This term is defined as follows: If the connection of a node is detected or configured to be an ad-hoc interface the Adjacent Link only consists of said interface. Otherwise the Adjacent Link contains all interfaces bidirectionally reachable from a given local interface. An interface X of a node A and an interface Y of a node B are bidirectionally reachable if and only if node A publishes a Neighbor TLV with the Neighbor Node Identifier B, the Neighbor Connection Identifier Y and the Local Connection Identifier X and node B publishes a Neighbor TLV with the Neighbor Node Identifier A, a Neighbor Connection Identifier X and the Local Connection Identifier Y. In addition a node MUST be able Stenberg, et al. Expires September 6, 2015 [Page 4] Internet-Draft Home Networking Control Protocol March 2015 to detect whether two of its local interfaces belong to the same Adjacent Link either by local means or by inferring that from the bidirectional reachability between two different local interfaces and the same remote interface. 5. Border Discovery HNCP associates each HNCP interface with a category (e.g., internal or external). This section defines the border discovery algorithm derived from the edge router interactions described in the Basic Requirements for IPv6 Customer Edge Routers [RFC7084]. This algorithm is suitable for both IPv4 and IPv6 (single or dual-stack) and determines whether an HNCP interface is internal, external, or uses another fixed category. This algorithm MUST be implemented by any router implementing HNCP. In order to avoid conflicts between border discovery and homenet routers running DHCPv4 [RFC2131] or DHCPv6-PD [RFC3633] servers, each router MUST implement the following mechanism based on The User Class Option for DHCPv4 [RFC3004] and its DHCPv6 counterpart [RFC3315]: o An HNCP router running a DHCP client on a homenet interface MUST include a DHCP User-Class consisting of the ASCII-String "HOMENET". o An HNCP router running a DHCP server on a homenet interface MUST ignore or reject DHCP-Requests containing a DHCP User-Class consisting of the ASCII-String "HOMENET". The border discovery auto-detection algorithm works as follows, with evaluation stopping at first match: 1. If a fixed category is configured for the interface, it MUST be used. 2. If a delegated prefix could be acquired by running a DHCPv6 client on the interface, it MUST be considered external. 3. If an IPv4 address could be acquired by running a DHCPv4 client on the interface it MUST be considered external. 4. Otherwise the interface MUST be considered internal. A router MUST allow setting a category of either auto-detected, internal or external for each interface which is suitable for both internal and external connections. In addition the following specializations of the internal category are defined to modify the local router behavior: Stenberg, et al. Expires September 6, 2015 [Page 5] Internet-Draft Home Networking Control Protocol March 2015 Leaf category: This declares an interface used by client devices only. A router MUST consider such interface as internal but MUST NOT send nor receive HNCP messages on such interface. A router SHOULD implement this category. Guest category: This declares an interface used by untrusted client devices only. In addition to the restrictions of the Leaf category, connected devices MUST NOT be able to reach other devices inside the HNCP network nor query services advertised by them unless explicitly allowed, instead they SHOULD only be able to reach the internet. This category SHOULD be supported. Ad-hoc category: This configures an interface to be ad-hoc (Section 4) and MAY be implemented. Hybrid category: This declares an interface to be internal while still using external connections on it. It is assumed that the link is under control of a legacy, trustworthy non-HNCP router, still within the same network. Detection of this category automatically in addition to manual configuration is out of scope for this document. This category MAY be implemented. Each router MUST continuously scan each active interface that does not have a fixed category in order to dynamically reclassify it if necessary. The router therefore runs an appropriately configured DHCPv4 and DHCPv6 client as long as the interface is active including states where it considers the interface to be internal. The router SHOULD wait for a reasonable time period (5 seconds as a default), during which the DHCP clients can acquire a lease, before treating a newly activated or previously external interface as internal. Once it treats a certain interface as internal it MUST start forwarding traffic with appropriate source addresses between its internal interfaces and allow internal traffic to reach external networks according to the routes it publishes. Once a router detects an interface transitioning to external it MUST stop any previously enabled internal forwarding. In addition it SHOULD announce the acquired information for use in the network as described in later sections of this draft if the interface appears to be connected to an external network. 6. Autonomic Address Configuration This section specifies how HNCP routers configure host and router addresses. At first border routers share information obtained from service providers or local configuration by publishing one or more External Connection TLVs. These contain other TLVs such as Delegated Prefix TLVs which are then used for prefix assignment. Finally, HNCP routers obtain addresses using a stateless (SLAAC-like) procedure or Stenberg, et al. Expires September 6, 2015 [Page 6] Internet-Draft Home Networking Control Protocol March 2015 a specific stateful mechanism and hosts and legacy routers are configured using SLAAC or DHCP. In all TLVs specified in this section which include a prefix, IPv4 prefixes are encoded using the IPv4-mapped IPv6 addresses format [RFC4291]. The prefix length of such prefix is set to 96 plus the IPv4 prefix length. 6.1. External Connections Each HNCP router MAY obtain external connection information from one or more sources, e.g. DHCPv6-PD [RFC3633], NETCONF [RFC6241] or static configuration. This section specifies how such information is encoded and advertised. 6.1.1. External Connection TLV An External Connection TLV is a container-TLV used to gather network configuration information associated with a single external connection. A node MAY publish zero, one or more instances of this 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: > 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nested TLVs | The External Connection TLV is a container which: o MAY contain zero, one or more Delegated Prefix TLVs. o MUST NOT contain multiple Delegated Prefix TLVs with the same prefix. In such a situation, the container MUST be ignored. o MAY contain at most one DHCPv6 Data TLV and at most one DHCPv4 Data TLV encoding options associated with the External Connection but MUST NOT contain more than one of each otherwise the whole External Connection TLV MUST be ignored. o MAY contain other TLVs for future use. 6.1.2. Delegated Prefix TLV The Delegated Prefix TLV is used by HNCP routers to advertise prefixes which are allocated to the whole network and will be used Stenberg, et al. Expires September 6, 2015 [Page 7] Internet-Draft Home Networking Control Protocol March 2015 for prefix assignment. All Delegated Prefix TLVs MUST be nested in an 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: DELEGATED-PREFIX (34) | Length: >= 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | | +-+-+-+-+-+-+-+-+ Prefix [+ nested TLVs] + | | Valid Lifetime: The time in seconds the delegated prefix is valid. The value is relative to the point in time the Node-Data TLV was last published. It MUST be updated whenever the node republishes its Node-Data TLV. Preferred Lifetime: The time in seconds the delegated prefix is preferred. The value is relative to the point in time the Node- Data TLV was last published. It MUST be updated whenever the node republishes its Node-Data TLV. Prefix Length: The number of significant bits in the Prefix. Prefix: Significant bits of the prefix padded with zeroes up to the next byte boundary. Nested TLVs: Other TLVs included in the Delegated Prefix TLV and starting at the next 32 bits boundary following the end of the encoded prefix. If the encoded prefix represents an IPv6 prefix, at most one DHCPv6 Data TLV MAY be included. If the encoded prefix represents an IPv4-mapped IPv6 address, at most one DHCPv4 Data TLV MAY be included. It MAY contain other TLVs for future use. 6.1.3. DHCP Data TLVs Auxiliary connectivity information is encoded as a stream of DHCP options. Such TLVs MUST only be present in an External Connection TLV or a Delegated Prefix TLV. When included in an External Stenberg, et al. Expires September 6, 2015 [Page 8] Internet-Draft Home Networking Control Protocol March 2015 Connection TLV, they MUST contain DHCP options which are relevant to the whole External Connection. When included in a Delegated Prefix, they MUST contain DHCP options which are specific to the Delegated Prefix. The DHCPv6 Data TLV uses the following format: 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 | DHCPv6 option stream: DHCPv6 options encoded as specified in [RFC3315]. The DHCPv4 Data TLV uses the following format: 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 | DHCPv4 option stream: DHCPv4 options encoded as specified in [RFC2131]. 6.2. Prefix Assignment HNCP uses the Distributed Prefix Assignment Algorithm specified in [I-D.ietf-homenet-prefix-assignment] in order to assign prefixes to HNCP internal links and uses the terminology defined there. 6.2.1. Assigned Prefix TLV Published Assigned Prefixes MUST be advertised using the Assigned Prefix TLV: Stenberg, et al. Expires September 6, 2015 [Page 9] Internet-Draft Home Networking Control Protocol March 2015 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsv. | Prty. | Prefix Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix + | | Connection Identifier: The DNCP Connection Identifier of the link the prefix is assigned to, or 0 if the link is a Private Link. Rsv.: Bits reserved for future use. MUST be set to zero when creating this TLV and ignored when parsing it. 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 specified in the router's configuration. 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 DHCPv6-PD Prefix Exclude Option [RFC6603]). Prefix Length: The number of significant bits in the Prefix field. Prefix: The significant bits of the prefix padded with zeroes up to the next byte boundary. 6.2.2. Prefix Assignment Algorithm Parameters All HNCP nodes running the prefix assignment algorithm MUST use the following parameters: Node IDs: DNCP Node Identifiers are used. The comparison operation is defined as bit-wise comparison. Stenberg, et al. Expires September 6, 2015 [Page 10] Internet-Draft Home Networking Control Protocol March 2015 Set of Delegated Prefixes: The set of prefixes encoded in Delegated Prefix TLVs which are not strictly included in prefixes encoded in other Delegated Prefix TLVs. Note that Delegated Prefix TLVs included in ignored External Connection TLVs are not considered. It is dynamically updated as Delegated Prefix TLVs are added or removed. Set of Shared Links: The set of HNCP internal, leaf, guest or hybrid links. It is dynamically updated as HNCP links are added, removed, become internal or cease to be. Set of Private Links: This document defines Private Links representing DHCPv6-PD clients or as a mean to advertise prefixes included in the DHCPv6 Exclude Prefix option. Other implementation-specific Private Links may exist. Set of Advertised Prefixes: The set of prefixes included in Assigned Prefix TLVs advertised by other HNCP routers. The associated Advertised Prefix Priority is the priority specified in the TLV. The associated Shared Link is determined as follows: * If the Link Identifier is zero, the Advertised Prefix is not assigned on a Shared Link. * If the Link Identifier is not zero the Shared Link is equal to the Adjacent Link (Section 4). Advertised Prefixes as well as their associated priorities and associated Shared Links MUST be updated as Assigned Prefix TLVs or Neighbor TLVs are added, removed or updated. ADOPT_MAX_DELAY: The default value is 0 seconds (i.e. prefix adoption MAY be 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. Expires September 6, 2015 [Page 11] Internet-Draft Home Networking Control Protocol March 2015 6.2.3. Making New Assignments Whenever the Prefix Assignment Algorithm routine is run on an Adjacent Link and whenever a new prefix may be assigned (case 1 of the routine), the decision of whether the assignment of a new prefix is desired MUST follow these rules: If the Delegated Prefix TLV contains a DHCPv4 or DHCPv6 Data TLV, and the meaning of one of the DHCP options is not understood by the HNCP router, the creation of a new prefix is not desired. 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-null preferred lifetime, the creation of a new prefix is not desired. Otherwise, the creation of a new prefix is 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 by an administrator. In case no prefix of length 64 would be available, a longer prefix MAY be selected. If the considered delegated prefix is an IPv4 prefix ( Section 6.4 details how IPv4 delegated prefixes are generated), a prefix of length 24 SHOULD be preferred. In any case, a router MUST support a mechanism suitable to distribute addresses from the considered prefix to clients on the link. Otherwise it MUST NOT create or adopt it, i.e. a router assigning an IPv4 prefix MUST support the L-capability and a router assigning an IPv6 prefix not suitable for stateless autoconfiguration MUST support the H-capability as defined in Section 10. 6.2.4. Applying Assignments The prefix assignment algorithm indicates when a prefix is applied to the respective Adjacent Link. When that happens each router connected to said link: MUST create an appropriate on-link route for said prefix and advertise it using the chosen routing protocol. MUST participate in the client configuration election as described in Section 7. Stenberg, et al. Expires September 6, 2015 [Page 12] Internet-Draft Home Networking Control Protocol March 2015 MAY add an address from said prefix to the respective network interface as described in Section 6.3. 6.2.5. DHCPv6-PD Excluded Prefix Support Whenever a DHCPv6 Prefix Exclude option [RFC6603] is received with a delegated prefix, the excluded prefix MUST be advertised as assigned to a Private Link with the maximum priority (i.e. 15). The same procedure MAY be applied in order to exclude prefixes obtained by other means of configuration. 6.2.6. Downstream Prefix Delegation Support When an HNCP router receives a request for prefix delegation, it SHOULD assign one prefix per delegated prefix, wait for them to be applied, and delegate them to the client. Such assignment MUST be done in accordance with the Prefix Assignment Algorithm. Each client MUST be considered as an independent Private Link and delegation MUST be based on the same set of Delegated Prefixes. The assigned prefixes MUST NOT be given to clients before they are applied, and MUST be withdrawn whenever they are destroyed. As an exception to this rule a router MAY prematurely give out a prefix which is advertised but not yet applied if it does so with a valid lifetime of not more than 30 seconds and ensures removal or correction of lifetimes as soon as possible to shorten delays of processed requests. 6.3. 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. SLAAC SHOULD be used whenever possible. The following method MUST be used otherwise. For any IPv6 prefix longer than 64 bits (resp. any IPv4 prefix) assigned to an Adjacent Link, the first quarter of the addresses are reserved for routers HNCP based assignments, whereas the last three quarters are left to the DHCPv6 (resp. DHCPv4) elected router (Section 10 specifies the DHCP server election process). For instance, if the prefix 192.0.2.0/24 is assigned and applied to an Adjacent Link, addresses included in 192.0.2.0/26 are reserved for HNCP nodes and the remaining addresses are reserved for the elected DHCPv4 server. HNCP routers assign themselves addresses using the Node Address TLV: Stenberg, et al. Expires September 6, 2015 [Page 13] Internet-Draft Home Networking Control Protocol March 2015 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IP Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Connection Identifier: The DNCP Connection Identifier of the link the address is assigned to, or 0 if it is not assigned on an HNCP enabled link. IP Address: The IPv6 address, or the IPv4 address encoded as an IPv4-mapped IPv6 address [RFC4291]. The process of obtaining addresses is specified as follows: o A router MUST NOT start advertising an address if it is already advertised by another router. o An assigned address MUST be in the first quarter of an assigned prefix currently applied on the specified link. o An address MUST NOT be used unless it has been advertised for at least ADDRESS_APPLY_DELAY consecutive seconds, and is still currently being advertised. The default value for ADDRESS_APPLY_DELAY is 3 seconds. o Whenever the same address is advertised by more than one node all but the one advertised by the node with the highest node identifier MUST be removed. 6.4. Local IPv4 and ULA Prefixes HNCP routers can create an ULA or private IPv4 prefix to enable connectivity between local devices. These prefixes are inserted in HNCP as if they were delegated prefixes. The following rules apply: An HNCP router SHOULD create an ULA prefix if there is no other non-deprecated IPv6 prefix in the network. It MAY also do so if there are other delegated IPv6 prefixes but none of which is a non-deprecated ULA but MUST NOT do so otherwise. Whenever it detects another non-deprecated ULA being advertised it MUST cease Stenberg, et al. Expires September 6, 2015 [Page 14] Internet-Draft Home Networking Control Protocol March 2015 to announce its locally generated one. It MAY also do so once it detects a non-deprecated non-ULA IPv6 delegated prefix. An HNCP router MUST create a non-deprecated private IPv4 prefix [RFC1918] whenever it wishes to provide external IPv4 connectivity to the network and no other non-deprecated private IPv4 prefix currently exists. It MAY also create a deprecated private IPv4 prefix if no IPv4 prefix exists and it wants to enable local IPv4 connectivity but MUST NOT do so otherwise. In case multiple IPv4 prefixes are announced all but one MUST be removed while non- deprecated ones take precedence over deprecated ones and announcements by nodes with a higher node identifier take precedence over those with a lower one. The router publishing the non-deprecated prefix MUST announce an IPv4 default route using the routing protocol and perform NAT on behalf of the network as long as it publishes the prefix, other routers in the network MUST NOT. Creation of such ULA and IPv4 prefixes MUST be delayed by a random timespan between 0 and 10 seconds in which the router MUST scan for other nodes trying to do the same. When a new ULA prefix is created, the prefix is selected based on the configuration, using the last non-deprecated ULA prefix, or generated based on [RFC4193]. 7. Configuration of Hosts and non-HNCP Routers HNCP routers need to ensure that hosts and non-HNCP downstream routers on internal links are configured with addresses and routes. Since DHCP-clients can usually only bind to one server at a time an election takes place. HNCP routers may have different capabilities for configuring downstream devices and providing naming services. Each router MUST therefore indicate its capabilities as specified in Section 10 in order to participate as a candidate in the election. 7.1. DHCPv6 for Addressing or Configuration In general stateless address configuration is preferred whenever possible since it enables fast renumbering and low overhead, however stateful DHCPv6 can be useful in addition to collect hostnames and use them to provide naming services or if stateless configuration is not possible for the assigned prefix length. The designated stateful DHCPv6 server for a link is elected based on the capabilities described in Section 10. The winner is the router Stenberg, et al. Expires September 6, 2015 [Page 15] Internet-Draft Home Networking Control Protocol March 2015 connected to the Adjacent Link (Section 4) advertising the greatest H-capability. In case of a tie, Capability Values and node identifiers are considered (greatest value is elected). The elected router MUST serve stateful DHCPv6 and Router Advertisements on the given link. Furthermore it MUST provide naming services for acquired hostnames as outlined in Section 8. Stateful addresses being handed out SHOULD have a low preferred lifetime (e.g. 1s) to not hinder fast renumbering if either the DHCPv6 server or client do not support the DHCPv6 reconfigure mechanism and the address is from a prefix for which stateless autoconfiguration is supported as well. In case no router was elected, stateful DHCPv6 is not provided and each router assigning IPv6-prefixes on said link MUST provide stateless DHCPv6 service. 7.2. Sending Router Advertisements Each HNCP router assigning an IPV6-prefix to an interface MUST send Router Advertisements periodically via multicast and via unicast in response to Router Solicitations. In addition other routers on the link MAY announce Router Advertisements. This might result in a more optimal routing decision for clients. The following rules MUST be followed when sending Router Advertisements: The "Managed address configuration" flag MUST be set whenever a router connected to the link is advertising a non-null H-capability and MUST NOT be set otherwise. The "Other configuration" flag MUST always be set. The default Router Lifetime MUST be set to an appropriate non-null value whenever an IPv6 default route is known in the HNCP network and MUST be set to zero otherwise. A Prefix Information Option MUST be added for each assigned and applied IPv6 prefix on the given link. The autonomous address- configuration flag MUST be set whenever the prefix is suitable for stateless configuration. The preferred and valid lifetimes MUST be smaller than the preferred and valid lifetimes of the delegated prefix the prefix is from. When a prefix is removed, it MUST be deprecated as specified in [RFC7084]. A Route Information Option [RFC4191] MUST be added for each delegated IPv6 prefix known in the HNCP network. Additional ones SHOULD be added for each non-default IPv6 route with an external destination advertised by the routing protocol. A Recursive DNS Server Option and a DNS Search List Option MUST be included with appropriate contents. Stenberg, et al. Expires September 6, 2015 [Page 16] Internet-Draft Home Networking Control Protocol March 2015 To allow for optimized routing decisions for clients on the local link routers SHOULD adjust their Default Router Preference and Route Preferences [RFC4191] so that the priority is set to low if the next hop of the default or more specific route is on the same interface as the Route Advertisement being sent on. Similarly the router MAY use the high priority if it is certain it has the best metric of all routers on the link for all routes known in the network with the respective destination. Every router sending Router Advertisements MUST immediately send an updated Router Advertisement via multicast as soon as it notices a condition resulting in a change of any advertised information. 7.3. DHCPv6 for Prefix Delegation The designated DHCPv6 server for prefix-delegation on a link is elected based on the capabilities described in Section 10. The winner is the router connected to the Adjacent Link (Section 4) advertising the greatest P-capability. In case of a tie, Capability Values and Node Identifiers are considered (greatest value is elected). The elected router MUST provide prefix-delegation services [RFC3633] on the given link and follow the rules in Section 6.2.6. 7.4. DHCPv4 for Adressing and Configuration The designated DHCPv4 server on a link is elected based on the capabilities described in Section 10. The winner is the router connected to the Adjacent Link (Section 4) advertising the greatest L-capability. In case of a tie, Capability Values and node identifiers are considered (greatest value is elected). The elected router MUST provide DHCPv4 services on the given link. The DHCPv4 serving router MUST announce itself as router [RFC2132] to clients if and only if there is an IPv4 default route known in the network. In addition the router SHOULD announce a Classless Static Route Option [RFC3442] for each non-default IPv4 route advertised in the routing protocol with an external destination. DHCPv4 lease times SHOULD be short (i.e. not longer than 5 minutes) in order to provide reasonable response times to changes. 7.5. Multicast DNS Proxy The designated MDNS [RFC6762]-proxy on a link is elected based on the capabilities described in Section 10. The winner is the router with the highest Node Identifier among those with the highest Capability Value on the link that support the M-capability. The elected router Stenberg, et al. Expires September 6, 2015 [Page 17] Internet-Draft Home Networking Control Protocol March 2015 MUST provide an MDNS-proxy on the given link and announce it as described in Section 8. 8. Naming and Service Discovery Network-wide naming and service discovery can greatly improve the user-friendliness of an IPv6 network. The following mechanism provides means to setup and delegate naming and service discovery across multiple HNCP routers. Each HNCP router SHOULD provide and announce an auto-generated or user-configured name for each internal Adjacent Link (Section 4) for which it is the designated DHCPv4, stateful DHCPv6 server or MDNS [RFC6762]-proxy and for which it provides DNS-services on behalf of devices on said link. In addition it MAY provide reverse lookup services. The following TLVs are defined and MUST be supported by all nodes implementing naming and service discovery: 8.1. DNS Delegated Zone TLV This TLV is used to announce a forward or reverse DNS zone delegation in the HNCP network. Its meaning is roughly equivalent to specifying an NS and A/AAAA record for said zone. There MUST NOT be more than one delegation for the same zone in the whole DNCP network. In case of a conflict the announcement of the node with the highest node identifier takes precedence and all other nodes MUST cease to announce the conflicting TLV. 0 1 2 3 0 1 2 3 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) | | | IP Address is the IPv6 address of the authoritative DNS server for the zone; IPv4 addresses are represented as IPv4-mapped addresses [RFC4291]. The special value of :: (all-zero) means the delegation is available in the global DNS-hierarchy. Stenberg, et al. Expires September 6, 2015 [Page 18] Internet-Draft Home Networking Control Protocol March 2015 reserved bits MUST be zero when creating and ignored when parsing this TLV. L-bit (DNS-SD [RFC6763] Legacy-Browse) indicates that this delegated zone should be included in the network's DNS-SD legacy browse list of domains at lb._dns- sd._udp.(DOMAIN-NAME). Local forward zones SHOULD have this bit set, reverse zones SHOULD NOT. B-bit (DNS-SD [RFC6763] Browse) indicates that this delegated zone should be included in the network's DNS-SD browse list of domains at b._dns-sd._udp. (DOMAIN-NAME). Local forward zones SHOULD have this bit set, reverse zones SHOULD NOT. S-bit (fully-qualified DNS-SD [RFC6763] -domain) indicates that this delegated zone consists of a fully-qualified DNS-SD domain, which should be used as base for DNS-SD domain enumeration, i.e. _dns-sd._udp.(Zone) exists. Forward zones MAY have this bit set, reverse zones MUST NOT. This can be used to provision DNS search path to hosts for non-local services (such as those provided by an ISP, or other manually configured service providers). Zones with this flag SHOULD be added to the search domains advertised to clients. Zone is the label sequence of the zone, encoded according to [RFC1035]. Compression MUST NOT be used. The zone MUST end with an empty label. 8.2. Domain Name TLV This TLV is used to indicate the base domain name for the network. It is the zone used as a base for all non fully-qualified delegated zones and node names. In case of conflicts the announced domain of the node with the highest node identifier takes precedence. By default ".home" is used, i.e. if no node advertises such a TLV. 0 1 2 3 0 1 2 3 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Domain is the label sequence encoded according to [RFC1035]. Compression MUST NOT be used. The zone MUST end with an empty label. Stenberg, et al. Expires September 6, 2015 [Page 19] Internet-Draft Home Networking Control Protocol March 2015 8.3. Node Name TLV This TLV is used to assign the name of a node in the network to a certain IP address. In case of conflicts the announcement of the node with the highest node identifier for a name takes precedence and all other nodes MUST cease to announce the conflicting TLV. 0 1 2 3 0 1 2 3 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IP Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name (not null-terminated - variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9. Securing Third-Party Protocols Pre-shared keys (PSKs) are often required to secure IGPs and other protocols which lack support for asymmetric security. The following mechanism manages PSKs using HNCP to enable bootstrapping of such third-party protocols and SHOULD therefore be used if such a need arises. The following rules define how such a PSK is managed and used: o If no Managed-PSK-TLV is currently being announced, an HNCP router MUST create one with a 32 bytes long random key and add it to its node data. o In case multiple routers announce such a TLV at the same time, all but the one with the highest node identifier stop advertising it and adopt the remaining one. o The router currently advertising the Managed-PSK-TLV must generate and advertise a new random one whenever an unreachable node is purged as described in DNCP. Stenberg, et al. Expires September 6, 2015 [Page 20] Internet-Draft Home Networking Control Protocol March 2015 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 PSK | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PSKs for individual protocols are derived from the random PSK through the use of HMAC-SHA256 [RFC6234] with a pre-defined per-protocol HMAC-key in ASCII-format. The following HMAC-keys are currently defined to derive PSKs for the respective protocols: "ROUTING": to be used for IGPs 10. HNCP Versioning and Capabilities Multiple versions of HNCP based on compatible DNCP [I-D.ietf-homenet-dncp] profiles may be present in the same network when transitioning between HNCP versions and HNCP routers may have different capabilities to support clients. The following mechanism describes a way to announce the currently active version and User- agent of a node. Each node MUST include an HNCP-Version-TLV in its Node Data and MUST ignore (except for DNCP synchronization purposes) any TLVs with a type greater than 32 of nodes not publishing an HNCP- Version TLV or publishing such a TLV with a different Version number. Capabilities are indicated by setting M, P, H and L fields in the TLV. The "capability value" is a metric indicated by interpreting the bits as an integer, i.e. (M << 12 | P << 8 | H << 4 | L). 0 1 2 3 0 1 2 3 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Reserved | M | P | H | L | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User-agent | Stenberg, et al. Expires September 6, 2015 [Page 21] Internet-Draft Home Networking Control Protocol March 2015 Version: Version indicates which version of HNCP is currently in use by this particular node. It MUST be set to 0. Nodes with different versions are considered incompatible. Reserved: Bits reserved for future use. MUST be set to zero when creating this TLV and ignored when parsing it. M-capability: Priority value used for electing the on-link MDNS [RFC6762] proxy. It MUST be set to some value between 1 and 7 included (4 is the default) if the router is capable of proxying MDNS and 0 otherwise. The values 8-15 are reserved for future use. P-capability: Priority value used for electing the on-link DHCPv6-PD server. It MUST be set to some value between 1 and 7 included (4 is the default) if the router is capable of providing prefixes through DHCPv6-PD (Section 6.2.6) and 0 otherwise. The values 8-15 are reserved for future use. H-capability: Priority value used for electing the on-link DHCPv6 server offering non-temporary addresses. It MUST be set to some value between 1 and 7 included (4 is the default) if the router is capable of providing such addresses and 0 otherwise. The values 8-15 are reserved for future use. L-capability: Priority value used for electing the on-link DHCPv4 server. It MUST be set to some value between 1 and 7 included (4 is the default) if the router is capable of running a legacy DHCPv4 server offering IPv4 addresses to clients and 0 otherwise. The values 8-15 are reserved for future use. User-Agent: The user-agent is a null-terminated human-readable UTF-8 string that describes the name and version of the current HNCP implementation. 11. Requirements for HNCP Routers Each router implementing HNCP is subject to the following requirements: o It MUST implement HNCP-Versioning, Border Discovery, Prefix Assignment and Configuration of hosts and non-HNCP routers as defined in this document. o It MUST implement and run the method for securing third-party protocols whenever it uses the security mechanism of HNCP. Stenberg, et al. Expires September 6, 2015 [Page 22] Internet-Draft Home Networking Control Protocol March 2015 o It SHOULD implement support for the Service Discovery and Naming TLVs as defined in this document. o It MUST implement and run the routing protocol $FOO with support for source-specific routes on all of the interfaces it sends and receives HNCP-messages on and MUST resort to announcing source- specific routes for external destinations appropriately. o It MUST use adequate security mechanisms for the routing protocol on any interface where it also uses the security mechanisms of HNCP. If the security mechanism is based on a PSK it MUST use a PSK derived from the Managed-PSK to secure the IGP. o It MUST comply with the Basic Requirements for IPv6 Customer Edge Routers [RFC7084] unless it would otherwise conflict with any requirements in this document (e.g. prefix assignment mandating a different prefix delegation and DHCP server election strategy). In general "WAN interface requirements" shall apply to external interfaces and "LAN interface requirements" to internal interfaces respectively. o It SHOULD 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. 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 [I-D.ietf-homenet-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 adjacent links Stenberg, et al. Expires September 6, 2015 [Page 23] Internet-Draft Home Networking Control Protocol March 2015 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 routers 12.1. Border Determination As described in Section 5, an HNCP router determines the internal or external state on a per-link basis. A firewall perimeter is set up for the external links, and for internal links, HNCP and IGP traffic is allowed. Threats concerning automatic border discovery cannot be mitigated by encrypting or authenticating HNCP traffic itself since external routers do not participate in the protocol and often cannot be authenticated by other means. These threats include propagation of forged uplinks in the homenet in order to e.g. redirect traffic destined to external locations and forged internal status by external routers to e.g. circumvent the perimeter firewall. 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 adequate fixed-category in order to secure the homenet border. Depending on the security of the external link eavesdropping, man-in-the-middle and similar attacks on external traffic can still happen between a homenet border router and the ISP, however these cannot be mitigated from inside the homenet. For example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4 messages, but this is very rarely implemented in large or small networks. Further, while PPP can provide secure authentication of both sides of a point to point link, it is most often deployed with one-way authentication of the subscriber to the ISP, not the ISP to the subscriber. 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 which is enabled for HNCP traffic. If left unsecured, attackers may perform arbitrary eavesdropping, spoofing or denial of service attacks on HNCP services such as address assignment or service discovery. Detailed interface categories like "leaf" or "guest" can be used to integrate not fully trusted devices to various degrees into the homenet by not exposing them to HNCP and IGP traffic or by using Stenberg, et al. Expires September 6, 2015 [Page 24] Internet-Draft Home Networking Control Protocol March 2015 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, DNCP secure mode 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 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 is requested to maintain a registry for HNCP TLV-Types. HNCP inherits the TLV-Types and allocation policy defined in DNCP [I-D.ietf-homenet-dncp]. In addition the following TLV-Types are defined in this document: 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 Stenberg, et al. Expires September 6, 2015 [Page 25] Internet-Draft Home Networking Control Protocol March 2015 HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP- DTLS-PORT, as well as an IPv6 link-local multicast address All- Homenet-Routers. 14. References 14.1. Normative references [I-D.ietf-homenet-dncp] Stenberg, M. and S. Barth, "Distributed Node Consensus Protocol", draft-ietf-homenet-dncp-01 (work in progress), March 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, May 2012. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [I-D.ietf-homenet-prefix-assignment] Pfister, P., Paterson, B., and J. Arkko, "Distributed Prefix Assignment Algorithm", draft-ietf-homenet-prefix- assignment-03 (work in progress), February 2015. 14.2. Informative references [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, November 2013. [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A., Beser, B., and J. Privat, "The User Class Option for DHCP", RFC 3004, November 2000. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. Stenberg, et al. Expires September 6, 2015 [Page 26] Internet-Draft Home Networking Control Protocol March 2015 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368, October 2014. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 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 Addresses", RFC 4193, October 2005. Stenberg, et al. Expires September 6, 2015 [Page 27] Internet-Draft Home Networking Control Protocol March 2015 14.3. URIs [3] http://www.openwrt.org [4] http://www.homewrt.org/doku.php?id=run-conf Appendix A. Some Outstanding Issues Should we define in-protocol fragmentation scheme or just use IPv6 fragmentation with 'big enough' minimum acceptable size allowed for implementations? In the same sense should we use TCP over UDP? How should we deal with stub-routers requiring reduced complexity versions? Stub IGPs? An HNCP-based solution? Even a stub-HNCP? Appendix B. Changelog draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP (homenet profile). draft-ietf-homenet-hncp-02: Removed any built-in security. Relying on IPsec. Reorganized interface categories, added requirements languages, made manual border configuration a MUST-support. Redesigned routing protocol election to consider non-router devices. draft-ietf-homenet-hncp-01: Added (MAY) guest, ad-hoc, hybrid categories for interfaces. Removed old hnetv2 reference, and now pointing just to OpenWrt + github. Fixed synchronization algorithm to spread also same update number, but different data hash case. Made purge step require bidirectional connectivity between nodes when traversing the graph. Edited few other things to be hopefully slightly clearer without changing their meaning. draft-ietf-homenet-hncp-00: Added version TLV to allow for TLV content changes pre-RFC without changing IDs. Added link id to assigned address TLV. Appendix C. Draft source This draft is available at https://github.com/fingon/ietf-drafts/ in source format. Issues and pull requests are welcome. Appendix D. Implementation A GPLv2-licensed implementation of HNCP is currently under development at https://github.com/sbyx/hnetd/ and binaries are available in the OpenWrt [3] package repositories. See [4] for more information. Feedback and contributions are welcome. Stenberg, et al. Expires September 6, 2015 [Page 28] Internet-Draft Home Networking Control Protocol March 2015 Appendix E. Acknowledgements Thanks to Ole Troan, Mark Baugher, Mark Townsley and Juliusz Chroboczek for their contributions to the draft. Thanks to Eric Kline for the original border discovery work. Authors' Addresses Markus Stenberg Helsinki 00930 Finland Email: markus.stenberg@iki.fi Steven Barth Halle 06114 Germany Email: cyrus@openwrt.org Pierre Pfister Cisco Systems Paris France Email: pierre.pfister@darou.fr Stenberg, et al. Expires September 6, 2015 [Page 29]