idnits 2.17.1 draft-ietf-homenet-hncp-09.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 : ---------------------------------------------------------------------------- -- 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? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 31, 2015) is 3158 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) -- Looks like a reference, but probably isn't: '3' on line 1777 -- Looks like a reference, but probably isn't: '4' on line 1777 == Outdated reference: A later version (-12) exists of draft-ietf-homenet-dncp-09 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 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 Intended status: Standards Track Independent 5 Expires: March 3, 2016 P. Pfister 6 Cisco Systems 7 August 31, 2015 9 Home Networking Control Protocol 10 draft-ietf-homenet-hncp-09 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 which supports routing based on both 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 March 3, 2016. 40 Copyright Notice 42 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . 11 69 6.2. External Connections . . . . . . . . . . . . . . . . . . 12 70 6.3. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 13 71 6.3.1. Prefix Assignment Algorithm Parameters . . . . . . . 13 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 . . . . . . . . . . . . . . . . . 16 76 6.5. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 17 77 7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 18 78 7.1. IPv6 Addressing and Configuration . . . . . . . . . . . . 19 79 7.2. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 19 80 7.3. DHCPv4 for Addressing and Configuration . . . . . . . . . 20 81 7.4. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 20 82 8. Naming and Service Discovery . . . . . . . . . . . . . . . . 20 83 9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 21 84 10. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 22 85 10.1. HNCP Version TLV . . . . . . . . . . . . . . . . . . . . 22 86 10.2. External Connection TLV . . . . . . . . . . . . . . . . 23 87 10.2.1. Delegated Prefix TLV . . . . . . . . . . . . . . . . 24 88 10.2.2. DHCPv6 Data TLV . . . . . . . . . . . . . . . . . . 25 89 10.2.3. DHCPv4 Data TLV . . . . . . . . . . . . . . . . . . 26 90 10.3. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . 26 91 10.4. Node Address TLV . . . . . . . . . . . . . . . . . . . . 27 92 10.5. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 28 93 10.6. Domain Name TLV . . . . . . . . . . . . . . . . . . . . 29 94 10.7. Node Name TLV . . . . . . . . . . . . . . . . . . . . . 29 95 10.8. Managed PSK TLV . . . . . . . . . . . . . . . . . . . . 30 96 11. General Requirements for HNCP Nodes . . . . . . . . . . . . . 31 97 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 98 12.1. Interface Classification . . . . . . . . . . . . . . . . 33 99 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 33 100 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 34 101 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 102 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 103 14.1. Normative references . . . . . . . . . . . . . . . . . . 35 104 14.2. Informative references . . . . . . . . . . . . . . . . . 36 105 Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 37 106 Appendix B. Draft source [RFC Editor: please remove] . . . . . . 38 107 Appendix C. Implementation [RFC Editor: please remove] . . . . . 38 108 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 38 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 111 1. Introduction 113 HNCP is designed to facilitate sharing of state among home routers to 114 fulfill the needs of the IPv6 homenet architecture [RFC7368], which 115 assumes zero-configuration operation, multiple subnets, multiple home 116 routers and (potentially) multiple upstream service providers 117 providing (potentially) multiple prefixes to the home network. While 118 RFC7368 sets no requirements for IPv4 support, HNCP aims to support 119 dual-stack mode of operation, and therefore the functionality is 120 designed with that in mind. The state is shared as TLVs among the 121 routers (and potentially advanced hosts) to enable: 123 o Autonomic discovery of network borders (Section 5.3) based on DNCP 124 topology. 126 o Automated portioning of prefixes delegated by the service 127 providers as well as assigned prefixes to both HNCP and non-HNCP 128 routers (Section 6.3) using [I-D.ietf-homenet-prefix-assignment]. 129 Prefixes assigned to HNCP routers are used to: 131 * Provide addresses to non-HNCP aware nodes (using SLAAC and 132 DHCP). 134 * Provide space in which HNCP nodes assign their own addresses 135 (Section 6.4). 137 o Internal and external name resolution, as well as multi-link 138 service discovery (Section 8). 140 o Other services not defined in this document, that do need to share 141 state among homenet nodes, and do not cause rapid and constant TLV 142 changes (see following applicability section). 144 HNCP is a DNCP [I-D.ietf-homenet-dncp]-based protocol and includes a 145 DNCP profile which defines transport and synchronization details for 146 sharing state across nodes defined in Section 3. The rest of the 147 document defines behavior of the services noted above, how the 148 required TLVs are encoded (Section 10), as well as additional 149 requirements on how HNCP nodes should behave (Section 11). 151 1.1. Applicability 153 While HNCP does not deal with routing protocols directly (except 154 potentially informing them about internal and external interfaces if 155 classification specified in Section 5.3 is used), in homenet 156 environments where multiple IPv6 source-prefixes can be present, 157 routing based on source and destination address is necessary 158 [RFC7368]. Ideally, the routing protocol is also zero-configuration 159 (e.g., no need to configure identifiers or metrics) although HNCP can 160 be used also with a manually configured routing protocol. 162 As HNCP uses DNCP as the actual state synchronization protocol, the 163 applicability statement of DNCP can be used here as well; HNCP should 164 not be used for any data that changes rapidly and constantly, and 165 locators to find such services should be published using it instead. 166 This is why the naming and service discovery (Section 8) TLVs contain 167 only DNS server addresses, and no actual per-name or per-service data 168 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 re-publishing 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 the home network size, 179 and 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 not 185 aware of the HNCP-managed network and thus might need to be 186 reconfigured to not result in unexpected behavior. 188 While HNCP is designed to be used by (home) routers, it can also be 189 used by advanced hosts that want to do, e.g., their own address 190 assignment and routing. 192 HNCP is link layer agnostic; if a link supports IPv6 (link-local) 193 multicast and unicast, HNCP will work on it. Trickle retransmissions 194 and keep-alives will handle both packet loss and non-transitive 195 connectivity, ensuring eventual convergence. 197 2. Terminology 199 The following terms are used as they are defined in 200 [I-D.ietf-homenet-prefix-assignment]: 202 o Advertised Prefix Priority 204 o Advertised Prefix 206 o Assigned Prefix 208 o Delegated Prefix 210 o Prefix Adoption 212 o Private Link 214 o Published Assigned Prefix 216 o Applied Assigned Prefix 218 o Shared Link 220 The following terms are used as they are defined in 221 [I-D.ietf-homenet-dncp]: 223 o DNCP profile 225 o Node identifier 227 o Link 229 o Interface 230 (HNCP) node A device implementing this specification. 231 (HNCP) router A device implementing this specification, which 232 forwards traffic on behalf of other devices. 233 Border separation point between administrative domains; in 234 this case, between the home network and any other 235 network, i.e., usually an ISP network. 237 Internal link a link that does not cross borders. 238 Internal an interface that is connected to an internal link. 239 interface 241 External an interface that is connected to a link which is 242 interface not an internal link. 244 Interface a local configuration denoting the use of a 245 category particular interface. The interface category 246 determines how a HNCP node should treat the 247 particular interface. External and internal 248 category mark the interface as out of or within the 249 network border; there are also a number of sub- 250 categories to internal that further affect local 251 node behavior. See Section 5.1 for a list of 252 interface categories and how they behave. The 253 internal or external categories may also be auto- 254 detected (Section 5.3). 256 Border router a router announcing external connectivity and 257 forwarding traffic across the network border. 259 Common Link a set of nodes on a link which share a common view 260 of it, i.e., they see each other's traffic and the 261 same set of hosts. Unless configured otherwise 262 transitive connectivity is assumed. 264 DHCPv4 refers to Dynamic Host Configuration Protocol 265 [RFC2131] in this document. 266 DHCPv6 refers to Dynamic Host Configuration Protocol for 267 IPv6 (DHCPv6) [RFC3315] in this document. 268 DHCP refers to cases which apply to both DHCPv4 and 269 DHCPv6 in this document. 271 2.1. Requirements language 273 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 274 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 275 "OPTIONAL" in this document are to be interpreted as described in RFC 276 2119 [RFC2119]. 278 3. DNCP Profile 280 The DNCP profile of HNCP is defined as follows: 282 o HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport over 283 link-local scoped IPv6, using unicast and multicast (All-Homenet- 284 Nodes is the HNCP group address). Received datagrams where either 285 or both of the IPv6 source or destination address is not link- 286 local scoped MUST be ignored. Replies to multicast and unicast 287 messages MUST be sent to the IPv6 source address and port of the 288 original message. Each node MUST be able to receive (and 289 potentially reassemble) UDP datagrams with a payload of at least 290 4000 bytes. 292 o HNCP operates on multicast-capable interfaces only. HNCP nodes 293 MUST assign a locally unique non-zero 32-bit endpoint identifier 294 to each interface for which HNCP is enabled. The value zero it is 295 not used in DNCP TLVs, but it has a special meaning in HNCP TLVs 296 (see Section 10.3 and Section 6.4). Implementations MAY use a 297 value equivalent to the IPv6 link-local scope identifier for the 298 given interface. 300 o HNCP uses opaque 32-bit node identifiers 301 (DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP 302 SHOULD use a random node identifier. If there is a node 303 identifier collision (as specified in the Node State TLV handling 304 of Section 4.4 of [I-D.ietf-homenet-dncp]), the node MUST 305 immediately generate and use a new random node identifier which is 306 not used by any other node at the time, based on the current DNCP 307 network state. 309 o HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP 310 non-cryptographic hash function H(x). 312 o HNCP nodes MUST use DNCP's per-endpoint keep-alive extension on 313 all endpoints. The following parameters are suggested: 315 * Default keep-alive interval (DNCP_KEEPALIVE_INTERVAL): 20 316 seconds. 318 * Multiplier (DNCP_KEEPALIVE_MULTIPLIER): 2.1 on virtually 319 lossless links works fine as it allows for one lost keep-alive. 320 If used on a lossy link, considerably higher multiplier, such 321 as 15, should be used instead. In that case, an implementation 322 might prefer shorter keep-alive intervals on that link as well 323 to ensure that DNCP_KEEPALIVE_INTERVAL * 324 DNCP_KEEPALIVE_MULTIPLIER timeout after which (entirely) lost 325 nodes time out is low enough. 327 o HNCP nodes use the following Trickle parameters for the per- 328 interface Trickle instances: 330 * k SHOULD be 1, as the timer reset when data is updated and 331 further retransmissions should handle packet loss. Even on a 332 non-transitive lossy link, the eventual per-endpoint keep- 333 alives should ensure status synchronization occurs. 335 * Imin SHOULD be 200 milliseconds but MUST NOT be lower. Note: 336 Earliest transmissions may occur at Imin / 2. 338 * Imax SHOULD be 7 doublings of Imin (i.e., 25.6 seconds) but 339 MUST NOT be lower. 341 o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as 342 described in DNCP if exchanged over unsecured links. UDP on port 343 HNCP-DTLS-PORT is used for this purpose. A node implementing HNCP 344 security MUST support the DNCP Pre-Shared Key method, SHOULD 345 support the DNCP Certificate Based Trust Consensus and MAY support 346 the PKI-based trust method. 348 o HNCP nodes MUST ignore all Node State TLVs received via multicast 349 on a link which has DNCP security enabled in order to prevent 350 spoofing of node state changes. 352 4. HNCP Versioning and Router Capabilities 354 Multiple versions of HNCP based on compatible DNCP profiles may be 355 present in the same network when transitioning between HNCP versions 356 and for troubleshooting purposes it might be beneficial to identify 357 the HNCP agent version running. Therefore each node MUST include an 358 HNCP-Version TLV (Section 10.1) in its Node Data and MUST ignore 359 (except for DNCP synchronization purposes) any TLVs with a type 360 greater than 32 published by nodes not also publishing an HNCP- 361 Version TLV. 363 HNCP routers may also have different capabilities regarding 364 interactions with hosts, e.g., for configuration or service 365 discovery. These are indicated by M, P, H and L values. The 366 combined "capability value" is a metric indicated by interpreting the 367 bits as an integer, i.e., (M << 12 | P << 8 | H << 4 | L). These 368 values are used to elect certain servers on a Common Link, as 369 described in Section 7. Nodes that are not routers MUST announce the 370 value 0 for all capabilities. Any node announcing the value 0 is 371 considered to not advertise the respective capability and thus does 372 not take part in the respective election. 374 5. Interface Classification 376 5.1. Interface Categories 378 HNCP specifies the following categories interfaces can be configured 379 to be in: 381 Internal category: This declares an interfaces to be internal, i.e., 382 within the borders of the HNCP network. HNCP traffic MUST be sent 383 and received. Routers MUST forward traffic with appropriate 384 source addresses between their internal interfaces and allow 385 internal traffic to reach external networks. All nodes MUST 386 implement this category and nodes not implementing any other 387 category implicitly use it as a fixed default. 389 External category: This declares an interface to be external, i.e., 390 not within the borders of the HNCP network. HNCP traffic MUST 391 neither be sent nor received. Accessing internal resources from 392 external interfaces is restricted, i.e., the use of [RFC6092] is 393 RECOMMENDED. HNCP routers SHOULD announce acquired configuration 394 information for use in the network as described in Section 6.2, if 395 the interface appears to be connected to an external network. 396 HNCP routers MUST implement this category. 398 Leaf category: This declares an interface used by client devices 399 only. Such an interface uses the Internal category with the 400 exception that HNCP traffic MUST NOT be sent on the interface, and 401 all such traffic received on the interface MUST be ignored. This 402 category SHOULD be supported by HNCP routers. 404 Guest category: This declares an interface used by untrusted client 405 devices only. In addition to the restrictions of the Leaf 406 category, HNCP routers MUST filter traffic from and to the 407 interface such that connected devices are unable to reach other 408 devices inside the HNCP network or query services advertised by 409 them unless explicitly allowed. This category SHOULD be supported 410 by HNCP routers. 412 Ad-hoc category: This configures an interface to use the Internal 413 category but no assumption is made about the the link's 414 transitivity. All other interface categories assume transitive 415 connectivity. This affects the Common Link (Section 6.1) 416 definition. Support for this category is OPTIONAL. 418 Hybrid category: This declares an interface to use the Internal 419 category while still trying to acquire (external) configuration 420 information on it, e.g., by running DHCP clients. This is useful, 421 e.g., if the link is shared with a non-HNCP router under control 422 and still within the borders of the same network. Detection of 423 this category automatically in addition to manual configuration is 424 out of scope of this document. Support for this category is 425 OPTIONAL. 427 5.2. DHCP Aided Auto-Detection 429 Auto-detection of interface categories is possible based on 430 interaction with DHCPv4 [RFC2131] and DHCPv6-PD [RFC3633] servers on 431 connected links. HNCP defines special DHCP behavior to differentiate 432 its internal servers from external ones in order to achieve this. 433 Therefore all internal devices (including HNCP nodes) running DHCP 434 servers on links where auto-detection is used by any HNCP node MUST 435 use the following mechanism based on The User Class Option for DHCPv4 436 [RFC3004] and its DHCPv6 counterpart [RFC3315]: 438 o The device MUST ignore or reject DHCP-Requests containing a DHCP 439 User-Class consisting of the ASCII-String "HOMENET". 441 Not following this rule (e.g., running unmodified DHCP servers) might 442 lead to false positives when auto-detection is used, i.e., HNCP nodes 443 assume an interface to not be internal, even though it was intended 444 to be. 446 5.3. Algorithm for Border Discovery 448 This section defines the interface classification algorithm. It is 449 suitable for both IPv4 and IPv6 (single or dual-stack) and detects 450 the category of an interface either automatically or based on a fixed 451 configuration. By determining the category for all interfaces, the 452 network borders are implicitly defined, i.e., all interfaces not 453 belonging to the External category are considered to be within the 454 borders of the network, all others are not. 456 The following algorithm MUST be implemented by any node implementing 457 HNCP. However, if the node does not implement auto-detection, only 458 the first step is required. The algorithm works as follows, with 459 evaluation stopping at first match: 461 1. If a fixed category is configured for an interface, it is used. 463 2. If a delegated prefix could be acquired by running a DHCPv6 464 client, it is considered external. The DHCPv6 client MUST have 465 included a DHCPv6 User-Class consisting of the ASCII-String 466 "HOMENET" in all of its requests. 468 3. If an IPv4 address could be acquired by running a DHCPv4 client 469 on the interface, it is considered external. The DHCPv4 client 470 MUST have included a DHCP User-Class consisting of the ASCII- 471 String "HOMENET" in all of its requests. 473 4. The interface is considered internal. 475 Note that as other HNCP nodes will ignore the client due to the user 476 class option, any server that replies is clearly external (or a 477 malicious internal node). 479 An HNCP router SHOULD allow setting the fixed category for each 480 interface which may be connected to either an internal or external 481 device (e.g., an Ethernet port that can be connected to a modem, 482 another HNCP router or a client). 484 An HNCP router using auto-detection on an interface MUST run the 485 appropriately configured DHCP clients as long as the interface 486 without a fixed category is active (including states where auto- 487 detection considers it to be internal) and rerun the algorithm above 488 to react to conditions resulting in a different interface category. 489 The router SHOULD wait for a reasonable time period (5 seconds as a 490 default), during which the DHCP clients can acquire a lease, before 491 treating a newly activated or previously external interface as 492 internal. 494 6. Autonomous Address Configuration 496 This section specifies how HNCP nodes configure host and node 497 addresses. At first border routers share information obtained from 498 service providers or local configuration by publishing one or more 499 External Connection TLVs (Section 10.2). These contain other TLVs 500 such as Delegated Prefix TLVs (Section 10.2.1) which are then used 501 for prefix assignment. Finally, HNCP nodes obtain addresses either 502 statelessly or using a specific stateful mechanism (Section 6.4). 503 Hosts and non-HNCP routers are configured using SLAAC, DHCP or 504 DHCPv6-PD. 506 6.1. Common Link 508 HNCP uses the concept of Common Link both in autonomic address 509 configuration and naming and service discovery (Section 8). A Common 510 Link refers to the set of interfaces of nodes that see each other's 511 traffic and presumably also the traffic of all hosts that may use the 512 nodes to, e.g., forward traffic. Common Links are used, e.g., to 513 determine where prefixes should be assigned or which peers 514 participate in the election of a DHCP server. The Common Link is 515 computed separately for each local internal interface, and it always 516 contains the local interface. Additionally, if the local interface 517 is not set to ad-hoc category (see Section 5.1), it also contains the 518 set of interfaces that are bidirectionally reachable from the given 519 local interface, that is, every remote interface of a remote node 520 meeting all of the following requirements: 522 o The local node publishes a Peer TLV with: 524 * Peer Node Identifier = remote node's node identifier 526 * Peer Endpoint Identifier = remote interface's endpoint 527 identifier 529 * Endpoint Identifier = local interface's endpoint identifier 531 o The remote node publishes a Peer TLV with: 533 * Peer Node Identifier = local node's node identifier 535 * Peer Endpoint Identifier = local interface's endpoint 536 identifier 538 * Endpoint Identifier = remote interface's endpoint identifier 540 A node MUST be able to detect whether two of its local internal 541 interfaces are connected, e.g., by detecting an identical remote 542 interface being part of the Common Links of both local interfaces. 544 6.2. External Connections 546 Each HNCP router MAY obtain external connection information such as 547 address prefixes, DNS server addresses and DNS search paths from one 548 or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or 549 static configuration. Each individual external connection to be 550 shared in the network is represented by one External Connection TLV 551 (Section 10.2). 553 Announcements of individual external connections may consist of the 554 following components: 556 Delegated Prefixes: address space available for assignment to 557 internal links announced using Delegated Prefix TLVs 558 (Section 10.2.1). Some address spaces might have special 559 properties which are necessary to understand in order to handle 560 them (e.g., information similar to [RFC6603]). This information 561 is encoded using DHCPv6 Data TLVs (Section 10.2.2) inside the 562 respective Delegated Prefix TLVs. 564 Auxiliary Information: information about services such as DNS or 565 time synchronization regularly used by hosts in addition to 566 addressing and routing information. This information is encoded 567 using DHCPv6 Data TLVs (Section 10.2.2) and DHCPv4 Data TLVs 568 (Section 10.2.3). 570 Whenever information about reserved parts (e.g., as specified in 571 [RFC6603]) is received for a delegated prefix, the reserved parts 572 MUST be advertised using Assigned Prefix TLVs (Section 10.3) with the 573 highest priority (i.e., 15), as if they were assigned to a Private 574 Link. 576 Some connections or delegated prefixes may have a special meaning and 577 are not regularly used for internal or internet connectivity, instead 578 they may provide access to special services like VPNs, sensor 579 networks, VoIP, IPTV, etc. Care must be taken that these prefixes 580 are properly integrated and dealt with in the network, in order to 581 avoid breaking connectivity for devices who are not aware of their 582 special characteristics or to only selectively allow certain devices 583 to use them. Such prefixes are distinguished using Prefix Policy 584 TLVs (Section 10.2.1.1). Their contents MAY be partly opaque to HNCP 585 nodes, and their identification and usage depends on local policy. 586 However the following general rules MUST be adhered to: 588 Special rules apply when making address assignments for prefixes 589 with Prefix Policy TLVs with type 131, as described in 590 Section 6.3.2 592 In presence of any type 1 to 128 Prefix Policy TLV the prefix is 593 specialized to reach destinations denoted by any such Prefix 594 Policy TLV, i.e., in absence of a type 0 Prefix Policy TLV it is 595 not usable for general internet connectivity. An HNCP router MAY 596 enforce this restriction with appropriate packet filter rules. 598 6.3. Prefix Assignment 600 HNCP uses the Prefix Assignment Algorithm 601 [I-D.ietf-homenet-prefix-assignment] in order to assign prefixes to 602 HNCP internal links and uses some of the terminology (Section 2) 603 defined there. HNCP furthermore defines the Assigned Prefix TLV 604 (Section 10.3) which MUST be used to announce Published Assigned 605 Prefixes. 607 6.3.1. Prefix Assignment Algorithm Parameters 609 All HNCP nodes running the prefix assignment algorithm use the 610 following values for its parameters: 612 Node IDs: HNCP node identifiers are used. The comparison operation 613 is defined as bit-wise comparison. 615 Set of Delegated Prefixes: The set of prefixes encoded in Delegated 616 Prefix TLVs which are not strictly included in prefixes encoded in 617 other Delegated Prefix TLVs. Note that Delegated Prefix TLVs 618 included in ignored External Connection TLVs are not considered. 619 It is dynamically updated as Delegated Prefix TLVs are added or 620 removed. 622 Set of Shared Links: The set of Common Links associated with 623 interfaces with internal, leaf, guest or ad-hoc category. It is 624 dynamically updated as interfaces are added, removed, or switch 625 from one category to another. When multiple interfaces are 626 detected as belonging to the same Common Link, prefix assignment 627 is disabled on all of these interfaces except one. 629 Set of Private Links: This document defines Private Links 630 representing DHCPv6-PD clients or as a mean to advertise prefixes 631 included in the DHCPv6 Exclude Prefix option. Other 632 implementation-specific Private Links may be defined whenever a 633 prefix needs to be assigned for a purpose that does not require a 634 consensus with other HNCP nodes. 636 Set of Advertised Prefixes: The set of prefixes included in 637 Assigned Prefix TLVs advertised by other HNCP nodes (Prefixes 638 advertised by the local node are not in this set). The associated 639 Advertised Prefix Priority is the priority specified in the TLV. 640 The associated Shared Link is determined as follows: 642 * If the Link Identifier is zero, the Advertised Prefix is not 643 assigned on a Shared Link. 645 * If the other node's interface identified by the Link Identifier 646 is included in one of the Common Links used for prefix 647 assignment, it is considered as assigned on the given Common 648 Link. 650 * Otherwise, the Advertised Prefix is not assigned on a Shared 651 Link. 653 Advertised Prefixes as well as their associated priorities and 654 associated Shared Links MUST be updated as Assigned Prefix TLVs 655 are added, updated or removed, and as Common Links are modified. 657 ADOPT_MAX_DELAY: The default value is 0 seconds (i.e., prefix 658 adoption MAY be done instantly). 660 BACKOFF_MAX_DELAY: The default value is 4 seconds. 662 RANDOM_SET_SIZE: The default value is 64. 664 Flooding Delay: The default value is 5 seconds. 666 Default Advertised Prefix Priority: When a new assignment is 667 created or an assignment is adopted - as specified in the prefix 668 assignment algorithm routine - the default Advertised Prefix 669 Priority to be used is 2. 671 6.3.2. Making New Assignments 673 Whenever the prefix assignment algorithm subroutine (Section 4.1 of 674 [I-D.ietf-homenet-prefix-assignment]) is run on a Common Link and 675 whenever a new prefix may be assigned (case 1 of the subroutine: no 676 Best Assignment and no Current Assignment), the decision of whether 677 the assignment of a new prefix is desired MUST follow these rules in 678 order: 680 If the Delegated Prefix TLV contains a DHCPv6 Data TLV, and the 681 meaning of one of the DHCP options is not understood by the HNCP 682 node, the creation of a new prefix is not desired. This rule 683 applies to TLVs inside Delegated Prefix TLVs but not to those 684 inside External Connection TLVs. 686 If the remaining preferred lifetime of the prefix is 0 and there 687 is another delegated prefix of the same IP version used for prefix 688 assignment with a non-zero preferred lifetime, the creation of a 689 new prefix is not desired. 691 If the Delegated Prefix does not include a Prefix Policy TLV 692 indicating restrictive assignment (type 131) or if local policy 693 exists to identify it based on, e.g., other Prefix Policy TLV 694 values and allows assignment, the creation of a new prefix is 695 desired. 697 Otherwise, the creation of a new prefix is not desired. 699 If the considered delegated prefix is an IPv6 prefix, and whenever 700 there is at least one available prefix of length 64, a prefix of 701 length 64 MUST be selected unless configured otherwise. In case no 702 prefix of length 64 would be available, a longer prefix MAY be 703 selected even without configuration. 705 If the considered delegated prefix is an IPv4 prefix (Section 6.5 706 details how IPv4 delegated prefixes are generated), a prefix of 707 length 24 SHOULD be preferred. 709 In any case, an HNCP router making an assignment MUST support a 710 mechanism suitable to distribute addresses from the considered prefix 711 if the link is intended to be used by clients. In this case a router 712 assigning an IPv4 prefix MUST announce the L-capability and a router 713 assigning an IPv6 prefix with a length greater than 64 MUST announce 714 the H-capability as defined in Section 4. 716 6.3.3. Applying Assignments 718 The prefix assignment algorithm indicates when a prefix is applied to 719 the respective Common Link. When that happens each router connected 720 to said link: 722 MUST forward traffic destined to said prefix to the respective 723 link. 725 MUST participate in the client configuration election as described 726 in Section 7, if the link is intended to be used by clients. 728 MAY add an address from said prefix to the respective network 729 interface as described in Section 6.4, e.g., if it is to be used 730 as source for locally originating traffic. 732 6.3.4. DHCPv6 Prefix Delegation 734 When an HNCP router announcing the P-Capability (Section 4) receives 735 a DHCPv6-PD request from a client, it SHOULD assign one prefix per 736 delegated prefix in the network. This set of assigned prefixes is 737 then delegated to the client, after it has been applied as described 738 in the prefix assignment algorithm. Each DHCPv6-PD client MUST be 739 considered as an independent Private Link and delegation MUST be 740 based on the same set of Delegated Prefixes as the one used for 741 Common Link prefix assignments, however the prefix length to be 742 delegated MAY be smaller than 64. 744 The assigned prefixes MUST NOT be given to DHCPv6-PD clients before 745 they are applied, and MUST be withdrawn whenever they are destroyed. 746 As an exception to this rule, in order to shorten delays of processed 747 requests, a router MAY prematurely give out a prefix which is 748 advertised but not yet applied if it does so with a valid lifetime of 749 not more than 30 seconds and ensures removal or correction of 750 lifetimes as soon as possible. 752 6.4. Node Address Assignment 754 This section specifies how HNCP nodes reserve addresses for their own 755 use. Nodes MAY, at any time, try to reserve a new address from any 756 Applied Assigned Prefix. Each HNCP node SHOULD announce an IPv6 757 address and - if it supports IPv4 - MUST announce an IPv4 address, 758 whenever matching prefixes are assigned to at least one of its Common 759 Links. These addresses are published using Node Address TLVs and 760 used to locally reach HNCP nodes for other services. Nodes SHOULD 761 NOT create and announce more than one assignment per IP version to 762 avoid cluttering the node data with redundant information unless a 763 special use case requires it. 765 Stateless assignment based on Semantically Opaque Interface 766 Identifiers [RFC7217] SHOULD be used for address assignment whenever 767 possible (e.g., the prefix length is 64), otherwise (e.g., for IPv4 768 if supported) the following method MUST be used instead: For any 769 assigned prefix for which stateless assignment is not used, the first 770 quarter of the addresses are reserved for HNCP based address 771 assignments, whereas the last three quarters are left to the DHCP 772 elected router (Section 4 specifies the DHCP server election 773 process). For example, if the prefix 192.0.2.0/24 is assigned and 774 applied to a Common Link, addresses included in 192.0.2.0/26 are 775 reserved for HNCP nodes and the remaining addresses are reserved for 776 the elected DHCPv4 server. 778 HNCP nodes assign themselves addresses, and then (to ensure eventual 779 lack of conflicting assignments) publish the assignments using the 780 Node Address TLV (Section 10.4). 782 The process of obtaining addresses is specified as follows: 784 o A node MUST NOT start advertising an address if it is already 785 advertised by another node. 787 o An assigned address MUST be part of an assigned prefix currently 788 applied on a Common Link which includes the interface specified by 789 the endpoint identifier. 791 o An address MUST NOT be used unless it has been advertised for at 792 least ADDRESS_APPLY_DELAY consecutive seconds, and is still 793 currently being advertised. The default value for 794 ADDRESS_APPLY_DELAY is 3 seconds. 796 o Whenever the same address is advertised by more than one node, all 797 but the one advertised by the node with the highest node 798 identifier MUST be removed. 800 6.5. Local IPv4 and ULA Prefixes 802 HNCP routers can create a ULA or private IPv4 prefix to enable 803 connectivity between local devices. These prefixes are inserted in 804 HNCP as if they were delegated prefixes of a (virtual) external 805 connection (Section 6.2). The following rules apply: 807 An HNCP router SHOULD create a ULA prefix if there is no other 808 IPv6 prefix with a preferred time greater than 0 in the network. 809 It MAY also do so, if there are other delegated IPv6 prefixes, but 810 none of which is locally generated (i.e., without any Prefix 811 Policy TLV) and has a preferred time greater than 0. However, it 812 MUST NOT do so otherwise. In case multiple locally generated ULA 813 prefixes are present, only the one published by the node with the 814 highest node identifier is kept among those with a preferred time 815 greater than 0 - if there is any. 817 An HNCP router MUST create a private IPv4 prefix [RFC1918] 818 whenever it wishes to provide IPv4 internet connectivity to the 819 network and no other private IPv4 prefix with internet 820 connectivity currently exists. It MAY also enable local IPv4 821 connectivity by creating a private IPv4 prefix if no IPv4 prefix 822 exists but MUST NOT do so otherwise. In case multiple IPv4 823 prefixes are announced, only the one published by the node with 824 the highest node identifier is kept among those with a Prefix 825 Policy of type 0 - if there is any. The router publishing a 826 prefix with internet connectivity MUST forward IPv4 traffic to the 827 internet and perform NAT on behalf of the network as long as it 828 publishes the prefix, other routers in the network MAY choose not 829 to. 831 Creation of such ULA and IPv4 prefixes MUST be delayed by a random 832 timespan between 0 and 10 seconds in which the router MUST scan for 833 others trying to do the same. 835 When a new ULA prefix is created, the prefix is selected based on the 836 configuration, using the last non-deprecated ULA prefix, or generated 837 based on [RFC4193]. 839 7. Configuration of Hosts and non-HNCP Routers 841 HNCP routers need to ensure that hosts and non-HNCP downstream 842 routers on internal links are configured with addresses and routes. 843 Since DHCP clients can usually only bind to one server at a time, a 844 per-link and per-service election takes place. 846 HNCP routers may have different capabilities for configuring 847 downstream devices and providing naming services. Each router MUST 848 therefore indicate its capabilities as specified in Section 4 in 849 order to participate as a candidate in the election. 851 7.1. IPv6 Addressing and Configuration 853 In general Stateless Address Autoconfiguration [RFC4861] is used for 854 client configuration for its low overhead and fast renumbering 855 capabilities. Therefore each HNCP router sends Router Advertisements 856 on interfaces which are intended to be used by clients and MUST at 857 least include a Prefix Information Option for each Applied Assigned 858 Prefix which it assigned to the respective link in every such 859 advertisement. However, stateful DHCPv6 can be used in addition by 860 administrative choice, to, e.g., collect hostnames and use them to 861 provide naming services or whenever stateless configuration is not 862 applicable. 864 The designated stateful DHCPv6 server for a Common Link (Section 6.1) 865 is elected based on the capabilities described in Section 4. The 866 winner is the router (connected to the Common Link) advertising the 867 greatest H-capability. In case of a tie, Capability Values 868 (Section 4) are compared, and the router with the greatest value is 869 elected. In case of another tie, the router with the highest node 870 identifier is elected among the routers with tied Capability Values. 872 The elected router MUST serve stateful DHCPv6 and SHOULD provide 873 naming services for acquired hostnames as outlined in Section 8, all 874 others nodes MUST NOT. Stateful addresses SHOULD be assigned in a 875 way not hindering fast renumbering even if the DHCPv6 server or 876 client do not support the DHCPv6 reconfigure mechanism, e.g., by only 877 handing out leases from locally-generated (ULA) prefixes and prefixes 878 with a length different from 64, and by using low renew and rebind 879 times (i.e., not longer than 5 minutes). In case no router was 880 elected, stateful DHCPv6 is not provided. Routers which cease to be 881 elected DHCP servers SHOULD - when applicable - invalidate remaining 882 existing bindings in order to trigger client reconfiguration. 884 7.2. DHCPv6 for Prefix Delegation 886 The designated DHCPv6 server for prefix-delegation on a Common Link 887 is elected based on the capabilities described in Section 4. The 888 winner is the router (connected to the Common Link) advertising the 889 greatest P-capability. In case of a tie, Capability Values 890 (Section 4) are compared, and the router with the greatest value is 891 elected. In case of another tie, the router with the highest node 892 identifier is elected among the routers with tied Capability Values. 894 The elected router MUST provide prefix-delegation services [RFC3633] 895 on the given link (and follow the rules in Section 6.3.4), all other 896 nodes MUST NOT. 898 7.3. DHCPv4 for Addressing and Configuration 900 The designated DHCPv4 server on a Common Link (Section 6.1) is 901 elected based on the capabilities described in Section 4. The winner 902 is the router (connected to the Common Link) advertising the greatest 903 L-capability. In case of a tie, Capability Values (Section 4) are 904 compared, and the router with the greatest value is elected. In case 905 of another tie, the router with the highest node identifier is 906 elected among the routers with tied Capability Values. 908 The elected router MUST provide DHCPv4 services on the given link, 909 all other nodes MUST NOT. The elected router MUST provide IP 910 addresses from the pool defined in Section 6.4 and MUST announce 911 itself as router [RFC2132] to clients. 913 DHCPv4 lifetimes renew and rebind times (T1 and T2) SHOULD be short 914 (i.e., not longer than 5 minutes) in order to provide reasonable 915 response times to changes. Routers which cease to be elected DHCP 916 servers SHOULD - when applicable - invalidate remaining existing 917 bindings in order to trigger client reconfiguration. 919 7.4. Multicast DNS Proxy 921 The designated MDNS [RFC6762] proxy on a Common Link is elected based 922 on the capabilities described in Section 4. The winner is the router 923 (connected to the Common Link) advertising the greatest M-capability. 924 In case of a tie, Capability Values (Section 4) are compared, and the 925 router with the greatest value is elected. In case of another tie, 926 the router with the highest node identifier is elected among the 927 routers with tied Capability Values. 929 The elected router MUST provide an MDNS-proxy on the given link and 930 announce it as described in Section 8. 932 8. Naming and Service Discovery 934 Network-wide naming and service discovery can greatly improve the 935 user-friendliness of a network. The following mechanism provides 936 means to setup and delegate naming and service discovery across 937 multiple HNCP routers. 939 Each HNCP router SHOULD provide and advertise a recursive name 940 resolving server to clients which honors the announcements made in 941 Delegated Zone TLVs (Section 10.5), Domain Name TLVs (Section 10.6) 942 and Node Name TLVs (Section 10.7), i.e., delegate queries to the 943 designated name servers and hand out appropriate A, AAAA and PTR 944 records according to the mentioned TLVs. 946 Each HNCP router SHOULD provide and announce an auto-generated or 947 user-configured name for each internal Common Link (Section 6.1) for 948 which it is the designated DHCPv4, stateful DHCPv6 server, MDNS 949 proxy, or for which it provides forward or reverse DNS services on 950 behalf of connected devices. This announcement is done using 951 Delegated Zone TLVs (Section 10.5) and MUST be unique in the whole 952 network. In case of a conflict the announcement of the node with the 953 highest node identifier takes precedence and all other nodes MUST 954 cease to announce the conflicting TLV. HNCP routers providing 955 recursive name resolving services MUST use the included DNS server 956 address within the TLV to resolve names belonging to the zone as if 957 there was an NS record. 959 Each HNCP node SHOULD announce a node name for itself to be easily 960 reachable and MAY do so on behalf of other devices. Announcements 961 are made using Node Name TLVs (Section 10.7) and MUST be unique in 962 the whole network. In case of a conflict the announcement of the 963 node with the highest node identifier takes precedence and all other 964 nodes MUST cease to announce the conflicting TLV. HNCP routers 965 providing recursive name resolving services as described above MUST 966 resolve such announced names to their respective IP addresses as if 967 there were corresponding A/AAAA records. 969 Names and unqualified zones are used in an HNCP network to provide 970 naming and service discovery with local significance. A network-wide 971 zone is appended to all single labels or unqualified zones in order 972 to qualify them. ".home" is the default, however an administrator MAY 973 configure announcing of a Domain Name TLV (Section 10.6) for the 974 network to use a different one. In case multiple are announced, the 975 domain of the node with the greatest node identifier takes 976 precedence. 978 9. Securing Third-Party Protocols 980 Pre-shared keys (PSKs) are often required to secure (for example) 981 IGPs and other protocols which lack support for asymmetric security. 982 The following mechanism manages PSKs using HNCP to enable 983 bootstrapping of such third-party protocols. The scheme SHOULD be 984 used only in conjunction with secured HNCP unicast transport (=DTLS), 985 as transferring the PSK in plain-text anywhere in the network is a 986 potential risk, especially as the originator may not know about 987 security (and use of DNCP security) on all links. The following 988 rules define how such a PSK is managed and used: 990 o If no Managed PSK TLV (Section 10.8) is currently being announced, 991 an HNCP node using this mechanism MUST create one after a random 992 delay of 0 to 10 seconds with a 32 bytes long random key and add 993 it to its node data. 995 o In case multiple nodes announce such a TLV at the same time, all 996 but the one with the greatest node identifier stop advertising it 997 and adopt the remaining one. 999 o The node currently advertising the Managed PSK TLV must generate 1000 and advertise a new random one whenever an unreachable node is 1001 removed from the DNCP topology as described in the Section 4.6 of 1002 [I-D.ietf-homenet-dncp]. 1004 PSKs for individual protocols SHOULD be derived from the random PSK 1005 using a suitable one-way hashing algorithm (e.g., by using HMAC- 1006 SHA256 [RFC6234] with a per-protocol HMAC-key) so that disclosure of 1007 any derived key does not impact other users of the managed PSK. 1008 Furthermore derived PSKs MUST be updated whenever the managed PSK 1009 changes. 1011 10. Type-Length-Value Objects 1013 HNCP defines the following TLVs in addition to those defined by DNCP. 1014 The same general rules and defaults for encoding as noted in 1015 Section 7 of [I-D.ietf-homenet-dncp] apply. Note that most HNCP 1016 variable-length TLVs also support optional nested TLVs, and they are 1017 encoded after the variable length content, followed by the zero 1018 padding of the variable length content to the next 32-bit boundary. 1020 TLVs defined here are only valid when appearing in their designated 1021 context, i.e., only directly within container TLVs mentioned in their 1022 definition, or - absent any mentions - only as top-level TLVs within 1023 the node data set. TLVs appearing outside their designated context 1024 MUST be ignored. 1026 TLVs encoding IP addresses or prefixes allow encoding both IPv6 and 1027 IPv4 addresses and prefixes. IPv6 information is encoded as is, 1028 whereas for IPv4 IPv4-mapped IPv6 addresses format [RFC4291] is used 1029 and prefix lengths are encoded as original IPv4 prefix length 1030 increased by 96. 1032 10.1. HNCP Version TLV 1034 0 1 2 3 1035 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 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Type: HNCP-VERSION (32) | Length: >= 5 | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Reserved | M | P | H | L | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | User-agent | 1042 This TLV is used to indicate the supported version and router 1043 capabilities of an HNCP node as described in Section 4. 1045 Reserved: Bits are reserved for future use. They MUST be set to 1046 zero when creating this TLV, and their value MUST be ignored when 1047 processing the TLV. 1049 M-capability: Priority value used for electing the on-link MDNS 1050 [RFC6762] proxy. It MUST be set to some value between 1 and 7 1051 included (4 is the default) if the router is capable of proxying 1052 MDNS and 0 otherwise. The values 8-15 are reserved for future 1053 use. 1055 P-capability: Priority value used for electing the on-link DHCPv6-PD 1056 server. It MUST be set to some value between 1 and 7 included (4 1057 is the default) if the router is capable of providing prefixes 1058 through DHCPv6-PD (Section 6.3.4) and 0 otherwise. The values 1059 8-15 are reserved for future use. 1061 H-capability: Priority value used for electing the on-link DHCPv6 1062 server offering non-temporary addresses. It MUST be set to some 1063 value between 1 and 7 included (4 is the default) if the router is 1064 capable of providing such addresses and 0 otherwise. The values 1065 8-15 are reserved for future use. 1067 L-capability: Priority value used for electing the on-link DHCPv4 1068 server. It MUST be set to some value between 1 and 7 included (4 1069 is the default) if the router is capable of running a legacy 1070 DHCPv4 server offering IPv4 addresses to clients and 0 otherwise. 1071 The values 8-15 are reserved for future use. 1073 User-Agent: The user-agent is a human-readable UTF-8 string that 1074 describes the name and version of the current HNCP implementation. 1076 10.2. External Connection TLV 1078 0 1 2 3 1079 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 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Type: EXTERNAL-CONNECTION (33)| Length | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | (Optional nested TLVs) | 1085 An External Connection TLV is a container TLV used to gather network 1086 configuration information associated with a single external 1087 connection (Section 6.2) to be shared across the HNCP network. A 1088 node MAY publish an arbitrary number of instances of this TLV to 1089 share the desired number of external connections. Upon reception, 1090 the information transmitted in any nested TLVs is used for the 1091 purposes of prefix assignment (Section 6.3) and host configuration 1092 (Section 7). 1094 10.2.1. Delegated Prefix TLV 1096 0 1 2 3 1097 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 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Type: DELEGATED-PREFIX (34) | Length: >= 9 | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Valid Lifetime Since Origination | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Preferred Lifetime Since Origination | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Prefix Length | | 1106 +-+-+-+-+-+-+-+-+ Prefix + 1107 ... 1108 | | 0-pad if any | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | (Optional nested TLVs) | 1112 The Delegated Prefix TLV is used by HNCP routers to advertise 1113 prefixes which are allocated to the whole network and can be used for 1114 prefix assignment. Delegated Prefix TLVs are only valid inside 1115 External Connection TLVs and their prefixes MUST NOT overlap with 1116 those of other such TLVs in the same container. 1118 Valid Lifetime Since Origination: The time in seconds the delegated 1119 prefix was valid for at the origination time of the node data 1120 containing this TLV. The value MUST be updated whenever the node 1121 republishes its Node State TLV. 1123 Preferred Lifetime Since Origination: The time in seconds the 1124 delegated prefix was preferred for at the origination time of the 1125 node data containing this TLV. The value MUST be updated whenever 1126 the node republishes its Node State TLV. 1128 Prefix Length: The number of significant bits in the Prefix. 1130 Prefix: Significant bits of the prefix padded with zeroes up to the 1131 next byte boundary. 1133 10.2.1.1. Prefix Policy TLV 1134 0 1 2 3 1135 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 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | Type: PREFIX-POLICY (43) | Length: >= 1 | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | Policy Type | | 1140 +-+-+-+-+-+-+-+-+ Value + 1141 | | 1143 The Prefix Policy TLV contains information about the policy or 1144 applicability of a delegated prefix. This information can be used to 1145 determine whether prefixes for a certain usecase (e.g., local 1146 reachability, internet connectivity) do exist or should be acquired 1147 and to make decisions about assigning prefixes to certain links or to 1148 fine-tune border firewalls. See Section 6.2 for a more in-depth 1149 discussion. This TLV is only valid inside a Delegated Prefix TLV. 1151 Policy Type: The type of the policy identifier. 1153 0 : Internet connectivity (no Value). 1155 1-128 : Explicit destination prefix with the Policy Type being 1156 the actual length of the prefix (Value contains significant 1157 bits of the destination prefix padded with zeroes up to the 1158 next byte boundary). 1160 129 : DNS Zone (Value contains an RFC 1035 [RFC1035] encoded 1161 DNS label sequence). 1163 130 : Opaque UTF-8 string (e.g., for administrative purposes). 1165 131 : Restrictive Assignment (no Value). 1167 132-255: Reserved for future additions. 1169 Value: A variable length identifier of the given type. 1171 10.2.2. DHCPv6 Data TLV 1173 0 1 2 3 1174 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 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | Type: DHCPV6-DATA (37) | Length: > 0 | 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | DHCPv6 option stream | 1180 This TLV is used to encode auxiliary IPv6 configuration information 1181 (e.g., recursive DNS servers) encoded as a stream of DHCPv6 options. 1183 It is only valid in an External Connection TLV or a Delegated Prefix 1184 TLV encoding an IPv6 prefix and MUST NOT occur more than once in any 1185 single container. When included in an External Connection TLV, it 1186 contains DHCPv6 options relevant to the External Connection as a 1187 whole. When included in a Delegated Prefix, it contains options 1188 mandatory to handle said prefix. 1190 DHCPv6 option stream: DHCPv6 options encoded as specified in 1191 [RFC3315]. 1193 10.2.3. DHCPv4 Data TLV 1195 0 1 2 3 1196 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 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | Type: DHCPV4-DATA (38) | Length: > 0 | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | DHCPv4 option stream | 1202 This TLV is used to encode auxiliary IPv4 configuration information 1203 (e.g., recursive DNS servers) encoded as a stream of DHCPv4 options. 1204 It is only valid in an External Connection TLV and MUST NOT occur 1205 more than once in any single container. It contains DHCPv4 options 1206 relevant to the External Connection as a whole. 1208 DHCPv4 option stream: DHCPv4 options encoded as specified in 1209 [RFC2131]. 1211 10.3. Assigned Prefix TLV 1213 0 1 2 3 1214 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 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | Type: ASSIGNED-PREFIX (35) | Length: >= 6 | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | Endpoint Identifier | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | Rsv. | Prty. | Prefix Length | | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix + 1222 ... 1223 | | 0-pad if any | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 | (Optional nested TLVs) | 1227 This TLV is used to announce Published Assigned Prefixes for the 1228 purposes of prefix assignment (Section 6.3). 1230 Endpoint Identifier: The endpoint identifier of the local interface 1231 the prefix is assigned to, or 0 if it is assigned to a Private 1232 Link (e.g., when the prefix is assigned for downstream prefix 1233 delegation). 1235 Rsv.: Bits are reserved for future use. They MUST be set to zero 1236 when creating this TLV, and their value MUST be ignored when 1237 processing the TLV. 1239 Prty: The Advertised Prefix Priority from 0 to 15. 1241 0-1 : Low priorities. 1243 2 : Default priority. 1245 3-7 : High priorities. 1247 8-11 : Administrative priorities. MUST NOT be used unless 1248 configured otherwise. 1250 12-14: Reserved for future use. 1252 15 : Provider priorities. MAY only be used by the router 1253 advertising the corresponding delegated prefix and based on 1254 static or dynamic configuration (e.g., for excluding a prefix 1255 based on DHCPv6-PD Prefix Exclude Option [RFC6603]). 1257 Prefix Length: The number of significant bits in the Prefix field. 1259 Prefix: The significant bits of the prefix padded with zeroes up to 1260 the next byte boundary. 1262 10.4. Node Address TLV 1264 0 1 2 3 1265 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 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | Type: NODE-ADDRESS (36) | Length: 20 | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | Endpoint Identifier | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | | 1272 | IP Address | 1273 | | 1274 | | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | (Optional nested TLVs) | 1277 This TLV is used to announce addresses assigned to an HNCP node as 1278 described in Section 6.4. 1280 Endpoint Identifier: The endpoint identifier of the local interface 1281 the prefix is assigned to, or 0 if it is not assigned on an HNCP 1282 enabled link. 1284 IP Address: The globally scoped IPv6 address, or the IPv4 address 1285 encoded as an IPv4-mapped IPv6 address [RFC4291]. 1287 10.5. DNS Delegated Zone TLV 1289 0 1 2 3 1290 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 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 | Type: DNS-DELEGATED-ZONE (39) | Length: >= 17 | 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | | 1295 | IP Address | 1296 | | 1297 | | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 |Reserved |L|B|S| | 1300 +-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) | 1301 ... 1302 | | 0-pad if any | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | (Optional nested TLVs) | 1306 This TLV is used to announce a forward or reverse DNS zone delegation 1307 in the HNCP network. Its meaning is roughly equivalent to specifying 1308 an NS and A/AAAA record for said zone. Details are specified in 1309 Section 8. 1311 IP Address : The IPv6 address of the authoritative DNS server for 1312 the zone; IPv4 addresses are represented as IPv4-mapped addresses 1313 [RFC4291]. The special value of :: (all-zero) means the 1314 delegation is available in the global DNS-hierarchy. 1316 Reserved : Those bits MUST be set to zero when creating the TLV and 1317 ignored when parsing it unless defined in a later specification. 1319 L-bit : DNS-SD [RFC6763] Legacy-Browse, indicates that this 1320 delegated zone should be included in the network's DNS-SD legacy 1321 browse list of domains at lb._dns- sd._udp.(DOMAIN-NAME). Local 1322 forward zones SHOULD have this bit set, reverse zones SHOULD NOT. 1324 B-bit : (DNS-SD [RFC6763] Browse) indicates that this delegated zone 1325 should be included in the network's DNS-SD browse list of domains 1326 at b._dns-sd._udp. (DOMAIN-NAME). Local forward zones SHOULD 1327 have this bit set, reverse zones SHOULD NOT. 1329 S-bit : (fully-qualified DNS-SD [RFC6763] domain) indicates that 1330 this delegated zone consists of a fully-qualified DNS-SD domain, 1331 which should be used as base for DNS-SD domain enumeration, i.e., 1332 _dns-sd._udp.(Zone) exists. Forward zones MAY have this bit set, 1333 reverse zones MUST NOT. This can be used to provision DNS search 1334 path to hosts for non-local services (such as those provided by an 1335 ISP, or other manually configured service providers). Zones with 1336 this flag SHOULD be added to the search domains advertised to 1337 clients. 1339 Zone : The label sequence of the zone, encoded as the domain names 1340 are encoded DNS messages as specified in [RFC1035]. The last 1341 label in the zone MUST be empty. 1343 10.6. Domain Name TLV 1345 0 1 2 3 1346 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 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | Type: DOMAIN-NAME (40) | Length: > 0 | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | Domain (DNS label sequence - variable length) | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 This TLV is used to indicate the base domain name for the network as 1354 specified in Section 8. This TLV MUST NOT be announced unless the 1355 domain name was explicitly configured by an administrator. 1357 Domain: The label sequence encoded according to [RFC1035]. 1358 Compression MUST NOT be used. The zone MUST end with an empty 1359 label. 1361 10.7. Node Name TLV 1362 0 1 2 3 1363 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 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Type: NODE-NAME (41) | Length: > 17 | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | | 1368 | IP Address | 1369 | | 1370 | | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | Length | Name | 1373 ... 1374 | (not null-terminated, variable length) | 0-pad if any | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 | (Optional nested TLVs) | 1378 This TLV is used to assign the name of a node in the network to a 1379 certain IP address as specified in Section 8. 1381 IP Address: The IP address associated with the name. IPv4 1382 addresses are encoded using IPv4-mapped IPv6 addresses. 1384 Length: The length of the name (0-63). 1386 Name: The name of the node as a single DNS label. 1388 10.8. Managed PSK TLV 1390 0 1 2 3 1391 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 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | Type: MANAGED-PSK (42) | Length: 32 | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | | 1396 | | 1397 | | 1398 | Random 256-bit PSK | 1399 | | 1400 | | 1401 | | 1402 | | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | (Optional nested TLVs) | 1406 This TLV is used to announce a PSK for securing third-party protocols 1407 exclusively supporting symmetric cryptography as specified in 1408 Section 9. 1410 11. General Requirements for HNCP Nodes 1412 Each node implementing HNCP is subject to the following requirements: 1414 o It MUST implement HNCP-Versioning (Section 4) and Interface 1415 Classification (Section 5). 1417 o It MUST implement and run the method for securing third-party 1418 protocols (Section 9) whenever it uses the security mechanism of 1419 HNCP. 1421 If the node is acting as a router, then the following requirements 1422 apply in addition: 1424 o It MUST support Autonomous Address Configuration (Section 6) and 1425 Configuration of Hosts and non-HNCP Routers (Section 7). 1427 o It SHOULD implement support for the Service Discovery and Naming 1428 (Section 8) as defined in this document. 1430 o It MAY be able to provide connectivity to IPv4-devices using 1431 DHCPv4. 1433 o It SHOULD be able to delegate prefixes to legacy IPv6 routers 1434 using DHCPv6-PD (Section 6.3.4). 1436 o In addition, normative language of Basic Requirements for IPv6 1437 Customer Edge Routers [RFC7084] applies with the following 1438 adjustments: 1440 * The generic requirements G-4 and G-5 are relaxed such that any 1441 known default router on any interface is sufficient for a 1442 router to announce itself as default router, similarly only the 1443 loss of all such default routers results in self-invalidation. 1445 * The section "WAN-Side Configuration" applies to interfaces 1446 classified as external. 1448 * If the CE sends a size-hint as indicated in WPD-2, the hint 1449 MUST NOT be determined by the number of LAN-interfaces of the 1450 CE, but SHOULD instead be large enough to at least accommodate 1451 prefix assignments announced for existing delegated or ULA- 1452 prefixes, if such prefixes exist and unless explicitly 1453 configured otherwise. 1455 * The dropping of packets with a destination address belonging to 1456 a delegated prefix mandated in WPD-5 MUST NOT be applied to 1457 destinations that are part of any prefix announced using an 1458 Assigned Prefix TLV by any HNCP router in the network. 1460 * The section "LAN-Side Configuration" applies to interfaces not 1461 classified as external. 1463 * The requirement L-2 to assign a separate /64 to each LAN 1464 interface is replaced by the participation in the prefix 1465 assignment mechanism (Section 6.3) for each such interface. 1467 * The requirement L-9 is modified, in that the M flag MUST be set 1468 if and only if a router connected to the respective Common Link 1469 is advertising a non-zero H-capability. The O flag SHOULD 1470 always be set. 1472 * The requirement L-12 to make DHCPv6 options available is 1473 adapted, in that a CER SHOULD publish the subset of options 1474 using the DHCPv6 Data TLV in an External Connection TLV. 1475 Similarly it SHOULD do the same for DHCPv4 options in a DHCPv4 1476 Data TLV. DHCPv6 options received inside an OPTION_IAPREFIX 1477 [RFC3633] MUST be published using a DHCPv6 Data TLV inside the 1478 respective Delegated Prefix TLV. HNCP routers SHOULD make 1479 relevant DHCPv6 and DHCPv4 options available to clients, i.e., 1480 options contained in External Connection TLVs that also include 1481 delegated prefixes from which a subset is assigned to the 1482 respective link. 1484 * The requirement L-13 to deprecate prefixes is applied to all 1485 delegated prefixes in the network from which assignments have 1486 been made on the respective interface. Furthermore the Prefix 1487 Information Options indicating deprecation MUST be included in 1488 Router Advertisements for the remainder of the prefixes' 1489 respective valid lifetime, but MAY be omitted after at least 2 1490 hours have passed. 1492 12. Security Considerations 1494 HNCP enables self-configuring networks, requiring as little user 1495 intervention as possible. However this zero-configuration goal 1496 usually conflicts with security goals and introduces a number of 1497 threats. 1499 General security issues for existing home networks are discussed in 1500 [RFC7368]. The protocols used to set up addresses and routes in such 1501 networks to this day rarely have security enabled within the 1502 configuration protocol itself. However these issues are out of scope 1503 for the security of HNCP itself. 1505 HNCP is a DNCP-based state synchronization mechanism carrying 1506 information with varying threat potential. For this consideration 1507 the payloads defined in DNCP and this document are reviewed: 1509 o Network topology information such as HNCP nodes and their common 1510 links. 1512 o Address assignment information such as delegated and assigned 1513 prefixes for individual links. 1515 o Naming and service discovery information such as auto-generated or 1516 customized names for individual links and nodes. 1518 12.1. Interface Classification 1520 As described in Section 5.3, an HNCP node determines the internal or 1521 external state on a per-interface basis. A firewall perimeter is set 1522 up for the external interfaces, and for internal interfaces, HNCP 1523 traffic is allowed, with the exception of leaf and guest sub- 1524 categories. 1526 Threats concerning automatic interface classification cannot be 1527 mitigated by encrypting or authenticating HNCP traffic itself since 1528 external routers do not participate in the protocol and often cannot 1529 be authenticated by other means. These threats include propagation 1530 of forged uplinks in the homenet in order to, e.g., redirect traffic 1531 destined to external locations and forged internal status by external 1532 routers to, e.g., circumvent the perimeter firewall. 1534 It is therefore imperative to either secure individual links on the 1535 physical or link-layer or preconfigure the adjacent interfaces of 1536 HNCP routers to an appropriate fixed category in order to secure the 1537 homenet border. Depending on the security of the external link 1538 eavesdropping, man-in-the-middle and similar attacks on external 1539 traffic can still happen between a homenet border router and the ISP, 1540 however these cannot be mitigated from inside the homenet. For 1541 example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4 1542 messages, but this is very rarely implemented in large or small 1543 networks. Further, while PPP can provide secure authentication of 1544 both sides of a point to point link, it is most often deployed with 1545 one-way authentication of the subscriber to the ISP, not the ISP to 1546 the subscriber. 1548 12.2. Security of Unicast Traffic 1550 Once the homenet border has been established there are several ways 1551 to secure HNCP against internal threats like manipulation or 1552 eavesdropping by compromised devices on a link which is enabled for 1553 HNCP traffic. If left unsecured, attackers may perform arbitrary 1554 eavesdropping, spoofing or denial of service attacks on HNCP services 1555 such as address assignment or service discovery. 1557 Detailed interface categories like "leaf" or "guest" can be used to 1558 integrate not fully trusted devices to various degrees into the 1559 homenet by not exposing them to HNCP traffic or by using firewall 1560 rules to prevent them from reaching homenet-internal resources. 1562 On links where this is not practical and lower layers do not provide 1563 adequate protection from attackers, DNCP secure mode MUST be used to 1564 secure traffic. 1566 12.3. Other Protocols in the Home 1568 IGPs and other protocols are usually run alongside HNCP therefore the 1569 individual security aspects of the respective protocols must be 1570 considered. It can however be summarized that many protocols to be 1571 run in the home (like IGPs) provide - to a certain extent - similar 1572 security mechanisms. Most of these protocols do not support 1573 encryption and only support authentication based on pre-shared keys 1574 natively. This influences the effectiveness of any encryption-based 1575 security mechanism deployed by HNCP as homenet routing information is 1576 thus usually not encrypted. 1578 13. IANA Considerations 1580 IANA should set up a registry for the (decimal values within range 1581 0-1023) "HNCP TLV Types" under "Distributed Node Consensus Protocol 1582 (DNCP)", with the following initial contents: 1584 0-31: Reserved - specified in the DNCP registry 1586 32: HNCP-Version 1588 33: External-Connection 1590 34: Delegated-Prefix 1592 35: Assigned-Prefix 1594 36: Node-Address 1596 37: DHCPv4-Data 1598 38: DHCPv6-Data 1600 39: DNS-Delegated-Zone 1601 40: Domain-Name 1603 41: Node-Name 1605 42: Managed-PSK 1607 43: Prefix-Policy 1609 44-512: Free - policy of 'RFC required' should be used. 1611 512-767: Reserved - specified in the DNCP registry 1613 768-1023: Reserved - to be used for per-implementation 1614 experimentation. How collision is avoided is out of scope of this 1615 document. 1617 HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP- 1618 DTLS-PORT, as well as an IPv6 link-local multicast address All- 1619 Homenet-Nodes. 1621 14. References 1623 14.1. Normative references 1625 [I-D.ietf-homenet-dncp] 1626 Stenberg, M. and S. Barth, "Distributed Node Consensus 1627 Protocol", draft-ietf-homenet-dncp-09 (work in progress), 1628 August 2015. 1630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1631 Requirement Levels", BCP 14, RFC 2119, March 1997. 1633 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1634 Security Version 1.2", RFC 6347, January 2012. 1636 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1637 "Prefix Exclude Option for DHCPv6-based Prefix 1638 Delegation", RFC 6603, May 2012. 1640 [I-D.ietf-homenet-prefix-assignment] 1641 Pfister, P., Paterson, B., and J. Arkko, "Distributed 1642 Prefix Assignment Algorithm", draft-ietf-homenet-prefix- 1643 assignment-08 (work in progress), August 2015. 1645 14.2. Informative references 1647 [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, 1648 A., Beser, B., and J. Privat, "The User Class Option for 1649 DHCP", RFC 3004, November 2000. 1651 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1652 Messages", RFC 3118, June 2001. 1654 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1655 2131, March 1997. 1657 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1658 and M. Carney, "Dynamic Host Configuration Protocol for 1659 IPv6 (DHCPv6)", RFC 3315, July 2003. 1661 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1662 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1663 December 2003. 1665 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1666 E. Lear, "Address Allocation for Private Internets", BCP 1667 5, RFC 1918, February 1996. 1669 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1670 Architecture", RFC 4291, February 2006. 1672 [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1673 "IPv6 Home Networking Architecture Principles", RFC 7368, 1674 October 2014. 1676 [RFC1035] Mockapetris, P., "Domain names - implementation and 1677 specification", STD 13, RFC 1035, November 1987. 1679 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1680 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 1682 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1683 April 1992. 1685 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1686 February 2013. 1688 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1689 Discovery", RFC 6763, February 2013. 1691 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1692 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1693 6241, June 2011. 1695 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1696 Extensions", RFC 2132, March 1997. 1698 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1699 Addresses", RFC 4193, October 2005. 1701 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1702 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1703 November 2013. 1705 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1706 Interface Identifiers with IPv6 Stateless Address 1707 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 1709 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1710 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1711 September 2007. 1713 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1714 Capabilities in Customer Premises Equipment (CPE) for 1715 Providing Residential IPv6 Internet Service", RFC 6092, 1716 DOI 10.17487/RFC6092, January 2011, 1717 . 1719 14.3. URIs 1721 [3] http://www.openwrt.org 1723 [4] http://www.homewrt.org/doku.php?id=run-conf 1725 Appendix A. Changelog [RFC Editor: please remove] 1727 draft-ietf-homenet-hncp-09: Added nested TLV definitions for variable 1728 length TLVs. NOTE: Node name TLV encoding includes now length byte. 1729 Version TLV now itself indicates version. 1731 draft-ietf-homenet-hncp-08: Editorial reorganization. 1733 draft-ietf-homenet-hncp-07: Using version 1 instead of version 0, as 1734 existing implementations already use it. 1736 draft-ietf-homenet-hncp-06: Various edits based on feedback, 1737 hopefully without functional delta. 1739 draft-ietf-homenet-hncp-05: Renamed "Adjacent Link" to "Common Link". 1740 Changed single IPv4 uplink election from MUST to MAY. Added explicit 1741 indication to distinguish (IPv4)-PDs for local connectivity and ones 1742 with uplink connectivity allowing, e.g., better local-only 1743 IPv4-connectivity. 1745 draft-ietf-homenet-hncp-04: Change the responsibility for sending RAs 1746 to the router assigning the prefix. 1748 draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP 1749 (homenet profile). 1751 draft-ietf-homenet-hncp-02: Removed any built-in security. Relying 1752 on IPsec. Reorganized interface categories, added requirements 1753 languages, made manual border configuration a MUST-support. 1754 Redesigned routing protocol election to consider non-router devices. 1756 draft-ietf-homenet-hncp-01: Added (MAY) guest, ad-hoc, hybrid 1757 categories for interfaces. Removed old hnetv2 reference, and now 1758 pointing just to OpenWrt + github. Fixed synchronization algorithm 1759 to spread also same update number, but different data hash case. 1760 Made purge step require bidirectional connectivity between nodes when 1761 traversing the graph. Edited few other things to be hopefully 1762 slightly clearer without changing their meaning. 1764 draft-ietf-homenet-hncp-00: Added version TLV to allow for TLV 1765 content changes pre-RFC without changing IDs. Added link id to 1766 assigned address TLV. 1768 Appendix B. Draft source [RFC Editor: please remove] 1770 This draft is available at https://github.com/fingon/ietf-drafts/ in 1771 source format. Issues and pull requests are welcome. 1773 Appendix C. Implementation [RFC Editor: please remove] 1775 A GPLv2-licensed implementation of HNCP is currently under 1776 development at https://github.com/sbyx/hnetd/ and binaries are 1777 available in the OpenWrt [3] package repositories. See [4] for more 1778 information. Feedback and contributions are welcome. 1780 Appendix D. Acknowledgements 1782 Thanks to Ole Troan, Mark Baugher, Mark Townsley, Juliusz Chroboczek 1783 and Thomas Clausen for their contributions to the draft. 1785 Thanks to Eric Kline for the original border discovery work. 1787 Authors' Addresses 1789 Markus Stenberg 1790 Independent 1791 Helsinki 00930 1792 Finland 1794 Email: markus.stenberg@iki.fi 1796 Steven Barth 1797 Independent 1798 Halle 06114 1799 Germany 1801 Email: cyrus@openwrt.org 1803 Pierre Pfister 1804 Cisco Systems 1805 Paris 1806 France 1808 Email: pierre.pfister@darou.fr