idnits 2.17.1 draft-ietf-homenet-hncp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 15, 2014) is 3661 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: '1' on line 122 -- Looks like a reference, but probably isn't: '2' on line 127 -- Looks like a reference, but probably isn't: '3' on line 1226 == Unused Reference: 'I-D.arkko-homenet-prefix-assignment' is defined on line 1139, but no explicit reference was found in the text == Unused Reference: 'I-D.stenberg-homenet-dnssdext-hybrid-proxy-ospf' is defined on line 1144, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-pfister-homenet-prefix-assignment-00 == Outdated reference: A later version (-02) exists of draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-00 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 1597 (Obsoleted by RFC 1918) == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-11 == Outdated reference: A later version (-02) exists of draft-behringer-homenet-trust-bootstrap-00 == Outdated reference: A later version (-02) exists of draft-baker-rtgwg-src-dst-routing-use-cases-00 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 7 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: October 17, 2014 6 April 15, 2014 8 Home Networking Control Protocol 9 draft-ietf-homenet-hncp-00 11 Abstract 13 This document describes the HomeNet Control Protocol (HNCP), a 14 minimalist state synchronization protocol for Homenet routers. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on October 17, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 52 3. Data model . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4.1. Trickle-Driven Status Updates . . . . . . . . . . . . . . 4 55 4.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 5 56 4.2.1. Network State Update (NetState) . . . . . . . . . . . 5 57 4.2.2. Network State Request, (NetState-Req) . . . . . . . . 5 58 4.2.3. Node Data Request (Node-Req) . . . . . . . . . . . . 6 59 4.2.4. Network and Node State Reply (NetNode-Reply) . . . . 6 60 4.3. HNCP Protocol Message Processing . . . . . . . . . . . . 6 61 4.4. Adding and Removing Neighbors . . . . . . . . . . . . . . 8 62 4.5. Purging Unreachable Nodes . . . . . . . . . . . . . . . . 8 63 5. Type-Length-Value objects . . . . . . . . . . . . . . . . . . 8 64 5.1. Request TLVs (for use within unicast requests) . . . . . 9 65 5.1.1. Request Network State TLV . . . . . . . . . . . . . . 9 66 5.1.2. Request Node Data TLV . . . . . . . . . . . . . . . . 9 67 5.2. Data TLVs (for use in both multi- and unicast data) . . . 10 68 5.2.1. Node Link TLV . . . . . . . . . . . . . . . . . . . . 10 69 5.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 10 70 5.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 10 71 5.2.4. Node Data TLV . . . . . . . . . . . . . . . . . . . . 11 72 5.2.5. Node Public Key TLV (within 73 Node Data TLV) . . . . . . . . . . . . . . . . . . . 11 74 5.2.6. Neighbor TLV (within Node Data TLV) . . . . . . . . . 12 75 5.3. Custom TLV (within/without Node Data TLV) . . . . . . . . 12 76 5.4. Version TLV (within Node Data TLV) . . . . . . . . . . . 13 77 5.5. Authentication TLVs . . . . . . . . . . . . . . . . . . . 13 78 5.5.1. Certificate-related TLVs . . . . . . . . . . . . . . 13 79 5.5.2. Signature TLV . . . . . . . . . . . . . . . . . . . . 13 80 6. Border Discovery and Prefix Assignment . . . . . . . . . . . 14 81 7. DNS-based Service Discovery . . . . . . . . . . . . . . . . . 18 82 7.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 18 83 7.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 18 84 7.3. Router Name TLV . . . . . . . . . . . . . . . . . . . . . 18 85 8. Routing support . . . . . . . . . . . . . . . . . . . . . . . 19 86 8.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 19 87 8.2. Announcement . . . . . . . . . . . . . . . . . . . . . . 19 88 8.3. Protocol Selection . . . . . . . . . . . . . . . . . . . 20 89 8.4. Fallback Mechanism . . . . . . . . . . . . . . . . . . . 20 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 11.1. Normative references . . . . . . . . . . . . . . . . . . 23 94 11.2. Informative references . . . . . . . . . . . . . . . . . 24 95 Appendix A. Some Outstanding Issues . . . . . . . . . . . . . . 25 96 Appendix B. Some Obvious Questions and Answers . . . . . . . . . 26 97 Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 27 98 Appendix D. Draft source . . . . . . . . . . . . . . . . . . . . 27 99 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 27 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 102 1. Introduction 104 HNCP is designed to synchronize state across a Homenet (or other 105 small site) in order to facilitate automated configuration within the 106 site, integration with trusted bootstrapping 107 [I-D.behringer-homenet-trust-bootstrap] and default perimeter 108 detection [I-D.kline-homenet-default-perimeter], automatic IP prefix 109 distribution [I-D.pfister-homenet-prefix-assignment], and service 110 discovery across multiple links within the homenet as defined in 111 [I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf]. 113 HNCP is designed to provide enough information for a routing protocol 114 to operate without homenet-specific extensions. In homenet 115 environments where multiple IPv6 prefixes are present, routing based 116 on source and destination address is necessary 117 [I-D.troan-homenet-sadr]. Routing protocol requirements for source 118 and destination routing are described in section 3 of 119 [I-D.baker-rtgwg-src-dst-routing-use-cases]. 121 A GPLv2-licensed implementation of the HNCP protocol is currently 122 under development at https://github.com/sbyx/hnetd/ [1]. Comments 123 and/or pull requests are welcome. 125 An earlier implementation using many of the same principles, 126 algorithms and data structures built within OSPFv3 is available at 127 http://www.homewrt.org/doku.php?id=downloads [2]. 129 2. Requirements language 131 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 132 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 133 described in [RFC2119]. 135 3. Data model 137 The data model of the HNCP protocol is simple: Every participating 138 node has (and also knows for every other participating node): 140 A unique node identifier. It may be a public key, unique hardware 141 ID, or some other unique blob of binary data which HNCP can run a 142 hash upon to obtain a node identifer that is very likely unique 143 among the set of routers in the Homenet. 145 A set of Type-Length-Value (TLV) data it wants to share with other 146 routers. The set of TLVs have a well-defined order based on 147 ascending binary content that is used to quickly identify changes 148 in the set as they occur. 150 Latest update sequence number. A four octet number that is 151 incremented anytime TLV data changes are detected. 153 Relative time, in milliseconds, since last publishing of the 154 current TLV data set. 156 If HNCP security is enabled, each node will have a public/private key 157 pair defined. The private key is used to create signatures for 158 messages and node state updates and never sent across the network by 159 HNCP. The public key is used to verify signatures of messages and 160 node state updates. 162 4. Operation 164 HNCP is designed to run on UDP port IANA-UDP-PORT, using both link- 165 local scoped IPv6 unicast and link-local scoped IPv6 multicast 166 messages to address IANA-MULTICAST-ADDRESS for transport. The 167 protocol consists of Trickle [RFC6206] driven multicast status 168 messages to indicate changes in shared TLV data, and unicast state 169 synchronization message exchanges when the Trickle state is found to 170 be inconsistent. 172 4.1. Trickle-Driven Status Updates 174 Each node MUST send link-local multicast NetState Messages 175 (Section 4.2.1) each time the Trickle algorithm [RFC6206] indicates 176 they should on each link the protocol is active on. When the locally 177 stored network state hash changes (either by a local node event that 178 affects the TLV data, or upon receipt of more recent data from 179 another node), all Trickle instances MUST be reset. Trickle state 180 MUST be maintained separately for each link. 182 Trickle algorithm has 3 parameters; Imin, Imax and k. Imin and Imax 183 represent minimum and maximum values for I, which is the time 184 interval during which at least k Trickle updates must be seen on a 185 link to prevent local state transmission. Bounds for recommended 186 Trickle values are described below. 188 k=1 SHOULD be used, as given the timer reset on data updates, 189 retransmissions should handle packet loss. 191 Imax MUST be at least one minute. 193 Imin MUST be at least 200 milliseconds (earliest transmissions may 194 occur at Imin/2 = 100 milliseconds given minimum values as per the 195 Trickle algorithm). 197 4.2. Protocol Messages 199 Protocol messages are encoded as purely as a sequence of TLV objects 200 (Section 5). This section describes which set of TLVs MUST or MAY be 201 present in a given message. 203 In order to facilitate fast comparing of local state with that in a 204 received message update, all TLVs in every encoding scope (either 205 root level, within the message itself, or within a container TLV) 206 MUST be placed in ascending order based on the binary comparison of 207 both TLV header and value. By design, the TLVs which MUST be present 208 have the lowest available type values, ensuring they will naturally 209 occur at the start of the Protocol Message, resembling a fixed format 210 preamble. 212 4.2.1. Network State Update (NetState) 214 This Message SHOULD be sent as a multicast message. 216 The following TLVs MUST be present at the start of the message: 218 Node Link TLV (Section 5.2.1). 220 Network State TLV (Section 5.2.2). 222 The NetState Message MAY contain Node State TLV(s) (Section 5.2.3). 223 If so, either all Node State TLVs are included (referred to as a 224 "long" NetState Message), or none are included (refered to as a 225 "short" NetState Message). The NetState Message MUST NOT contain 226 only a portion of Node State TLVs as this could cause problems with 227 the Protocol Message Processing (Section 4.3) algorithm. Finally, if 228 the long version of the NetState message would exceed the minimum 229 IPv6 MTU when sent, the short version of the NetState message MUST be 230 used instead. 232 If HNCP security is enabled, authentication TLVs (Section 5.5) MUST 233 be present. 235 4.2.2. Network State Request, (NetState-Req) 237 This Message MUST be sent as a unicast message. 239 The following TLVs MUST be present at the start of the message: 241 Node Link TLV (Section 5.2.1). 243 Request Network State TLV (Section 5.1.1). 245 If HNCP security is enabled, authentication TLVs (Section 5.5) MUST 246 be present. 248 4.2.3. Node Data Request (Node-Req) 250 This Message MUST be sent as a unicast message. 252 MUST be present: 254 Node Link TLV (Section 5.2.1). 256 one or more Request Node Data TLVs (Section 5.1.2). 258 If HNCP security is enabled, authentication TLVs (Section 5.5) MUST 259 be present. 261 4.2.4. Network and Node State Reply (NetNode-Reply) 263 This Message MUST be sent as a unicast message. 265 MUST be present: 267 Node Link TLV (Section 5.2.1). 269 Network State TLV (Section 5.2.2) and Node State TLV 270 (Section 5.2.3) for every known node by the sender, or 272 one or more combinations of Node State and Node Data TLVs 273 (Section 5.2.4). 275 If HNCP security is enabled, authentication TLVs (Section 5.5) MUST 276 be present. 278 4.3. HNCP Protocol Message Processing 280 The majority of status updates among known nodes are handled via the 281 Trickle-Driven updates (Section 4.1). This section describes 282 processing of messages as received, along with associated actions or 283 responses. 285 HNCP is designed to operate between directly connected neighbors on a 286 shared link using link-local IPv6 addresses. If the source address 287 of a received HNCP packet is not an IPv6 link-local unicast address, 288 the packet SHOULD be dropped. Similarly, if the destination address 289 is not IPv6 link-local unicast or IPv6 link-local multicast address, 290 packet SHOULD be dropped. 292 Upon receipt of: 294 NetState Message (Section 4.2.1): If the network state hash within 295 the message matches the hash of the locally stored network state, 296 consider Trickle state as consistent with no further processing 297 required. If the hashes do not match, consider Trickle state as 298 inconsistent. In this case, if the message is "short" (contains 299 zero Node State TLVs), reply with a NetState-Req Message 300 (Section 4.2.2). If the message was in long format (contained all 301 Node State TLVs), reply with NodeState-Req (Section 4.2.3) for any 302 nodes for which local information is outdated (local update number 303 is lower than that within the message) or missing. Note that if 304 local information is more recent than that of the neighbor, there 305 is no need to send a message. 307 NetState-Req (Section 4.2.2): Provide requested data in a NetNode- 308 Reply Message containing Network State TLV and all Node State 309 TLVs. 311 NodeState-Req (Section 4.2.3): Provide requested data in a 312 NetNode-Reply containing Node State and Node Data TLVs. 314 State-Reply (Section 4.2.4): If the message contains Node State 315 TLVs that are more recent than local state (higher update number 316 or we lack the node data altogether), if the message also contains 317 corresponding Node Data TLVs, update local state and reset 318 Trickle. If the message is lacking Node Data TLVs for some Node 319 State TLVs which are more recent than local state, reply with a 320 NodeState-Req (Section 4.2.3) for the corresponding nodes. 322 Each node is responsible for publishing a valid set of data TLVs. 323 When there is a change in a node's set of data TLVs, the update 324 number MUST be incremented accordingly. 326 If a message containing Node State TLVs (Section 5.2.3) is received 327 via unicast or multicast with the node's own node identifier and a 328 higher update number than current local value, or the same update 329 number and different hash, there is an error somewhere. A 330 recommended default way to handle this is to attempt to assert local 331 state by increasing the local update number to a value higher than 332 that received and republish node data using the same node identifier. 333 If this happens more than 3 times in 60 seconds and the local node 334 identifier is not globally unique, there may be more than one router 335 with the same node identifier on the network. If HNCP security is 336 not enabled, a new node identifier SHOULD be generated and node data 337 republished accordingly. If HNCP security is enabled, this is event 338 is highly unlikely to occur as collision of identifier hashes for 339 public keys is highly unlikely. 341 In all cases, if node data for any node changes, all Trickle 342 instances MUST be considered inconsistent (I=Imin + timer reset). 344 4.4. Adding and Removing Neighbors 346 Whenever multicast message or unicast reply is received on a link 347 from another node, the node should be added as Neighbor TLV 348 (Section 5.2.6) for current node. If nothing (for example - no 349 router advertisements, no HNCP traffic) is received from that 350 neighbor in Imax seconds and the neighbor is not in neighbor 351 discovery cache (and L2 indication of presence is available), at 352 least 3 attempts to ping it with request network state message 353 (Section 4.2.2) SHOULD be sent with increasing timeouts (e.g. 1, 2, 4 354 seconds). If even after suitable period after the last message 355 nothing is received, the Neighbor TLV MUST be removed so that there 356 are no dangling neighbors. As an alternative, if there is a layer 2 357 unreachability notification of some sort available for either whole 358 link or for individual neighbor, it MAY be used to immediately 359 trigger removal of corresponding Neighbor TLV(s). 361 4.5. Purging Unreachable Nodes 363 Nodes should be purged when unreachable. When node data has changed, 364 the neighbor graph SHOULD be traversed for each node following the 365 Neighbor TLVs, purging nodes that were found entirely unreachable 366 (not traversed). 368 5. Type-Length-Value objects 370 Every TLV is encoded as 2 octet type, followed by 2 octet length (of 371 the whole TLV, including header; 4 means no value whatsoever), and 372 then the value itself (if any). The actual length of TLV MUST be 373 always divisible by 4; if the length of the value is not, zeroed 374 padding bytes MUST be inserted at the end of TLV. The padding bytes 375 MUST NOT be included in the length field. 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Type | Length | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Value | 383 | (variable # of bytes) | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Encoding of type=123 (0x7b) TLV with value 'x' (120 = 0x78): 007B 387 0005 7800 0000 389 Notation: 391 .. = octet string concatenation operation 393 H(x) = MD5 hash of x 395 H-64(x) = H(x) truncated by taking just first 64 bits of the 396 result. 398 5.1. Request TLVs (for use within unicast requests) 400 5.1.1. Request Network State TLV 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Type: REQ-NETWORK-STATE (2) | Length: 4 | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 5.1.2. Request Node Data TLV 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Type: REQ-NODE-DATA (3) | Length: 20 | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | | 416 | H(node identifier) | 417 | | 418 | | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 5.2. Data TLVs (for use in both multi- and unicast data) 423 5.2.1. Node Link TLV 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type: NODE-LINK (1) | Length: 24 | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | | 431 | H(node identifier) | 432 | | 433 | | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Link-Identifier | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 5.2.2. Network State TLV 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Type: NETWORK-STATE (4) | Length: 20 | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | | 446 | H(H(node data TLV 1) .. H(node data TLV N)) | 447 | | 448 | | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 The Node Data TLVs are ordered for hashing by octet comparison of the 452 corresponding node identifier hashes in ascending order. 454 5.2.3. Node State TLV 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Type: NODE-STATE (5) | Length: 44 | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | | 462 | H(node identifier) | 463 | | 464 | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Update Sequence Number | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Milliseconds since Origination | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | | 471 | H(node data TLV) | 472 | | 473 | | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 The whole network should have roughly the same idea about the time 477 since origination, i.e. even the originating router should increment 478 the time whenever it needs to send a new Node State TLV regarding 479 itself without changing the corresponding Node Data TLV. This age 480 value is not included within the Node Data TLV, however, as that is 481 immutable and potentially signed by the originating node at the time 482 of origination. 484 5.2.4. Node Data TLV 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type: NODE-DATA (6) | Length: >= 24 | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | 492 | H(node identifier) | 493 | | 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Update Sequence Number | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Nested TLVs containing node information | 500 The Node Public Key TLV (Section 5.2.5) SHOULD be always included if 501 signatures are ever used. 503 If signatures are in use, the Node Data TLV SHOULD also contain the 504 originator's own Signature TLV (Section 5.5.2). 506 5.2.5. Node Public Key TLV (within Node Data TLV) 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Type: PUBLIC-KEY (7) | Length: >= 4 | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Public Key (raw node identifier) | 515 Public key data for the node. Only relevant if signatures are used. 516 Can be used to verify that H(node identifier) in the received data 517 for the node equals H(public key), and that the Signature TLVs are 518 signed by appropriate public keys. 520 5.2.6. Neighbor TLV (within Node Data TLV) 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Type: NEIGHBOR (8) | Length: 28 | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | | 528 | H(neighbor node identifier) | 529 | | 530 | | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Neighbor Link Identifier | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Local Link Identifier | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 This TLV indicates that the node in question vouches that the 538 specified neighbor is reachable by it on the local link id given. 539 This reachability may be unidirectional (if no unicast exchanges have 540 been performed with the neighbor). The presence of this TLV at least 541 guarantees that the node publishing it has received traffic from the 542 neighbor recently. For guaranteed bidirectional reachability, 543 existence of both nodes' matching Neighbor TLVs should be checked. 545 5.3. Custom TLV (within/without Node Data TLV) 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type: CUSTOM-DATA (9) | Length: >= 12 | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | H-64(URI) | 553 | | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Opaque Data | 556 This TLV can be used to contain anything; the URI used should be 557 under control of the author of that specification. For example: 559 V=H-64('http://example.com/author/json-for-hncp') .. '{"cool": "json 560 extension!"}' 562 or 564 V=H-64('mailto:author@example.com') .. '{"cool": "json extension!"}' 566 5.4. Version TLV (within Node Data TLV) 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Type: VERSION (10) | Length: >= 8 | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Version | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | User-agent | 577 This TLV indicates which version of HNCP TLV binary structures is in 578 use by this particular node. All TLVs within node data from nodes 579 that do not publish version TLV, or with different Version value than 580 locally supported one MUST be ignored (but forwarded). under control 581 of the author of that specification. The user-agent is an optional 582 human-readable UTF-8 string that can describe e.g. current hnetd 583 version. This draft describes Version=1 TLVs. 585 5.5. Authentication TLVs 587 5.5.1. Certificate-related TLVs 589 TBD; should be probably some sort of certificate ID to be used in a 590 lookup at most, as raw certificates will overflow easily IPv6 minimum 591 MTU. 593 5.5.2. Signature TLV 595 TLV with T=0xFFFF, V=(TBD) public key algorithm based signature of 596 all TLVs within current scope as well as the parent TLV header, if 597 any. The assumed signature key is private key matching the public 598 key of the the originator of node link TLV (if signature TLV is 599 within main body of message), or that of the originator of the node 600 data TLV (if signature TLV is within Node Data TLV).. 602 Given the ordering of TLVs, this TLV should be last one processed 603 within current scope. 605 6. Border Discovery and Prefix Assignment 607 Using Default Border Definition [I-D.kline-homenet-default-perimeter] 608 as a basis, this section defines border discovery algorithm specifics 609 derived from the edge router interactions described in the Basic 610 Requirements for IPv6 Customer Edge Routers [RFC7084]. The algorithm 611 is designed to work for both IPv4 and IPv6 (single or dual-stack). 613 In order to avoid conflicts between border discovery and homenet 614 routers running DHCP [RFC2131] or DHCPv6-PD [RFC3633] servers each 615 router MUST implement the following mechanism based on The User Class 616 Option for DHCP [RFC3004] or its DHCPv6 counterpart [RFC3315] 617 respectively into its DHCP and DHCPv6-logic: 619 A homenet router running a DHCP-client on a homenet-interface MUST 620 include a DHCP User-Class consisting of the ASCII-String 621 "HOMENET". 623 A homenet router running a DHCP-server on a homenet-interface MUST 624 ignore or reject DHCP-Requests containing a DHCP User-Class 625 consisting of the ASCII-String "HOMENET". 627 An interface MUST be considered external if at least one of the 628 following conditions is satisfied: 630 1. The interface has a fixed category classifying it as external. 632 2. A delegated prefix could be acquired by running a DHCPv6-client 633 on the interface. 635 3. An IPv4-address could be acquired by running a DHCP-client on the 636 interface. 638 4. HNCP security is enabled and there are routers on the interface 639 which could not be authenticated. 641 Each router MUST continuously scan each active interface that does 642 not have a fixed category in order to dynamically reclassify it if 643 necessary. The router therefore runs an appropriately configured 644 DHCP and DHCPv6-client as long as the interface is active including 645 states where it considers the interface to be internal. The router 646 SHOULD wait for a reasonable time period (5 seconds as a possible 647 default) in which the DHCP-clients can acquire a lease before 648 treating a newly activated or previously external interface as 649 internal. Once it treats a certain interface as internal it MUST 650 start forwarding traffic with appropriate source addresses between 651 its internal interfaces and allow internal traffic to reach external 652 networks. Once a router detects an interface to be external it MUST 653 stop any previously enabled internal forwarding. In addition it 654 SHOULD announce the acquired information for use in the homenet as 655 described in later sections of this draft if the interface appears to 656 be connected to an external network. 658 To distribute an external connection in the homenet an edge router 659 announces one or more delegated prefixes and associated 660 DHCP(v6)-encoded auxiliary information like recursive DNS-servers. 661 Each external connection is announced using one container-TLV as 662 follows: 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Type: EXTERNAL-CONNECTION (41)| Length: > 4 | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Nested TLVs | 671 Auxiliary connectivity information is encoded as a stream of 672 DHCPv6-attributes or DHCP-attributes placed inside a TLV of type 673 EXTERNAL-CONNECTION or DELEGATED-PREFIX (for IPv6 prefix-specific 674 information). There MUST NOT be more than one instance of this TLV 675 inside a container and the order of the DHCP(v6)-attributes contained 676 within it MUST be preserved as long as the information contained does 677 not change. The TLVs are encoded as follows: 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Type: DHCPV6-DATA (45) | Length: > 4 | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | DHCPv6 attribute stream | 686 and 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Type: DHCP-DATA (44) | Length: > 4 | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | DHCP attribute stream | 694 Each delegated prefix is encoded using one TLV inside an EXTERNAL- 695 CONNECTION TLV. For external IPv4 connections the prefix is encoded 696 in the form of an IPv4-mapped address [RFC4291] and is usually from a 697 private address range [RFC1597]. The related TLV is defined as 698 follows. 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Type: DELEGATED-PREFIX (42) | Length: >= 13 | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Valid until (milliseconds) | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Preferred until (milliseconds) | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Prefix Length | | 710 +-+-+-+-+-+-+-+-+ Prefix Address [+ nested TLVs] + 711 | | 713 Valid until is the time in milliseconds the delegated prefix is 714 valid. The value is relative to the point in time the TLV is 715 first announced. 717 Preferred until is the time in milliseconds the delegated prefix 718 is preferred. The value is relative to the point in time the TLV 719 is first announced. 721 Prefix length specifies the number of significant bits in the 722 prefix. 724 Prefix address is of variable length and contains the significant 725 bits of the prefix padded with zeroes up to the next byte 726 boundary. 728 Nested TLVs might contain prefix-specific information like 729 DHCPv6-options. 731 In order for routers to use the distributed information, prefixes and 732 addresses have to be assigned to the interior links of the homenet. 733 A router MUST therefore implement the algorithm defined in Prefix and 734 Address Assignment in a Home Network 735 [I-D.pfister-homenet-prefix-assignment]. In order to announce the 736 assigned prefixes the following TLVs are defined. 738 Each assigned prefix is given to an interior link and is encoded 739 using one TLVs. Assigned IPv4 prefixes are stored as mapped 740 IPv4-addresses. The TLV is defined as follows: 742 0 1 2 3 743 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 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Type: ASSIGNED-PREFIX (43) | Length: >= 9 | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Link Identifier | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | R. |A| Pref. | Prefix Length | | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix Address + 751 | | 753 Link Identifier is the local HNCP identifier of the link the 754 prefix is assigned to. 756 R. is reserved for future additions and MUST be set to 0 when 757 creating TLVs and ignored when parsing them. 759 A is the authoritative flag which indicates that an assigment is 760 enforced and ignores usual collision detection rules. 762 Pref. describes the preference of the assignment and can be used 763 to differentiate the importance of a given assignment over others. 765 Prefix length specifies the number of significant bits in the 766 prefix. 768 Prefix address is of variable length and contains the significant 769 bits of the prefix padded with zeroes up to the next byte 770 boundary. 772 In some cases (e.g. IPv4) the set of addresses is very limited and 773 stateless mechanisms are not really suitable for address assignment. 774 Therefore HNCP can manage router address in these cases by itself. 775 Each router assigning an address to one of its interfaces announces 776 one TLV of the following kind: 778 0 1 2 3 779 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 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Type: ROUTER-ADDRESS (46) | Length: 24 | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Link Identifier | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | | 786 | Router Address | 787 | | 788 | | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 Link Identifier is the local HNCP identifier of the link the 792 address is assigned to. 794 Router Address is the address assigned to one of the router 795 interfaces. 797 7. DNS-based Service Discovery 799 Service discovery is generally limited to a local link. 800 [I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf] defines a 801 mechanism to automatically extended DNS-based service discovery 802 across multiple links within the home automatically. Following TLVs 803 MAY be used to provide transport for that specification. 805 7.1. DNS Delegated Zone TLV 807 0 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Type: DNS-DELEGATED-ZONE (50) | Length: >= 21 | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | | 813 | Address | 814 | | 815 | | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Reserved |S|B| | 818 +-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) | 819 | | 821 7.2. Domain Name TLV 823 0 1 2 3 824 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 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Type: DOMAIN-NAME (51) | Length: >= 4 | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Domain (DNS label sequence - variable length) | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 7.3. Router Name TLV 832 0 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Type: ROUTER-NAME (52) | Length: >= 4 | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Name (not null-terminated - variable length) | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 8. Routing support 842 8.1. Protocol Requirements 844 In order to be advertised for use within the Homenet, a routing 845 protocol MUST: 847 Comply with Requirements and Use Cases for Source/Destination 848 Routing [I-D.baker-rtgwg-src-dst-routing-use-cases]. 850 Be configured with suitable defaults or have an autoconfiguration 851 mechanism (e.g. [I-D.acee-ospf-ospfv3-autoconfig]) such that it 852 will run in a Homenet without requiring specific configuration 853 from the Home user. 855 A router MUST NOT announce that it supports a certain routing 856 protocol if its implementation of the routing protocol does not meet 857 these requirements, e.g. it does not implement extensions that are 858 necessary for compliance. 860 8.2. Announcement 862 Each router SHOULD announce all routing protocols that it is capable 863 of supporting in the Homenet. It SHOULD assign a preference value 864 for each protocol that indicates its desire to use said protocol over 865 other protocols it supports and SHOULD make these values 866 configurable. 868 Each router includes one HNCP TLV of type ROUTING-PROTOCOL for every 869 such routing protocol. This TLV is defined as follows: 871 0 1 2 3 872 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 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Type: ROUTING-PROTOCOL (60) | Length: 6 | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Protocol ID | Preference | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 Protocol ID is one of: 880 0 = reserved 882 1 = Babel (dual-stack) 884 2 = OSPFv3 (dual-stack) 886 3 = IS-IS (dual-stack) 888 4 = RIP (dual-stack) 890 Preference is a value from 0 to 255. If a router is neutral about 891 a routing protocol it SHOULD use the value 128, otherwise a lower 892 value indicating lower preference or a higher value indicating 893 higher preference respectively. 895 8.3. Protocol Selection 897 When HNCP detects that a router has joined or left the Homenet it 898 MUST examine all advertised routing protocols and preference values 899 from all routers in the Homenet in order to find the one routing 900 protocol which: 902 1. Is understood by all routers in the homenet 904 2. Has the highest preference value among all routers (calculated as 905 sum of preference values) 907 3. Has the highest protocol ID among those with the highest 908 preference 910 If the router protocol selection results in the need to change from 911 one routing protocol to another on the homenet, the router MUST stop 912 the previously running protocol, remove associated routes, and start 913 the new protocol in a graceful manner. If there is no common routing 914 protocol available among all Homenet routers, routers MUST utilize 915 the Fallback Mechanism (Section 8.4). 917 8.4. Fallback Mechanism 919 In cases where there is no commonly supported routing protocol 920 available the following fallback algorithm is run to setup routing 921 and preserve interoperability among the homenet. While not intended 922 to replace a routing protocol, this mechanism provides a valid - but 923 not necessarily optimal - routing topology. This algorithm uses the 924 node and neighbor state already synchronized by HNCP, and therefore 925 does not require any additional protocol message exchange. 927 1. Interpret the neighbour information received via HNCP as a graph 928 of connected routers. 930 2. Use breadth-first traversal to determine the next-hop and hop- 931 count in the path to each router in the homenet: 933 Start the traversal with the immediate neighbours of the 934 router running the algorithm. 936 Always visit the immediate neighbours of a router in ascending 937 order of their router ID. 939 Never visit a router more often than once. 941 3. For each delegated prefix P of any router R in the homenet: 942 Create a default route via the next-hop for R acquired in #2. 943 Each such route MUST be source-restricted to only apply to 944 traffic with a source address within P and its metric MUST 945 reflect the hop-count to R. 947 4. For each assigned prefix A of a router R: Create a route to A via 948 the next-hop for R acquired in #2. Each such route MUST NOT be 949 source-restricted. 951 5. For the first router R visited in the traversal annuncing an 952 IPv4-uplink: Create a default IPv4-route via the next-hop for R 953 acquired in #2. 955 6. For each assigned IPv4-prefix A of a router R: Create an 956 IPv4-route to A via the next-hop for R acquired in #2. 958 9. Security Considerations 960 General security issues for Home Networks are discussed at length in 961 [I-D.ietf-homenet-arch]. The protocols used to setup IP in home 962 networks today have very little security enabled within the control 963 protocol itself. For example, DHCP has defined [RFC3118] to 964 authenticate DHCP messages, but this is very rarely implemented in 965 large or small networks. Further, while PPP can provide secure 966 authentication of both sides of a point to point link, it is most 967 often deployed with one-way authentication of the subscriber to the 968 ISP, not the ISP to the subscriber. HNCP aims to make security as 969 easy as possible for the implementer by including built-in 970 capabilities for authentication of node data being exchanged as well 971 as the protocol messages themselves, but it is ultimately up to the 972 shipping system to take advantage of the protocol constructs defined. 974 HNCP is designed to integrate with trusted bootstrapping 975 [I-D.behringer-homenet-trust-bootstrap] including the ability to 976 authenticate messages between nodes. This authentication can be used 977 to securely define a border as well as protect against malicious 978 attacks and spoofing attempts from inside or outside the border. 980 HNCP itself sends messages as (possibly authenticated) clear text 981 which is as secure, or insecure, as the security of the link below as 982 discussed in [I-D.kline-homenet-default-perimeter]. When no unique 983 public key is available, a hardware fingerprint or equivalent to 984 identify routers must be available for use by HNCP. 986 As HNCP messages are sent over UDP/IP, IPsec may be used for 987 confidentiality or additional message authenitation. However, this 988 requires manually keyed IPsec per-port granularity for port IANA-UDP- 989 PORT UDP traffic. Also, a pre-shared key has to be utilized in this 990 case given IKE cannot be used with multicast traffic. 992 If no router can be trusted and additional guarantees about source of 993 node status updates is necessary, real public and private keys should 994 be used to create signatures and verify them in HNCP on both on per- 995 node data TLVs as well as across the entire HNCP message. In this 996 mode, care must be taken in rate limiting verification of invalid 997 packets, as otherwise denial of service may occur due to exhaustion 998 of computation resources. 1000 As a performance optimization, instead of providing signatures for 1001 actual node data and the protocol messages themselves, it is also 1002 possible to provide signatures just for protocol messages. While 1003 this means it is no longer possible to verify the original source of 1004 the node data itself, as long as the set of routers is trusted (i.e., 1005 no router in the set has itself been hacked to provide malicious node 1006 data) then one can assume the node data is trusted because the router 1007 is trusted and the data arrived in a protected protocol message. 1009 10. IANA Considerations 1011 IANA should set up a registry (policy TBD) for HNCP TLV types, with 1012 following initial contents: 1014 0: Reserved (should not happen on wire) 1016 1: Node link 1018 2: Request network state 1020 3: Request node data 1021 4: Network state 1023 5: Node state 1025 6: Node data 1027 7: Node public key 1029 8: Neighbor 1031 9: Custom 1033 10: Version 1035 41: External connection 1037 42: Delegated prefix 1039 43: Assigned prefix 1041 44: DHCP-data 1043 45: DHCPv6-data 1045 46: Router-address 1047 50: DNS Delegated Zone 1049 51: Domain name 1051 52: Node name 1053 60: Routing protocol 1055 65535: Signature 1057 HNCP will also require allocation of a UDP port number IANA-UDP-PORT, 1058 as well as IPv6 link-local multicast address IANA-MULTICAST-ADDRESS. 1060 11. References 1062 11.1. Normative references 1064 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1065 Requirement Levels", BCP 14, RFC 2119, March 1997. 1067 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1068 "The Trickle Algorithm", RFC 6206, March 2011. 1070 [I-D.pfister-homenet-prefix-assignment] 1071 Pfister, P., Paterson, B., and J. Arkko, "Prefix and 1072 Address Assignment in a Home Network", draft-pfister- 1073 homenet-prefix-assignment-00 (work in progress), February 1074 2014. 1076 [I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf] 1077 Stenberg, M., "Auto-Configuration of a Network of Hybrid 1078 Unicast/Multicast DNS-Based Service Discovery Proxy 1079 Nodes", draft-stenberg-homenet-dnssd-hybrid-proxy- 1080 zeroconf-00 (work in progress), February 2014. 1082 11.2. Informative references 1084 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1085 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1086 November 2013. 1088 [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, 1089 A., Beser, B., and J. Privat, "The User Class Option for 1090 DHCP", RFC 3004, November 2000. 1092 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1093 Messages", RFC 3118, June 2001. 1095 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1096 2131, March 1997. 1098 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1099 and M. Carney, "Dynamic Host Configuration Protocol for 1100 IPv6 (DHCPv6)", RFC 3315, July 2003. 1102 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1103 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1104 December 2003. 1106 [RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de 1107 Groot, "Address Allocation for Private Internets", RFC 1108 1597, March 1994. 1110 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1111 Architecture", RFC 4291, February 2006. 1113 [I-D.ietf-homenet-arch] 1114 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1115 "IPv6 Home Networking Architecture Principles", draft- 1116 ietf-homenet-arch-11 (work in progress), October 2013. 1118 [I-D.troan-homenet-sadr] 1119 Troan, O. and L. Colitti, "IPv6 Multihoming with Source 1120 Address Dependent Routing (SADR)", draft-troan-homenet- 1121 sadr-01 (work in progress), September 2013. 1123 [I-D.behringer-homenet-trust-bootstrap] 1124 Behringer, M., Pritikin, M., and S. Bjarnason, 1125 "Bootstrapping Trust on a Homenet", draft-behringer- 1126 homenet-trust-bootstrap-00 (work in progress), October 1127 2012. 1129 [I-D.baker-rtgwg-src-dst-routing-use-cases] 1130 Baker, F., "Requirements and Use Cases for Source/ 1131 Destination Routing", draft-baker-rtgwg-src-dst-routing- 1132 use-cases-00 (work in progress), August 2013. 1134 [I-D.kline-homenet-default-perimeter] 1135 Kline, E., "Default Border Definition", draft-kline- 1136 homenet-default-perimeter-00 (work in progress), March 1137 2013. 1139 [I-D.arkko-homenet-prefix-assignment] 1140 Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment 1141 in a Home Network", draft-arkko-homenet-prefix- 1142 assignment-04 (work in progress), May 2013. 1144 [I-D.stenberg-homenet-dnssdext-hybrid-proxy-ospf] 1145 Stenberg, M., "Hybrid Unicast/Multicast DNS-Based Service 1146 Discovery Auto-Configuration Using OSPFv3", draft- 1147 stenberg-homenet-dnssdext-hybrid-proxy-ospf-00 (work in 1148 progress), June 2013. 1150 [I-D.acee-ospf-ospfv3-autoconfig] 1151 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 1152 draft-acee-ospf-ospfv3-autoconfig-03 (work in progress), 1153 July 2012. 1155 Appendix A. Some Outstanding Issues 1157 Should we use MD5 hashes, or EUI-64 node identifier to identify 1158 nodes? 1160 Is there a case for non-link-local unicast? Currently explicitly 1161 stating this is link-local only protocol. 1163 Consider if using Trickle with k=1 really pays off, as we need to do 1164 reachability checks if L2 doesn't provide them periodically in any 1165 case. Using Trickle with k=inf would remove the need for unicast 1166 reachability checks, but at cost of extra multicast traffic. On the 1167 other hand, N*(N-1)/2 unicast reachability checks when lot of routers 1168 share a link is not appealing either. 1170 Should we use something else than MD5 as hash? It IS somewhat 1171 insecure; however signature stuff (TBD) should rely on it mainly for 1172 security in any case, and MD5 is used in a non-security role. 1174 Valid and preferred are now 32 bit millisecond and you cannot even 1175 represent a month in them; is this enough? Or should we switch to 32 1176 bit seconds (or 64 bit milliseconds)? 1178 Appendix B. Some Obvious Questions and Answers 1180 Q: Why not use TCP? 1182 A: It doesn't address the node discovery problem. It also leads to 1183 N*(N-1)/2 connections when N nodes share a link, which is awkward. 1185 Q: Why not multicast-only? 1187 A: It would require defining application level fragmentation scheme. 1188 Hopefully the data amounts used will stay small so we just trust 1189 unicast UDP to handle 'big enough' packets to contain single node's 1190 TLV data. On some link layers unicast is also much more reliable 1191 than multicast, especially for large packets. 1193 Q: Why so long IDs? Why real hash even in insecure mode? 1195 A: Scalability of protocol isn't really affected by using real 1196 (=cryptographic) hash function. 1198 Q: Why trust IPv6 fragmentation in unicast case? Why not do L7 1199 fragmentation? 1201 A: Because it will be there for a while at least. And while PMTU et 1202 al may be problems on open internet, in a home network environment 1203 UDP fragmentation should NOT be broken in the foreseeable future. 1205 Q: Should there be nested container syntax that is actually self- 1206 describing? (i.e. type flag that indicates container, no body except 1207 sub-TLVs?) 1209 A: Not for now, but perhaps valid design.. TBD. 1211 Q: Why not doing (performance thing X, Y or Z)? 1212 A: This is designed mostly to be minimal (only timers Trickle ones; 1213 everything triggered by Trickle-driven messages or local state 1214 changes). However, feel free to suggest better (even more minimal) 1215 design which works. 1217 Appendix C. Changelog 1219 draft-ietf-homenet-hncp-00: Added version TLV to allow for TLV 1220 content changes pre-RFC without changing IDs. Added link id to 1221 assigned address TLV. 1223 Appendix D. Draft source 1225 As usual, this draft is available at https://github.com/fingon/ietf- 1226 drafts/ [3] in source format (with nice Makefile too). Feel free to 1227 send comments and/or pull requests if and when you have changes to 1228 it! 1230 Appendix E. Acknowledgements 1232 Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley and 1233 Juliusz Chroboczek for their contributions to the draft. 1235 Authors' Addresses 1237 Markus Stenberg 1238 Helsinki 00930 1239 Finland 1241 Email: markus.stenberg@iki.fi 1243 Steven Barth 1245 Email: cyrus@openwrt.org