idnits 2.17.1 draft-ietf-homenet-hncp-06.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 (June 17, 2015) is 3230 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 1414 -- Looks like a reference, but probably isn't: '4' on line 1414 == Outdated reference: A later version (-12) exists of draft-ietf-homenet-dncp-05 ** 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 4 Intended status: Standards Track S. Barth 5 Expires: December 19, 2015 6 P. Pfister 7 Cisco Systems 8 June 17, 2015 10 Home Networking Control Protocol 11 draft-ietf-homenet-hncp-06 13 Abstract 15 This document describes the Home Networking Control Protocol (HNCP), 16 an extensible configuration protocol and a set of requirements for 17 home network devices on top of the Distributed Node Consensus 18 Protocol (DNCP). It enables automated configuration of addresses, 19 naming, network borders and the seamless use of a routing protocol. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 19, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 57 3. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Common Links . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Border Discovery . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Autonomic Address Configuration . . . . . . . . . . . . . . . 7 61 6.1. External Connections . . . . . . . . . . . . . . . . . . 7 62 6.1.1. External Connection TLV . . . . . . . . . . . . . . . 7 63 6.1.2. Delegated Prefix TLV . . . . . . . . . . . . . . . . 8 64 6.1.3. Prefix Domain TLV . . . . . . . . . . . . . . . . . . 9 65 6.1.4. DHCP Data TLVs . . . . . . . . . . . . . . . . . . . 10 66 6.2. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 11 67 6.2.1. Prefix Assignment Algorithm Parameters . . . . . . . 11 68 6.2.2. Assigned Prefix TLV . . . . . . . . . . . . . . . . . 12 69 6.2.3. Making New Assignments . . . . . . . . . . . . . . . 13 70 6.2.4. Applying Assignments . . . . . . . . . . . . . . . . 14 71 6.2.5. DHCPv6-PD Excluded Prefix Support . . . . . . . . . . 14 72 6.2.6. Downstream Prefix Delegation Support . . . . . . . . 14 73 6.3. Node Address Assignment . . . . . . . . . . . . . . . . . 15 74 6.4. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 16 75 7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 17 76 7.1. DHCPv6 for Addressing or Configuration . . . . . . . . . 17 77 7.2. Sending Router Advertisements . . . . . . . . . . . . . . 17 78 7.3. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 18 79 7.4. DHCPv4 for Addressing and Configuration . . . . . . . . . 18 80 7.5. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 19 81 8. Naming and Service Discovery . . . . . . . . . . . . . . . . 19 82 8.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 19 83 8.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 21 84 8.3. Node Name TLV . . . . . . . . . . . . . . . . . . . . . . 21 85 9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 22 86 10. HNCP Versioning and Capabilities . . . . . . . . . . . . . . 22 87 11. Requirements for HNCP Routers . . . . . . . . . . . . . . . . 24 88 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 89 12.1. Border Determination . . . . . . . . . . . . . . . . . . 25 90 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 26 91 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 26 92 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 93 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 94 14.1. Normative references . . . . . . . . . . . . . . . . . . 27 95 14.2. Informative references . . . . . . . . . . . . . . . . . 28 96 Appendix A. Changelog [RFC Editor: please remove] . . . . . . . 29 97 Appendix B. Draft source [RFC Editor: please remove] . . . . . . 30 98 Appendix C. Implementation [RFC Editor: please remove] . . . . . 30 99 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 30 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 102 1. Introduction 104 HNCP synchronizes state across a small site in order to allow 105 automated network configuration. The protocol enables use of border 106 discovery, address prefix distribution 107 [I-D.ietf-homenet-prefix-assignment], naming and other services 108 across multiple links. 110 HNCP provides enough information for a routing protocol to operate 111 without homenet-specific extensions. In homenet environments where 112 multiple IPv6 source-prefixes can be present, routing based on source 113 and destination address is necessary [RFC7368]. 115 2. Requirements language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 3. DNCP Profile 123 HNCP is defined as a profile of DNCP [I-D.ietf-homenet-dncp] with the 124 following parameters: 126 o HNCP uses UDP datagrams on port HNCP-UDP-PORT as a transport over 127 link-local scoped IPv6, using unicast and multicast (All-Homenet- 128 Routers is the HNCP group address). Received datagrams with an 129 IPv6 source or destination address which is not link-local scoped 130 MUST be ignored. Each node MUST be able to receive (and 131 potentially reassemble) UDP datagrams with a payload of at least 132 4000 bytes. 134 o HNCP operates on multicast-capable interfaces only. HNCP routers 135 MUST assign a unique 32-bit endpoint identifier to each interface 136 for which HNCP is enabled. The value zero is reserved for 137 internal purposes. Implementations MAY use a value equivalent to 138 the sin6_scope_id for the given interface. 140 o HNCP unicast traffic SHOULD be secured using DTLS [RFC6347] as 141 described in DNCP if exchanged over unsecured links. UDP on port 142 HNCP-DTLS-PORT is used for this purpose. A node implementing HNCP 143 security MUST support the DNCP Pre-Shared Key method, SHOULD 144 support the DNCP Certificate Based Trust Consensus and MAY support 145 the PKI-based trust method. 147 o HNCP uses opaque 32-bit node identifiers 148 (DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP 149 SHOULD generate and use a random node identifier. If using a 150 random node identifier and there is a node identifier collision, 151 the node MUST immediately generate and use a new random node 152 identifier which is not used by any other node. 154 o HNCP nodes MUST ignore all Node State TLVs received via multicast 155 on a link which has DNCP security enabled in order to prevent 156 spoofing of node state changes. 158 o HNCP nodes use the following Trickle parameters: 160 * k SHOULD be 1, as the timer reset when data is updated and 161 further retransmissions should handle packet loss. 163 * Imin SHOULD be 200 milliseconds but MUST NOT be lower. Note: 164 Earliest transmissions may occur at Imin / 2. 166 * Imax SHOULD be 7 doublings of Imin (i.e. 25.6 seconds) but MUST 167 NOT be lower. 169 o HNCP nodes MUST use the leading 64 bits of MD5 [RFC1321] as DNCP 170 non-cryptographic hash function H(x). 172 o HNCP nodes MUST use DNCP's keep-alive extension on all endpoints 173 with the following parameters: 175 * The default keep-alive interval (DNCP_KEEPALIVE_INTERVAL) is 20 176 seconds. 178 * The multiplier (DNCP_KEEPALIVE_MULTIPLIER) MUST be 2.1. 180 * The grace-interval (DNCP_GRACE_INTERVAL) SHOULD be equal to 181 DNCP_KEEPALIVE_MULTIPLIER times DNCP_KEEPALIVE_INTERVAL. 183 4. Common Links 185 HNCP uses the concept of Common Links for some of its applications. 186 The Common Link is computed separately for each local interface, and 187 it always contains the local interface. Additionally, if the local 188 interface is not in ad-hoc mode, it also contains the set of 189 interfaces that are bidirectionally reachable from the given local 190 interface, i.e. every remote interface of a remote node meeting all 191 of the following requirements: 193 o The local node publishes a Neighbor TLV with: 195 * Neighbor Node Identifier = remote node's node identifier 197 * Neighbor Endpoint Identifier = remote interface's endpoint 198 identifier 200 * Endpoint Identifier = local interface's endpoint identifier 202 o The remote node publishes a Neighbor TLV with: 204 * Neighbor Node Identifier = local node's node identifier 206 * Neighbor Endpoint Identifier = local interface's endpoint 207 identifier 209 * Endpoint Identifier = remote interface's endpoint identifier 211 A node MUST be able to detect whether two of its local interfaces are 212 connected, e.g. by detecting an identical remote interface being part 213 of the Common Links of both local interfaces. 215 5. Border Discovery 217 HNCP router's interfaces are either internal, external or of a 218 different category derived from the internal one. This section 219 defines the border discovery algorithm. It is suitable for both IPv4 220 and IPv6 (single or dual-stack) and determines whether an HNCP 221 interface is internal, external, or uses another fixed category. The 222 algorithm is derived from the edge router interactions described in 223 the Basic Requirements for IPv6 Customer Edge Routers [RFC7084]. 224 This algorithm MUST be implemented by any router implementing HNCP. 226 The border discovery auto-detection algorithm works as follows, with 227 evaluation stopping at first match: 229 1. If a fixed category is configured for the interface, it MUST be 230 used. 232 2. If a delegated prefix could be acquired by running a DHCPv6 233 client on the interface, it MUST be considered external. 235 3. If an IPv4 address could be acquired by running a DHCPv4 client 236 on the interface it MUST be considered external. 238 4. Otherwise the interface MUST be considered internal. 240 In order to avoid conflicts between border discovery and HNCP routers 241 running DHCPv4 [RFC2131] or DHCPv6-PD [RFC3633] servers, each router 242 MUST implement the following mechanism based on The User Class Option 243 for DHCPv4 [RFC3004] and its DHCPv6 counterpart [RFC3315]: 245 o An HNCP router running a DHCP client on an HNCP interface MUST 246 include a DHCP User-Class consisting of the ASCII-String 247 "HOMENET". 249 o An HNCP router running a DHCP server on an HNCP interface MUST 250 ignore or reject DHCP-Requests containing a DHCP User-Class 251 consisting of the ASCII-String "HOMENET". 253 A router MUST allow setting a category of either auto-detected, 254 internal or external for each interface which is suitable for both 255 internal and external connections. In addition the following 256 specializations of the internal category are defined to modify the 257 local router behavior: 259 Leaf category: This declares an interface used by client devices 260 only. Such an interface acts as an internal interface with the 261 exception that HNCP or routing protocol traffic MUST NOT be sent 262 on the interface, and all such traffic received on the interface 263 MUST be ignored. This category SHOULD be supported. 265 Guest category: This declares an interface used by untrusted client 266 devices only. In addition to the restrictions of the Leaf 267 category, HNCP routers MUST enable firewalling rules such that 268 connected devices are unable to reach other devices inside the 269 HNCP network or query services advertised by them unless 270 explicitly allowed. This category SHOULD be supported. 272 Ad-hoc category: This configures an interface to be ad-hoc 273 (Section 4). Ad-hoc interfaces are considered internal but no 274 assumption is made on the the link transitivity properties. 275 Support for this category is OPTIONAL. 277 Hybrid category: This declares an interface to be internal while 278 still running DHCPv4 and DHCPv6-PD clients on it. It is assumed 279 that the link is under control of a legacy, trustworthy non-HNCP 280 router, still within the same network. Detection of this category 281 automatically in addition to manual configuration is out of scope 282 of this document. Support for this category is OPTIONAL. 284 Each router MUST continuously scan each active interface that does 285 not have a fixed category in order to dynamically reclassify it if 286 necessary. The router therefore runs an appropriately configured 287 DHCPv4 and DHCPv6 client as long as the interface is active including 288 states where it considers the interface to be internal. The router 289 SHOULD wait for a reasonable time period (5 seconds as a default), 290 during which the DHCP clients can acquire a lease, before treating a 291 newly activated or previously external interface as internal. Once 292 it treats a certain interface as internal it MUST start forwarding 293 traffic with appropriate source addresses between its internal 294 interfaces and allow internal traffic to reach external networks 295 according to the routes it publishes. Once a router detects an 296 interface transitioning to external it MUST stop any previously 297 enabled internal forwarding. In addition it SHOULD announce the 298 acquired information for use in the network as described in later 299 sections of this draft if the interface appears to be connected to an 300 external network. 302 6. Autonomic Address Configuration 304 This section specifies how HNCP routers configure host and router 305 addresses. At first border routers share information obtained from 306 service providers or local configuration by publishing one or more 307 External Connection TLVs. These contain other TLVs such as Delegated 308 Prefix TLVs which are then used for prefix assignment. Finally, HNCP 309 routers obtain addresses using a stateless (SLAAC-like) procedure or 310 a specific stateful mechanism and hosts and legacy routers are 311 configured using SLAAC or DHCP. 313 In all TLVs specified in this section which include a prefix, IPv4 314 prefixes are encoded using the IPv4-mapped IPv6 addresses format 315 [RFC4291]. The prefix length of such IPv4 prefix is set to 96 plus 316 the IPv4 prefix length. 318 6.1. External Connections 320 Each HNCP router MAY obtain external connection information from one 321 or more sources, e.g., DHCPv6-PD [RFC3633], NETCONF [RFC6241] or 322 static configuration. This section specifies how such information is 323 encoded and advertised. 325 6.1.1. External Connection TLV 327 An External Connection TLV is a container-TLV used to gather network 328 configuration information associated with a single external 329 connection. A node MAY publish an arbitrary number of instances of 330 this TLV. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Type: EXTERNAL-CONNECTION (33)| Length | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Nested TLVs | 339 The External Connection TLV is a container which: 341 o MAY contain an arbitrary number of Delegated Prefix TLVs. 343 o MUST NOT contain multiple Delegated Prefix TLVs with identical or 344 overlapping prefixes. In such a situation, the External 345 Connection TLV MUST be ignored. 347 o MAY contain at most one DHCPv6 Data TLV and at most one DHCPv4 348 Data TLV encoding options associated with the External Connection 349 but MUST NOT contain more than one of each otherwise the External 350 Connection TLV MUST be ignored. 352 o MAY contain other TLVs for future use. Such additional TLVs MUST 353 be ignored. 355 6.1.2. Delegated Prefix TLV 357 The Delegated Prefix TLV is used by HNCP routers to advertise 358 prefixes which are allocated to the whole network and will be used 359 for prefix assignment. Any Delegated Prefix TLV MUST be nested in an 360 External Connection TLV. 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Type: DELEGATED-PREFIX (34) | Length: >= 9 | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Valid Lifetime | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Preferred Lifetime | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Prefix Length | | 372 +-+-+-+-+-+-+-+-+ Prefix [+ nested TLVs] + 373 | | 375 Valid Lifetime: The time in seconds the delegated prefix is valid. 376 The value is relative to the point in time the Node-Data TLV was 377 last published. It MUST be updated whenever the node republishes 378 its Node-Data TLV. 380 Preferred Lifetime: The time in seconds the delegated prefix is 381 preferred. The value is relative to the point in time the Node- 382 Data TLV was last published. It MUST be updated whenever the node 383 republishes its Node-Data TLV. 385 Prefix Length: The number of significant bits in the Prefix. 387 Prefix: Significant bits of the prefix padded with zeroes up to the 388 next byte boundary. 390 Nested TLVs: Other TLVs included in the Delegated Prefix TLV and 391 starting at the next 32-bit boundary following the end of the 392 encoded prefix: 394 * Zero or more Prefix Domain TLVs. In absence of any such TLV 395 the prefix is assumed to be generated by an HNCP-router and for 396 internal use only. 398 * If the encoded prefix represents an IPv6 prefix, at most one 399 DHCPv6 Data TLV MAY be included, and any included DHCPv4 Data 400 TLV MUST be ignored. 402 * If the prefix represents an IPv4 prefix (encoded as an 403 IPv4-mapped IPv6 prefix), at most one DHCPv4 Data TLV MAY be 404 included, and any included DHCPv6 Data TLV MUST be ignored. 406 * It MAY contain other TLVs for future use. Such additional TLVs 407 MUST be ignored. 409 6.1.3. Prefix Domain TLV 411 The Prefix Domain TLV contains information about the origin and 412 applicability of a delegated prefix. This information can be used to 413 determine whether prefixes for a certain domain (e.g. local 414 reachability, internet connectivity) do exist or should be acquired 415 and to make decisions about assigning prefixes to certain links or to 416 fine-tune border firewalls. 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Type: PREFIX-DOMAIN (43) | Length: >= 1 | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Domain Type | | 424 +-+-+-+-+-+-+-+-+ Domain ID + 425 | | 427 Domain Type: The type of the domain identifier. 429 0 : Internet connectivity (domain ID is empty). 431 1-128 : Explicit destination prefix with the Domain Type being 432 the actual length of the prefix (Domain ID contains significant 433 bits of the destination prefix padded with zeroes up to the 434 next byte boundary). 436 129 : UTF-8 String (e.g. FQDN). 438 130-255: Reserved for future additions. 440 Domain Identifier: A variable length identifier of the given type. 442 6.1.4. DHCP Data TLVs 444 Auxiliary connectivity information is encoded as a stream of DHCP 445 options. Such TLVs MUST only be present in an External Connection 446 TLV or a Delegated Prefix TLV. When included in an External 447 Connection TLV, they MUST contain DHCP options which are relevant to 448 the whole External Connection. When included in a Delegated Prefix, 449 they MUST contain DHCP options which are specific to the Delegated 450 Prefix. 452 The DHCPv6 Data TLV uses the following format: 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Type: DHCPV6-DATA (37) | Length: > 0 | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | DHCPv6 option stream | 461 DHCPv6 option stream: DHCPv6 options encoded as specified in 462 [RFC3315]. 464 The DHCPv4 Data TLV uses the following format: 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Type: DHCPV4-DATA (38) | Length: > 0 | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | DHCPv4 option stream | 473 DHCPv4 option stream: DHCPv4 options encoded as specified in 474 [RFC2131]. 476 6.2. Prefix Assignment 478 HNCP uses the Distributed Prefix Assignment Algorithm specified in 479 [I-D.ietf-homenet-prefix-assignment] in order to assign prefixes to 480 HNCP internal links and uses the terminology defined there. 482 6.2.1. Prefix Assignment Algorithm Parameters 484 All HNCP nodes running the prefix assignment algorithm MUST use the 485 following parameters: 487 Node IDs: HNCP node identifiers are used. The comparison operation 488 is defined as bit-wise comparison. 490 Set of Delegated Prefixes: The set of prefixes encoded in Delegated 491 Prefix TLVs which are not strictly included in prefixes encoded in 492 other Delegated Prefix TLVs. Note that Delegated Prefix TLVs 493 included in ignored External Connection TLVs are not considered. 494 It is dynamically updated as Delegated Prefix TLVs are added or 495 removed. 497 Set of Shared Links: The set of Common Links associated with 498 internal, leaf, guest or ad-hoc interfaces. It is dynamically 499 updated as HNCP interfaces are added, removed, or switch from one 500 category to another. When multiple interfaces are detected as 501 belonging to the same Common Link, prefix assignment is disabled 502 on all of these interfaces except one. 504 Set of Private Links: This document defines Private Links 505 representing DHCPv6-PD clients or as a mean to advertise prefixes 506 included in the DHCPv6 Exclude Prefix option. Other 507 implementation-specific Private Links may be defined whenever a 508 prefix needs to be assigned for a purpose that does not require a 509 consensus with other HNCP routers. 511 Set of Advertised Prefixes: The set of prefixes included in 512 Assigned Prefix TLVs advertised by other HNCP routers (Prefixes 513 advertised by the local node are not in this set). The associated 514 Advertised Prefix Priority is the priority specified in the TLV. 515 The associated Shared Link is determined as follows: 517 * If the Link Identifier is zero, the Advertised Prefix is not 518 assigned on a Shared Link. 520 * If the other node's interface identified by the Link Identifier 521 is included in one of the Common Links used for prefix 522 assignment, it is considered as assigned on the given Common 523 Link. 525 * Otherwise, the Advertised Prefix is not assigned on a Shared 526 Link. 528 Advertised Prefixes as well as their associated priorities and 529 associated Shared Links MUST be updated as Assigned Prefix TLVs 530 are added, updated or removed, and as Common Links are modified. 532 ADOPT_MAX_DELAY: The default value is 0 seconds (i.e. prefix 533 adoption MAY be done instantly). 535 BACKOFF_MAX_DELAY: The default value is 4 seconds. 537 RANDOM_SET_SIZE: The default value is 64. 539 Flooding Delay: The default value is 5 seconds. 541 Default Advertised Prefix Priority: When a new assignment is 542 created or an assignment is adopted - as specified in the prefix 543 assignment algorithm routine - the default Advertised Prefix 544 Priority to be used is 2. 546 6.2.2. Assigned Prefix TLV 548 Published Assigned Prefixes MUST be advertised using the Assigned 549 Prefix TLV: 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Type: ASSIGNED-PREFIX (35) | Length: >= 6 | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Endpoint Identifier | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Rsv. | Prty. | Prefix Length | | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix + 560 | | 562 Endpoint Identifier: The endpoint identifier of the local interface 563 that belongs to the Common Link the prefix is assigned to, or 0 if 564 the Common Link is a Private Link (e.g., when the prefix is 565 assigned for downstream prefix delegation). 567 Rsv.: Bits are reserved for future use. They MUST be set to zero 568 when creating this TLV, and their value MUST be ignored when 569 processing the TLV. 571 Prty: The Advertised Prefix Priority from 0 to 15. 573 0-1 : Low priorities. 575 2 : Default priority. 577 3-7 : High priorities. 579 8-11 : Administrative priorities. MUST NOT be used unless 580 configured otherwise. 582 12-14: Reserved for future use. 584 15 : Provider priorities. MAY only be used by the router 585 advertising the corresponding delegated prefix and based on 586 static or dynamic configuration (e.g., for excluding a prefix 587 based on DHCPv6-PD Prefix Exclude Option [RFC6603]). 589 Prefix Length: The number of significant bits in the Prefix field. 591 Prefix: The significant bits of the prefix padded with zeroes up to 592 the next byte boundary. 594 6.2.3. Making New Assignments 596 Whenever the Prefix Assignment Algorithm subroutine is run on a 597 Common Link and whenever a new prefix may be assigned (case 1 of the 598 subroutine), the decision of whether the assignment of a new prefix 599 is desired MUST follow these rules: 601 If the Delegated Prefix TLV contains a DHCPv4 or DHCPv6 Data TLV, 602 and the meaning of one of the DHCP options is not understood by 603 the HNCP router, the creation of a new prefix is not desired. 605 If the remaining preferred lifetime of the prefix is 0 and there 606 is another delegated prefix of the same IP version used for prefix 607 assignment with a non-null preferred lifetime, the creation of a 608 new prefix is not desired. 610 Otherwise, the creation of a new prefix is desired. 612 If the considered delegated prefix is an IPv6 prefix, and whenever 613 there is at least one available prefix of length 64, a prefix of 614 length 64 MUST be selected unless configured otherwise by an 615 administrator. In case no prefix of length 64 would be available, a 616 longer prefix MAY be selected. 618 If the considered delegated prefix is an IPv4 prefix (Section 6.4 619 details how IPv4 delegated prefixes are generated), a prefix of 620 length 24 SHOULD be preferred. 622 In any case, a router MUST support a mechanism suitable to distribute 623 addresses from the considered prefix to clients on the link. 624 Otherwise it MUST NOT create or adopt it, i.e. a router assigning an 625 IPv4 prefix MUST support the L-capability and a router assigning an 626 IPv6 prefix not suitable for Stateless Address Autoconfiguration MUST 627 support the H-capability as defined in Section 10. 629 6.2.4. Applying Assignments 631 The prefix assignment algorithm indicates when a prefix is applied to 632 the respective Common Link. When that happens each router connected 633 to said link: 635 MUST create an appropriate on-link route for said prefix and 636 advertise it using the chosen routing protocol. 638 MUST participate in the client configuration election as described 639 in Section 7. 641 MAY add an address from said prefix to the respective network 642 interface as described in Section 6.3. 644 6.2.5. DHCPv6-PD Excluded Prefix Support 646 Whenever a DHCPv6 Prefix Exclude option [RFC6603] is received with a 647 delegated prefix, the excluded prefix MUST be advertised as assigned 648 to a Private Link with the maximum priority (i.e. 15). 650 The same procedure MAY be applied in order to exclude prefixes 651 obtained by other means of configuration. 653 6.2.6. Downstream Prefix Delegation Support 655 When an HNCP router receives a request for prefix delegation, it 656 SHOULD assign one prefix per delegated prefix, wait for them to be 657 applied, and delegate them to the client. Such assignment MUST be 658 done in accordance with the Prefix Assignment Algorithm. Each client 659 MUST be considered as an independent Private Link and delegation MUST 660 be based on the same set of Delegated Prefixes as the one used for 661 Common Links prefixes assignment. 663 The assigned prefixes MUST NOT be given to clients before they are 664 applied, and MUST be withdrawn whenever they are destroyed. As an 665 exception to this rule, in order to shorten delays of processed 666 requests, a router MAY prematurely give out a prefix which is 667 advertised but not yet applied if it does so with a valid lifetime of 668 not more than 30 seconds and ensures removal or correction of 669 lifetimes as soon as possible. 671 6.3. Node Address Assignment 673 This section specifies how HNCP nodes reserve addresses for their own 674 use. Nodes MAY, at any time, try to reserve a new address from any 675 applied Assigned Prefix. SLAAC SHOULD be used whenever possible. 676 The following method MUST be used otherwise. 678 For any IPv6 prefix for which SLAAC cannot be used (resp. any IPv4 679 prefix) assigned to a Common Link, the first quarter of the addresses 680 are reserved for routers HNCP based address assignments, whereas the 681 last three quarters are left to the DHCPv6 (resp. DHCPv4) elected 682 router (Section 10 specifies the DHCP server election process). For 683 instance, if the prefix 192.0.2.0/24 is assigned and applied to a 684 Common Link, addresses included in 192.0.2.0/26 are reserved for HNCP 685 nodes and the remaining addresses are reserved for the elected DHCPv4 686 server. 688 HNCP routers assign themselves addresses using the Node Address TLV: 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Type: NODE-ADDRESS (36) | Length: 20 | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Endpoint Identifier | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | | 698 | IP Address | 699 | | 700 | | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 Endpoint Identifier: The endpoint identifier of the local interface 704 that belongs to the Common Link the prefix is assigned to, or 0 if 705 it is not assigned on an HNCP enabled link. 707 IP Address: The globally scoped IPv6 address, or the IPv4 address 708 encoded as an IPv4-mapped IPv6 address [RFC4291]. 710 The process of obtaining addresses is specified as follows: 712 o A router MUST NOT start advertising an address if it is already 713 advertised by another router. 715 o An assigned address MUST be in the first quarter of an assigned 716 prefix currently applied on a Common Link which includes the 717 interface specified by the endpoint identifier. 719 o An address MUST NOT be used unless it has been advertised for at 720 least ADDRESS_APPLY_DELAY consecutive seconds, and is still 721 currently being advertised. The default value for 722 ADDRESS_APPLY_DELAY is 3 seconds. 724 o Whenever the same address is advertised by more than one node, all 725 but the one advertised by the node with the highest node 726 identifier MUST be removed. 728 6.4. Local IPv4 and ULA Prefixes 730 HNCP routers can create an ULA or private IPv4 prefix to enable 731 connectivity between local devices. These prefixes are inserted in 732 HNCP as if they were delegated prefixes. The following rules apply: 734 An HNCP router SHOULD create a ULA prefix if there is no other 735 non-deprecated IPv6 prefix in the network. It MAY also do so if 736 there are other delegated IPv6 prefixes but none of which is 737 generated by an HNCP router (i.e., none of which is specified in a 738 Delegated Prefix TLV which also includes a Prefix Domain TLV) but 739 MUST NOT do so otherwise. Whenever it detects another non- 740 deprecated IPv6 prefix generated by an HNCP router with a greater 741 HNCP identifier, it MUST cease to announce its own locally 742 generated one. 744 An HNCP router MUST create a private IPv4 prefix [RFC1918] 745 whenever it wishes to provide IPv4 internet connectivity to the 746 network and no other private IPv4 prefix with internet 747 connectivity currently exists. It MAY also enable local IPv4 748 connectivity by creating a private IPv4 prefix if no IPv4 prefix 749 exists but MUST NOT do so otherwise. In case multiple IPv4 750 prefixes are announced all but one MUST be removed while those 751 associated with a Prefix Domain TLV of type 0 take precedence over 752 those without and, in case of a tie, announcements by nodes with a 753 greater node identifier take precedence over those with a lower 754 one. The router publishing a prefix with internet connectivity 755 MUST announce an IPv4 default route using the routing protocol and 756 perform NAT on behalf of the network as long as it publishes the 757 prefix, other routers in the network MAY choose not to. Internet 758 Connectivity is indicated using a Prefix Domain TLV. 760 Creation of such ULA and IPv4 prefixes MUST be delayed by a random 761 timespan between 0 and 10 seconds in which the router MUST scan for 762 other nodes trying to do the same. 764 When a new ULA prefix is created, the prefix is selected based on the 765 configuration, using the last non-deprecated ULA prefix, or generated 766 based on [RFC4193]. 768 7. Configuration of Hosts and non-HNCP Routers 770 HNCP routers need to ensure that hosts and non-HNCP downstream 771 routers on internal links are configured with addresses and routes. 772 Since DHCP-clients can usually only bind to one server at a time, a 773 per-link and per-service election takes place. 775 HNCP routers may have different capabilities for configuring 776 downstream devices and providing naming services. Each router MUST 777 therefore indicate its capabilities as specified in Section 10 in 778 order to participate as a candidate in the election. 780 7.1. DHCPv6 for Addressing or Configuration 782 In general Stateless Address Autoconfiguration is used for client 783 configuration for its low overhead and fast renumbering capabilities, 784 however stateful DHCPv6 can be used in addition by administrative 785 choice, to e.g. collect hostnames and use them to provide naming 786 services or whenever stateless configuration is not applicable. 788 The designated stateful DHCPv6 server for a Common Link (Section 4) 789 is elected based on the capabilities described in Section 10. The 790 winner is the router (connected to the Common Link) advertising the 791 greatest H-capability. In case of a tie, Capability Values and node 792 identifiers are considered (greatest value is elected). The elected 793 router MUST serve stateful DHCPv6 and MUST provide naming services 794 for acquired hostnames as outlined in Section 8. Stateful addresses 795 SHOULD be assigned in a way not hindering fast renumbering even if 796 the DHCPv6 server or client do not support the DHCPv6 reconfigure 797 mechanism. In case no router was elected, stateful DHCPv6 is not 798 provided and each router assigning IPv6-prefixes on said link MUST 799 provide stateless DHCPv6 service. 801 7.2. Sending Router Advertisements 803 All HNCP routers MUST send Router Advertisements periodically via 804 multicast and via unicast in response to Router Solicitations. 806 o The "Managed address configuration" flag MUST be set whenever a 807 router connected to the link is advertising a non-null 808 H-capability and MUST NOT be set otherwise. The "Other 809 configuration" flag MUST always be set. 811 o The default Router Lifetime MUST be set to an appropriate non-null 812 value whenever an IPv6 default route is known in the HNCP network 813 and MUST be set to zero otherwise. 815 o A Prefix Information Option MUST be added for each assigned and 816 applied IPv6 prefix on the given link. The autonomous address- 817 configuration flag MUST be set whenever the prefix is suitable for 818 stateless configuration. The preferred and valid lifetimes MUST 819 be smaller than the preferred and valid lifetimes of the delegated 820 prefix the prefix is from. When a prefix is removed, it MUST be 821 deprecated as specified in [RFC7084]. 823 o A Route Information Option [RFC4191] MUST be added for each 824 delegated IPv6 prefix known in the HNCP network. Additional ones 825 SHOULD be added for each non-default IPv6 route with an external 826 destination prefix advertised by the routing protocol. 828 o A Recursive DNS Server Option and a DNS Search List Option MUST be 829 included with appropriate contents. 831 o To allow for optimized routing decisions for clients on the local 832 link routers SHOULD adjust their Default Router Preference and 833 Route Preferences [RFC4191] so that the priority is set to low if 834 the next hop of the default or more specific route is on the same 835 interface as the Route Advertisement being sent on. Similarly the 836 router MAY use the high priority if it is certain it has the best 837 metric of all routers on the link for all routes known in the 838 network with the respective destination. 840 Every router sending Router Advertisements MUST immediately send an 841 updated Router Advertisement via multicast as soon as it notices a 842 condition resulting in a change of any advertised information. 844 7.3. DHCPv6 for Prefix Delegation 846 The designated DHCPv6 server for prefix-delegation on a Common Link 847 is elected based on the capabilities described in Section 10. The 848 winner is the router (connected to the Common Link) advertising the 849 greatest P-capability. In case of a tie, Capability Values are 850 compared, and router with the greatest value is elected. In case of 851 another tie, the router with the highest node identifier is elected 852 among the routers with tied Capability Values. The elected router 853 MUST provide prefix-delegation services [RFC3633] on the given link 854 and follow the rules in Section 6.2.6. 856 7.4. DHCPv4 for Addressing and Configuration 858 The designated DHCPv4 server on a Common Link (Section 4) is elected 859 based on the capabilities described in Section 10. The winner is the 860 router (connected to the Common Link) advertising the greatest 861 L-capability. In case of a tie, Capability Values are compared, and 862 router with the greatest value is elected. In case of another tie, 863 the router with the highest node identifier is elected among the 864 routers with tied Capability Values. The elected router MUST provide 865 DHCPv4 services on the given link. 867 The DHCPv4 serving router MUST announce itself as router [RFC2132] to 868 clients if and only if there is an IPv4 default route known in the 869 network. In addition, the router SHOULD announce a Classless Static 870 Route Option [RFC3442] for each non-default IPv4 route advertised in 871 the routing protocol with an external destination. 873 DHCPv4 lease times SHOULD be short (i.e. not longer than 5 minutes) 874 in order to provide reasonable response times to changes. 876 7.5. Multicast DNS Proxy 878 The designated MDNS [RFC6762] proxy on a Common Link is elected based 879 on the capabilities described in Section 10. The winner is the 880 router (connected to the Common Link) advertising the greatest 881 M-capability. In case of a tie, Capability Values are compared, and 882 router with the greatest value is elected. In case of another tie, 883 the router with the highest node identifier is elected among the 884 routers with tied Capability Values. The elected router MUST provide 885 an MDNS-proxy on the given link and announce it as described in 886 Section 8. 888 8. Naming and Service Discovery 890 Network-wide naming and service discovery can greatly improve the 891 user-friendliness of an IPv6 network. The following mechanism 892 provides means to setup and delegate naming and service discovery 893 across multiple HNCP routers. 895 Each HNCP router SHOULD provide and announce an auto-generated or 896 user-configured name for each internal Common Link (Section 4) for 897 which it is the designated DHCPv4, stateful DHCPv6 server or MDNS 898 proxy and for which it provides DNS services on behalf of devices on 899 said link. In addition it MAY provide reverse lookup services. 901 The following TLVs are defined and MUST be supported by all nodes 902 implementing naming and service discovery: 904 8.1. DNS Delegated Zone TLV 906 This TLV is used to announce a forward or reverse DNS zone delegation 907 in the HNCP network. Its meaning is roughly equivalent to specifying 908 an NS and A/AAAA record for said zone. There MUST NOT be more than 909 one delegation for the same zone in the whole DNCP network. In case 910 of a conflict the announcement of the node with the highest node 911 identifier takes precedence and all other nodes MUST cease to 912 announce the conflicting TLV. 914 0 1 2 3 915 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 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Type: DNS-DELEGATED-ZONE (39) | Length: >= 17 | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | | 920 | IP Address | 921 | | 922 | | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 |Reserved |L|B|S| | 925 +-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) | 926 | | 928 IP Address : The IPv6 address of the authoritative DNS server for 929 the zone; IPv4 addresses are represented as IPv4-mapped addresses 930 [RFC4291]. The special value of :: (all-zero) means the 931 delegation is available in the global DNS-hierarchy. 933 Reserved : Those bits MUST be set to zero when creating the TLV and 934 ignored when parsing it unless defined in a later specification. 936 L-bit : DNS-SD [RFC6763] Legacy-Browse, indicates that this 937 delegated zone should be included in the network's DNS-SD legacy 938 browse list of domains at lb._dns- sd._udp.(DOMAIN-NAME). Local 939 forward zones SHOULD have this bit set, reverse zones SHOULD NOT. 941 B-bit : (DNS-SD [RFC6763] Browse) indicates that this delegated zone 942 should be included in the network's DNS-SD browse list of domains 943 at b._dns-sd._udp. (DOMAIN-NAME). Local forward zones SHOULD 944 have this bit set, reverse zones SHOULD NOT. 946 S-bit : (fully-qualified DNS-SD [RFC6763] domain) indicates that 947 this delegated zone consists of a fully-qualified DNS-SD domain, 948 which should be used as base for DNS-SD domain enumeration, i.e. 949 _dns-sd._udp.(Zone) exists. Forward zones MAY have this bit set, 950 reverse zones MUST NOT. This can be used to provision DNS search 951 path to hosts for non-local services (such as those provided by an 952 ISP, or other manually configured service providers). Zones with 953 this flag SHOULD be added to the search domains advertised to 954 clients. 956 Zone : The label sequence of the zone, encoded as the domain names 957 are encoded DNS messages as specified in [RFC1035]. The last 958 label in the zone MUST be empty. 960 8.2. Domain Name TLV 962 This TLV is used to indicate the base domain name for the network. 963 It is the zone used as a base for all non fully-qualified delegated 964 zones and node names. In case of conflicts the announced domain of 965 the node with the greatest node identifier takes precedence. By 966 default, i.e., if no node advertises such a TLV., ".home" is used. 968 0 1 2 3 969 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 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Type: DOMAIN-NAME (40) | Length: > 0 | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Domain (DNS label sequence - variable length) | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 Domain: The label sequence encoded according to [RFC1035]. 977 Compression MUST NOT be used. The zone MUST end with an empty 978 label. 980 8.3. Node Name TLV 982 This TLV is used to assign the name of a node in the network to a 983 certain IP address. In case of conflicts the announcement of the 984 node with the greatest node identifier for a name takes precedence 985 and all other nodes MUST cease to announce the conflicting TLV. 987 0 1 2 3 988 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 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Type: NODE-NAME (41) | Length: > 16 | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | | 993 | IP Address | 994 | | 995 | | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Name (not null-terminated - variable length) | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 IP Address: The IP address associated with the name. IPv4 1001 addresses are encoded using IPv4-mapped IPv6 addresses. 1003 Name: The name of the node as a DNS label. The length of the label 1004 is the Length value of the TLV minus 16. 1006 9. Securing Third-Party Protocols 1008 Pre-shared keys (PSKs) are often required to secure IGPs and other 1009 protocols which lack support for asymmetric security. The following 1010 mechanism manages PSKs using HNCP to enable bootstrapping of such 1011 third-party protocols and SHOULD therefore be used if such a need 1012 arises. The following rules define how such a PSK is managed and 1013 used: 1015 o If no Managed-PSK-TLV is currently being announced, an HNCP router 1016 MUST create one after a random delay of 0 to 10 seconds with a 32 1017 bytes long random key and add it to its node data. 1019 o In case multiple routers announce such a TLV at the same time, all 1020 but the one with the greatest node identifier stop advertising it 1021 and adopt the remaining one. 1023 o The router currently advertising the Managed-PSK-TLV must generate 1024 and advertise a new random one whenever an unreachable node is 1025 purged as described in DNCP. 1027 0 1 2 3 1028 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 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | Type: Managed-PSK (42) | Length: 32 | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | | 1033 | | 1034 | | 1035 | Random PSK | 1036 | | 1037 | | 1038 | | 1039 | | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 PSKs for individual protocols are derived from the random PSK through 1043 the use of HMAC-SHA256 [RFC6234] with a pre-defined per-protocol 1044 HMAC-key in ASCII-format. The following HMAC-keys are currently 1045 defined to derive PSKs for the respective protocols: 1047 "ROUTING": to be used for IGPs 1049 10. HNCP Versioning and Capabilities 1051 Multiple versions of HNCP based on compatible DNCP profiles may be 1052 present in the same network when transitioning between HNCP versions 1053 and HNCP routers may have different capabilities to support clients. 1055 The following mechanism describes a way to announce the currently 1056 active version and User-agent of a node. Each node MUST include an 1057 HNCP-Version-TLV in its Node Data and MUST ignore (except for DNCP 1058 synchronization purposes) any TLVs with a type greater than 32 1059 published by nodes not also publishing an HNCP-Version TLV or 1060 publishing such a TLV with a different Version number. 1062 Capabilities are indicated by setting M, P, H and L fields in the 1063 TLV. The "capability value" is a metric indicated by interpreting 1064 the bits as an integer, i.e. (M << 12 | P << 8 | H << 4 | L). 1066 0 1 2 3 1067 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 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Type: HNCP-VERSION (32) | Length: >= 5 | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Version | Reserved | M | P | H | L | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | User-agent | 1075 Version: Indicates which version of HNCP is currently in use by this 1076 particular node. It MUST be set to 0. Nodes with different 1077 versions are considered incompatible. 1079 Reserved: Bits are reserved for future use. They MUST be set to 1080 zero when creating this TLV, and their value MUST be ignored when 1081 processing the TLV. 1083 M-capability: Priority value used for electing the on-link MDNS 1084 [RFC6762] proxy. It MUST be set to some value between 1 and 7 1085 included (4 is the default) if the router is capable of proxying 1086 MDNS and 0 otherwise. The values 8-15 are reserved for future 1087 use. 1089 P-capability: Priority value used for electing the on-link DHCPv6-PD 1090 server. It MUST be set to some value between 1 and 7 included (4 1091 is the default) if the router is capable of providing prefixes 1092 through DHCPv6-PD (Section 6.2.6) and 0 otherwise. The values 1093 8-15 are reserved for future use. 1095 H-capability: Priority value used for electing the on-link DHCPv6 1096 server offering non-temporary addresses. It MUST be set to some 1097 value between 1 and 7 included (4 is the default) if the router is 1098 capable of providing such addresses and 0 otherwise. The values 1099 8-15 are reserved for future use. 1101 L-capability: Priority value used for electing the on-link DHCPv4 1102 server. It MUST be set to some value between 1 and 7 included (4 1103 is the default) if the router is capable of running a legacy 1104 DHCPv4 server offering IPv4 addresses to clients and 0 otherwise. 1105 The values 8-15 are reserved for future use. 1107 User-Agent: The user-agent is a human-readable UTF-8 string that 1108 describes the name and version of the current HNCP implementation. 1110 11. Requirements for HNCP Routers 1112 Each router implementing HNCP is subject to the following 1113 requirements: 1115 o It MUST implement HNCP-Versioning, Border Discovery, Prefix 1116 Assignment and Configuration of hosts and non-HNCP routers as 1117 defined in this document. 1119 o It MUST implement and run the method for securing third-party 1120 protocols whenever it uses the security mechanism of HNCP. 1122 o It SHOULD implement support for the Service Discovery and Naming 1123 TLVs as defined in this document. 1125 o It MUST implement and run a routing protocol appropriate for the 1126 given link type on all of the interfaces it sends and receives 1127 HNCP traffic on. The protocol MUST support source-specific routes 1128 and MUST correctly propagate those also for the external 1129 destinations that may have only implicit source-specific 1130 information, such as a combination of a DHCPv6 PD-derived prefix 1131 and a non-source-specific default route. 1133 o It MUST use adequate security mechanisms for the routing protocol 1134 on any interface where it also uses the security mechanisms of 1135 HNCP. If the security mechanism is based on a PSK it MUST use a 1136 PSK derived from the Managed-PSK to secure the IGP. 1138 o It MUST comply with the Basic Requirements for IPv6 Customer Edge 1139 Routers [RFC7084] unless it would otherwise conflict with any 1140 requirements in this document (e.g. prefix assignment mandating a 1141 different prefix delegation and DHCP server election strategy). 1142 In general "WAN interface requirements" shall apply to external 1143 interfaces and "LAN interface requirements" to internal interfaces 1144 respectively. 1146 o It MAY be able to provide connectivity to IPv4-devices using 1147 DHCPv4. 1149 o It SHOULD be able to delegate prefixes to legacy IPv6 routers 1150 using DHCPv6-PD. 1152 12. Security Considerations 1154 HNCP enables self-configuring networks, requiring as little user 1155 intervention as possible. However this zero-configuration goal 1156 usually conflicts with security goals and introduces a number of 1157 threats. 1159 General security issues for existing home networks are discussed in 1160 [RFC7368]. The protocols used to set up addresses and routes in such 1161 networks to this day rarely have security enabled within the 1162 configuration protocol itself. However these issues are out of scope 1163 for the security of HNCP itself. 1165 HNCP is a DNCP-based state synchronization mechanism carrying 1166 information with varying threat potential. For this consideration 1167 the payloads defined in DNCP and this document are reviewed: 1169 o Network topology information such as HNCP nodes and their common 1170 links. 1172 o Address assignment information such as delegated and assigned 1173 prefixes for individual links. 1175 o Naming and service discovery information such as auto-generated or 1176 customized names for individual links and routers. 1178 12.1. Border Determination 1180 As described in Section 5, an HNCP router determines the internal or 1181 external state on a per-link basis. A firewall perimeter is set up 1182 for the external links, and for internal links, HNCP and IGP traffic 1183 is allowed. 1185 Threats concerning automatic border discovery cannot be mitigated by 1186 encrypting or authenticating HNCP traffic itself since external 1187 routers do not participate in the protocol and often cannot be 1188 authenticated by other means. These threats include propagation of 1189 forged uplinks in the homenet in order to e.g. redirect traffic 1190 destined to external locations and forged internal status by external 1191 routers to e.g. circumvent the perimeter firewall. 1193 It is therefore imperative to either secure individual links on the 1194 physical or link-layer or preconfigure the adjacent interfaces of 1195 HNCP routers to an adequate fixed-category in order to secure the 1196 homenet border. Depending on the security of the external link 1197 eavesdropping, man-in-the-middle and similar attacks on external 1198 traffic can still happen between a homenet border router and the ISP, 1199 however these cannot be mitigated from inside the homenet. For 1200 example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4 1201 messages, but this is very rarely implemented in large or small 1202 networks. Further, while PPP can provide secure authentication of 1203 both sides of a point to point link, it is most often deployed with 1204 one-way authentication of the subscriber to the ISP, not the ISP to 1205 the subscriber. 1207 12.2. Security of Unicast Traffic 1209 Once the homenet border has been established there are several ways 1210 to secure HNCP against internal threats like manipulation or 1211 eavesdropping by compromised devices on a link which is enabled for 1212 HNCP traffic. If left unsecured, attackers may perform arbitrary 1213 eavesdropping, spoofing or denial of service attacks on HNCP services 1214 such as address assignment or service discovery. 1216 Detailed interface categories like "leaf" or "guest" can be used to 1217 integrate not fully trusted devices to various degrees into the 1218 homenet by not exposing them to HNCP and IGP traffic or by using 1219 firewall rules to prevent them from reaching homenet-internal 1220 resources. 1222 On links where this is not practical and lower layers do not provide 1223 adequate protection from attackers, DNCP secure mode MUST be used to 1224 secure traffic. 1226 12.3. Other Protocols in the Home 1228 IGPs and other protocols are usually run alongside HNCP therefore the 1229 individual security aspects of the respective protocols must be 1230 considered. It can however be summarized that many protocols to be 1231 run in the home (like IGPs) provide - to a certain extent - similar 1232 security mechanisms. Most of these protocols do not support 1233 encryption and only support authentication based on pre-shared keys 1234 natively. This influences the effectiveness of any encryption-based 1235 security mechanism deployed by HNCP as homenet routing information is 1236 thus usually not encrypted. 1238 13. IANA Considerations 1240 IANA is requested to maintain a registry for HNCP TLV-Types. This 1241 registry inherits TLV-Types and allocation policy defined in DNCP 1242 [I-D.ietf-homenet-dncp], but is independent with regard to all TLV- 1243 Types not specified or reserved by DNCP. Particularly, other DNCP 1244 profile may have there own registries, using same TLV numbers. 1246 The following TLV-Types are defined in this document: 1248 32: HNCP-Version 1250 33: External-Connection 1252 34: Delegated-Prefix 1254 35: Assigned-Prefix 1256 36: Node-Address 1258 37: DHCPv4-Data 1260 38: DHCPv6-Data 1262 39: DNS-Delegated-Zone 1264 40: Domain-Name 1266 41: Node-Name 1268 42: Managed-PSK 1270 HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP- 1271 DTLS-PORT, as well as an IPv6 link-local multicast address All- 1272 Homenet-Routers. 1274 14. References 1276 14.1. Normative references 1278 [I-D.ietf-homenet-dncp] 1279 Stenberg, M. and S. Barth, "Distributed Node Consensus 1280 Protocol", draft-ietf-homenet-dncp-05 (work in progress), 1281 June 2015. 1283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1284 Requirement Levels", BCP 14, RFC 2119, March 1997. 1286 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1287 Security Version 1.2", RFC 6347, January 2012. 1289 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1290 "Prefix Exclude Option for DHCPv6-based Prefix 1291 Delegation", RFC 6603, May 2012. 1293 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1294 More-Specific Routes", RFC 4191, November 2005. 1296 [I-D.ietf-homenet-prefix-assignment] 1297 Pfister, P., Paterson, B., and J. Arkko, "Distributed 1298 Prefix Assignment Algorithm", draft-ietf-homenet-prefix- 1299 assignment-07 (work in progress), June 2015. 1301 14.2. Informative references 1303 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1304 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1305 November 2013. 1307 [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, 1308 A., Beser, B., and J. Privat, "The User Class Option for 1309 DHCP", RFC 3004, November 2000. 1311 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1312 Messages", RFC 3118, June 2001. 1314 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1315 2131, March 1997. 1317 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1318 and M. Carney, "Dynamic Host Configuration Protocol for 1319 IPv6 (DHCPv6)", RFC 3315, July 2003. 1321 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1322 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1323 December 2003. 1325 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1326 E. Lear, "Address Allocation for Private Internets", BCP 1327 5, RFC 1918, February 1996. 1329 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1330 Architecture", RFC 4291, February 2006. 1332 [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1333 "IPv6 Home Networking Architecture Principles", RFC 7368, 1334 October 2014. 1336 [RFC1035] Mockapetris, P., "Domain names - implementation and 1337 specification", STD 13, RFC 1035, November 1987. 1339 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1340 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 1342 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1343 April 1992. 1345 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1346 February 2013. 1348 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1349 Discovery", RFC 6763, February 2013. 1351 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1352 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1353 6241, June 2011. 1355 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1356 Extensions", RFC 2132, March 1997. 1358 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 1359 Static Route Option for Dynamic Host Configuration 1360 Protocol (DHCP) version 4", RFC 3442, December 2002. 1362 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1363 Addresses", RFC 4193, October 2005. 1365 14.3. URIs 1367 [3] http://www.openwrt.org 1369 [4] http://www.homewrt.org/doku.php?id=run-conf 1371 Appendix A. Changelog [RFC Editor: please remove] 1373 draft-ietf-homenet-hncp-06: Various edits based on feedback, 1374 hopefully without functional delta. 1376 draft-ietf-homenet-hncp-05: Renamed "Adjacent Link" to "Common Link". 1377 Changed single IPv4 uplink election from MUST to MAY. Added explicit 1378 indication to distinguish (IPv4)-PDs for local connectivity and ones 1379 with uplink connectivity allowing e.g. better local-only 1380 IPv4-connectivity. 1382 draft-ietf-homenet-hncp-04: Change the responsibility for sending RAs 1383 to the router assigning the prefix. 1385 draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP 1386 (homenet profile). 1388 draft-ietf-homenet-hncp-02: Removed any built-in security. Relying 1389 on IPsec. Reorganized interface categories, added requirements 1390 languages, made manual border configuration a MUST-support. 1391 Redesigned routing protocol election to consider non-router devices. 1393 draft-ietf-homenet-hncp-01: Added (MAY) guest, ad-hoc, hybrid 1394 categories for interfaces. Removed old hnetv2 reference, and now 1395 pointing just to OpenWrt + github. Fixed synchronization algorithm 1396 to spread also same update number, but different data hash case. 1397 Made purge step require bidirectional connectivity between nodes when 1398 traversing the graph. Edited few other things to be hopefully 1399 slightly clearer without changing their meaning. 1401 draft-ietf-homenet-hncp-00: Added version TLV to allow for TLV 1402 content changes pre-RFC without changing IDs. Added link id to 1403 assigned address TLV. 1405 Appendix B. Draft source [RFC Editor: please remove] 1407 This draft is available at https://github.com/fingon/ietf-drafts/ in 1408 source format. Issues and pull requests are welcome. 1410 Appendix C. Implementation [RFC Editor: please remove] 1412 A GPLv2-licensed implementation of HNCP is currently under 1413 development at https://github.com/sbyx/hnetd/ and binaries are 1414 available in the OpenWrt [3] package repositories. See [4] for more 1415 information. Feedback and contributions are welcome. 1417 Appendix D. Acknowledgements 1419 Thanks to Ole Troan, Mark Baugher, Mark Townsley and Juliusz 1420 Chroboczek for their contributions to the draft. 1422 Thanks to Eric Kline for the original border discovery work. 1424 Authors' Addresses 1426 Markus Stenberg 1427 Helsinki 00930 1428 Finland 1430 Email: markus.stenberg@iki.fi 1432 Steven Barth 1433 Halle 06114 1434 Germany 1436 Email: cyrus@openwrt.org 1437 Pierre Pfister 1438 Cisco Systems 1439 Paris 1440 France 1442 Email: pierre.pfister@darou.fr