idnits 2.17.1 draft-ietf-homenet-hncp-04.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 (March 5, 2015) is 3337 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 1319 -- Looks like a reference, but probably isn't: '4' on line 1319 == Outdated reference: A later version (-12) exists of draft-ietf-homenet-dncp-01 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-08) exists of draft-ietf-homenet-prefix-assignment-03 -- 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: September 6, 2015 6 P. Pfister 7 Cisco Systems 8 March 5, 2015 10 Home Networking Control Protocol 11 draft-ietf-homenet-hncp-04 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 September 6, 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. Adjacent Links . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Border Discovery . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Autonomic Address Configuration . . . . . . . . . . . . . . . 6 61 6.1. External Connections . . . . . . . . . . . . . . . . . . 7 62 6.1.1. External Connection TLV . . . . . . . . . . . . . . . 7 63 6.1.2. Delegated Prefix TLV . . . . . . . . . . . . . . . . 7 64 6.1.3. DHCP Data TLVs . . . . . . . . . . . . . . . . . . . 8 65 6.2. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 9 66 6.2.1. Assigned Prefix TLV . . . . . . . . . . . . . . . . . 9 67 6.2.2. Prefix Assignment Algorithm Parameters . . . . . . . 10 68 6.2.3. Making New Assignments . . . . . . . . . . . . . . . 12 69 6.2.4. Applying Assignments . . . . . . . . . . . . . . . . 12 70 6.2.5. DHCPv6-PD Excluded Prefix Support . . . . . . . . . . 13 71 6.2.6. Downstream Prefix Delegation Support . . . . . . . . 13 72 6.3. Node Address Assignment . . . . . . . . . . . . . . . . . 13 73 6.4. Local IPv4 and ULA Prefixes . . . . . . . . . . . . . . . 14 74 7. Configuration of Hosts and non-HNCP Routers . . . . . . . . . 15 75 7.1. DHCPv6 for Addressing or Configuration . . . . . . . . . 15 76 7.2. Sending Router Advertisements . . . . . . . . . . . . . . 16 77 7.3. DHCPv6 for Prefix Delegation . . . . . . . . . . . . . . 17 78 7.4. DHCPv4 for Adressing and Configuration . . . . . . . . . 17 79 7.5. Multicast DNS Proxy . . . . . . . . . . . . . . . . . . . 17 80 8. Naming and Service Discovery . . . . . . . . . . . . . . . . 18 81 8.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 18 82 8.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 19 83 8.3. Node Name TLV . . . . . . . . . . . . . . . . . . . . . . 20 84 9. Securing Third-Party Protocols . . . . . . . . . . . . . . . 20 85 10. HNCP Versioning and Capabilities . . . . . . . . . . . . . . 21 86 11. Requirements for HNCP Routers . . . . . . . . . . . . . . . . 22 87 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 88 12.1. Border Determination . . . . . . . . . . . . . . . . . . 24 89 12.2. Security of Unicast Traffic . . . . . . . . . . . . . . 24 90 12.3. Other Protocols in the Home . . . . . . . . . . . . . . 25 91 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 92 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 14.1. Normative references . . . . . . . . . . . . . . . . . . 26 94 14.2. Informative references . . . . . . . . . . . . . . . . . 26 95 Appendix A. Some Outstanding Issues . . . . . . . . . . . . . . 28 96 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 28 97 Appendix C. Draft source . . . . . . . . . . . . . . . . . . . . 28 98 Appendix D. Implementation . . . . . . . . . . . . . . . . . . . 28 99 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 29 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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 (group All- 128 Homenet-Routers). Received datagrams with an IPv6 source or 129 destination address which is not link-local scoped MUST be 130 ignored. IPv6 fragmentation and reassembly up to TBD bytes MUST 131 be supported by the stack of the node. 133 o HNCP operates on multicast-capable interfaces only, thus every 134 DNCP Connection Identifier MUST refer to one, except for the value 135 0 which is reserved for internal purposes and MUST NOT be used for 136 connection enumeration. Implementations MAY use a value 137 equivalent to the sin6_scope_id for the given interface. 139 o HNCP unicast messages SHOULD be secured using DTLS [RFC6347] as 140 described in DNCP if exchanged over unsecured links. UDP on port 141 HNCP-DTLS-PORT is used for this purpose. A node implementing the 142 security mechanism MUST support the DNCP Pre-Shared Key method, 143 SHOULD support the DNCP Certificate Based Trust Consensus and MAY 144 support the PKI-based trust method. 146 o HNCP uses opaque 32-bit node identifiers 147 (DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP 148 SHOULD generate and use a random node identifier. If it receives 149 a Node State TLV with the same node identifier and a higher update 150 sequence number, it MUST immediately generate and use a new random 151 node identifier which is not used by any other node. 153 o HNCP nodes MUST treat all Long Network State Update messages 154 received via multicast on a link which has DNCP security enabled 155 as if they were Short Network State Update messages, i.e. they 156 MUST ignore all contained Node State TLVs. 158 o HNCP nodes use the following Trickle parameters: 160 * k SHOULD be 1, given the timer reset on data updates and 161 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 the keep-alive extension on all connections. 173 The default keep-alive interval (DNCP_KEEPALIVE_INTERVAL) is 20 174 seconds, the multiplier (DNCP_KEEPALIVE_MULTIPLIER) MUST be 2.1, 175 the grace-interval (DNCP_GRACE_INTERVAL) SHOULD be equal to 176 DNCP_KEEPALIVE_MULTIPLIER times DNCP_KEEPALIVE_INTERVAL. 178 4. Adjacent Links 180 HNCP uses the concept of Adjacent Links for some of its applications. 181 This term is defined as follows: 183 If the connection of a node is detected or configured to be an ad-hoc 184 interface the Adjacent Link only consists of said interface. 186 Otherwise the Adjacent Link contains all interfaces bidirectionally 187 reachable from a given local interface. An interface X of a node A 188 and an interface Y of a node B are bidirectionally reachable if and 189 only if node A publishes a Neighbor TLV with the Neighbor Node 190 Identifier B, the Neighbor Connection Identifier Y and the Local 191 Connection Identifier X and node B publishes a Neighbor TLV with the 192 Neighbor Node Identifier A, a Neighbor Connection Identifier X and 193 the Local Connection Identifier Y. In addition a node MUST be able 194 to detect whether two of its local interfaces belong to the same 195 Adjacent Link either by local means or by inferring that from the 196 bidirectional reachability between two different local interfaces and 197 the same remote interface. 199 5. Border Discovery 201 HNCP associates each HNCP interface with a category (e.g., internal 202 or external). This section defines the border discovery algorithm 203 derived from the edge router interactions described in the Basic 204 Requirements for IPv6 Customer Edge Routers [RFC7084]. This 205 algorithm is suitable for both IPv4 and IPv6 (single or dual-stack) 206 and determines whether an HNCP interface is internal, external, or 207 uses another fixed category. This algorithm MUST be implemented by 208 any router implementing HNCP. 210 In order to avoid conflicts between border discovery and homenet 211 routers running DHCPv4 [RFC2131] or DHCPv6-PD [RFC3633] servers, each 212 router MUST implement the following mechanism based on The User Class 213 Option for DHCPv4 [RFC3004] and its DHCPv6 counterpart [RFC3315]: 215 o An HNCP router running a DHCP client on a homenet interface MUST 216 include a DHCP User-Class consisting of the ASCII-String 217 "HOMENET". 219 o An HNCP router running a DHCP server on a homenet interface MUST 220 ignore or reject DHCP-Requests containing a DHCP User-Class 221 consisting of the ASCII-String "HOMENET". 223 The border discovery auto-detection algorithm works as follows, with 224 evaluation stopping at first match: 226 1. If a fixed category is configured for the interface, it MUST be 227 used. 229 2. If a delegated prefix could be acquired by running a DHCPv6 230 client on the interface, it MUST be considered external. 232 3. If an IPv4 address could be acquired by running a DHCPv4 client 233 on the interface it MUST be considered external. 235 4. Otherwise the interface MUST be considered internal. 237 A router MUST allow setting a category of either auto-detected, 238 internal or external for each interface which is suitable for both 239 internal and external connections. In addition the following 240 specializations of the internal category are defined to modify the 241 local router behavior: 243 Leaf category: This declares an interface used by client devices 244 only. A router MUST consider such interface as internal but MUST 245 NOT send nor receive HNCP messages on such interface. A router 246 SHOULD implement this category. 248 Guest category: This declares an interface used by untrusted client 249 devices only. In addition to the restrictions of the Leaf 250 category, connected devices MUST NOT be able to reach other 251 devices inside the HNCP network nor query services advertised by 252 them unless explicitly allowed, instead they SHOULD only be able 253 to reach the internet. This category SHOULD be supported. 255 Ad-hoc category: This configures an interface to be ad-hoc 256 (Section 4) and MAY be implemented. 258 Hybrid category: This declares an interface to be internal while 259 still using external connections on it. It is assumed that the 260 link is under control of a legacy, trustworthy non-HNCP router, 261 still within the same network. Detection of this category 262 automatically in addition to manual configuration is out of scope 263 for this document. This category MAY be implemented. 265 Each router MUST continuously scan each active interface that does 266 not have a fixed category in order to dynamically reclassify it if 267 necessary. The router therefore runs an appropriately configured 268 DHCPv4 and DHCPv6 client as long as the interface is active including 269 states where it considers the interface to be internal. The router 270 SHOULD wait for a reasonable time period (5 seconds as a default), 271 during which the DHCP clients can acquire a lease, before treating a 272 newly activated or previously external interface as internal. Once 273 it treats a certain interface as internal it MUST start forwarding 274 traffic with appropriate source addresses between its internal 275 interfaces and allow internal traffic to reach external networks 276 according to the routes it publishes. Once a router detects an 277 interface transitioning to external it MUST stop any previously 278 enabled internal forwarding. In addition it SHOULD announce the 279 acquired information for use in the network as described in later 280 sections of this draft if the interface appears to be connected to an 281 external network. 283 6. Autonomic Address Configuration 285 This section specifies how HNCP routers configure host and router 286 addresses. At first border routers share information obtained from 287 service providers or local configuration by publishing one or more 288 External Connection TLVs. These contain other TLVs such as Delegated 289 Prefix TLVs which are then used for prefix assignment. Finally, HNCP 290 routers obtain addresses using a stateless (SLAAC-like) procedure or 291 a specific stateful mechanism and hosts and legacy routers are 292 configured using SLAAC or DHCP. 294 In all TLVs specified in this section which include a prefix, IPv4 295 prefixes are encoded using the IPv4-mapped IPv6 addresses format 296 [RFC4291]. The prefix length of such prefix is set to 96 plus the 297 IPv4 prefix length. 299 6.1. External Connections 301 Each HNCP router MAY obtain external connection information from one 302 or more sources, e.g. DHCPv6-PD [RFC3633], NETCONF [RFC6241] or 303 static configuration. This section specifies how such information is 304 encoded and advertised. 306 6.1.1. External Connection TLV 308 An External Connection TLV is a container-TLV used to gather network 309 configuration information associated with a single external 310 connection. A node MAY publish zero, one or more instances of this 311 TLV. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type: EXTERNAL-CONNECTION (33)| Length: > 0 | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Nested TLVs | 320 The External Connection TLV is a container which: 322 o MAY contain zero, one or more Delegated Prefix TLVs. 324 o MUST NOT contain multiple Delegated Prefix TLVs with the same 325 prefix. In such a situation, the container MUST be ignored. 327 o MAY contain at most one DHCPv6 Data TLV and at most one DHCPv4 328 Data TLV encoding options associated with the External Connection 329 but MUST NOT contain more than one of each otherwise the whole 330 External Connection TLV MUST be ignored. 332 o MAY contain other TLVs for future use. 334 6.1.2. Delegated Prefix TLV 336 The Delegated Prefix TLV is used by HNCP routers to advertise 337 prefixes which are allocated to the whole network and will be used 338 for prefix assignment. All Delegated Prefix TLVs MUST be nested in 339 an External Connection TLV. 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Type: DELEGATED-PREFIX (34) | Length: >= 9 | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Valid Lifetime | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Preferred Lifetime | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Prefix Length | | 351 +-+-+-+-+-+-+-+-+ Prefix [+ nested TLVs] + 352 | | 354 Valid Lifetime: The time in seconds the delegated prefix is valid. 355 The value is relative to the point in time the Node-Data TLV was 356 last published. It MUST be updated whenever the node republishes 357 its Node-Data TLV. 359 Preferred Lifetime: The time in seconds the delegated prefix is 360 preferred. The value is relative to the point in time the Node- 361 Data TLV was last published. It MUST be updated whenever the node 362 republishes its Node-Data TLV. 364 Prefix Length: The number of significant bits in the Prefix. 366 Prefix: Significant bits of the prefix padded with zeroes up to the 367 next byte boundary. 369 Nested TLVs: Other TLVs included in the Delegated Prefix TLV and 370 starting at the next 32 bits boundary following the end of the 371 encoded prefix. 373 If the encoded prefix represents an IPv6 prefix, at most one 374 DHCPv6 Data TLV MAY be included. 376 If the encoded prefix represents an IPv4-mapped IPv6 address, 377 at most one DHCPv4 Data TLV MAY be included. 379 It MAY contain other TLVs for future use. 381 6.1.3. DHCP Data TLVs 383 Auxiliary connectivity information is encoded as a stream of DHCP 384 options. Such TLVs MUST only be present in an External Connection 385 TLV or a Delegated Prefix TLV. When included in an External 386 Connection TLV, they MUST contain DHCP options which are relevant to 387 the whole External Connection. When included in a Delegated Prefix, 388 they MUST contain DHCP options which are specific to the Delegated 389 Prefix. 391 The DHCPv6 Data TLV uses the following format: 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type: DHCPV6-DATA (37) | Length: > 0 | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | DHCPv6 option stream | 400 DHCPv6 option stream: DHCPv6 options encoded as specified in 401 [RFC3315]. 403 The DHCPv4 Data TLV uses the following format: 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Type: DHCPV4-DATA (38) | Length: > 0 | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | DHCPv4 option stream | 412 DHCPv4 option stream: DHCPv4 options encoded as specified in 413 [RFC2131]. 415 6.2. Prefix Assignment 417 HNCP uses the Distributed Prefix Assignment Algorithm specified in 418 [I-D.ietf-homenet-prefix-assignment] in order to assign prefixes to 419 HNCP internal links and uses the terminology defined there. 421 6.2.1. Assigned Prefix TLV 423 Published Assigned Prefixes MUST be advertised using the Assigned 424 Prefix TLV: 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Type: ASSIGNED-PREFIX (35) | Length: >= 6 | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Connection Identifier | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Rsv. | Prty. | Prefix Length | | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix + 435 | | 437 Connection Identifier: The DNCP Connection Identifier of the link 438 the prefix is assigned to, or 0 if the link is a Private Link. 440 Rsv.: Bits reserved for future use. MUST be set to zero when 441 creating this TLV and ignored when parsing it. 443 Prty: The Advertised Prefix Priority from 0 to 15. 445 0-1 : Low priorities. 447 2 : Default priority. 449 3-7 : High priorities. 451 8-11 : Administrative priorities. MUST NOT be used unless 452 specified in the router's configuration. 454 12-14: Reserved for future use. 456 15 : Provider priorities. MAY only be used by the router 457 advertising the corresponding delegated prefix and based on 458 static or dynamic configuration (e.g., for excluding a prefix 459 based on DHCPv6-PD Prefix Exclude Option [RFC6603]). 461 Prefix Length: The number of significant bits in the Prefix field. 463 Prefix: The significant bits of the prefix padded with zeroes up to 464 the next byte boundary. 466 6.2.2. Prefix Assignment Algorithm Parameters 468 All HNCP nodes running the prefix assignment algorithm MUST use the 469 following parameters: 471 Node IDs: DNCP Node Identifiers are used. The comparison operation 472 is defined as bit-wise comparison. 474 Set of Delegated Prefixes: The set of prefixes encoded in Delegated 475 Prefix TLVs which are not strictly included in prefixes encoded in 476 other Delegated Prefix TLVs. Note that Delegated Prefix TLVs 477 included in ignored External Connection TLVs are not considered. 478 It is dynamically updated as Delegated Prefix TLVs are added or 479 removed. 481 Set of Shared Links: The set of HNCP internal, leaf, guest or 482 hybrid links. It is dynamically updated as HNCP links are added, 483 removed, become internal or cease to be. 485 Set of Private Links: This document defines Private Links 486 representing DHCPv6-PD clients or as a mean to advertise prefixes 487 included in the DHCPv6 Exclude Prefix option. Other 488 implementation-specific Private Links may exist. 490 Set of Advertised Prefixes: The set of prefixes included in 491 Assigned Prefix TLVs advertised by other HNCP routers. The 492 associated Advertised Prefix Priority is the priority specified in 493 the TLV. The associated Shared Link is determined as follows: 495 * If the Link Identifier is zero, the Advertised Prefix is not 496 assigned on a Shared Link. 498 * If the Link Identifier is not zero the Shared Link is equal to 499 the Adjacent Link (Section 4). Advertised Prefixes as well as 500 their associated priorities and associated Shared Links MUST be 501 updated as Assigned Prefix TLVs or Neighbor TLVs are added, 502 removed or updated. 504 ADOPT_MAX_DELAY: The default value is 0 seconds (i.e. prefix 505 adoption MAY be done instantly). 507 BACKOFF_MAX_DELAY: The default value is 4 seconds. 509 RANDOM_SET_SIZE: The default value is 64. 511 Flooding Delay: The default value is 5 seconds. 513 Default Advertised Prefix Priority: When a new assignment is 514 created or an assignment is adopted - as specified in the prefix 515 assignment algorithm routine - the default Advertised Prefix 516 Priority to be used is 2. 518 6.2.3. Making New Assignments 520 Whenever the Prefix Assignment Algorithm routine is run on an 521 Adjacent Link and whenever a new prefix may be assigned (case 1 of 522 the routine), the decision of whether the assignment of a new prefix 523 is desired MUST follow these rules: 525 If the Delegated Prefix TLV contains a DHCPv4 or DHCPv6 Data TLV, 526 and the meaning of one of the DHCP options is not understood by 527 the HNCP router, the creation of a new prefix is not desired. 529 If the remaining preferred lifetime of the prefix is 0 and there 530 is another delegated prefix of the same IP version used for prefix 531 assignment with a non-null preferred lifetime, the creation of a 532 new prefix is not desired. 534 Otherwise, the creation of a new prefix is desired. 536 If the considered delegated prefix is an IPv6 prefix, and whenever 537 there is at least one available prefix of length 64, a prefix of 538 length 64 MUST be selected unless configured otherwise by an 539 administrator. In case no prefix of length 64 would be available, a 540 longer prefix MAY be selected. 542 If the considered delegated prefix is an IPv4 prefix ( Section 6.4 543 details how IPv4 delegated prefixes are generated), a prefix of 544 length 24 SHOULD be preferred. 546 In any case, a router MUST support a mechanism suitable to distribute 547 addresses from the considered prefix to clients on the link. 548 Otherwise it MUST NOT create or adopt it, i.e. a router assigning an 549 IPv4 prefix MUST support the L-capability and a router assigning an 550 IPv6 prefix not suitable for stateless autoconfiguration MUST support 551 the H-capability as defined in Section 10. 553 6.2.4. Applying Assignments 555 The prefix assignment algorithm indicates when a prefix is applied to 556 the respective Adjacent Link. When that happens each router 557 connected to said link: 559 MUST create an appropriate on-link route for said prefix and 560 advertise it using the chosen routing protocol. 562 MUST participate in the client configuration election as described 563 in Section 7. 565 MAY add an address from said prefix to the respective network 566 interface as described in Section 6.3. 568 6.2.5. DHCPv6-PD Excluded Prefix Support 570 Whenever a DHCPv6 Prefix Exclude option [RFC6603] is received with a 571 delegated prefix, the excluded prefix MUST be advertised as assigned 572 to a Private Link with the maximum priority (i.e. 15). 574 The same procedure MAY be applied in order to exclude prefixes 575 obtained by other means of configuration. 577 6.2.6. Downstream Prefix Delegation Support 579 When an HNCP router receives a request for prefix delegation, it 580 SHOULD assign one prefix per delegated prefix, wait for them to be 581 applied, and delegate them to the client. Such assignment MUST be 582 done in accordance with the Prefix Assignment Algorithm. Each client 583 MUST be considered as an independent Private Link and delegation MUST 584 be based on the same set of Delegated Prefixes. 586 The assigned prefixes MUST NOT be given to clients before they are 587 applied, and MUST be withdrawn whenever they are destroyed. As an 588 exception to this rule a router MAY prematurely give out a prefix 589 which is advertised but not yet applied if it does so with a valid 590 lifetime of not more than 30 seconds and ensures removal or 591 correction of lifetimes as soon as possible to shorten delays of 592 processed requests. 594 6.3. Node Address Assignment 596 This section specifies how HNCP nodes reserve addresses for their own 597 use. Nodes MAY, at any time, try to reserve a new address. SLAAC 598 SHOULD be used whenever possible. The following method MUST be used 599 otherwise. 601 For any IPv6 prefix longer than 64 bits (resp. any IPv4 prefix) 602 assigned to an Adjacent Link, the first quarter of the addresses are 603 reserved for routers HNCP based assignments, whereas the last three 604 quarters are left to the DHCPv6 (resp. DHCPv4) elected router 605 (Section 10 specifies the DHCP server election process). For 606 instance, if the prefix 192.0.2.0/24 is assigned and applied to an 607 Adjacent Link, addresses included in 192.0.2.0/26 are reserved for 608 HNCP nodes and the remaining addresses are reserved for the elected 609 DHCPv4 server. 611 HNCP routers assign themselves addresses using the Node Address TLV: 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Type: NODE-ADDRESS (36) | Length: 20 | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Connection Identifier | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | | 621 | IP Address | 622 | | 623 | | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Connection Identifier: The DNCP Connection Identifier of the link 627 the address is assigned to, or 0 if it is not assigned on an HNCP 628 enabled link. 630 IP Address: The IPv6 address, or the IPv4 address encoded as an 631 IPv4-mapped IPv6 address [RFC4291]. 633 The process of obtaining addresses is specified as follows: 635 o A router MUST NOT start advertising an address if it is already 636 advertised by another router. 638 o An assigned address MUST be in the first quarter of an assigned 639 prefix currently applied on the specified link. 641 o An address MUST NOT be used unless it has been advertised for at 642 least ADDRESS_APPLY_DELAY consecutive seconds, and is still 643 currently being advertised. The default value for 644 ADDRESS_APPLY_DELAY is 3 seconds. 646 o Whenever the same address is advertised by more than one node all 647 but the one advertised by the node with the highest node 648 identifier MUST be removed. 650 6.4. Local IPv4 and ULA Prefixes 652 HNCP routers can create an ULA or private IPv4 prefix to enable 653 connectivity between local devices. These prefixes are inserted in 654 HNCP as if they were delegated prefixes. The following rules apply: 656 An HNCP router SHOULD create an ULA prefix if there is no other 657 non-deprecated IPv6 prefix in the network. It MAY also do so if 658 there are other delegated IPv6 prefixes but none of which is a 659 non-deprecated ULA but MUST NOT do so otherwise. Whenever it 660 detects another non-deprecated ULA being advertised it MUST cease 661 to announce its locally generated one. It MAY also do so once it 662 detects a non-deprecated non-ULA IPv6 delegated prefix. 664 An HNCP router MUST create a non-deprecated private IPv4 prefix 665 [RFC1918] whenever it wishes to provide external IPv4 connectivity 666 to the network and no other non-deprecated private IPv4 prefix 667 currently exists. It MAY also create a deprecated private IPv4 668 prefix if no IPv4 prefix exists and it wants to enable local IPv4 669 connectivity but MUST NOT do so otherwise. In case multiple IPv4 670 prefixes are announced all but one MUST be removed while non- 671 deprecated ones take precedence over deprecated ones and 672 announcements by nodes with a higher node identifier take 673 precedence over those with a lower one. The router publishing the 674 non-deprecated prefix MUST announce an IPv4 default route using 675 the routing protocol and perform NAT on behalf of the network as 676 long as it publishes the prefix, other routers in the network MUST 677 NOT. 679 Creation of such ULA and IPv4 prefixes MUST be delayed by a random 680 timespan between 0 and 10 seconds in which the router MUST scan for 681 other nodes trying to do the same. 683 When a new ULA prefix is created, the prefix is selected based on the 684 configuration, using the last non-deprecated ULA prefix, or generated 685 based on [RFC4193]. 687 7. Configuration of Hosts and non-HNCP Routers 689 HNCP routers need to ensure that hosts and non-HNCP downstream 690 routers on internal links are configured with addresses and routes. 691 Since DHCP-clients can usually only bind to one server at a time an 692 election takes place. 694 HNCP routers may have different capabilities for configuring 695 downstream devices and providing naming services. Each router MUST 696 therefore indicate its capabilities as specified in Section 10 in 697 order to participate as a candidate in the election. 699 7.1. DHCPv6 for Addressing or Configuration 701 In general stateless address configuration is preferred whenever 702 possible since it enables fast renumbering and low overhead, however 703 stateful DHCPv6 can be useful in addition to collect hostnames and 704 use them to provide naming services or if stateless configuration is 705 not possible for the assigned prefix length. 707 The designated stateful DHCPv6 server for a link is elected based on 708 the capabilities described in Section 10. The winner is the router 709 connected to the Adjacent Link (Section 4) advertising the greatest 710 H-capability. In case of a tie, Capability Values and node 711 identifiers are considered (greatest value is elected). The elected 712 router MUST serve stateful DHCPv6 and Router Advertisements on the 713 given link. Furthermore it MUST provide naming services for acquired 714 hostnames as outlined in Section 8. Stateful addresses being handed 715 out SHOULD have a low preferred lifetime (e.g. 1s) to not hinder fast 716 renumbering if either the DHCPv6 server or client do not support the 717 DHCPv6 reconfigure mechanism and the address is from a prefix for 718 which stateless autoconfiguration is supported as well. In case no 719 router was elected, stateful DHCPv6 is not provided and each router 720 assigning IPv6-prefixes on said link MUST provide stateless DHCPv6 721 service. 723 7.2. Sending Router Advertisements 725 Each HNCP router assigning an IPV6-prefix to an interface MUST send 726 Router Advertisements periodically via multicast and via unicast in 727 response to Router Solicitations. In addition other routers on the 728 link MAY announce Router Advertisements. This might result in a more 729 optimal routing decision for clients. The following rules MUST be 730 followed when sending Router Advertisements: 732 The "Managed address configuration" flag MUST be set whenever a 733 router connected to the link is advertising a non-null 734 H-capability and MUST NOT be set otherwise. The "Other 735 configuration" flag MUST always be set. 737 The default Router Lifetime MUST be set to an appropriate non-null 738 value whenever an IPv6 default route is known in the HNCP network 739 and MUST be set to zero otherwise. 741 A Prefix Information Option MUST be added for each assigned and 742 applied IPv6 prefix on the given link. The autonomous address- 743 configuration flag MUST be set whenever the prefix is suitable for 744 stateless configuration. The preferred and valid lifetimes MUST 745 be smaller than the preferred and valid lifetimes of the delegated 746 prefix the prefix is from. When a prefix is removed, it MUST be 747 deprecated as specified in [RFC7084]. 749 A Route Information Option [RFC4191] MUST be added for each 750 delegated IPv6 prefix known in the HNCP network. Additional ones 751 SHOULD be added for each non-default IPv6 route with an external 752 destination advertised by the routing protocol. 754 A Recursive DNS Server Option and a DNS Search List Option MUST be 755 included with appropriate contents. 757 To allow for optimized routing decisions for clients on the local 758 link routers SHOULD adjust their Default Router Preference and 759 Route Preferences [RFC4191] so that the priority is set to low if 760 the next hop of the default or more specific route is on the same 761 interface as the Route Advertisement being sent on. Similarly the 762 router MAY use the high priority if it is certain it has the best 763 metric of all routers on the link for all routes known in the 764 network with the respective destination. 766 Every router sending Router Advertisements MUST immediately send an 767 updated Router Advertisement via multicast as soon as it notices a 768 condition resulting in a change of any advertised information. 770 7.3. DHCPv6 for Prefix Delegation 772 The designated DHCPv6 server for prefix-delegation on a link is 773 elected based on the capabilities described in Section 10. The 774 winner is the router connected to the Adjacent Link (Section 4) 775 advertising the greatest P-capability. In case of a tie, Capability 776 Values and Node Identifiers are considered (greatest value is 777 elected). The elected router MUST provide prefix-delegation services 778 [RFC3633] on the given link and follow the rules in Section 6.2.6. 780 7.4. DHCPv4 for Adressing and Configuration 782 The designated DHCPv4 server on a link is elected based on the 783 capabilities described in Section 10. The winner is the router 784 connected to the Adjacent Link (Section 4) advertising the greatest 785 L-capability. In case of a tie, Capability Values and node 786 identifiers are considered (greatest value is elected). The elected 787 router MUST provide DHCPv4 services on the given link. 789 The DHCPv4 serving router MUST announce itself as router [RFC2132] to 790 clients if and only if there is an IPv4 default route known in the 791 network. In addition the router SHOULD announce a Classless Static 792 Route Option [RFC3442] for each non-default IPv4 route advertised in 793 the routing protocol with an external destination. 795 DHCPv4 lease times SHOULD be short (i.e. not longer than 5 minutes) 796 in order to provide reasonable response times to changes. 798 7.5. Multicast DNS Proxy 800 The designated MDNS [RFC6762]-proxy on a link is elected based on the 801 capabilities described in Section 10. The winner is the router with 802 the highest Node Identifier among those with the highest Capability 803 Value on the link that support the M-capability. The elected router 804 MUST provide an MDNS-proxy on the given link and announce it as 805 described in Section 8. 807 8. Naming and Service Discovery 809 Network-wide naming and service discovery can greatly improve the 810 user-friendliness of an IPv6 network. The following mechanism 811 provides means to setup and delegate naming and service discovery 812 across multiple HNCP routers. 814 Each HNCP router SHOULD provide and announce an auto-generated or 815 user-configured name for each internal Adjacent Link (Section 4) for 816 which it is the designated DHCPv4, stateful DHCPv6 server or MDNS 817 [RFC6762]-proxy and for which it provides DNS-services on behalf of 818 devices on said link. In addition it MAY provide reverse lookup 819 services. 821 The following TLVs are defined and MUST be supported by all nodes 822 implementing naming and service discovery: 824 8.1. DNS Delegated Zone TLV 826 This TLV is used to announce a forward or reverse DNS zone delegation 827 in the HNCP network. Its meaning is roughly equivalent to specifying 828 an NS and A/AAAA record for said zone. There MUST NOT be more than 829 one delegation for the same zone in the whole DNCP network. In case 830 of a conflict the announcement of the node with the highest node 831 identifier takes precedence and all other nodes MUST cease to 832 announce the conflicting TLV. 834 0 1 2 3 835 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 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Type: DNS-DELEGATED-ZONE (39) | Length: >= 17 | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | | 840 | IP Address | 841 | | 842 | | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 |reserved |L|B|S| | 845 +-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) | 846 | | 848 IP Address is the IPv6 address of the authoritative DNS server for 849 the zone; IPv4 addresses are represented as IPv4-mapped addresses 850 [RFC4291]. The special value of :: (all-zero) means the 851 delegation is available in the global DNS-hierarchy. 853 reserved bits MUST be zero when creating and ignored when parsing 854 this TLV. 856 L-bit (DNS-SD [RFC6763] Legacy-Browse) indicates that this 857 delegated zone should be included in the network's DNS-SD legacy 858 browse list of domains at lb._dns- sd._udp.(DOMAIN-NAME). Local 859 forward zones SHOULD have this bit set, reverse zones SHOULD NOT. 861 B-bit (DNS-SD [RFC6763] Browse) indicates that this delegated zone 862 should be included in the network's DNS-SD browse list of domains 863 at b._dns-sd._udp. (DOMAIN-NAME). Local forward zones SHOULD 864 have this bit set, reverse zones SHOULD NOT. 866 S-bit (fully-qualified DNS-SD [RFC6763] -domain) indicates that 867 this delegated zone consists of a fully-qualified DNS-SD domain, 868 which should be used as base for DNS-SD domain enumeration, i.e. 869 _dns-sd._udp.(Zone) exists. Forward zones MAY have this bit set, 870 reverse zones MUST NOT. This can be used to provision DNS search 871 path to hosts for non-local services (such as those provided by an 872 ISP, or other manually configured service providers). Zones with 873 this flag SHOULD be added to the search domains advertised to 874 clients. 876 Zone is the label sequence of the zone, encoded according to 877 [RFC1035]. Compression MUST NOT be used. The zone MUST end with 878 an empty label. 880 8.2. Domain Name TLV 882 This TLV is used to indicate the base domain name for the network. 883 It is the zone used as a base for all non fully-qualified delegated 884 zones and node names. In case of conflicts the announced domain of 885 the node with the highest node identifier takes precedence. By 886 default ".home" is used, i.e. if no node advertises such a TLV. 888 0 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Type: DOMAIN-NAME (40) | Length: > 0 | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Domain (DNS label sequence - variable length) | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 Domain is the label sequence encoded according to [RFC1035]. 897 Compression MUST NOT be used. The zone MUST end with an empty 898 label. 900 8.3. Node Name TLV 902 This TLV is used to assign the name of a node in the network to a 903 certain IP address. In case of conflicts the announcement of the 904 node with the highest node identifier for a name takes precedence and 905 all other nodes MUST cease to announce the conflicting TLV. 907 0 1 2 3 908 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 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Type: NODE-NAME (41) | Length: > 16 | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | | 913 | IP Address | 914 | | 915 | | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Name (not null-terminated - variable length) | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 9. Securing Third-Party Protocols 922 Pre-shared keys (PSKs) are often required to secure IGPs and other 923 protocols which lack support for asymmetric security. The following 924 mechanism manages PSKs using HNCP to enable bootstrapping of such 925 third-party protocols and SHOULD therefore be used if such a need 926 arises. The following rules define how such a PSK is managed and 927 used: 929 o If no Managed-PSK-TLV is currently being announced, an HNCP router 930 MUST create one with a 32 bytes long random key and add it to its 931 node data. 933 o In case multiple routers announce such a TLV at the same time, all 934 but the one with the highest node identifier stop advertising it 935 and adopt the remaining one. 937 o The router currently advertising the Managed-PSK-TLV must generate 938 and advertise a new random one whenever an unreachable node is 939 purged as described in DNCP. 941 0 1 2 3 942 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 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Type: Managed-PSK (42) | Length: 32 | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | | 947 | | 948 | | 949 | Random PSK | 950 | | 951 | | 952 | | 953 | | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 PSKs for individual protocols are derived from the random PSK through 957 the use of HMAC-SHA256 [RFC6234] with a pre-defined per-protocol 958 HMAC-key in ASCII-format. The following HMAC-keys are currently 959 defined to derive PSKs for the respective protocols: 961 "ROUTING": to be used for IGPs 963 10. HNCP Versioning and Capabilities 965 Multiple versions of HNCP based on compatible DNCP 966 [I-D.ietf-homenet-dncp] profiles may be present in the same network 967 when transitioning between HNCP versions and HNCP routers may have 968 different capabilities to support clients. The following mechanism 969 describes a way to announce the currently active version and User- 970 agent of a node. Each node MUST include an HNCP-Version-TLV in its 971 Node Data and MUST ignore (except for DNCP synchronization purposes) 972 any TLVs with a type greater than 32 of nodes not publishing an HNCP- 973 Version TLV or publishing such a TLV with a different Version number. 975 Capabilities are indicated by setting M, P, H and L fields in the 976 TLV. The "capability value" is a metric indicated by interpreting 977 the bits as an integer, i.e. (M << 12 | P << 8 | H << 4 | L). 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Type: HNCP-VERSION (32) | Length: >= 5 | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Version | Reserved | M | P | H | L | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | User-agent | 987 Version: Version indicates which version of HNCP is currently in use 988 by this particular node. It MUST be set to 0. Nodes with 989 different versions are considered incompatible. 991 Reserved: Bits reserved for future use. MUST be set to zero when 992 creating this TLV and ignored when parsing it. 994 M-capability: Priority value used for electing the on-link MDNS 995 [RFC6762] proxy. It MUST be set to some value between 1 and 7 996 included (4 is the default) if the router is capable of proxying 997 MDNS and 0 otherwise. The values 8-15 are reserved for future 998 use. 1000 P-capability: Priority value used for electing the on-link DHCPv6-PD 1001 server. It MUST be set to some value between 1 and 7 included (4 1002 is the default) if the router is capable of providing prefixes 1003 through DHCPv6-PD (Section 6.2.6) and 0 otherwise. The values 1004 8-15 are reserved for future use. 1006 H-capability: Priority value used for electing the on-link DHCPv6 1007 server offering non-temporary addresses. It MUST be set to some 1008 value between 1 and 7 included (4 is the default) if the router is 1009 capable of providing such addresses and 0 otherwise. The values 1010 8-15 are reserved for future use. 1012 L-capability: Priority value used for electing the on-link DHCPv4 1013 server. It MUST be set to some value between 1 and 7 included (4 1014 is the default) if the router is capable of running a legacy 1015 DHCPv4 server offering IPv4 addresses to clients and 0 otherwise. 1016 The values 8-15 are reserved for future use. 1018 User-Agent: The user-agent is a null-terminated human-readable UTF-8 1019 string that describes the name and version of the current HNCP 1020 implementation. 1022 11. Requirements for HNCP Routers 1024 Each router implementing HNCP is subject to the following 1025 requirements: 1027 o It MUST implement HNCP-Versioning, Border Discovery, Prefix 1028 Assignment and Configuration of hosts and non-HNCP routers as 1029 defined in this document. 1031 o It MUST implement and run the method for securing third-party 1032 protocols whenever it uses the security mechanism of HNCP. 1034 o It SHOULD implement support for the Service Discovery and Naming 1035 TLVs as defined in this document. 1037 o It MUST implement and run the routing protocol $FOO with support 1038 for source-specific routes on all of the interfaces it sends and 1039 receives HNCP-messages on and MUST resort to announcing source- 1040 specific routes for external destinations appropriately. 1042 o It MUST use adequate security mechanisms for the routing protocol 1043 on any interface where it also uses the security mechanisms of 1044 HNCP. If the security mechanism is based on a PSK it MUST use a 1045 PSK derived from the Managed-PSK to secure the IGP. 1047 o It MUST comply with the Basic Requirements for IPv6 Customer Edge 1048 Routers [RFC7084] unless it would otherwise conflict with any 1049 requirements in this document (e.g. prefix assignment mandating a 1050 different prefix delegation and DHCP server election strategy). 1051 In general "WAN interface requirements" shall apply to external 1052 interfaces and "LAN interface requirements" to internal interfaces 1053 respectively. 1055 o It SHOULD be able to provide connectivity to IPv4-devices using 1056 DHCPv4. 1058 o It SHOULD be able to delegate prefixes to legacy IPv6 routers 1059 using DHCPv6-PD. 1061 12. Security Considerations 1063 HNCP enables self-configuring networks, requiring as little user 1064 intervention as possible. However this zero-configuration goal 1065 usually conflicts with security goals and introduces a number of 1066 threats. 1068 General security issues for existing home networks are discussed in 1069 [RFC7368]. The protocols used to set up addresses and routes in such 1070 networks to this day rarely have security enabled within the 1071 configuration protocol itself. However these issues are out of scope 1072 for the security of HNCP itself. 1074 HNCP is a DNCP [I-D.ietf-homenet-dncp]-based state synchronization 1075 mechanism carrying information with varying threat potential. For 1076 this consideration the payloads defined in DNCP and this document are 1077 reviewed: 1079 o Network topology information such as HNCP nodes and their adjacent 1080 links 1082 o Address assignment information such as delegated and assigned 1083 prefixes for individual links 1085 o Naming and service discovery information such as auto-generated or 1086 customized names for individual links and routers 1088 12.1. Border Determination 1090 As described in Section 5, an HNCP router determines the internal or 1091 external state on a per-link basis. A firewall perimeter is set up 1092 for the external links, and for internal links, HNCP and IGP traffic 1093 is allowed. 1095 Threats concerning automatic border discovery cannot be mitigated by 1096 encrypting or authenticating HNCP traffic itself since external 1097 routers do not participate in the protocol and often cannot be 1098 authenticated by other means. These threats include propagation of 1099 forged uplinks in the homenet in order to e.g. redirect traffic 1100 destined to external locations and forged internal status by external 1101 routers to e.g. circumvent the perimeter firewall. 1103 It is therefore imperative to either secure individual links on the 1104 physical or link-layer or preconfigure the adjacent interfaces of 1105 HNCP routers to an adequate fixed-category in order to secure the 1106 homenet border. Depending on the security of the external link 1107 eavesdropping, man-in-the-middle and similar attacks on external 1108 traffic can still happen between a homenet border router and the ISP, 1109 however these cannot be mitigated from inside the homenet. For 1110 example, DHCPv4 has defined [RFC3118] to authenticate DHCPv4 1111 messages, but this is very rarely implemented in large or small 1112 networks. Further, while PPP can provide secure authentication of 1113 both sides of a point to point link, it is most often deployed with 1114 one-way authentication of the subscriber to the ISP, not the ISP to 1115 the subscriber. 1117 12.2. Security of Unicast Traffic 1119 Once the homenet border has been established there are several ways 1120 to secure HNCP against internal threats like manipulation or 1121 eavesdropping by compromised devices on a link which is enabled for 1122 HNCP traffic. If left unsecured, attackers may perform arbitrary 1123 eavesdropping, spoofing or denial of service attacks on HNCP services 1124 such as address assignment or service discovery. 1126 Detailed interface categories like "leaf" or "guest" can be used to 1127 integrate not fully trusted devices to various degrees into the 1128 homenet by not exposing them to HNCP and IGP traffic or by using 1129 firewall rules to prevent them from reaching homenet-internal 1130 resources. 1132 On links where this is not practical and lower layers do not provide 1133 adequate protection from attackers, DNCP secure mode MUST be used to 1134 secure traffic. 1136 12.3. Other Protocols in the Home 1138 IGPs and other protocols are usually run alongside HNCP therefore the 1139 individual security aspects of the respective protocols must be 1140 considered. It can however be summarized that many protocols to be 1141 run in the home (like IGPs) provide - to a certain extent - similar 1142 security mechanisms. Most of these protocols do not support 1143 encryption and only support authentication based on pre-shared keys 1144 natively. This influences the effectiveness of any encryption-based 1145 security mechanism deployed by HNCP as homenet routing information is 1146 thus usually not encrypted. 1148 13. IANA Considerations 1150 IANA is requested to maintain a registry for HNCP TLV-Types. 1152 HNCP inherits the TLV-Types and allocation policy defined in DNCP 1153 [I-D.ietf-homenet-dncp]. In addition the following TLV-Types are 1154 defined in this document: 1156 32: HNCP-Version 1158 33: External-Connection 1160 34: Delegated-Prefix 1162 35: Assigned-Prefix 1164 36: Node-Address 1166 37: DHCPv4-Data 1168 38: DHCPv6-Data 1170 39: DNS-Delegated-Zone 1172 40: Domain-Name 1174 41: Node-Name 1176 42: Managed-PSK 1178 HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP- 1179 DTLS-PORT, as well as an IPv6 link-local multicast address All- 1180 Homenet-Routers. 1182 14. References 1184 14.1. Normative references 1186 [I-D.ietf-homenet-dncp] 1187 Stenberg, M. and S. Barth, "Distributed Node Consensus 1188 Protocol", draft-ietf-homenet-dncp-01 (work in progress), 1189 March 2015. 1191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1192 Requirement Levels", BCP 14, RFC 2119, March 1997. 1194 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1195 Security Version 1.2", RFC 6347, January 2012. 1197 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1198 "Prefix Exclude Option for DHCPv6-based Prefix 1199 Delegation", RFC 6603, May 2012. 1201 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1202 More-Specific Routes", RFC 4191, November 2005. 1204 [I-D.ietf-homenet-prefix-assignment] 1205 Pfister, P., Paterson, B., and J. Arkko, "Distributed 1206 Prefix Assignment Algorithm", draft-ietf-homenet-prefix- 1207 assignment-03 (work in progress), February 2015. 1209 14.2. Informative references 1211 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1212 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1213 November 2013. 1215 [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, 1216 A., Beser, B., and J. Privat, "The User Class Option for 1217 DHCP", RFC 3004, November 2000. 1219 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1220 Messages", RFC 3118, June 2001. 1222 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1223 2131, March 1997. 1225 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1226 and M. Carney, "Dynamic Host Configuration Protocol for 1227 IPv6 (DHCPv6)", RFC 3315, July 2003. 1229 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1230 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1231 December 2003. 1233 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1234 E. Lear, "Address Allocation for Private Internets", BCP 1235 5, RFC 1918, February 1996. 1237 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1238 Architecture", RFC 4291, February 2006. 1240 [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1241 "IPv6 Home Networking Architecture Principles", RFC 7368, 1242 October 2014. 1244 [RFC1035] Mockapetris, P., "Domain names - implementation and 1245 specification", STD 13, RFC 1035, November 1987. 1247 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1248 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 1250 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1251 April 1992. 1253 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1254 February 2013. 1256 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1257 Discovery", RFC 6763, February 2013. 1259 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1260 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1261 6241, June 2011. 1263 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1264 Extensions", RFC 2132, March 1997. 1266 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 1267 Static Route Option for Dynamic Host Configuration 1268 Protocol (DHCP) version 4", RFC 3442, December 2002. 1270 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1271 Addresses", RFC 4193, October 2005. 1273 14.3. URIs 1275 [3] http://www.openwrt.org 1277 [4] http://www.homewrt.org/doku.php?id=run-conf 1279 Appendix A. Some Outstanding Issues 1281 Should we define in-protocol fragmentation scheme or just use IPv6 1282 fragmentation with 'big enough' minimum acceptable size allowed for 1283 implementations? In the same sense should we use TCP over UDP? 1285 How should we deal with stub-routers requiring reduced complexity 1286 versions? Stub IGPs? An HNCP-based solution? Even a stub-HNCP? 1288 Appendix B. Changelog 1290 draft-ietf-homenet-hncp-03: Split to DNCP (generic protocol) and HNCP 1291 (homenet profile). 1293 draft-ietf-homenet-hncp-02: Removed any built-in security. Relying 1294 on IPsec. Reorganized interface categories, added requirements 1295 languages, made manual border configuration a MUST-support. 1296 Redesigned routing protocol election to consider non-router devices. 1298 draft-ietf-homenet-hncp-01: Added (MAY) guest, ad-hoc, hybrid 1299 categories for interfaces. Removed old hnetv2 reference, and now 1300 pointing just to OpenWrt + github. Fixed synchronization algorithm 1301 to spread also same update number, but different data hash case. 1302 Made purge step require bidirectional connectivity between nodes when 1303 traversing the graph. Edited few other things to be hopefully 1304 slightly clearer without changing their meaning. 1306 draft-ietf-homenet-hncp-00: Added version TLV to allow for TLV 1307 content changes pre-RFC without changing IDs. Added link id to 1308 assigned address TLV. 1310 Appendix C. Draft source 1312 This draft is available at https://github.com/fingon/ietf-drafts/ in 1313 source format. Issues and pull requests are welcome. 1315 Appendix D. Implementation 1317 A GPLv2-licensed implementation of HNCP is currently under 1318 development at https://github.com/sbyx/hnetd/ and binaries are 1319 available in the OpenWrt [3] package repositories. See [4] for more 1320 information. Feedback and contributions are welcome. 1322 Appendix E. Acknowledgements 1324 Thanks to Ole Troan, Mark Baugher, Mark Townsley and Juliusz 1325 Chroboczek for their contributions to the draft. 1327 Thanks to Eric Kline for the original border discovery work. 1329 Authors' Addresses 1331 Markus Stenberg 1332 Helsinki 00930 1333 Finland 1335 Email: markus.stenberg@iki.fi 1337 Steven Barth 1338 Halle 06114 1339 Germany 1341 Email: cyrus@openwrt.org 1343 Pierre Pfister 1344 Cisco Systems 1345 Paris 1346 France 1348 Email: pierre.pfister@darou.fr