idnits 2.17.1 draft-ietf-homenet-hncp-08.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 6, 2015) is 3185 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 1743 -- Looks like a reference, but probably isn't: '4' on line 1743 == Outdated reference: A later version (-12) exists of draft-ietf-homenet-dncp-09 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-08) exists of draft-ietf-homenet-prefix-assignment-07 -- 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 (~~), 3 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: February 7, 2016 P. Pfister 6 Cisco Systems 7 August 6, 2015 9 Home Networking Control Protocol 10 draft-ietf-homenet-hncp-08 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 February 7, 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. DHCPv6 for Addressing or Configuration . . . . . . . . . 19 79 7.2. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 19 80 7.3. DHCPv4 for Addressing and Configuration . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . 30 97 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 98 12.1. Interface Classification . . . . . . . . . . . . . . . . 32 99 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 33 100 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 33 101 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 102 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 103 14.1. Normative references . . . . . . . . . . . . . . . . . . 35 104 14.2. Informative references . . . . . . . . . . . . . . . . . 35 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 . . . . . . . . . . . . . . . . . . . . . . . 38 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 or publishing such a TLV with a different Version. 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 and therefore do not take part in these 371 elections. 373 5. Interface Classification 375 5.1. Interface Categories 377 HNCP specifies the following categories interfaces can be configured 378 to be in: 380 Internal category: This declares an interfaces to be internal, i.e., 381 within the borders of the HNCP network. HNCP traffic MUST be sent 382 and received. Routers MUST forward traffic with appropriate 383 source addresses between their internal interfaces and allow 384 internal traffic to reach external networks. All nodes MUST 385 implement this category and nodes not implementing any other 386 category implicitly use it as a fixed default. 388 External category: This declares an interface to be external, i.e., 389 not within the borders of the HNCP network. HNCP traffic MUST 390 neither be sent nor received. HNCP routers SHOULD announce 391 acquired configuration information for use in the network as 392 described in Section 6.2, if the interface appears to be connected 393 to an external network. HNCP routers MUST implement this 394 category. 396 Leaf category: This declares an interface used by client devices 397 only. Such an interface uses the Internal category with the 398 exception that HNCP traffic MUST NOT be sent on the interface, and 399 all such traffic received on the interface MUST be ignored. This 400 category SHOULD be supported by HNCP routers. 402 Guest category: This declares an interface used by untrusted client 403 devices only. In addition to the restrictions of the Leaf 404 category, HNCP routers MUST filter traffic from and to the 405 interface such that connected devices are unable to reach other 406 devices inside the HNCP network or query services advertised by 407 them unless explicitly allowed. This category SHOULD be supported 408 by HNCP routers. 410 Ad-hoc category: This configures an interface to use the Internal 411 category but no assumption is made about the the link's 412 transitivity. All other interface categories assume transitive 413 connectivity. This affects the Common Link (Section 6.1) 414 definition. Support for this category is OPTIONAL. 416 Hybrid category: This declares an interface to use the Internal 417 category while still trying to acquire (external) configuration 418 information on it, e.g., by running DHCP clients. This is useful, 419 e.g., if the link is shared with a non-HNCP router under control 420 and still within the borders of the same network. Detection of 421 this category automatically in addition to manual configuration is 422 out of scope of this document. Support for this category is 423 OPTIONAL. 425 5.2. DHCP Aided Auto-Detection 427 Auto-detection of interface categories is possible based on 428 interaction with DHCPv4 [RFC2131] and DHCPv6-PD [RFC3633] servers on 429 connected links. HNCP defines special DHCP behavior to differentiate 430 its internal servers from external ones in order to achieve this. 431 Therefore all internal devices (including HNCP nodes) running DHCP 432 servers on links where auto-detection is used by any HNCP node MUST 433 use the following mechanism based on The User Class Option for DHCPv4 434 [RFC3004] and its DHCPv6 counterpart [RFC3315]: 436 o The device MUST ignore or reject DHCP-Requests containing a DHCP 437 User-Class consisting of the ASCII-String "HOMENET". 439 Not following this rule (e.g., running unmodified DHCP servers) might 440 lead to false positives when auto-detection is used, i.e., HNCP nodes 441 assume an interface to not be internal, even though it was intended 442 to be. 444 5.3. Algorithm for Border Discovery 446 This section defines the interface classification algorithm. It is 447 suitable for both IPv4 and IPv6 (single or dual-stack) and detects 448 the category of an interface either automatically or based on a fixed 449 configuration. By determining the category for all interfaces, the 450 network borders are implicitly defined, i.e., all interfaces not 451 belonging to the External category are considered to be within the 452 borders of the network, all others are not. 454 The following algorithm MUST be implemented by any node implementing 455 HNCP. However, if the node does not implement auto-detection, only 456 the first step is required. The algorithm works as follows, with 457 evaluation stopping at first match: 459 1. If a fixed category is configured for an interface, it is used. 461 2. If a delegated prefix could be acquired by running a DHCPv6 462 client, it is considered external. The DHCPv6 client MUST have 463 included a DHCPv6 User-Class consisting of the ASCII-String 464 "HOMENET" in all of its requests. 466 3. If an IPv4 address could be acquired by running a DHCPv4 client 467 on the interface, it is considered external. The DHCPv4 client 468 MUST have included a DHCP User-Class consisting of the ASCII- 469 String "HOMENET" in all of its requests. 471 4. The interface is considered internal. 473 Note that as other HNCP nodes will ignore the client due to the user 474 class option, any server that replies is clearly external (or a 475 malicious internal node). 477 An HNCP router SHOULD allow setting the fixed category for each 478 interface which may be connected to either an internal or external 479 device (e.g., an Ethernet port that can be connected to a modem, 480 another HNCP router or a client). 482 An HNCP router using auto-detection on an interface MUST run the 483 appropriately configured DHCP clients as long as the interface 484 without a fixed category is active (including states where auto- 485 detection considers it to be internal) and rerun the algorithm above 486 to react to conditions resulting in a different interface category. 487 The router SHOULD wait for a reasonable time period (5 seconds as a 488 default), during which the DHCP clients can acquire a lease, before 489 treating a newly activated or previously external interface as 490 internal. 492 6. Autonomous Address Configuration 494 This section specifies how HNCP nodes configure host and node 495 addresses. At first border routers share information obtained from 496 service providers or local configuration by publishing one or more 497 External Connection TLVs (Section 10.2). These contain other TLVs 498 such as Delegated Prefix TLVs (Section 10.2.1) which are then used 499 for prefix assignment. Finally, HNCP nodes obtain addresses either 500 statelessly or using a specific stateful mechanism (Section 6.4). 501 Hosts and non-HNCP routers are configured using SLAAC, DHCP or 502 DHCPv6-PD. 504 6.1. Common Link 506 HNCP uses the concept of Common Link both in autonomic address 507 configuration and naming and service discovery (Section 8). A Common 508 Link refers to the set of interfaces of nodes that see each other's 509 traffic and presumably also the traffic of all hosts that may use the 510 nodes to, e.g., forward traffic. Common Links are used, e.g., to 511 determine where prefixes should be assigned or which peers 512 participate in the election of a DHCP server. The Common Link is 513 computed separately for each local internal interface, and it always 514 contains the local interface. Additionally, if the local interface 515 is not set to ad-hoc category (see Section 5.1), it also contains the 516 set of interfaces that are bidirectionally reachable from the given 517 local interface, that is, every remote interface of a remote node 518 meeting all of the following requirements: 520 o The local node publishes a Peer TLV with: 522 * Peer Node Identifier = remote node's node identifier 524 * Peer Endpoint Identifier = remote interface's endpoint 525 identifier 527 * Endpoint Identifier = local interface's endpoint identifier 529 o The remote node publishes a Peer TLV with: 531 * Peer Node Identifier = local node's node identifier 533 * Peer Endpoint Identifier = local interface's endpoint 534 identifier 536 * Endpoint Identifier = remote interface's endpoint identifier 538 A node MUST be able to detect whether two of its local internal 539 interfaces are connected, e.g., by detecting an identical remote 540 interface being part of the Common Links of both local interfaces. 542 6.2. External Connections 544 Each HNCP router MAY obtain external connection information such as 545 address prefixes, DNS server addresses and DNS search paths from one 546 or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or 547 static configuration. Each individual external connection to be 548 shared in the network is represented by one External Connection TLV 549 (Section 10.2). 551 Announcements of individual external connections may consist of the 552 following components: 554 Delegated Prefixes: address space available for assignment to 555 internal links announced using Delegated Prefix TLVs 556 (Section 10.2.1). Some address spaces might have special 557 properties which are necessary to understand in order to handle 558 them (e.g., information similar to [RFC6603]). This information 559 is encoded using DHCPv6 Data TLVs (Section 10.2.2) inside the 560 respective Delegated Prefix TLVs. 562 Auxiliary Information: information about services such as DNS or 563 time synchronization regularly used by hosts in addition to 564 addressing and routing information. This information is encoded 565 using DHCPv6 Data TLVs (Section 10.2.2) and DHCPv4 Data TLVs 566 (Section 10.2.3). 568 Whenever information about reserved parts (e.g., as specified in 569 [RFC6603]) is received for a delegated prefix, the reserved parts 570 MUST be advertised using Assigned Prefix TLVs (Section 10.3) with the 571 highest priority (i.e., 15), as if they were assigned to a Private 572 Link. 574 Some connections or delegated prefixes may have a special meaning and 575 are not regularly used for internal or internet connectivity, instead 576 they may provide access to special services like VPNs, sensor 577 networks, VoIP, IPTV, etc. Care must be taken that these prefixes 578 are properly integrated and dealt with in the network, in order to 579 avoid breaking connectivity for devices who are not aware of their 580 special characteristics or to only selectively allow certain devices 581 to use them. Such prefixes are distinguished using Prefix Policy 582 TLVs (Section 10.2.1.1). Their contents MAY be partly opaque to HNCP 583 nodes, and their identification and usage depends on local policy. 584 However the following general rules MUST be adhered to: 586 Special rules apply when making address assignments for prefixes 587 with Prefix Policy TLVs with type 131, as described in 588 Section 6.3.2 590 In presence of any type 1 to 128 Prefix Policy TLV the prefix is 591 specialized to reach destinations denoted by any such Prefix 592 Policy TLV, i.e., in absence of a type 0 Prefix Policy TLV it is 593 not usable for general internet connectivity. An HNCP router MAY 594 enforce this restriction with appropriate packet filter rules. 596 6.3. Prefix Assignment 598 HNCP uses the Prefix Assignment Algorithm 599 [I-D.ietf-homenet-prefix-assignment] in order to assign prefixes to 600 HNCP internal links and uses some of the terminology (Section 2) 601 defined there. HNCP furthermore defines the Assigned Prefix TLV 602 (Section 10.3) which MUST be used to announce Published Assigned 603 Prefixes. 605 6.3.1. Prefix Assignment Algorithm Parameters 607 All HNCP nodes running the prefix assignment algorithm use the 608 following values for its parameters: 610 Node IDs: HNCP node identifiers are used. The comparison operation 611 is defined as bit-wise comparison. 613 Set of Delegated Prefixes: The set of prefixes encoded in Delegated 614 Prefix TLVs which are not strictly included in prefixes encoded in 615 other Delegated Prefix TLVs. Note that Delegated Prefix TLVs 616 included in ignored External Connection TLVs are not considered. 617 It is dynamically updated as Delegated Prefix TLVs are added or 618 removed. 620 Set of Shared Links: The set of Common Links associated with 621 interfaces with internal, leaf, guest or ad-hoc category. It is 622 dynamically updated as interfaces are added, removed, or switch 623 from one category to another. When multiple interfaces are 624 detected as belonging to the same Common Link, prefix assignment 625 is disabled on all of these interfaces except one. 627 Set of Private Links: This document defines Private Links 628 representing DHCPv6-PD clients or as a mean to advertise prefixes 629 included in the DHCPv6 Exclude Prefix option. Other 630 implementation-specific Private Links may be defined whenever a 631 prefix needs to be assigned for a purpose that does not require a 632 consensus with other HNCP nodes. 634 Set of Advertised Prefixes: The set of prefixes included in 635 Assigned Prefix TLVs advertised by other HNCP nodes (Prefixes 636 advertised by the local node are not in this set). The associated 637 Advertised Prefix Priority is the priority specified in the TLV. 638 The associated Shared Link is determined as follows: 640 * If the Link Identifier is zero, the Advertised Prefix is not 641 assigned on a Shared Link. 643 * If the other node's interface identified by the Link Identifier 644 is included in one of the Common Links used for prefix 645 assignment, it is considered as assigned on the given Common 646 Link. 648 * Otherwise, the Advertised Prefix is not assigned on a Shared 649 Link. 651 Advertised Prefixes as well as their associated priorities and 652 associated Shared Links MUST be updated as Assigned Prefix TLVs 653 are added, updated or removed, and as Common Links are modified. 655 ADOPT_MAX_DELAY: The default value is 0 seconds (i.e., prefix 656 adoption MAY be done instantly). 658 BACKOFF_MAX_DELAY: The default value is 4 seconds. 660 RANDOM_SET_SIZE: The default value is 64. 662 Flooding Delay: The default value is 5 seconds. 664 Default Advertised Prefix Priority: When a new assignment is 665 created or an assignment is adopted - as specified in the prefix 666 assignment algorithm routine - the default Advertised Prefix 667 Priority to be used is 2. 669 6.3.2. Making New Assignments 671 Whenever the prefix assignment algorithm subroutine (Section 4.1 of 672 [I-D.ietf-homenet-prefix-assignment]) is run on a Common Link and 673 whenever a new prefix may be assigned (case 1 of the subroutine: no 674 Best Assignment and no Current Assignment), the decision of whether 675 the assignment of a new prefix is desired MUST follow these rules in 676 order: 678 If the Delegated Prefix TLV contains a DHCPv6 Data TLV, and the 679 meaning of one of the DHCP options is not understood by the HNCP 680 node, the creation of a new prefix is not desired. This rule 681 applies to TLVs inside Delegated Prefix TLVs but not to those 682 inside External Connection TLVs. 684 If the remaining preferred lifetime of the prefix is 0 and there 685 is another delegated prefix of the same IP version used for prefix 686 assignment with a non-zero preferred lifetime, the creation of a 687 new prefix is not desired. 689 If the Delegated Prefix does not include a Prefix Policy TLV 690 indicating restrictive assignment (type 131) or if local policy 691 exists to identify it based on, e.g., other Prefix Policy TLV 692 values and allows assignment, the creation of a new prefix is 693 desired. 695 Otherwise, the creation of a new prefix is not desired. 697 If the considered delegated prefix is an IPv6 prefix, and whenever 698 there is at least one available prefix of length 64, a prefix of 699 length 64 MUST be selected unless configured otherwise. In case no 700 prefix of length 64 would be available, a longer prefix MAY be 701 selected even without configuration. 703 If the considered delegated prefix is an IPv4 prefix (Section 6.5 704 details how IPv4 delegated prefixes are generated), a prefix of 705 length 24 SHOULD be preferred. 707 In any case, an HNCP router making an assignment MUST support a 708 mechanism suitable to distribute addresses from the considered prefix 709 if the link is intended to be used by clients. In this case a router 710 assigning an IPv4 prefix MUST announce the L-capability and a router 711 assigning an IPv6 prefix with a length greater than 64 MUST announce 712 the H-capability as defined in Section 4. 714 6.3.3. Applying Assignments 716 The prefix assignment algorithm indicates when a prefix is applied to 717 the respective Common Link. When that happens each router connected 718 to said link: 720 MUST forward traffic destined to said prefix to the respective 721 link. 723 MUST participate in the client configuration election as described 724 in Section 7, if the link is intended to be used by clients. 726 MAY add an address from said prefix to the respective network 727 interface as described in Section 6.4, e.g., if it is to be used 728 as source for locally originating traffic. 730 6.3.4. DHCPv6 Prefix Delegation 732 When an HNCP router announcing the P-Capability (Section 4) receives 733 a DHCPv6-PD request from a client, it SHOULD assign one prefix per 734 delegated prefix in the network. This set of assigned prefixes is 735 then delegated to the client, after it has been applied as described 736 in the prefix assignment algorithm. Each DHCPv6-PD client MUST be 737 considered as an independent Private Link and delegation MUST be 738 based on the same set of Delegated Prefixes as the one used for 739 Common Link prefix assignments, however the prefix length to be 740 delegated MAY be smaller than 64. 742 The assigned prefixes MUST NOT be given to DHCPv6-PD clients before 743 they are applied, and MUST be withdrawn whenever they are destroyed. 744 As an exception to this rule, in order to shorten delays of processed 745 requests, a router MAY prematurely give out a prefix which is 746 advertised but not yet applied if it does so with a valid lifetime of 747 not more than 30 seconds and ensures removal or correction of 748 lifetimes as soon as possible. 750 6.4. Node Address Assignment 752 This section specifies how HNCP nodes reserve addresses for their own 753 use. Nodes MAY, at any time, try to reserve a new address from any 754 Applied Assigned Prefix. Each HNCP node SHOULD announce an IPv6 755 address and - if it supports IPv4 - MUST announce an IPv4 address, 756 whenever matching prefixes are assigned to at least one of its Common 757 Links. These addresses are published using Node Address TLVs and 758 used to locally reach HNCP nodes for other services. Nodes SHOULD 759 NOT create and announce more than one assignment per IP version to 760 avoid cluttering the node data with redundant information unless a 761 special use case requires it. 763 Stateless assignment based on Semantically Opaque Interface 764 Identifiers [RFC7217] SHOULD be used for address assignment whenever 765 possible (e.g., the prefix length is 64), otherwise (e.g., for IPv4 766 if supported) the following method MUST be used instead: For any 767 assigned prefix for which stateless assignment is not used, the first 768 quarter of the addresses are reserved for HNCP based address 769 assignments, whereas the last three quarters are left to the DHCP 770 elected router (Section 4 specifies the DHCP server election 771 process). For example, if the prefix 192.0.2.0/24 is assigned and 772 applied to a Common Link, addresses included in 192.0.2.0/26 are 773 reserved for HNCP nodes and the remaining addresses are reserved for 774 the elected DHCPv4 server. 776 HNCP nodes assign themselves addresses, and then (to ensure eventual 777 lack of conflicting assignments) publish the assignments using the 778 Node Address TLV (Section 10.4). 780 The process of obtaining addresses is specified as follows: 782 o A node MUST NOT start advertising an address if it is already 783 advertised by another node. 785 o An assigned address MUST be part of an assigned prefix currently 786 applied on a Common Link which includes the interface specified by 787 the endpoint identifier. 789 o An address MUST NOT be used unless it has been advertised for at 790 least ADDRESS_APPLY_DELAY consecutive seconds, and is still 791 currently being advertised. The default value for 792 ADDRESS_APPLY_DELAY is 3 seconds. 794 o Whenever the same address is advertised by more than one node, all 795 but the one advertised by the node with the highest node 796 identifier MUST be removed. 798 6.5. Local IPv4 and ULA Prefixes 800 HNCP routers can create a ULA or private IPv4 prefix to enable 801 connectivity between local devices. These prefixes are inserted in 802 HNCP as if they were delegated prefixes of a (virtual) external 803 connection (Section 6.2). The following rules apply: 805 An HNCP router SHOULD create a ULA prefix if there is no other 806 IPv6 prefix with a preferred time greater than 0 in the network. 807 It MAY also do so, if there are other delegated IPv6 prefixes, but 808 none of which is locally generated (i.e., without any Prefix 809 Policy TLV) and has a preferred time greater than 0. However, it 810 MUST NOT do so otherwise. In case multiple locally generated ULA 811 prefixes are present, only the one published by the node with the 812 highest node identifier is kept among those with a preferred time 813 greater than 0 - if there is any. 815 An HNCP router MUST create a private IPv4 prefix [RFC1918] 816 whenever it wishes to provide IPv4 internet connectivity to the 817 network and no other private IPv4 prefix with internet 818 connectivity currently exists. It MAY also enable local IPv4 819 connectivity by creating a private IPv4 prefix if no IPv4 prefix 820 exists but MUST NOT do so otherwise. In case multiple IPv4 821 prefixes are announced, only the one published by the node with 822 the highest node identifier is kept among those with a Prefix 823 Policy of type 0 - if there is any. The router publishing a 824 prefix with internet connectivity MUST forward IPv4 traffic to the 825 internet and perform NAT on behalf of the network as long as it 826 publishes the prefix, other routers in the network MAY choose not 827 to. 829 Creation of such ULA and IPv4 prefixes MUST be delayed by a random 830 timespan between 0 and 10 seconds in which the router MUST scan for 831 others trying to do the same. 833 When a new ULA prefix is created, the prefix is selected based on the 834 configuration, using the last non-deprecated ULA prefix, or generated 835 based on [RFC4193]. 837 7. Configuration of Hosts and non-HNCP Routers 839 HNCP routers need to ensure that hosts and non-HNCP downstream 840 routers on internal links are configured with addresses and routes. 841 Since DHCP clients can usually only bind to one server at a time, a 842 per-link and per-service election takes place. 844 HNCP routers may have different capabilities for configuring 845 downstream devices and providing naming services. Each router MUST 846 therefore indicate its capabilities as specified in Section 4 in 847 order to participate as a candidate in the election. 849 7.1. DHCPv6 for Addressing or Configuration 851 In general Stateless Address Autoconfiguration is used for client 852 configuration for its low overhead and fast renumbering capabilities, 853 however stateful DHCPv6 can be used in addition by administrative 854 choice, to, e.g., collect hostnames and use them to provide naming 855 services or whenever stateless configuration is not applicable. 857 The designated stateful DHCPv6 server for a Common Link (Section 6.1) 858 is elected based on the capabilities described in Section 4. The 859 winner is the router (connected to the Common Link) advertising the 860 greatest H-capability. In case of a tie, Capability Values are 861 compared, and router with the greatest value is elected. In case of 862 another tie, the router with the highest node identifier is elected 863 among the routers with tied Capability Values. 865 The elected router MUST serve stateful DHCPv6 and SHOULD provide 866 naming services for acquired hostnames as outlined in Section 8. 867 Stateful addresses SHOULD be assigned in a way not hindering fast 868 renumbering even if the DHCPv6 server or client do not support the 869 DHCPv6 reconfigure mechanism. In case no router was elected, 870 stateful DHCPv6 is not provided. 872 7.2. DHCPv6 for Prefix Delegation 874 The designated DHCPv6 server for prefix-delegation on a Common Link 875 is elected based on the capabilities described in Section 4. The 876 winner is the router (connected to the Common Link) advertising the 877 greatest P-capability. In case of a tie, Capability Values are 878 compared, and router with the greatest value is elected. In case of 879 another tie, the router with the highest node identifier is elected 880 among the routers with tied Capability Values. 882 The elected router MUST provide prefix-delegation services [RFC3633] 883 on the given link and follow the rules in Section 6.3.4. 885 7.3. DHCPv4 for Addressing and Configuration 887 The designated DHCPv4 server on a Common Link (Section 6.1) is 888 elected based on the capabilities described in Section 4. The winner 889 is the router (connected to the Common Link) advertising the greatest 890 L-capability. In case of a tie, Capability Values are compared, and 891 router with the greatest value is elected. In case of another tie, 892 the router with the highest node identifier is elected among the 893 routers with tied Capability Values. 895 The elected router MUST provide DHCPv4 services on the given link. 896 It MUST announce itself as router [RFC2132] to clients if and only if 897 there is an IPv4 default route known in the network. If there is no 898 default route, the elected router MUST announce a Classless Static 899 Route Option [RFC3442] for the IPv4 prefix announced in the Delegated 900 Prefix TLV and MAY announce such an option for known reachable IPv4 901 destinations not within any local delegated prefix. 903 DHCPv4 lease times SHOULD be short (i.e., not longer than 5 minutes) 904 in order to provide reasonable response times to changes. 906 7.4. Multicast DNS Proxy 908 The designated MDNS [RFC6762] proxy on a Common Link is elected based 909 on the capabilities described in Section 4. The winner is the router 910 (connected to the Common Link) advertising the greatest M-capability. 911 In case of a tie, Capability Values are compared, and router with the 912 greatest value is elected. In case of another tie, the router with 913 the highest node identifier is elected among the routers with tied 914 Capability Values. 916 The elected router MUST provide an MDNS-proxy on the given link and 917 announce it as described in Section 8. 919 8. Naming and Service Discovery 921 Network-wide naming and service discovery can greatly improve the 922 user-friendliness of a network. The following mechanism provides 923 means to setup and delegate naming and service discovery across 924 multiple HNCP routers. 926 Each HNCP router SHOULD provide a recursive name resolution server 927 which honors the announcements made in Delegated Zone TLVs 928 (Section 10.5), Domain Name TLVs (Section 10.6) and Node Name TLVs 929 (Section 10.7), i.e., delegate queries to the designated name servers 930 and hand out appropriate A, AAAA and PTR records according to the 931 mentioned TLVs. 933 Each HNCP router SHOULD provide and announce an auto-generated or 934 user-configured name for each internal Common Link (Section 6.1) for 935 which it is the designated DHCPv4, stateful DHCPv6 server, MDNS 936 proxy, or for which it provides forward or reverse DNS services on 937 behalf of connected devices. This announcement is done using 938 Delegated Zone TLVs (Section 10.5) and MUST be unique in the whole 939 network. In case of a conflict the announcement of the node with the 940 highest node identifier takes precedence and all other nodes MUST 941 cease to announce the conflicting TLV. HNCP routers providing name 942 resolving services MUST use the included DNS server address within 943 the TLV to resolve names belonging to the zone as if there was an NS 944 record. 946 Each HNCP node SHOULD announce a node name for itself to be easily 947 reachable and MAY do so on behalf of other devices. Announcements 948 are made using Node Name TLVs (Section 10.7) and MUST be unique in 949 the whole network. In case of a conflict the announcement of the 950 node with the highest node identifier takes precedence and all other 951 nodes MUST cease to announce the conflicting TLV. HNCP routers 952 providing name resolving services MUST resolve these names to their 953 respective IP addresses as if there were corresponding A/AAAA 954 records. 956 Names and unqualified zones are used in an HNCP network to provide 957 naming and service discovery with local significance. A network-wide 958 zone is appended to all single labels or unqualified zones in order 959 to qualify them. ".home" is the default, however an administrator MAY 960 configure announcing of a Domain Name TLV (Section 10.6) for the 961 network to use a different one. In case multiple are announced, the 962 domain of the node with the greatest node identifier takes 963 precedence. 965 9. Securing Third-Party Protocols 967 Pre-shared keys (PSKs) are often required to secure (for example) 968 IGPs and other protocols which lack support for asymmetric security. 969 The following mechanism manages PSKs using HNCP to enable 970 bootstrapping of such third-party protocols. The scheme SHOULD be 971 used only in conjunction with secured HNCP unicast transport (=DTLS), 972 as transferring the PSK in plain-text anywhere in the network is a 973 potential risk, especially as the originator may not know about 974 security (and use of DNCP security) on all links. The following 975 rules define how such a PSK is managed and used: 977 o If no Managed PSK TLV (Section 10.8) is currently being announced, 978 an HNCP node using this mechanism MUST create one after a random 979 delay of 0 to 10 seconds with a 32 bytes long random key and add 980 it to its node data. 982 o In case multiple nodes announce such a TLV at the same time, all 983 but the one with the greatest node identifier stop advertising it 984 and adopt the remaining one. 986 o The node currently advertising the Managed PSK TLV must generate 987 and advertise a new random one whenever an unreachable node is 988 removed from the DNCP topology as described in the Section 4.6 of 989 [I-D.ietf-homenet-dncp]. 991 PSKs for individual protocols SHOULD be derived from the random PSK 992 using a suitable one-way hashing algorithm (e.g., by using HMAC- 993 SHA256 [RFC6234] with a per-protocol HMAC-key) so that disclosure of 994 any derived key does not impact other users of the managed PSK. 995 Furthermore derived PSKs MUST be updated whenever the managed PSK 996 changes. 998 10. Type-Length-Value Objects 1000 HNCP defines the following TLVs in addition to those defined by DNCP. 1001 The same general rules and defaults for encoding as noted in 1002 Section 7 of [I-D.ietf-homenet-dncp] apply. 1004 TLVs defined here are only valid when appearing in their designated 1005 context, i.e., only directly within container TLVs mentioned in their 1006 definition, or - absent any mentions - only as top-level TLVs within 1007 the node data set. TLVs appearing outside their designated context 1008 MUST be ignored. 1010 Unless specified otherwise, TLVs encoding IP addresses or prefixes 1011 allow encoding both IPv6 and IPv4 addresses and prefixes. IPv6 1012 information is encoded as is, whereas for IPv4 IPv4-mapped IPv6 1013 addresses format [RFC4291] is used and prefix lengths are encoded as 1014 original IPv4 prefix length increased by 96. 1016 10.1. HNCP Version TLV 1018 0 1 2 3 1019 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 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Type: HNCP-VERSION (32) | Length: >= 5 | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Version | Reserved | M | P | H | L | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | User-agent | 1027 This TLV is used to indicate the supported version and router 1028 capabilities of an HNCP node as described in Section 4. 1030 Version: Indicates which version of HNCP is currently in use by this 1031 particular node. It MUST be set to 1. Nodes with different 1032 versions are considered incompatible. 1034 Reserved: Bits are reserved for future use. They MUST be set to 1035 zero when creating this TLV, and their value MUST be ignored when 1036 processing the TLV. 1038 M-capability: Priority value used for electing the on-link MDNS 1039 [RFC6762] proxy. It MUST be set to some value between 1 and 7 1040 included (4 is the default) if the router is capable of proxying 1041 MDNS and 0 otherwise. The values 8-15 are reserved for future 1042 use. 1044 P-capability: Priority value used for electing the on-link DHCPv6-PD 1045 server. It MUST be set to some value between 1 and 7 included (4 1046 is the default) if the router is capable of providing prefixes 1047 through DHCPv6-PD (Section 6.3.4) and 0 otherwise. The values 1048 8-15 are reserved for future use. 1050 H-capability: Priority value used for electing the on-link DHCPv6 1051 server offering non-temporary addresses. It MUST be set to some 1052 value between 1 and 7 included (4 is the default) if the router is 1053 capable of providing such addresses and 0 otherwise. The values 1054 8-15 are reserved for future use. 1056 L-capability: Priority value used for electing the on-link DHCPv4 1057 server. It MUST be set to some value between 1 and 7 included (4 1058 is the default) if the router is capable of running a legacy 1059 DHCPv4 server offering IPv4 addresses to clients and 0 otherwise. 1060 The values 8-15 are reserved for future use. 1062 User-Agent: The user-agent is a human-readable UTF-8 string that 1063 describes the name and version of the current HNCP implementation. 1065 10.2. External Connection TLV 1067 0 1 2 3 1068 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 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Type: EXTERNAL-CONNECTION (33)| Length | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | Nested TLVs | 1074 An External Connection TLV is a container TLV used to gather network 1075 configuration information associated with a single external 1076 connection (Section 6.2) to be shared across the HNCP network. A 1077 node MAY publish an arbitrary number of instances of this TLV to 1078 share the desired number of external connections. 1080 10.2.1. Delegated Prefix TLV 1081 0 1 2 3 1082 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 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | Type: DELEGATED-PREFIX (34) | Length: >= 9 | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | Valid Lifetime Since Origination | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | Preferred Lifetime Since Origination | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 | Prefix Length | | 1091 +-+-+-+-+-+-+-+-+ Prefix [+ nested TLVs] + 1092 | | 1094 The Delegated Prefix TLV is used by HNCP routers to advertise 1095 prefixes which are allocated to the whole network and can be used for 1096 prefix assignment. Delegated Prefix TLVs are only valid inside 1097 External Connection TLVs and their prefixes MUST NOT overlap with 1098 those of other such TLVs in the same container. 1100 Valid Lifetime Since Origination: The time in seconds the delegated 1101 prefix was valid for at the origination time of the node data 1102 containing this TLV. The value MUST be updated whenever the node 1103 republishes its Node State TLV. 1105 Preferred Lifetime Since Origination: The time in seconds the 1106 delegated prefix was preferred for at the origination time of the 1107 node data containing this TLV. The value MUST be updated whenever 1108 the node republishes its Node State TLV. 1110 Prefix Length: The number of significant bits in the Prefix. 1112 Prefix: Significant bits of the prefix padded with zeroes up to the 1113 next byte boundary. 1115 Nested TLVs: Other TLVs included in the Delegated Prefix TLV 1116 starting at the next 32-bit boundary following the end of the 1117 encoded prefix. 1119 10.2.1.1. Prefix Policy TLV 1121 0 1 2 3 1122 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 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Type: PREFIX-POLICY (43) | Length: >= 1 | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Policy Type | | 1127 +-+-+-+-+-+-+-+-+ Value + 1128 | | 1129 The Prefix Policy TLV contains information about the policy or 1130 applicability of a delegated prefix. This information can be used to 1131 determine whether prefixes for a certain usecase (e.g., local 1132 reachability, internet connectivity) do exist or should be acquired 1133 and to make decisions about assigning prefixes to certain links or to 1134 fine-tune border firewalls. See Section 6.2 for a more in-depth 1135 discussion. This TLV is only valid inside a Delegated Prefix TLV. 1137 Policy Type: The type of the policy identifier. 1139 0 : Internet connectivity (no Value). 1141 1-128 : Explicit destination prefix with the Policy Type being 1142 the actual length of the prefix (Value contains significant 1143 bits of the destination prefix padded with zeroes up to the 1144 next byte boundary). 1146 129 : DNS Zone (Value contains an RFC 1035 [RFC1035] encoded 1147 DNS label sequence). 1149 130 : Opaque UTF-8 string (e.g., for administrative purposes). 1151 131 : Restrictive Assignment (no Value). 1153 132-255: Reserved for future additions. 1155 Value: A variable length identifier of the given type. 1157 10.2.2. DHCPv6 Data TLV 1159 0 1 2 3 1160 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 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Type: DHCPV6-DATA (37) | Length: > 0 | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | DHCPv6 option stream | 1166 This TLV is used to encode auxiliary IPv6 configuration information 1167 (e.g., recursive DNS servers) encoded as a stream of DHCPv6 options. 1168 It is only valid in an External Connection TLV or a Delegated Prefix 1169 TLV encoding an IPv6 prefix and MUST NOT occur more than once in any 1170 single container. When included in an External Connection TLV, it 1171 contains DHCPv6 options relevant to the External Connection as a 1172 whole. When included in a Delegated Prefix, it contains options 1173 mandatory to handle said prefix. 1175 DHCPv6 option stream: DHCPv6 options encoded as specified in 1176 [RFC3315]. 1178 10.2.3. DHCPv4 Data TLV 1180 0 1 2 3 1181 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 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Type: DHCPV4-DATA (38) | Length: > 0 | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | DHCPv4 option stream | 1187 This TLV is used to encode auxiliary IPv4 configuration information 1188 (e.g., recursive DNS servers) encoded as a stream of DHCPv4 options. 1189 It is only valid in an External Connection TLV and MUST NOT occur 1190 more than once in any single container. It contains DHCPv4 options 1191 relevant to the External Connection as a whole. 1193 DHCPv4 option stream: DHCPv4 options encoded as specified in 1194 [RFC2131]. 1196 10.3. Assigned Prefix TLV 1198 0 1 2 3 1199 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 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Type: ASSIGNED-PREFIX (35) | Length: >= 6 | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Endpoint Identifier | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | Rsv. | Prty. | Prefix Length | | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix + 1207 | | 1209 This TLV is used to announce Published Assigned Prefixes for the 1210 purposes of prefix assignment (Section 6.3). 1212 Endpoint Identifier: The endpoint identifier of the local interface 1213 the prefix is assigned to, or 0 if it is assigned to a Private 1214 Link (e.g., when the prefix is assigned for downstream prefix 1215 delegation). 1217 Rsv.: Bits are reserved for future use. They MUST be set to zero 1218 when creating this TLV, and their value MUST be ignored when 1219 processing the TLV. 1221 Prty: The Advertised Prefix Priority from 0 to 15. 1223 0-1 : Low priorities. 1225 2 : Default priority. 1227 3-7 : High priorities. 1229 8-11 : Administrative priorities. MUST NOT be used unless 1230 configured otherwise. 1232 12-14: Reserved for future use. 1234 15 : Provider priorities. MAY only be used by the router 1235 advertising the corresponding delegated prefix and based on 1236 static or dynamic configuration (e.g., for excluding a prefix 1237 based on DHCPv6-PD Prefix Exclude Option [RFC6603]). 1239 Prefix Length: The number of significant bits in the Prefix field. 1241 Prefix: The significant bits of the prefix padded with zeroes up to 1242 the next byte boundary. 1244 10.4. Node Address TLV 1246 0 1 2 3 1247 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 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Type: NODE-ADDRESS (36) | Length: 20 | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | Endpoint Identifier | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | | 1254 | IP Address | 1255 | | 1256 | | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 This TLV is used to announce addresses assigned to an HNCP node as 1260 described in Section 6.4. 1262 Endpoint Identifier: The endpoint identifier of the local interface 1263 the prefix is assigned to, or 0 if it is not assigned on an HNCP 1264 enabled link. 1266 IP Address: The globally scoped IPv6 address, or the IPv4 address 1267 encoded as an IPv4-mapped IPv6 address [RFC4291]. 1269 10.5. DNS Delegated Zone TLV 1270 0 1 2 3 1271 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 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Type: DNS-DELEGATED-ZONE (39) | Length: >= 17 | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | | 1276 | IP Address | 1277 | | 1278 | | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 |Reserved |L|B|S| | 1281 +-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) | 1282 | | 1284 This TLV is used to announce a forward or reverse DNS zone delegation 1285 in the HNCP network. Its meaning is roughly equivalent to specifying 1286 an NS and A/AAAA record for said zone. Details are specified in 1287 Section 8. 1289 IP Address : The IPv6 address of the authoritative DNS server for 1290 the zone; IPv4 addresses are represented as IPv4-mapped addresses 1291 [RFC4291]. The special value of :: (all-zero) means the 1292 delegation is available in the global DNS-hierarchy. 1294 Reserved : Those bits MUST be set to zero when creating the TLV and 1295 ignored when parsing it unless defined in a later specification. 1297 L-bit : DNS-SD [RFC6763] Legacy-Browse, indicates that this 1298 delegated zone should be included in the network's DNS-SD legacy 1299 browse list of domains at lb._dns- sd._udp.(DOMAIN-NAME). Local 1300 forward zones SHOULD have this bit set, reverse zones SHOULD NOT. 1302 B-bit : (DNS-SD [RFC6763] Browse) indicates that this delegated zone 1303 should be included in the network's DNS-SD browse list of domains 1304 at b._dns-sd._udp. (DOMAIN-NAME). Local forward zones SHOULD 1305 have this bit set, reverse zones SHOULD NOT. 1307 S-bit : (fully-qualified DNS-SD [RFC6763] domain) indicates that 1308 this delegated zone consists of a fully-qualified DNS-SD domain, 1309 which should be used as base for DNS-SD domain enumeration, i.e., 1310 _dns-sd._udp.(Zone) exists. Forward zones MAY have this bit set, 1311 reverse zones MUST NOT. This can be used to provision DNS search 1312 path to hosts for non-local services (such as those provided by an 1313 ISP, or other manually configured service providers). Zones with 1314 this flag SHOULD be added to the search domains advertised to 1315 clients. 1317 Zone : The label sequence of the zone, encoded as the domain names 1318 are encoded DNS messages as specified in [RFC1035]. The last 1319 label in the zone MUST be empty. 1321 10.6. Domain Name TLV 1323 0 1 2 3 1324 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 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Type: DOMAIN-NAME (40) | Length: > 0 | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | Domain (DNS label sequence - variable length) | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 This TLV is used to indicate the base domain name for the network as 1332 specified in Section 8. This TLV MUST NOT be announced unless the 1333 domain name was explicitly configured by an administrator. 1335 Domain: The label sequence encoded according to [RFC1035]. 1336 Compression MUST NOT be used. The zone MUST end with an empty 1337 label. 1339 10.7. Node Name TLV 1341 0 1 2 3 1342 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 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | Type: NODE-NAME (41) | Length: > 16 | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | | 1347 | IP Address | 1348 | | 1349 | | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Name (not null-terminated - variable length) | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 This TLV is used to assign the name of a node in the network to a 1355 certain IP address as specified in Section 8. 1357 IP Address: The IP address associated with the name. IPv4 1358 addresses are encoded using IPv4-mapped IPv6 addresses. 1360 Name: The name of the node as a single DNS label (up to 63 1361 characters, no leading length byte). 1363 10.8. Managed PSK TLV 1365 0 1 2 3 1366 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 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | Type: MANAGED-PSK (42) | Length: 32 | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | | 1371 | | 1372 | | 1373 | Random 256-bit PSK | 1374 | | 1375 | | 1376 | | 1377 | | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 This TLV is used to announce a PSK for securing third-party protocols 1381 exclusively supporting symmetric cryptography as specified in 1382 Section 9. 1384 11. General Requirements for HNCP Nodes 1386 Each node implementing HNCP is subject to the following requirements: 1388 o It MUST implement HNCP-Versioning (Section 4) and Interface 1389 Classification (Section 5). 1391 o It MUST implement and run the method for securing third-party 1392 protocols (Section 9) whenever it uses the security mechanism of 1393 HNCP. 1395 If the node is acting as a router, then the following requirements 1396 apply in addition: 1398 o It MUST support Autonomous Address Configuration (Section 6) and 1399 Configuration of Hosts and non-HNCP Routers (Section 7). 1401 o It SHOULD implement support for the Service Discovery and Naming 1402 (Section 8) as defined in this document. 1404 o It MAY be able to provide connectivity to IPv4-devices using 1405 DHCPv4. 1407 o It SHOULD be able to delegate prefixes to legacy IPv6 routers 1408 using DHCPv6-PD (Section 6.3.4). 1410 o In addition, normative language of Basic Requirements for IPv6 1411 Customer Edge Routers [RFC7084] applies with the following 1412 adjustments: 1414 * The generic requirements G-4 and G-5 are relaxed such that any 1415 known default router on any interface is sufficient for a 1416 router to announce itself as default router, similarly only the 1417 loss of all such default routers results in self-invalidation. 1419 * The section "WAN-Side Configuration" applies to interfaces 1420 classified as external. 1422 * If the CE sends a size-hint as indicated in WPD-2, the hint 1423 MUST NOT be determined by the number of LAN-interfaces of the 1424 CE, but SHOULD instead be large enough to at least accommodate 1425 prefix assignments announced for existing delegated or ULA- 1426 prefixes, if such prefixes exist and unless explicitly 1427 configured otherwise. 1429 * The dropping of packets with a destination address belonging to 1430 a delegated prefix mandated in WPD-5 MUST NOT be applied to 1431 destinations that are part of any prefix announced using an 1432 Assigned Prefix TLV by any HNCP router in the network. 1434 * The section "LAN-Side Configuration" applies to interfaces not 1435 classified as external. 1437 * The requirement L-2 to assign a separate /64 to each LAN 1438 interface is replaced by the participation in the prefix 1439 assignment mechanism (Section 6.3) for each such interface. 1441 * The requirement L-9 is modified, in that the M flag MUST be set 1442 if and only if a router connected to the respective Common Link 1443 is advertising a non-zero H-capability. 1445 * The requirement L-12 to make DHCPv6 options available is 1446 adapted, in that a CER SHOULD publish the subset of options 1447 using the DHCPv6 Data TLV in an External Connection TLV. 1448 Similarly it SHOULD do the same for DHCPv4 options in a DHCPv4 1449 Data TLV. DHCPv6 options received inside an OPTION_IAPREFIX 1450 [RFC3633] MUST be published using a DHCPv6 Data TLV inside the 1451 respective Delegated Prefix TLV. HNCP routers SHOULD make 1452 relevant DHCPv6 and DHCPv4 options available to clients, i.e., 1453 options contained in External Connection TLVs that also include 1454 delegated prefixes from which a subset is assigned to the 1455 respective link. 1457 * The requirement L-13 to deprecate prefixes is applied to all 1458 delegated prefixes in the network from which assignments have 1459 been made on the respective interface. Furthermore the Prefix 1460 Information Options indicating deprecation MUST be included in 1461 Router Advertisements for the remainder of the prefixes' 1462 respective valid lifetime, but MAY be omitted after at least 2 1463 hours have passed. 1465 12. Security Considerations 1467 HNCP enables self-configuring networks, requiring as little user 1468 intervention as possible. However this zero-configuration goal 1469 usually conflicts with security goals and introduces a number of 1470 threats. 1472 General security issues for existing home networks are discussed in 1473 [RFC7368]. The protocols used to set up addresses and routes in such 1474 networks to this day rarely have security enabled within the 1475 configuration protocol itself. However these issues are out of scope 1476 for the security of HNCP itself. 1478 HNCP is a DNCP-based state synchronization mechanism carrying 1479 information with varying threat potential. For this consideration 1480 the payloads defined in DNCP and this document are reviewed: 1482 o Network topology information such as HNCP nodes and their common 1483 links. 1485 o Address assignment information such as delegated and assigned 1486 prefixes for individual links. 1488 o Naming and service discovery information such as auto-generated or 1489 customized names for individual links and nodes. 1491 12.1. Interface Classification 1493 As described in Section 5.3, an HNCP node determines the internal or 1494 external state on a per-interface basis. A firewall perimeter is set 1495 up for the external interfaces, and for internal interfaces, HNCP 1496 traffic is allowed, with the exception of leaf and guest sub- 1497 categories. 1499 Threats concerning automatic interface classification cannot be 1500 mitigated by encrypting or authenticating HNCP traffic itself since 1501 external routers do not participate in the protocol and often cannot 1502 be authenticated by other means. These threats include propagation 1503 of forged uplinks in the homenet in order to, e.g., redirect traffic 1504 destined to external locations and forged internal status by external 1505 routers to, e.g., circumvent the perimeter firewall. 1507 It is therefore imperative to either secure individual links on the 1508 physical or link-layer or preconfigure the adjacent interfaces of 1509 HNCP routers to an appropriate fixed category in order to secure the 1510 homenet border. Depending on the security of the external link 1511 eavesdropping, man-in-the-middle and similar attacks on external 1512 traffic can still happen between a homenet border router and the ISP, 1513 however these cannot be mitigated from inside the homenet. For 1514 example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4 1515 messages, but this is very rarely implemented in large or small 1516 networks. Further, while PPP can provide secure authentication of 1517 both sides of a point to point link, it is most often deployed with 1518 one-way authentication of the subscriber to the ISP, not the ISP to 1519 the subscriber. 1521 12.2. Security of Unicast Traffic 1523 Once the homenet border has been established there are several ways 1524 to secure HNCP against internal threats like manipulation or 1525 eavesdropping by compromised devices on a link which is enabled for 1526 HNCP traffic. If left unsecured, attackers may perform arbitrary 1527 eavesdropping, spoofing or denial of service attacks on HNCP services 1528 such as address assignment or service discovery. 1530 Detailed interface categories like "leaf" or "guest" can be used to 1531 integrate not fully trusted devices to various degrees into the 1532 homenet by not exposing them to HNCP traffic or by using firewall 1533 rules to prevent them from reaching homenet-internal resources. 1535 On links where this is not practical and lower layers do not provide 1536 adequate protection from attackers, DNCP secure mode MUST be used to 1537 secure traffic. 1539 12.3. Other Protocols in the Home 1541 IGPs and other protocols are usually run alongside HNCP therefore the 1542 individual security aspects of the respective protocols must be 1543 considered. It can however be summarized that many protocols to be 1544 run in the home (like IGPs) provide - to a certain extent - similar 1545 security mechanisms. Most of these protocols do not support 1546 encryption and only support authentication based on pre-shared keys 1547 natively. This influences the effectiveness of any encryption-based 1548 security mechanism deployed by HNCP as homenet routing information is 1549 thus usually not encrypted. 1551 13. IANA Considerations 1553 IANA should set up a registry for the (decimal values within range 1554 0-1023) "HNCP DNCP-profile TLV Types" under "Distributed Node 1555 Consensus Protocol (DNCP)", with the following initial contents: [TO 1556 BE REMOVED BY RFC-EDITOR: Ideally as http://www.iana.org/assignments/ 1557 hncp-registry] 1559 0-31: Reserved - specified in the DNCP registry 1561 32: HNCP-Version 1563 33: External-Connection 1565 34: Delegated-Prefix 1567 35: Assigned-Prefix 1569 36: Node-Address 1571 37: DHCPv4-Data 1573 38: DHCPv6-Data 1575 39: DNS-Delegated-Zone 1577 40: Domain-Name 1579 41: Node-Name 1581 42: Managed-PSK 1583 43: Prefix-Policy 1585 44-512: Free - policy of 'standards action' should be used. 1587 512-767: Reserved - specified in the DNCP registry 1589 768-1023: Reserved - to be used for per-implementation 1590 experimentation. How collision is avoided is out of scope of this 1591 document. 1593 HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP- 1594 DTLS-PORT, as well as an IPv6 link-local multicast address All- 1595 Homenet-Nodes. 1597 14. References 1599 14.1. Normative references 1601 [I-D.ietf-homenet-dncp] 1602 Stenberg, M. and S. Barth, "Distributed Node Consensus 1603 Protocol", draft-ietf-homenet-dncp-09 (work in progress), 1604 August 2015. 1606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1607 Requirement Levels", BCP 14, RFC 2119, March 1997. 1609 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1610 Security Version 1.2", RFC 6347, January 2012. 1612 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1613 "Prefix Exclude Option for DHCPv6-based Prefix 1614 Delegation", RFC 6603, May 2012. 1616 [I-D.ietf-homenet-prefix-assignment] 1617 Pfister, P., Paterson, B., and J. Arkko, "Distributed 1618 Prefix Assignment Algorithm", draft-ietf-homenet-prefix- 1619 assignment-07 (work in progress), June 2015. 1621 14.2. Informative references 1623 [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, 1624 A., Beser, B., and J. Privat, "The User Class Option for 1625 DHCP", RFC 3004, November 2000. 1627 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1628 Messages", RFC 3118, June 2001. 1630 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1631 2131, March 1997. 1633 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1634 and M. Carney, "Dynamic Host Configuration Protocol for 1635 IPv6 (DHCPv6)", RFC 3315, July 2003. 1637 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1638 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1639 December 2003. 1641 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1642 E. Lear, "Address Allocation for Private Internets", BCP 1643 5, RFC 1918, February 1996. 1645 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1646 Architecture", RFC 4291, February 2006. 1648 [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1649 "IPv6 Home Networking Architecture Principles", RFC 7368, 1650 October 2014. 1652 [RFC1035] Mockapetris, P., "Domain names - implementation and 1653 specification", STD 13, RFC 1035, November 1987. 1655 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1656 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 1658 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1659 April 1992. 1661 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1662 February 2013. 1664 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1665 Discovery", RFC 6763, February 2013. 1667 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1668 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1669 6241, June 2011. 1671 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1672 Extensions", RFC 2132, March 1997. 1674 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 1675 Static Route Option for Dynamic Host Configuration 1676 Protocol (DHCP) version 4", RFC 3442, December 2002. 1678 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1679 Addresses", RFC 4193, October 2005. 1681 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1682 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1683 November 2013. 1685 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1686 Interface Identifiers with IPv6 Stateless Address 1687 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 1689 14.3. URIs 1691 [3] http://www.openwrt.org 1693 [4] http://www.homewrt.org/doku.php?id=run-conf 1695 Appendix A. Changelog [RFC Editor: please remove] 1697 draft-ietf-homenet-hncp-08: Editorial reorganization. 1699 draft-ietf-homenet-hncp-07: Using version 1 instead of version 0, as 1700 existing implementations already use it. 1702 draft-ietf-homenet-hncp-06: Various edits based on feedback, 1703 hopefully without functional delta. 1705 draft-ietf-homenet-hncp-05: Renamed "Adjacent Link" to "Common Link". 1706 Changed single IPv4 uplink election from MUST to MAY. Added explicit 1707 indication to distinguish (IPv4)-PDs for local connectivity and ones 1708 with uplink connectivity allowing, e.g., better local-only 1709 IPv4-connectivity. 1711 draft-ietf-homenet-hncp-04: Change the responsibility for sending RAs 1712 to the router assigning the prefix. 1714 draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP 1715 (homenet profile). 1717 draft-ietf-homenet-hncp-02: Removed any built-in security. Relying 1718 on IPsec. Reorganized interface categories, added requirements 1719 languages, made manual border configuration a MUST-support. 1720 Redesigned routing protocol election to consider non-router devices. 1722 draft-ietf-homenet-hncp-01: Added (MAY) guest, ad-hoc, hybrid 1723 categories for interfaces. Removed old hnetv2 reference, and now 1724 pointing just to OpenWrt + github. Fixed synchronization algorithm 1725 to spread also same update number, but different data hash case. 1726 Made purge step require bidirectional connectivity between nodes when 1727 traversing the graph. Edited few other things to be hopefully 1728 slightly clearer without changing their meaning. 1730 draft-ietf-homenet-hncp-00: Added version TLV to allow for TLV 1731 content changes pre-RFC without changing IDs. Added link id to 1732 assigned address TLV. 1734 Appendix B. Draft source [RFC Editor: please remove] 1736 This draft is available at https://github.com/fingon/ietf-drafts/ in 1737 source format. Issues and pull requests are welcome. 1739 Appendix C. Implementation [RFC Editor: please remove] 1741 A GPLv2-licensed implementation of HNCP is currently under 1742 development at https://github.com/sbyx/hnetd/ and binaries are 1743 available in the OpenWrt [3] package repositories. See [4] for more 1744 information. Feedback and contributions are welcome. 1746 Appendix D. Acknowledgements 1748 Thanks to Ole Troan, Mark Baugher, Mark Townsley, Juliusz Chroboczek 1749 and Thomas Clausen for their contributions to the draft. 1751 Thanks to Eric Kline for the original border discovery work. 1753 Authors' Addresses 1755 Markus Stenberg 1756 Independent 1757 Helsinki 00930 1758 Finland 1760 Email: markus.stenberg@iki.fi 1762 Steven Barth 1763 Independent 1764 Halle 06114 1765 Germany 1767 Email: cyrus@openwrt.org 1769 Pierre Pfister 1770 Cisco Systems 1771 Paris 1772 France 1774 Email: pierre.pfister@darou.fr