idnits 2.17.1 draft-ietf-homenet-hncp-bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document obsoletes RFC7788, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2016) is 2847 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6092 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Homenet Working Group M. Stenberg 3 Internet-Draft S. Barth 4 Obsoletes: 7788 (if approved) Independent 5 Intended status: Standards Track P. Pfister 6 Expires: January 9, 2017 Cisco Systems 7 July 8, 2016 9 Home Networking Control Protocol 10 draft-ietf-homenet-hncp-bis-00 12 Abstract 14 This document describes the Home Networking Control Protocol (HNCP), 15 an extensible configuration protocol, and a set of requirements for 16 home network devices. HNCP is described as a profile of and 17 extension to the Distributed Node Consensus Protocol (DNCP). HNCP 18 enables discovery of network borders, automated configuration of 19 addresses, name resolution, service discovery, and the use of any 20 routing protocol that supports routing based on both the source and 21 destination address. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 9, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 7 61 3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. HNCP Versioning and Router Capabilities . . . . . . . . . . . 8 63 5. Interface Classification . . . . . . . . . . . . . . . . . . 9 64 5.1. Interface Categories . . . . . . . . . . . . . . . . . . 9 65 5.2. DHCP-Aided Auto-Detection . . . . . . . . . . . . . . . . 10 66 5.3. Algorithm for Border Discovery . . . . . . . . . . . . . 10 67 6. Autonomous Address Configuration . . . . . . . . . . . . . . 11 68 6.1. Common Link . . . . . . . . . . . . . . . . . . . . . . . 12 69 6.2. External Connections . . . . . . . . . . . . . . . . . . 12 70 6.3. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 14 71 6.3.1. Prefix Assignment Algorithm Parameters . . . . . . . 14 72 6.3.2. Making New Assignments . . . . . . . . . . . . . . . 15 73 6.3.3. Applying Assignments . . . . . . . . . . . . . . . . 16 74 6.3.4. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . 16 75 6.4. Node Address Assignment . . . . . . . . . . . . . . . . . 17 76 6.5. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 18 77 7. Configuration of Hosts and Non-HNCP Routers . . . . . . . . . 19 78 7.1. IPv6 Addressing and Configuration . . . . . . . . . . . . 19 79 7.2. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 20 80 7.3. DHCPv4 for Addressing and Configuration . . . . . . . . . 20 81 7.4. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 20 82 8. Naming and Service Discovery . . . . . . . . . . . . . . . . 21 83 9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 22 84 10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 22 85 10.1. HNCP-Version TLV . . . . . . . . . . . . . . . . . . . . 23 86 10.2. External-Connection TLV . . . . . . . . . . . . . . . . 24 87 10.2.1. Delegated-Prefix TLV . . . . . . . . . . . . . . . . 24 88 10.2.2. DHCPv6-Data TLV . . . . . . . . . . . . . . . . . . 26 89 10.2.3. DHCPv4-Data TLV . . . . . . . . . . . . . . . . . . 26 90 10.3. Assigned-Prefix TLV . . . . . . . . . . . . . . . . . . 27 91 10.4. Node-Address TLV . . . . . . . . . . . . . . . . . . . . 28 92 10.5. DNS-Delegated-Zone TLV . . . . . . . . . . . . . . . . . 28 93 10.6. Domain-Name TLV . . . . . . . . . . . . . . . . . . . . 29 94 10.7. Node-Name TLV . . . . . . . . . . . . . . . . . . . . . 30 95 10.8. Managed-PSK TLV . . . . . . . . . . . . . . . . . . . . 30 96 11. General Requirements for HNCP Nodes . . . . . . . . . . . . . 31 97 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 98 12.1. Interface Classification . . . . . . . . . . . . . . . . 33 99 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 34 100 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 34 101 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 102 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 103 14.1. Normative References . . . . . . . . . . . . . . . . . . 36 104 14.2. Informative References . . . . . . . . . . . . . . . . . 37 105 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 38 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 108 1. Introduction 110 The Home Networking Control Protocol (HNCP) is designed to facilitate 111 the sharing of state among home routers to fulfill the needs of the 112 IPv6 homenet architecture [RFC7368], which assumes zero-configuration 113 operation, multiple subnets, multiple home routers, and (potentially) 114 multiple upstream service providers providing (potentially) multiple 115 prefixes to the home network. While RFC 7368 sets no requirements 116 for IPv4 support, HNCP aims to support the dual-stack mode of 117 operation, and therefore the functionality is designed with that in 118 mind. The state is shared as TLVs transported in the DNCP node state 119 among the routers (and potentially advanced hosts) to enable: 121 o Autonomic discovery of network borders (Section 5.3) based on 122 Distributed Node Consensus Protocol (DNCP) topology. 124 o Automated portioning of prefixes delegated by the service 125 providers as well as assigned prefixes to both HNCP and non-HNCP 126 routers (Section 6.3) using [RFC7695]. Prefixes assigned to HNCP 127 routers are used to: 129 * Provide addresses to non-HNCP aware nodes (using Stateless 130 Address Autoconfiguration (SLAAC) and DHCP). 132 * Provide space in which HNCP nodes assign their own addresses 133 (Section 6.4). 135 o Internal and external name resolution, as well as multi-link 136 service discovery (Section 8). 138 o Other services not defined in this document that do need to share 139 state among homenet nodes and do not cause rapid and constant TLV 140 changes (see the following applicability section). 142 HNCP is a protocol based on DNCP [RFC7787] and includes a DNCP 143 profile that defines transport and synchronization details for 144 sharing state across nodes defined in Section 3. The rest of the 145 document defines behavior of the services noted above, how the 146 required TLVs are encoded (Section 10), as well as additional 147 requirements on how HNCP nodes should behave (Section 11). 149 1.1. Applicability 151 While HNCP does not deal with routing protocols directly (except 152 potentially informing them about internal and external interfaces if 153 classification specified in Section 5.3 is used), in homenet 154 environments where multiple IPv6 source prefixes can be present, 155 routing based on the source and destination address is necessary 156 [RFC7368]. Ideally, the routing protocol is also zero configuration 157 (e.g., no need to configure identifiers or metrics), although HNCP 158 can also be used with a manually configured routing protocol. 160 As HNCP uses DNCP as the actual state synchronization protocol, the 161 applicability statement of DNCP applies here as well; HNCP should not 162 be used for any data that changes rapidly and constantly. If such 163 data needs to be published in an HNCP network, 1) a more applicable 164 protocol should be used for those portions, and 2) locators to a 165 server of said protocol should be announced using HNCP instead. An 166 example for this is naming and service discovery (Section 8) for 167 which HNCP only transports DNS server addresses and no actual per- 168 name or per-service data of hosts. 170 HNCP TLVs specified within this document, in steady state, stay 171 constant, with one exception: as Delegated-Prefix TLVs 172 (Section 10.2.1) do contain lifetimes, they force republishing of 173 that data every time the valid or preferred lifetimes of prefixes are 174 updated (significantly). Therefore, it is desirable for ISPs to 175 provide large enough valid and preferred lifetimes to avoid 176 unnecessary HNCP state churn in homes, but even given non-cooperating 177 ISPs, the state churn is proportional only to the number of 178 externally received delegated prefixes and not to the home network 179 size, and it should therefore be relatively low. 181 HNCP assumes a certain level of control over host configuration 182 servers (e.g., DHCP [RFC2131]) on links that are managed by its 183 routers. Some HNCP functionality (such as border discovery or some 184 aspects of naming) might be affected by existing DHCP servers that 185 are not aware of the HNCP-managed network and thus might need to be 186 reconfigured to not result in unexpected behavior. 188 While HNCP routers can provide configuration to and receive 189 configuration from non-HNCP routers, they are not able to traverse 190 such devices based solely on the protocol as defined in this 191 document, i.e., HNCP routers that are connected only by different 192 interfaces of a non-HNCP router will not be part of the same HNCP 193 network. 195 While HNCP is designed to be used by (home) routers, it can also be 196 used by advanced hosts that want to do, e.g., their own address 197 assignment and routing. 199 HNCP is link-layer agnostic; if a link supports IPv6 (link-local) 200 multicast and unicast, HNCP will work on it. Trickle retransmissions 201 and keep-alives will handle both packet loss and non-transitive 202 connectivity, ensuring eventual convergence. 204 2. Terminology 206 The following terms are used as they are defined in [RFC7695]: 208 o Advertised Prefix Priority 210 o Advertised Prefix 212 o Assigned Prefix 214 o Delegated Prefix 216 o Prefix Adoption 218 o Private Link 220 o Published Assigned Prefix 222 o Applied Assigned Prefix 224 o Shared Link 226 The following terms are used as they are defined in [RFC7787]: 228 o DNCP profile 230 o Node identifier 232 o Link 234 o Interface 235 (HNCP) node a device implementing this specification. 237 (HNCP) router a device implementing this specification, which 238 forwards traffic on behalf of other devices. 240 Greatest node when comparing the DNCP node identifiers of 241 identifier multiple nodes, the one that has the greatest value 242 in a bitwise comparison. 243 Border separation point between administrative domains; in 244 this case, between the home network and any other 245 network, i.e., usually an ISP network. 247 Internal link a link that does not cross borders. 248 Internal an interface that is connected to an internal link. 249 interface 251 External an interface that is connected to a link that is 252 interface not an internal link. 254 Interface a local configuration denoting the use of a 255 category particular interface. The Interface category 256 determines how an HNCP node should treat the 257 particular interface. The External and Internal 258 categories mark the interface as out of or within 259 the network border; there are also a number of 260 subcategories of Internal that further affect local 261 node behavior. See Section 5.1 for a list of 262 interface categories and how they behave. The 263 Internal or External category may also be auto- 264 detected (Section 5.3). 266 Border router a router announcing external connectivity and 267 forwarding traffic across the network border. 269 Common Link a set of nodes on a link that share a common view 270 of it, i.e., they see each other's traffic and the 271 same set of hosts. Unless configured otherwise, 272 transitive connectivity is assumed. 274 DHCPv4 refers to the Dynamic Host Configuration Protocol 275 [RFC2131] in this document. 277 DHCPv6 refers to the Dynamic Host Configuration Protocol 278 for IPv6 (DHCPv6) [RFC3315] in this document. 280 DHCP refers to cases that apply to both DHCPv4 and 281 DHCPv6 in this document. 283 2.1. Requirements Language 285 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 286 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 287 "OPTIONAL" in this document are to be interpreted as described in RFC 288 2119 [RFC2119]. 290 3. DNCP Profile 292 The DNCP profile for HNCP is defined as follows: 294 o HNCP uses UDP datagrams on port 8231 as a transport over link- 295 local scoped IPv6, using unicast and multicast 296 (FF02:0:0:0:0:0:0:11 is the HNCP group address). Received 297 datagrams where either or both of the IPv6 source or destination 298 addresses are not link-local scoped MUST be ignored. Replies to 299 multicast and unicast messages MUST be sent to the IPv6 source 300 address and port of the original message. Each node MUST be able 301 to receive (and potentially reassemble) UDP datagrams with a 302 payload of at least 4000 bytes. 304 o HNCP operates on multicast-capable interfaces only. HNCP nodes 305 MUST assign a non-zero 32-bit endpoint identifier to each 306 interface for which HNCP is enabled. The value 0 is not used in 307 DNCP TLVs but has a special meaning in HNCP TLVs (see Sections 6.4 308 and 10.3). These identifiers MUST be locally unique within the 309 scope of the node, and using values equivalent to the IPv6 link- 310 local scope identifiers for the given interfaces are RECOMMENDED. 312 o HNCP uses opaque 32-bit node identifiers 313 (DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP 314 SHOULD use a random node identifier. If there is a node 315 identifier collision (as specified in the Node-State TLV handling 316 of Section 4.4 of [RFC7787]), the node MUST immediately generate 317 and use a new random node identifier that is not used by any other 318 node at the time, based on the current DNCP network state. 320 o HNCP nodes MUST use the leading 64 bits of the MD5 message digest 321 [RFC1321] as the DNCP hash function H(x) used in building the DNCP 322 hash tree. 324 o HNCP nodes MUST use DNCP's per-endpoint keep-alive extension on 325 all endpoints. The following parameters are suggested: 327 * Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20 328 seconds. 330 * Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1 on virtually 331 lossless links works fine, as it allows for one lost keep- 332 alive. If used on a lossy link, a considerably higher 333 multiplier, such as 15, should be used instead. In that case, 334 an implementation might prefer shorter keep-alive intervals on 335 that link as well to ensure that the timeout (equal to 336 DNCP_KEEPALIVE_INTERVAL * DNCP_KEEPALIVE_MULTIPLIER) after 337 which entirely lost nodes time out is low enough. 339 o HNCP nodes use the following Trickle parameters for the per- 340 interface Trickle instances: 342 * k SHOULD be 1, as the timer reset when data is updated, and 343 further retransmissions should handle packet loss. Even on a 344 non-transitive lossy link, the eventual per-endpoint keep- 345 alives should ensure status synchronization occurs. 347 * Imin SHOULD be 200 milliseconds but MUST NOT be lower. Note: 348 earliest transmissions may occur at Imin / 2. 350 * Imax SHOULD be 7 doublings of Imin [RFC6206] but MUST NOT be 351 lower. 353 o HNCP unicast traffic SHOULD be secured using Datagram Transport 354 Layer Security (DTLS) [RFC6347] as described in DNCP if exchanged 355 over unsecured links. UDP on port 8232 is used for this purpose. 356 A node implementing HNCP security MUST support the DNCP Pre-Shared 357 Key (PSK) method, SHOULD support the PKI-based trust method, and 358 MAY support the DNCP certificate-based trust consensus method. 359 [RFC7525] provides guidance on how to securely utilize DTLS. 361 o HNCP nodes MUST ignore all Node-State TLVs received via multicast 362 on a link that has DNCP security enabled in order to prevent 363 spoofing of node state changes. 365 4. HNCP Versioning and Router Capabilities 367 Multiple versions of HNCP based on compatible DNCP profiles may be 368 present in the same network when transitioning between HNCP versions, 369 and for troubleshooting purposes, it might be beneficial to identify 370 the HNCP agent version running. Therefore, each node MUST include an 371 HNCP-Version TLV (Section 10.1) indicating the currently supported 372 version in its node data and MUST ignore (except for DNCP 373 synchronization purposes) any TLVs that have a type greater than 32 374 and that are published by nodes that didn't also publish an HNCP- 375 Version TLV. 377 HNCP routers may also have different capabilities regarding 378 interactions with hosts, e.g., for configuration or service 379 discovery. These are indicated by M, P, H, and L values. The 380 combined "capability value" is a metric indicated by interpreting the 381 bits as an integer, i.e., (M << 12 | P << 8 | H << 4 | L). These 382 values are used to elect certain servers on a Common Link, as 383 described in Section 7. Nodes that are not routers MUST announce the 384 value 0 for all capabilities. Any node announcing the value 0 for a 385 capability is considered to not advertise said capability and thus 386 does not take part in the respective election. 388 5. Interface Classification 390 5.1. Interface Categories 392 HNCP specifies the following categories that interfaces can be 393 configured to be in: 395 Internal category: This declares an interface to be internal, i.e., 396 within the borders of the HNCP network. The interface MUST 397 operate as a DNCP endpoint. Routers MUST forward traffic with 398 appropriate source addresses between their internal interfaces and 399 allow internal traffic to reach external networks. All nodes MUST 400 implement this category, and nodes not implementing any other 401 category implicitly use it as a fixed default. 403 External category: This declares an interface to be external, i.e., 404 not within the borders of the HNCP network. The interface MUST 405 NOT operate as a DNCP endpoint. Accessing internal resources from 406 external interfaces is restricted, i.e., the use of Recommended 407 Simple Security Capabilities in Customer Premises Equipments 408 (CPEs) [RFC6092] is RECOMMENDED. HNCP routers SHOULD announce 409 acquired configuration information for use in the network as 410 described in Section 6.2, if the interface appears to be connected 411 to an external network. HNCP routers MUST implement this 412 category. 414 Leaf category: This declares an interface used by client devices 415 only. Such an interface uses the Internal category with the 416 exception that it MUST NOT operate as a DNCP endpoint. This 417 category SHOULD be supported by HNCP routers. 419 Guest category: This declares an interface used by untrusted client 420 devices only. In addition to the restrictions of the Leaf 421 category, HNCP routers MUST filter traffic from and to the 422 interface such that connected devices are unable to reach other 423 devices inside the HNCP network or query services advertised by 424 them unless explicitly allowed. This category SHOULD be supported 425 by HNCP routers. 427 Ad Hoc category: This configures an interface to use the Internal 428 category, but no assumption is made about the link's transitivity. 429 All other interface categories assume transitive connectivity. 430 This affects the Common Link (Section 6.1) definition. Support 431 for this category is OPTIONAL. 433 Hybrid category: This declares an interface to use the Internal 434 category while still trying to acquire (external) configuration 435 information on it, e.g., by running DHCP clients. This is useful, 436 e.g., if the link is shared with a non-HNCP router under control 437 and still within the borders of the same network. Detection of 438 this category automatically in addition to manual configuration is 439 out of scope of this document. Support for this category is 440 OPTIONAL. 442 5.2. DHCP-Aided Auto-Detection 444 Auto-detection of interface categories is possible based on 445 interaction with DHCPv4 [RFC2131] and DHCPv6 Prefix Delegation 446 (DHCPv6-PD) [RFC3633] servers on connected links. HNCP defines 447 special DHCP behavior to differentiate its internal servers from 448 external ones in order to achieve this. Therefore, all internal 449 devices (including HNCP nodes) running DHCP servers on links where 450 auto-detection is used by any HNCP node MUST use the following 451 mechanism based on "The User Class Option for DHCP" [RFC3004] and its 452 DHCPv6 counterpart [RFC3315]: 454 o The device MUST ignore or reject DHCP-Requests containing a DHCP 455 user class consisting of the ASCII string "HOMENET". 457 Not following this rule (e.g., running unmodified DHCP servers) might 458 lead to false positives when auto-detection is used, i.e., HNCP nodes 459 assume an interface to not be internal, even though it was intended 460 to be. 462 5.3. Algorithm for Border Discovery 464 This section defines the interface classification algorithm. It is 465 suitable for both IPv4 and IPv6 (single or dual stack) and detects 466 the category of an interface either automatically or based on a fixed 467 configuration. By determining the category for all interfaces, the 468 network borders are implicitly defined, i.e., all interfaces not 469 belonging to the External category are considered to be within the 470 borders of the network; all others are not. 472 The following algorithm MUST be implemented by any node implementing 473 HNCP. However, if the node does not implement auto-detection, only 474 the first and last step are required. The algorithm works as 475 follows, with evaluation stopping at first match: 477 1. If a fixed category is configured for an interface, it is used. 479 2. If a delegated prefix could be acquired by running a DHCPv6 480 client, it is considered external. The DHCPv6 client MUST have 481 included a DHCPv6 user class consisting of the ASCII string 482 "HOMENET" in all of its requests. 484 3. If an IPv4 address could be acquired by running a DHCPv4 client 485 on the interface, it is considered external. The DHCPv4 client 486 MUST have included a DHCP user class consisting of the ASCII 487 string "HOMENET" in all of its requests. 489 4. The interface is considered internal. 491 Note that as other HNCP nodes will ignore the client due to the User 492 Class option, any server that replies is clearly external (or a 493 malicious internal node). 495 An HNCP router SHOULD allow setting the fixed category for each 496 interface that may be connected to either an internal or external 497 device (e.g., an Ethernet port that can be connected to a modem, 498 another HNCP router, or a client). Note that all fixed categories 499 except internal and external cannot be auto-detected and can only be 500 selected using manual configuration. 502 An HNCP router using auto-detection on an interface MUST run the 503 appropriately configured DHCP clients as long as the interface 504 without a fixed category is active (including states where auto- 505 detection considers it to be internal) and rerun the algorithm above 506 to react to conditions resulting in a different interface category. 507 The router SHOULD wait for a reasonable time period (5 seconds as a 508 default), during which the DHCP clients can acquire a lease, before 509 treating a newly activated or previously external interface as 510 internal. 512 6. Autonomous Address Configuration 514 This section specifies how HNCP nodes configure host and node 515 addresses. At first, border routers share information obtained from 516 service providers or local configuration by publishing one or more 517 External-Connection TLVs (Section 10.2). These contain other TLVs 518 such as Delegated-Prefix TLVs (Section 10.2.1) that are then used for 519 prefix assignment. Finally, HNCP nodes obtain addresses either 520 statelessly or using a specific stateful mechanism (Section 6.4). 521 Hosts and non-HNCP routers are configured using SLAAC, DHCP, or 522 DHCPv6-PD. 524 6.1. Common Link 526 HNCP uses the concept of Common Link both in autonomic address 527 configuration and naming and service discovery (Section 8). A Common 528 Link refers to the set of interfaces of nodes that see each other's 529 traffic and presumably also the traffic of all hosts that may use the 530 nodes to, e.g., forward traffic. Common Links are used, e.g., to 531 determine where prefixes should be assigned or which peers 532 participate in the election of a DHCP server. The Common Link is 533 computed separately for each local internal interface, and it always 534 contains the local interface. Additionally, if the local interface 535 is not set to the Ad Hoc category (see Section 5.1), it also contains 536 the set of interfaces that are bidirectionally reachable from the 537 given local interface; that is, every remote interface of a remote 538 node meeting all of the following requirements: 540 o The local node publishes a Peer TLV with: 542 * Peer Node Identifier = remote node's node identifier 544 * Peer Endpoint Identifier = remote interface's endpoint 545 identifier 547 * Endpoint Identifier = local interface's endpoint identifier 549 o The remote node publishes a Peer TLV with: 551 * Peer Node Identifier = local node's node identifier 553 * Peer Endpoint Identifier = local interface's endpoint 554 identifier 556 * Endpoint Identifier = remote interface's endpoint identifier 558 A node MUST be able to detect whether two of its local internal 559 interfaces are connected, e.g., by detecting an identical remote 560 interface being part of the Common Links of both local interfaces. 562 6.2. External Connections 564 Each HNCP router MAY obtain external connection information such as 565 address prefixes, DNS server addresses, and DNS search paths from one 566 or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241], or 567 static configuration. Each individual external connection to be 568 shared in the network is represented by one External-Connection TLV 569 (Section 10.2). 571 Announcements of individual external connections can consist of the 572 following components: 574 Delegated Prefixes: Address space available for assignment to 575 internal links announced using Delegated-Prefix TLVs 576 (Section 10.2.1). Some address spaces might have special 577 properties that are necessary to understand in order to handle 578 them (e.g., information similar to [RFC6603]). This information 579 is encoded using DHCPv6-Data TLVs (Section 10.2.2) inside the 580 respective Delegated-Prefix TLVs. 582 Auxiliary Information: Information about services such as DNS or 583 time synchronization regularly used by hosts in addition to 584 addressing and routing information. This information is encoded 585 using DHCPv6-Data TLVs (Section 10.2.2) and DHCPv4-Data TLVs 586 (Section 10.2.3). 588 Whenever information about reserved parts (e.g., as specified in 589 [RFC6603]) is received for a delegated prefix, the reserved parts 590 MUST be advertised using Assigned-Prefix TLVs (Section 10.3) with the 591 greatest priority (i.e., 15), as if they were assigned to a Private 592 Link. 594 Some connections or delegated prefixes may have a special meaning and 595 are not regularly used for internal or Internet connectivity; 596 instead, they may provide access to special services like VPNs, 597 sensor networks, Voice over IP (VoIP), IPTV, etc. Care must be taken 598 that these prefixes are properly integrated and dealt with in the 599 network, in order to avoid breaking connectivity for devices who are 600 not aware of their special characteristics or to only selectively 601 allow certain devices to use them. Such prefixes are distinguished 602 using Prefix-Policy TLVs (Section 10.2.1.1). Their contents MAY be 603 partly opaque to HNCP nodes, and their identification and usage 604 depends on local policy. However, the following general rules MUST 605 be adhered to: 607 Special rules apply when making address assignments for prefixes 608 with Prefix-Policy TLVs with type 131, as described in 609 Section 6.3.2. 611 In the presence of any type 1 to 128 Prefix-Policy TLV, the prefix 612 is specialized to reach destinations denoted by any such Prefix- 613 Policy TLV, i.e., in absence of a type 0 Prefix-Policy TLV, it is 614 not usable for general Internet connectivity. An HNCP router MAY 615 enforce this restriction with appropriate packet filter rules. 617 6.3. Prefix Assignment 619 HNCP uses the prefix assignment algorithm [RFC7695] in order to 620 assign prefixes to HNCP internal links and uses some of the 621 terminology (Section 2) defined there. HNCP furthermore defines the 622 Assigned-Prefix TLV (Section 10.3), which MUST be used to announce 623 Published Assigned Prefixes. 625 6.3.1. Prefix Assignment Algorithm Parameters 627 All HNCP nodes running the prefix assignment algorithm use the 628 following values for its parameters: 630 Node IDs: HNCP node identifiers are used. The comparison operation 631 is defined as bitwise comparison. 633 Set of Delegated Prefixes: The set of prefixes encoded in 634 Delegated-Prefix TLVs that are not strictly included in prefixes 635 encoded in other Delegated-Prefix TLVs. Note that Delegated- 636 Prefix TLVs included in ignored External-Connection TLVs are not 637 considered. It is dynamically updated as Delegated-Prefix TLVs 638 are added or removed. 640 Set of Shared Links: The set of Common Links associated with 641 interfaces with the Internal, Leaf, Guest, or Ad Hoc category. It 642 is dynamically updated as interfaces are added, removed, or 643 switched from one category to another. When multiple interfaces 644 are detected as belonging to the same Common Link, prefix 645 assignment is disabled on all of these interfaces except one. 647 Set of Private Links: This document defines Private Links as 648 representing DHCPv6-PD clients or as a mean to advertise prefixes 649 included in the DHCPv6 Exclude Prefix option. Other 650 implementation-specific Private Links may be defined whenever a 651 prefix needs to be assigned for a purpose that does not require a 652 consensus with other HNCP nodes. 654 Set of Advertised Prefixes: The set of prefixes included in 655 Assigned-Prefix TLVs advertised by other HNCP nodes (prefixes 656 advertised by the local node are not in this set). The associated 657 Advertised Prefix Priority is the priority specified in the TLV. 658 The associated Shared Link is determined as follows: 660 * If the Link Identifier is 0, the Advertised Prefix is not 661 assigned on a Shared Link. 663 * If the other node's interface identified by the Link Identifier 664 is included in one of the Common Links used for prefix 665 assignment, it is considered as assigned on the given Common 666 Link. 668 * Otherwise, the Advertised Prefix is not assigned on a Shared 669 Link. 671 Advertised Prefixes as well as their associated priorities and 672 associated Shared Links MUST be updated as Assigned-Prefix TLVs 673 are added, updated, or removed, and as Common Links are modified. 675 ADOPT_MAX_DELAY: The default value is 0 seconds (i.e., prefix 676 adoption is done instantly). 678 BACKOFF_MAX_DELAY: The default value is 4 seconds. 680 RANDOM_SET_SIZE: The default value is 64. 682 Flooding Delay: The default value is 5 seconds. 684 Default Advertised Prefix Priority: When a new assignment is 685 created or an assignment is adopted -- as specified in the prefix 686 assignment algorithm routine -- the default Advertised Prefix 687 Priority to be used is 2. 689 6.3.2. Making New Assignments 691 Whenever the prefix assignment algorithm subroutine (Section 4.1 of 692 [RFC7695]) is run on a Common Link, and whenever a new prefix may be 693 assigned (case 1 of the subroutine: no Best Assignment and no Current 694 Assignment), the decision of whether the assignment of a new prefix 695 is desired MUST follow these rules in order: 697 If the Delegated-Prefix TLV contains a DHCPv6-Data TLV, and the 698 meaning of one of the DHCP options is not understood by the HNCP 699 node, the creation of a new prefix is not desired. This rule 700 applies to TLVs inside Delegated-Prefix TLVs but not to those 701 inside External-Connection TLVs. 703 If the remaining preferred lifetime of the prefix is 0 and there 704 is another delegated prefix of the same IP version used for prefix 705 assignment with a non-zero preferred lifetime, the creation of a 706 new prefix is not desired. 708 If the Delegated-Prefix TLV does not include a Prefix-Policy TLV 709 indicating restrictive assignment (type 131) or if local policy 710 exists to identify it based on, e.g., other Prefix-Policy TLV 711 values and allows assignment, the creation of a new prefix is 712 desired. 714 Otherwise, the creation of a new prefix is not desired. 716 If the considered delegated prefix is an IPv6 prefix, and whenever 717 there is at least one available prefix of length 64, a prefix of 718 length 64 MUST be selected unless configured otherwise. In case no 719 prefix of length 64 would be available, a longer prefix MAY be 720 selected even without configuration. 722 If the considered delegated prefix is an IPv4 prefix (Section 6.5 723 details how IPv4-delegated prefixes are generated), a prefix of 724 length 24 SHOULD be preferred. 726 In any case, an HNCP router making an assignment MUST support a 727 mechanism suitable to distribute addresses from the considered prefix 728 if the link is intended to be used by clients. In this case, a 729 router assigning an IPv4 prefix MUST announce the L-capability, and a 730 router assigning an IPv6 prefix with a length greater than 64 MUST 731 announce the H-capability as defined in Section 4. 733 6.3.3. Applying Assignments 735 The prefix assignment algorithm indicates when a prefix is applied to 736 the respective Common Link. When that happens, each router connected 737 to said link: 739 MUST forward traffic destined to said prefix to the respective 740 link. 742 MUST participate in the client configuration election as described 743 in Section 7, if the link is intended to be used by clients. 745 MAY add an address from said prefix to the respective network 746 interface as described in Section 6.4, e.g., if it is to be used 747 as source for locally originating traffic. 749 6.3.4. DHCPv6 Prefix Delegation 751 When an HNCP router announcing the P-Capability (Section 4) receives 752 a DHCPv6-PD request from a client, it SHOULD assign one prefix per 753 delegated prefix in the network. This set of assigned prefixes is 754 then delegated to the client, after it has been applied as described 755 in the prefix assignment algorithm. Each DHCPv6-PD client MUST be 756 considered as an independent Private Link, and delegation MUST be 757 based on the same set of delegated prefixes as the one used for 758 Common Link prefix assignments; however, the prefix length to be 759 delegated MAY be smaller than 64. 761 The assigned prefixes MUST NOT be given to DHCPv6-PD clients before 762 they are applied and MUST be withdrawn whenever they are destroyed. 763 As an exception to this rule, in order to shorten delays of processed 764 requests, a router MAY prematurely give out a prefix that is 765 advertised but not yet applied if it does so with a valid lifetime of 766 not more than 30 seconds and ensures removal or correction of 767 lifetimes as soon as possible. 769 6.4. Node Address Assignment 771 This section specifies how HNCP nodes reserve addresses for their own 772 use. Nodes MAY, at any time, try to reserve a new address from any 773 Applied Assigned Prefix. Each HNCP node SHOULD announce an IPv6 774 address and -- if it supports IPv4 -- MUST announce an IPv4 address, 775 whenever matching prefixes are assigned to at least one of its Common 776 Links. These addresses are published using Node-Address TLVs and 777 used to locally reach HNCP nodes for other services. Nodes SHOULD 778 NOT create and announce more than one assignment per IP version to 779 avoid cluttering the node data with redundant information unless a 780 special use case requires it. 782 Stateless assignment based on Semantically Opaque Interface 783 Identifiers [RFC7217] SHOULD be used for address assignment whenever 784 possible (e.g., the prefix length is 64), otherwise (e.g., for IPv4 785 if supported) the following method MUST be used instead: For any 786 assigned prefix for which stateless assignment is not used, the first 787 quarter of the addresses are reserved for HNCP-based address 788 assignments, whereas the last three quarters are left to the DHCP 789 elected router (Section 4 specifies the DHCP server election 790 process). For example, if the prefix 192.0.2.0/24 is assigned and 791 applied to a Common Link, addresses included in 192.0.2.0/26 are 792 reserved for HNCP nodes, and the remaining addresses are reserved for 793 the elected DHCPv4 server. 795 HNCP nodes assign addresses to themselves and then (to ensure 796 eventual lack of conflicting assignments) publish the assignments 797 using the Node-Address TLV (Section 10.4). 799 The process of obtaining addresses is specified as follows: 801 o A node MUST NOT start advertising an address if it is already 802 advertised by another node. 804 o An assigned address MUST be part of an assigned prefix currently 805 applied on a Common Link that includes the interface specified by 806 the endpoint identifier. 808 o An address MUST NOT be used unless it has been advertised for at 809 least ADDRESS_APPLY_DELAY consecutive seconds and is still 810 currently being advertised. The default value for 811 ADDRESS_APPLY_DELAY is 3 seconds. 813 o Whenever the same address is advertised by more than one node, all 814 but the one advertised by the node with the greatest node 815 identifier MUST be removed. 817 6.5. Local IPv4 and ULA Prefixes 819 HNCP routers can create a Unique Local Address (ULA) or private IPv4 820 prefix to enable connectivity between local devices. These prefixes 821 are inserted in HNCP as if they were delegated prefixes of a 822 (virtual) external connection (Section 6.2). The following rules 823 apply: 825 An HNCP router SHOULD create a ULA prefix if there is no other 826 IPv6 prefix with a preferred time greater than 0 in the network. 827 It MAY also do so if there are other delegated IPv6 prefixes, but 828 none of which is locally generated (i.e., without any Prefix- 829 Policy TLV) and has a preferred time greater than 0. However, it 830 MUST NOT do so otherwise. In case multiple locally generated ULA 831 prefixes are present, only the one published by the node with the 832 greatest node identifier is kept among those with a preferred time 833 greater than 0 -- if there is any. 835 An HNCP router MUST create a private IPv4 prefix [RFC1918] 836 whenever it wishes to provide IPv4 Internet connectivity to the 837 network and no other private IPv4 prefix with Internet 838 connectivity currently exists. It MAY also enable local IPv4 839 connectivity by creating a private IPv4 prefix if no IPv4 prefix 840 exists but MUST NOT do so otherwise. In case multiple IPv4 841 prefixes are announced, only the one published by the node with 842 the greatest node identifier is kept among those with a Prefix- 843 Policy TLV of type 0 -- if there is any. The router publishing a 844 prefix with Internet connectivity MUST forward IPv4 traffic to the 845 Internet and perform NAT on behalf of the network as long as it 846 publishes the prefix; other routers in the network MAY choose not 847 to. 849 Creation of such ULA and IPv4 prefixes MUST be delayed by a random 850 time span between 0 and 10 seconds in which the router MUST scan for 851 others trying to do the same. 853 When a new ULA prefix is created, the prefix is selected based on the 854 configuration, using the last non-deprecated ULA prefix, or generated 855 based on [RFC4193]. 857 7. Configuration of Hosts and Non-HNCP Routers 859 HNCP routers need to ensure that hosts and non-HNCP downstream 860 routers on internal links are configured with addresses and routes. 861 Since DHCP clients can usually only bind to one server at a time, a 862 per-link and per-service election takes place. 864 HNCP routers may have different capabilities for configuring 865 downstream devices and providing naming services. Each router MUST 866 therefore indicate its capabilities as specified in Section 4 in 867 order to participate as a candidate in the election. 869 7.1. IPv6 Addressing and Configuration 871 In general, Stateless Address Autoconfiguration [RFC4861] is used for 872 client configuration for its low overhead and fast renumbering 873 capabilities. Therefore, each HNCP router sends Router 874 Advertisements on interfaces that are intended to be used by clients 875 and MUST at least include a Prefix Information Option for each 876 Applied Assigned Prefix that it assigned to the respective link in 877 every such advertisement. However, stateful DHCPv6 can be used in 878 addition by administrative choice to, e.g., collect hostnames and use 879 them to provide naming services or whenever stateless configuration 880 is not applicable. 882 The designated stateful DHCPv6 server for a Common Link (Section 6.1) 883 is elected based on the capabilities described in Section 4. The 884 winner is the router (connected to the Common Link) advertising the 885 greatest H-capability. In case of a tie, Capability Values 886 (Section 4) are compared, and the router with the greatest value is 887 elected. In case of another tie, the router with the greatest node 888 identifier is elected among the routers with tied Capability Values. 890 The elected router MUST serve stateful DHCPv6 and SHOULD provide 891 naming services for acquired hostnames as outlined in Section 8; all 892 other nodes MUST NOT. Stateful addresses SHOULD be assigned in a way 893 that does not hinder fast renumbering even if the DHCPv6 server or 894 client do not support the DHCPv6 reconfigure mechanism, e.g., by only 895 handing out leases from locally generated (ULA) prefixes and prefixes 896 with a length different from 64 and by using low renew and rebind 897 times (i.e., not longer than 5 minutes). In case no router was 898 elected, stateful DHCPv6 is not provided. Routers that cease to be 899 elected DHCP servers SHOULD -- when applicable -- invalidate 900 remaining existing bindings in order to trigger client 901 reconfiguration. 903 7.2. DHCPv6 for Prefix Delegation 905 The designated DHCPv6 server for prefix delegation on a Common Link 906 is elected based on the capabilities described in Section 4. The 907 winner is the router (connected to the Common Link) advertising the 908 greatest P-capability. In case of a tie, Capability Values 909 (Section 4) are compared, and the router with the greatest value is 910 elected. In case of another tie, the router with the greatest node 911 identifier is elected among the routers with tied Capability Values. 913 The elected router MUST provide prefix delegation services [RFC3633] 914 on the given link (and follow the rules in Section 6.3.4); all other 915 nodes MUST NOT. 917 7.3. DHCPv4 for Addressing and Configuration 919 The designated DHCPv4 server on a Common Link (Section 6.1) is 920 elected based on the capabilities described in Section 4. The winner 921 is the router (connected to the Common Link) advertising the greatest 922 L-capability. In case of a tie, Capability Values (Section 4) are 923 compared, and the router with the greatest value is elected. In case 924 of another tie, the router with the greatest node identifier is 925 elected among the routers with tied Capability Values. 927 The elected router MUST provide DHCPv4 services on the given link; 928 all other nodes MUST NOT. The elected router MUST provide IP 929 addresses from the pool defined in Section 6.4 and MUST announce 930 itself as router [RFC2132] to clients. 932 DHCPv4 lifetimes renew and rebind times (T1 and T2) SHOULD be short 933 (i.e., not longer than 5 minutes) in order to provide reasonable 934 response times to changes. Routers that cease to be elected DHCP 935 servers SHOULD -- when applicable -- invalidate remaining existing 936 bindings in order to trigger client reconfiguration. 938 7.4. Multicast DNS Proxy 940 The designated Multicast DNS (mDNS) [RFC6762] proxy on a Common Link 941 is elected based on the capabilities described in Section 4. The 942 winner is the router (connected to the Common Link) advertising the 943 greatest M-capability. In case of a tie, Capability Values 944 (Section 4) are compared, and the router with the greatest value is 945 elected. In case of another tie, the router with the greatest node 946 identifier is elected among the routers with tied Capability Values. 948 The elected router MUST provide an mDNS proxy on the given link and 949 announce it as described in Section 8. 951 8. Naming and Service Discovery 953 Network-wide naming and service discovery can greatly improve the 954 user friendliness of a network. The following mechanism provides 955 means to setup and delegate naming and service discovery across 956 multiple HNCP routers. 958 Each HNCP router SHOULD provide and advertise a recursive name 959 resolving server to clients that honor the announcements made in 960 Delegated-Zone TLVs (Section 10.5), Domain-Name TLVs (Section 10.6), 961 and Node-Name TLVs (Section 10.7), i.e., delegate queries to the 962 designated name servers and hand out appropriate A, AAAA, and PTR 963 records according to the mentioned TLVs. 965 Each HNCP router SHOULD provide and announce an auto-generated or 966 user-configured name for each internal Common Link (Section 6.1) for 967 which it is the designated DHCPv4, stateful DHCPv6 server, mDNS 968 proxy, or for which it provides forward or reverse DNS services on 969 behalf of connected devices. This announcement is done using 970 Delegated-Zone TLVs (Section 10.5) and MUST be unique in the whole 971 network. In case of a conflict, the announcement of the node with 972 the greatest node identifier takes precedence, and all other nodes 973 MUST cease to announce the conflicting TLV. HNCP routers providing 974 recursive name resolving services MUST use the included DNS server 975 address within the TLV to resolve names belonging to the zone as if 976 there was an NS record. 978 Each HNCP node SHOULD announce a node name for itself to be easily 979 reachable and MAY announce names on behalf of other devices. 980 Announcements are made using Node-Name TLVs (Section 10.7), and the 981 announced names MUST be unique in the whole network. In case of a 982 conflict, the announcement of the node with the greatest node 983 identifier takes precedence, and all other nodes MUST cease to 984 announce the conflicting TLV. HNCP routers providing recursive name 985 resolving services as described above MUST resolve such announced 986 names to their respective IP addresses as if there were corresponding 987 A/AAAA records. 989 Names and unqualified zones are used in an HNCP network to provide 990 naming and service discovery with local significance. A network-wide 991 zone is appended to all single labels or unqualified zones in order 992 to qualify them. A default value for this TLV MUST be set, although 993 the default value of the Domain-Name TLV (Section 10.6) is out of 994 scope of this document, and an administrator MAY configure the 995 announcement of a Domain-Name TLV for the network. In case multiple 996 are announced, the domain of the node with the greatest node 997 identifier takes precedence. 999 9. Securing Third-Party Protocols 1001 PSKs are often required to secure (for example) IGPs and other 1002 protocols that lack support for asymmetric security. The following 1003 mechanism manages PSKs using HNCP to enable bootstrapping of such 1004 third-party protocols. The scheme SHOULD NOT be used unless it's in 1005 conjunction with secured HNCP unicast transport (i.e., DTLS), as 1006 transferring the PSK in plaintext anywhere in the network is a 1007 potential risk, especially as the originator may not know about 1008 security (and use of DNCP security) on all links. The following 1009 rules define how such a PSK is managed and used: 1011 o If no Managed-PSK TLV (Section 10.8) is currently being announced, 1012 an HNCP node using this mechanism MUST create one after a random 1013 delay of 0 to 10 seconds with a 32 bytes long random key and add 1014 it to its node data. 1016 o In case multiple nodes announce such a TLV at the same time, all 1017 but the one with the greatest node identifier stop advertising it 1018 and adopt the remaining one. 1020 o The node currently advertising the Managed-PSK TLV MUST generate 1021 and advertise a new random one whenever an unreachable node is 1022 removed from the DNCP topology as described in Section 4.6 of 1023 [RFC7787]. 1025 PSKs for individual protocols SHOULD be derived from the random PSK 1026 using a suitable one-way hashing algorithm (e.g., by using the HMAC- 1027 based Key Derivation Function (HKDF) based on HMAC-SHA256 [RFC6234] 1028 with the particular protocol name in the info field) so that 1029 disclosure of any derived key does not impact other users of the 1030 managed PSK. Furthermore, derived PSKs MUST be updated whenever the 1031 managed PSK changes. 1033 10. Type-Length-Value Objects 1035 HNCP defines the following TLVs in addition to those defined by DNCP. 1036 The same general rules and defaults for encoding as noted in 1037 Section 7 of [RFC7787] apply. Note that most HNCP variable-length 1038 TLVs also support optional nested TLVs, and they are encoded after 1039 the variable-length content, followed by the zero padding of the 1040 variable-length content to the next 32-bit boundary. 1042 TLVs defined here are only valid when appearing in their designated 1043 context, i.e., only directly within container TLVs mentioned in their 1044 definition or -- absent any mentions -- only as top-level TLVs within 1045 the node data set. TLVs appearing outside their designated context 1046 MUST be ignored. 1048 TLVs encoding IP addresses or prefixes allow encoding both IPv6 and 1049 IPv4 addresses and prefixes. IPv6 information is encoded as is, 1050 whereas for IPv4, the IPv4-mapped IPv6 addresses format [RFC4291] is 1051 used, and prefix lengths are encoded as the original IPv4 prefix 1052 length increased by 96. 1054 10.1. HNCP-Version TLV 1056 0 1 2 3 1057 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 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Type: HNCP-Version (32) | Length: >= 5 | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Reserved | M | P | H | L | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | User-agent | 1065 This TLV is used to indicate the supported version and router 1066 capabilities of an HNCP node as described in Section 4. 1068 Reserved: Bits are reserved for future use. They MUST be set to 0 1069 when creating this TLV, and their value MUST be ignored when 1070 processing the TLV. 1072 M-capability: Priority value used for electing the on-link mDNS 1073 [RFC6762] proxy. It MUST be set to 0 if the router is not capable 1074 of proxying mDNS, otherwise it SHOULD be set to 4 but MAY be set 1075 to any value from 1 to 7 to indicate a non-default priority. The 1076 values 8-15 are reserved for future use. 1078 P-capability: Priority value used for electing the on-link DHCPv6-PD 1079 server. It MUST be set to 0 if the router is not capable of 1080 providing prefixes through DHCPv6-PD (Section 6.3.4), otherwise it 1081 SHOULD be set to 4 but MAY be set to any value from 1 to 7 to 1082 indicate a non-default priority. The values 8-15 are reserved for 1083 future use. 1085 H-capability: Priority value used for electing the on-link DHCPv6 1086 server offering non-temporary addresses. It MUST be set to 0 if 1087 the router is not capable of providing such addresses, otherwise 1088 it SHOULD be set to 4 but MAY be set to any value from 1 to 7 to 1089 indicate a non-default priority. The values 8-15 are reserved for 1090 future use. 1092 L-capability: Priority value used for electing the on-link DHCPv4 1093 server. It MUST be set to 0 if the router is not capable of 1094 running a legacy DHCPv4 server offering IPv4 addresses to clients, 1095 otherwise it SHOULD be set to 4 but MAY be set to any value from 1 1096 to 7 to indicate a non-default priority. The values 8-15 are 1097 reserved for future use. 1099 User-Agent: The user-agent is a human-readable UTF-8 string that 1100 describes the name and version of the current HNCP implementation. 1102 10.2. External-Connection TLV 1104 0 1 2 3 1105 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 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Type: External-Connection (33)| Length | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | (Optional nested TLVs) | 1111 An External-Connection TLV is a container TLV used to gather network 1112 configuration information associated with a single external 1113 connection (Section 6.2) to be shared across the HNCP network. A 1114 node MAY publish an arbitrary number of instances of this TLV to 1115 share the desired number of external connections. Upon reception, 1116 the information transmitted in any nested TLVs is used for the 1117 purposes of prefix assignment (Section 6.3) and host configuration 1118 (Section 7). 1120 10.2.1. Delegated-Prefix TLV 1122 0 1 2 3 1123 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 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Type: Delegated-Prefix (34) | Length: >= 9 | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | Valid Lifetime Since Origination | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Preferred Lifetime Since Origination | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | Prefix Length | | 1132 +-+-+-+-+-+-+-+-+ Prefix + 1133 ... 1134 | | 0-pad if any | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | (Optional nested TLVs) | 1138 The Delegated-Prefix TLV is used by HNCP routers to advertise 1139 prefixes that are allocated to the whole network and can be used for 1140 prefix assignment. Delegated-Prefix TLVs are only valid inside 1141 External-Connection TLVs, and their prefixes MUST NOT overlap with 1142 those of other such TLVs in the same container. 1144 Valid Lifetime Since Origination: The time in seconds the delegated 1145 prefix was valid for at the origination time of the node data 1146 containing this TLV. The value MUST be updated whenever the node 1147 republishes its Node-State TLV. 1149 Preferred Lifetime Since Origination: The time in seconds the 1150 delegated prefix was preferred for at the origination time of the 1151 node data containing this TLV. The value MUST be updated whenever 1152 the node republishes its Node-State TLV. 1154 Prefix Length: The number of significant bits in the prefix. 1156 Prefix: Significant bits of the prefix padded with zeros up to the 1157 next byte boundary. 1159 10.2.1.1. Prefix-Policy TLV 1161 0 1 2 3 1162 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 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Type: Prefix-Policy (43) | Length: >= 1 | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 | Policy Type | | 1167 +-+-+-+-+-+-+-+-+ Value + 1168 | | 1170 The Prefix-Policy TLV contains information about the policy or 1171 applicability of a delegated prefix. This information can be used to 1172 determine whether prefixes for a certain use case (e.g., local 1173 reachability, Internet connectivity) do exist or are to be acquired 1174 and to make decisions about assigning prefixes to certain links or to 1175 fine-tune border firewalls. See Section 6.2 for a more in-depth 1176 discussion. This TLV is only valid inside a Delegated-Prefix TLV. 1178 Policy Type: The type of the policy identifier. 1180 0: Internet connectivity (no value). 1182 1-128: Explicit destination prefix with the Policy Type being 1183 the actual length of the prefix and the value containing 1184 significant bits of the destination prefix padded with 1185 zeros up to the next byte boundary. 1187 129: DNS domain. The value contains a DNS label sequence 1188 encoded per [RFC1035]. Compression MUST NOT be used. 1189 The label sequence MUST end with an empty label. 1191 130: Opaque UTF-8 string (e.g., for administrative purposes). 1193 131: Restrictive assignment (no value). 1195 132-255: Reserved for future additions. 1197 Value: A variable-length identifier of the given type. 1199 10.2.2. DHCPv6-Data TLV 1201 0 1 2 3 1202 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 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Type: DHCPv6-Data (38) | Length: > 0 | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | DHCPv6 option stream | 1208 This TLV is used to encode auxiliary IPv6 configuration information 1209 (e.g., recursive DNS servers) encoded as a stream of DHCPv6 options. 1210 It is only valid in an External-Connection TLV or a Delegated-Prefix 1211 TLV encoding an IPv6 prefix and MUST NOT occur more than once in any 1212 single container. When included in an External-Connection TLV, it 1213 contains DHCPv6 options relevant to the external connection as a 1214 whole. When included in a delegated prefix, it contains options 1215 mandatory to handle said prefix. 1217 DHCPv6 option stream: DHCPv6 options encoded as specified in 1218 [RFC3315]. 1220 10.2.3. DHCPv4-Data TLV 1222 0 1 2 3 1223 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 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 | Type: DHCPv4-Data (37) | Length: > 0 | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 | DHCPv4 option stream | 1229 This TLV is used to encode auxiliary IPv4 configuration information 1230 (e.g., recursive DNS servers) encoded as a stream of DHCPv4 options. 1231 It is only valid in an External-Connection TLV and MUST NOT occur 1232 more than once in any single container. It contains DHCPv4 options 1233 relevant to the external connection as a whole. 1235 DHCPv4 option stream: DHCPv4 options encoded as specified in 1236 [RFC2131]. 1238 10.3. Assigned-Prefix TLV 1240 0 1 2 3 1241 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 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 | Type: Assigned-Prefix (35) | Length: >= 6 | 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | Endpoint Identifier | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | Rsv. | Prty. | Prefix Length | | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix + 1249 ... 1250 | | 0-pad if any | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | (Optional nested TLVs) | 1254 This TLV is used to announce Published Assigned Prefixes for the 1255 purposes of prefix assignment (Section 6.3). 1257 Endpoint Identifier: The endpoint identifier of the local interface 1258 the prefix is assigned to, or 0 if it is assigned to a Private 1259 Link (e.g., when the prefix is assigned for downstream prefix 1260 delegation). 1262 Rsv.: Bits are reserved for future use. They MUST be set to 0 when 1263 creating this TLV, and their value MUST be ignored when processing 1264 the TLV. 1266 Prty: The Advertised Prefix Priority from 0 to 15. 1268 0-1: Low priorities. 1270 2: Default priority. 1272 3-7: High priorities. 1274 8-11: Administrative priorities. MUST NOT be used unless 1275 configured otherwise. 1277 12-14: Reserved for future use. 1279 15: Provider priorities. MAY only be used by the router 1280 advertising the corresponding delegated prefix and based 1281 on static or dynamic configuration (e.g., for excluding a 1282 prefix based on the DHCPv6-PD Prefix Exclude Option 1283 [RFC6603]). 1285 Prefix Length: The number of significant bits in the Prefix field. 1287 Prefix: The significant bits of the prefix padded with zeros up to 1288 the next byte boundary. 1290 10.4. Node-Address TLV 1292 0 1 2 3 1293 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 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Type: Node-Address (36) | Length: 20 | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | Endpoint Identifier | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | | 1300 | IP Address | 1301 | | 1302 | | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | (Optional nested TLVs) | 1306 This TLV is used to announce addresses assigned to an HNCP node as 1307 described in Section 6.4. 1309 Endpoint Identifier: The endpoint identifier of the local interface 1310 the prefix is assigned to, or 0 if it is not assigned on an HNCP 1311 enabled link. 1313 IP Address: The globally scoped IPv6 address, or the IPv4 address 1314 encoded as an IPv4-mapped IPv6 address [RFC4291]. 1316 10.5. DNS-Delegated-Zone TLV 1318 0 1 2 3 1319 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 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | Type: DNS-Delegated-Zone (39) | Length: >= 17 | 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 | | 1324 | IP Address | 1325 | | 1326 | | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 |Reserved |L|B|S| | 1329 +-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) | 1330 ... 1331 | | 0-pad if any | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | (Optional nested TLVs) | 1334 This TLV is used to announce a forward or reverse DNS zone delegation 1335 in the HNCP network. Its meaning is roughly equivalent to specifying 1336 an NS and A/AAAA record for said zone. Details are specified in 1337 Section 8. 1339 IP Address: The IPv6 address of the authoritative DNS server for the 1340 zone; IPv4 addresses are represented as IPv4-mapped addresses 1341 [RFC4291]. The special value of :: (all zeros) means the 1342 delegation is available in the global DNS hierarchy. 1344 Reserved: Those bits MUST be set to 0 when creating the TLV and 1345 ignored when parsing it unless defined in a later specification. 1347 L-bit: (DNS-based Service Discovery (DNS-SD) [RFC6763] Legacy- 1348 Browse) indicates that this delegated zone SHOULD be included in 1349 the network's DNS-SD legacy browse list of domains at 1350 lb._dns-sd._udp.(DOMAIN-NAME). Local forward zones SHOULD have 1351 this bit set; reverse zones SHOULD NOT. 1353 B-bit: (DNS-SD [RFC6763] Browse) indicates that this delegated zone 1354 SHOULD be included in the network's DNS-SD browse list of domains 1355 at b._dns-sd._udp.(DOMAIN-NAME). Local forward zones SHOULD have 1356 this bit set; reverse zones SHOULD NOT. 1358 S-bit: (Fully qualified DNS-SD [RFC6763] domain) indicates that this 1359 delegated zone consists of a fully qualified DNS-SD domain, which 1360 should be used as the base for DNS-SD domain enumeration, i.e., 1361 _dns-sd._udp.(Zone) exists. Forward zones MAY have this bit set; 1362 reverse zones MUST NOT. This can be used to provision a DNS 1363 search path to hosts for non-local services (such as those 1364 provided by an ISP or other manually configured service 1365 providers). Zones with this flag SHOULD be added to the search 1366 domains advertised to clients. 1368 Zone: The label sequence encoded according to [RFC1035]. 1369 Compression MUST NOT be used. The label sequence MUST end with an 1370 empty label. 1372 10.6. Domain-Name TLV 1374 0 1 2 3 1375 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 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Type: Domain-Name (40) | Length: > 0 | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | Domain (DNS label sequence - variable length) | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 This TLV is used to indicate the base domain name for the network as 1382 specified in Section 8. This TLV MUST NOT be announced unless the 1383 domain name was explicitly configured by an administrator. 1385 Domain: The label sequence encoded according to [RFC1035]. 1386 Compression MUST NOT be used. The label sequence MUST end with an 1387 empty label. 1389 10.7. Node-Name TLV 1391 0 1 2 3 1392 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 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | Type: Node-Name (41) | Length: > 17 | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | | 1397 | IP Address | 1398 | | 1399 | | 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 | Length | Name | 1402 ... 1403 | (not null-terminated, variable length) | 0-pad if any | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | (Optional nested TLVs) | 1407 This TLV is used to assign the name of a node in the network to a 1408 certain IP address as specified in Section 8. 1410 IP Address: The IP address associated with the name. IPv4 1411 addresses are encoded using IPv4-mapped IPv6 addresses. 1413 Length: The length of the name (0-63). 1415 Name: The name of the node as a single DNS label. 1417 10.8. Managed-PSK TLV 1418 0 1 2 3 1419 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 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | Type: Managed-PSK (42) | Length: 32 | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | | 1424 | | 1425 | | 1426 | Random 256-bit PSK | 1427 | | 1428 | | 1429 | | 1430 | | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | (Optional nested TLVs) | 1434 This TLV is used to announce a PSK for securing third-party protocols 1435 exclusively supporting symmetric cryptography as specified in 1436 Section 9. 1438 11. General Requirements for HNCP Nodes 1440 Each node implementing HNCP is subject to the following requirements: 1442 o It MUST implement HNCP versioning (Section 4) and interface 1443 classification (Section 5). 1445 o It MUST implement and run the method for securing third-party 1446 protocols (Section 9) whenever it uses the security mechanism of 1447 HNCP. 1449 If the node is acting as a router, then the following requirements 1450 apply in addition: 1452 o It MUST support Autonomous Address Configuration (Section 6) and 1453 configuration of hosts and non-HNCP routers (Section 7). 1455 o It SHOULD implement support for naming and service discovery 1456 (Section 8) as defined in this document. 1458 o It MAY be able to provide connectivity to IPv4 devices using 1459 DHCPv4. 1461 o It SHOULD be able to delegate prefixes to legacy IPv6 routers 1462 using DHCPv6-PD (Section 6.3.4). 1464 o In addition, the normative language of "Basic Requirements for 1465 IPv6 Customer Edge Routers" [RFC7084] applies with the following 1466 adjustments: 1468 * The generic requirements G-4 and G-5 are relaxed such that any 1469 known default router on any interface is sufficient for a 1470 router to announce itself as the default router; similarly, 1471 only the loss of all such default routers results in self- 1472 invalidation. 1474 * "WAN-Side Configuration" (Section 4.2) applies to interfaces 1475 classified as external. 1477 * If the Customer Edge (CE) sends a size hint as indicated in 1478 WPD-2, the hint MUST NOT be determined by the number of LAN 1479 interfaces of the CE but SHOULD instead be large enough to at 1480 least accommodate prefix assignments announced for existing 1481 delegated or ULA prefixes, if such prefixes exist and unless 1482 explicitly configured otherwise. 1484 * The dropping of packets with a destination address belonging to 1485 a delegated prefix mandated in WPD-5 MUST NOT be applied to 1486 destinations that are part of any prefix announced using an 1487 Assigned-Prefix TLV by any HNCP router in the network. 1489 * "LAN-Side Configuration" (Section 4.3) applies to interfaces 1490 not classified as external. 1492 * The requirement L-2 to assign a separate /64 to each LAN 1493 interface is replaced by the participation in the prefix 1494 assignment mechanism (Section 6.3) for each such interface. 1496 * The requirement L-9 is modified, in that the M flag MUST be set 1497 if and only if a router connected to the respective Common Link 1498 is advertising a non-zero H-capability. The O flag SHOULD 1499 always be set. 1501 * The requirement L-12 to make DHCPv6 options available is 1502 adapted, in that Canonical Encoding Rules (CER) SHOULD publish 1503 the subset of options using the DHCPv6-Data TLV in an External- 1504 Connection TLV. Similarly, it SHOULD do the same for DHCPv4 1505 options in a DHCPv4-Data TLV. DHCPv6 options received inside 1506 an OPTION_IAPREFIX [RFC3633] MUST be published using a 1507 DHCPv6-Data TLV inside the respective Delegated-Prefix TLV. 1508 HNCP routers SHOULD make relevant DHCPv6 and DHCPv4 options 1509 available to clients, i.e., options contained in External- 1510 Connection TLVs that also include delegated prefixes from which 1511 a subset is assigned to the respective link. 1513 * The requirement L-13 to deprecate prefixes is applied to all 1514 delegated prefixes in the network from which assignments have 1515 been made on the respective interface. Furthermore, the Prefix 1516 Information Options indicating deprecation MUST be included in 1517 Router Advertisements for the remainder of the prefixes' 1518 respective valid lifetime but MAY be omitted after at least 2 1519 hours have passed. 1521 12. Security Considerations 1523 HNCP enables self-configuring networks, requiring as little user 1524 intervention as possible. However, this zero-configuration goal 1525 usually conflicts with security goals and introduces a number of 1526 threats. 1528 General security issues for existing home networks are discussed in 1529 [RFC7368]. The protocols used to set up addresses and routes in such 1530 networks to this day rarely have security enabled within the 1531 configuration protocol itself. However, these issues are out of 1532 scope for the security of HNCP itself. 1534 HNCP is a DNCP-based state synchronization mechanism carrying 1535 information with varying threat potential. For this consideration, 1536 the payloads defined in DNCP and this document are reviewed: 1538 o Network topology information such as HNCP nodes and their common 1539 links. 1541 o Address assignment information such as delegated and assigned 1542 prefixes for individual links. 1544 o Naming and service discovery information such as auto-generated or 1545 customized names for individual links and nodes. 1547 12.1. Interface Classification 1549 As described in Section 5.3, an HNCP node determines the internal or 1550 external state on a per-interface basis. A firewall perimeter is set 1551 up for the external interfaces, and for internal interfaces, HNCP 1552 traffic is allowed, with the exception of the Leaf and Guest 1553 subcategories. 1555 Threats concerning automatic interface classification cannot be 1556 mitigated by encrypting or authenticating HNCP traffic itself since 1557 external routers do not participate in the protocol and often cannot 1558 be authenticated by other means. These threats include propagation 1559 of forged uplinks in the homenet in order to, e.g., redirect traffic 1560 destined to external locations and forged internal status by external 1561 routers to, e.g., circumvent the perimeter firewall. 1563 It is therefore imperative to either secure individual links on the 1564 physical or link layer or preconfigure the adjacent interfaces of 1565 HNCP routers to an appropriate fixed category in order to secure the 1566 homenet border. Depending on the security of the external link, 1567 eavesdropping, man-in-the-middle, and similar attacks on external 1568 traffic can still happen between a homenet border router and the ISP; 1569 however, these cannot be mitigated from inside the homenet. For 1570 example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4 1571 messages, but this is very rarely implemented in large or small 1572 networks. Further, while PPP can provide secure authentication of 1573 both sides of a point-to-point link, it is most often deployed with 1574 one-way authentication of the subscriber to the ISP, not the ISP to 1575 the subscriber. 1577 12.2. Security of Unicast Traffic 1579 Once the homenet border has been established, there are several ways 1580 to secure HNCP against internal threats like manipulation or 1581 eavesdropping by compromised devices on a link that is enabled for 1582 HNCP traffic. If left unsecured, attackers may perform arbitrary 1583 traffic redirection, eavesdropping, spoofing, or denial-of-service 1584 attacks on HNCP services such as address assignment or service 1585 discovery, and the protocols are secured using HNCP-derived keys such 1586 as routing protocols. 1588 Detailed interface categories like "Leaf" or "Guest" can be used to 1589 integrate not fully trusted devices to various degrees into the 1590 homenet by not exposing them to HNCP traffic or by using firewall 1591 rules to prevent them from reaching homenet-internal resources. 1593 On links where this is not practical and lower layers do not provide 1594 adequate protection from attackers, DTLS-based secure unicast 1595 transport MUST be used to secure traffic. 1597 12.3. Other Protocols in the Home 1599 IGPs and other protocols are usually run alongside HNCP; therefore, 1600 the individual security aspects of the respective protocols must be 1601 considered. It can, however, be summarized that many protocols to be 1602 run in the home (like IGPs) provide -- to a certain extent -- similar 1603 security mechanisms. Most of these protocols do not support 1604 encryption and only support authentication based on Pre-Shared Keys 1605 natively. This influences the effectiveness of any encryption-based 1606 security mechanism deployed by HNCP as homenet routing information is 1607 thus usually not encrypted. 1609 13. IANA Considerations 1611 IANA has set up a registry for the (decimal values within range 1612 32-511) "HNCP TLV Types" under "Distributed Node Consensus Protocol 1613 (DNCP)". The registration procedures is 'RFC Required' [RFC5226]. 1614 The initial contents are: 1616 32: HNCP-Version 1618 33: External-Connection 1620 34: Delegated-Prefix 1622 35: Assigned-Prefix 1624 36: Node-Address 1626 37: DHCPv4-Data 1628 38: DHCPv6-Data 1630 39: DNS-Delegated-Zone 1632 40: Domain-Name 1634 41: Node-Name 1636 42: Managed-PSK 1638 43: Prefix-Policy 1640 44-511: Unassigned. 1642 768-1023: Reserved for Private Use. This range is used by HNCP for 1643 per-implementation experimentation. How collisions are avoided is 1644 outside the scope of this document. 1646 IANA has registered the UDP port numbers 8231 (service name: hncp- 1647 udp-port, description: HNCP) and 8232 (service name: hncp-dtls-port, 1648 description: HNCP over DTLS), as well as an IPv6 link-local multicast 1649 address FF02:0:0:0:0:0:0:11 (description: All-Homenet-Nodes). 1651 14. References 1652 14.1. Normative References 1654 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1655 April 1992. 1657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1658 Requirement Levels", BCP 14, RFC 2119, March 1997. 1660 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1661 2131, March 1997. 1663 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1664 Extensions", RFC 2132, March 1997. 1666 [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, 1667 A., Beser, B., and J. Privat, "The User Class Option for 1668 DHCP", RFC 3004, November 2000. 1670 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1671 and M. Carney, "Dynamic Host Configuration Protocol for 1672 IPv6 (DHCPv6)", RFC 3315, July 2003. 1674 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1675 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1676 December 2003. 1678 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1679 Addresses", RFC 4193, October 2005. 1681 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1682 Architecture", RFC 4291, February 2006. 1684 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1685 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1686 September 2007. 1688 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1689 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1690 DOI 10.17487/RFC5226, May 2008, 1691 . 1693 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1694 Capabilities in Customer Premises Equipment (CPE) for 1695 Providing Residential IPv6 Internet Service", RFC 6092, 1696 DOI 10.17487/RFC6092, January 2011, 1697 . 1699 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1700 "The Trickle Algorithm", RFC 6206, March 2011. 1702 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1703 Security Version 1.2", RFC 6347, January 2012. 1705 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1706 "Prefix Exclude Option for DHCPv6-based Prefix 1707 Delegation", RFC 6603, May 2012. 1709 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1710 Discovery", RFC 6763, February 2013. 1712 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1713 Interface Identifiers with IPv6 Stateless Address 1714 Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/ 1715 RFC7217, April 2014, 1716 . 1718 [RFC7695] Pfister, P., Paterson, B., and J. Arkko, "Distributed 1719 Prefix Assignment Algorithm", RFC 7695, DOI 10.17487/ 1720 RFC7695, November 2015, 1721 . 1723 [RFC7787] Stenberg, M. and S. Barth, "Distributed Node Consensus 1724 Protocol", RFC 7787, DOI 10.17487/RFC7787, February 2016, 1725 . 1727 14.2. Informative References 1729 [RFC1035] Mockapetris, P., "Domain names - implementation and 1730 specification", STD 13, RFC 1035, November 1987. 1732 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1733 E. Lear, "Address Allocation for Private Internets", BCP 1734 5, RFC 1918, February 1996. 1736 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1737 Messages", RFC 3118, June 2001. 1739 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1740 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 1742 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1743 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1744 6241, June 2011. 1746 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1747 February 2013. 1749 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1750 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1751 November 2013. 1753 [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1754 "IPv6 Home Networking Architecture Principles", RFC 7368, 1755 October 2014. 1757 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1758 "Recommendations for Secure Use of Transport Layer 1759 Security (TLS) and Datagram Transport Layer Security 1760 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1761 2015, . 1763 Appendix A. Acknowledgments 1765 Thanks to Ole Troan, Mark Baugher, Mark Townsley, Juliusz Chroboczek, 1766 and Thomas Clausen for their contributions to the document. 1768 Thanks to Eric Kline for the original border discovery work. 1770 Authors' Addresses 1772 Markus Stenberg 1773 Independent 1774 Helsinki 00930 1775 Finland 1777 Email: markus.stenberg@iki.fi 1779 Steven Barth 1780 Independent 1781 Halle 06114 1782 Germany 1784 Email: stbarth@cisco.com 1786 Pierre Pfister 1787 Cisco Systems 1788 Paris 1789 France 1791 Email: pierre.pfister@darou.fr