idnits 2.17.1 draft-rashid-6lo-iid-assignment-03.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 date (March 12, 2017) is 2602 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) == Missing Reference: 'RFC5226' is mentioned on line 447, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo AR. Sangi 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 13, 2017 C. Perkins 6 Futurewei 7 March 12, 2017 9 Designating 6LBR for IID Assignment 10 draft-rashid-6lo-iid-assignment-03 12 Abstract 14 In IPv6 Stateless Address Autoconfiguration (SLAAC), randomizing the 15 interface identifier (IID) is a common practice to promote privacy. 16 If there are a very large number of nodes, as has been discussed in 17 several use cases, the effect will to proportionately increase the 18 number of IIDs. A duplicate address detection (DAD) cycle is needed 19 for each configured IID, introducing more and more overhead into the 20 network. Each failed DAD requires the initiating node to regenerate 21 a new IID and undergo the DAD cycle again. This document proposes an 22 optimized approach when higher privacy is required in a given network 23 by allowing a 6LBR (6LoWPAN Border Router) to provide a unique IID, 24 avoiding any potential duplication. Such practice also prevents 25 failure of time-critical applications, by enabling 6LBR to provide a 26 unique IID, in case of address collision. 28 Further improvements are proposed to enable multiple concurrent DAD 29 cycles, and to return the randomized IID from 6LBR to 6LN in a space- 30 efficient manner. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 13, 2017. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Likelihood of Address Collision . . . . . . . . . . . . . . . 4 69 4. IID Assignment by 6LBR . . . . . . . . . . . . . . . . . . . 4 70 4.1. Advantages of proposed algorithm . . . . . . . . . . . . 6 71 4.2. Extended Duplicate Address Request (EDAR) . . . . . . . . 6 72 4.3. Extended Duplicate Address Confirmation (EDAC) . . . . . 7 73 4.4. Extended Address Registration Option . . . . . . . . . . 7 74 5. Multiple DAD cycles . . . . . . . . . . . . . . . . . . . . . 8 75 6. XOR Encoding . . . . . . . . . . . . . . . . . . . . . . . . 8 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 7.1. EDAR and EDAC Messages, and EARO Option . . . . . . . . . 9 78 7.2. Additions to Status Field . . . . . . . . . . . . . . . . 10 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 9.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 IPv6 addresses in SLAAC are formed by concatenating a network prefix, 88 acquired from Router Advertisement (RA) messages, with a locally 89 generated IID [RFC4862], [RFC2464]. Since the best method for 90 generating IIDs varies depending on the network, none of the proposed 91 mechanisms [RFC4941],[RFC7217] is considered a default mechanism. 92 Using neighbour discovery (ND), the uniqueness of newly a generated 93 IID is verified [RFC6775]. 6LBR performs DAD, and replies with a 94 status. A failed DAD would require the initiating 6LN (6LoWPAN node) 95 to regenerate an IID and wait for another DAD cycle, until the 6LN 96 successfully registers a unique address [RFC6775]. 98 A locally generated IID can be derived either from an embedded IEEE 99 identifier [RFC4941], or randomly (based on a few variables) 100 [RFC7217]. Since MAC reuse is unfortunately far more common than 101 usually assumed [RFC7217][MAC-Duplication], IIDs derived from MAC 102 address are likely to cause more than the expected number of DAD 103 failures. As soon as the 6LN generates an IID, it sends the NS 104 (Neighbor Solicitation) message to 6LR (LLN Router). Then 6LR 105 proceeds to send an ICMPv6 based DAR (Duplicate Address Request) 106 message to 6LBR. An LN sends out a NS after checking its local cache 107 for duplication; before proceeding with DAR, the 6LR also protects 108 against address duplication within a locally maintained Neighbor 109 Cache Entry (NCE) [RFC7217]. 111 Use cases including huge numbers of nodes and vast scale networks are 112 discussed in [RFC5548], [RFC5827]. The use of arbitrary IIDs can 113 resolve privacy concerns for a participating node, but a simple NS 114 intended to be targeted to a small group of nodes can pollute a great 115 deal of wireless bandwidth [I-D.vyncke-6man-mcast-not-efficient]. 116 Multicast NS and NA are much more frequent in large scale radio 117 environment with mobile devices [I-D.ietf-6lo-backbone-router]. 118 Since the IIDs may be sporadically changed for privacy, the 119 probability further increases that a duplicate IIDs would result in 120 DAD failure and repeated DAD cycles. 122 On the other hand, waiting for 6LN to regenerate another IID due to a 123 failed DAD might lead to failure of a time-critical application. 125 Address assignment can also be done using DNS (Domain Name Server), 126 but doing so typically requires multicast traffic and introduces more 127 control overhead. Unlike DNS, the 6LoWPAN ND works on layer 2 and 128 our proposed mechanism implicitly provides assistance to the DAD 129 process. 131 This document describes improvements to 6LoWPAN ND which enable 6LBR 132 to grant a unique IID for failed DAD, to enable multiple concurrent 133 DAD cycles, and to return an IID to 6LN in a space-efficient manner. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in 140 [RFC2119]. This document uses terminology from [RFC6775], [RFC2464], 141 [RFC8064], and [RFC7721]. 143 SLLAO: Stateless Link-Local Address Option 145 RID: Random IDentifier 146 PRF: Pseudo Random Function 148 IID: Interface IDentifier 150 This document also uses the following terms: 152 EARO: Extended Address Registration Option 154 EDAR: Extended Duplicate Address Request 156 EDAC: Extended Duplicate Address Confirmation 158 LSB: Least Significant Bit 160 3. Likelihood of Address Collision 162 The following observations have motivated the design of this 163 proposal: 165 o Manufacturer may not follow a fine grained randomness in MAC 166 addresses. 168 o MAC addresses shorter than 64 bits are used in various constrained 169 technologies. 171 o The frequency of an IID being changed depends on the degree of 172 privacy that a particular application requires. 174 o Depending upon the method by which an IID is generated using MAC 175 address, or with shorter MAC addresses, address collisions may 176 become much more likely. 178 4. IID Assignment by 6LBR 180 MAC driven IIDs [RFC2464] reduce or eliminate the need for DAD, but 181 in practice such IID generation is discouraged ([RFC8064], 182 [RFC7721]), as common privacy concerns still persist, for instance: 184 o Network activity correlation, 186 o Location tracking, 188 o Address scanning, and 190 o Device-specific vulnerability exploitation. 192 Multiple approaches are proposed to suit different network 193 constraints. The mechanisms specified in [RFC4941], which are mainly 194 based on MAC address or an appropriate simple random number 195 generation algorithm can also be used to generate IID. 197 Considering the scalability of a network and enabling 6LBR to 198 randomize an IID, the method for IID generation specified in 199 [RFC7217] SHOULD be used because this method is appropriate to 200 support periodically changing IIDs. 202 RID (Random Identifier) := 203 |Prefix|Interface Index|N/W ID|DAD Counter|Randomized Secret Key| 204 \ / 205 \ / 206 \ / 207 +--------+--------+--------+ 208 | Hash Function | 209 +--------+--------+--------+ 210 / \ 211 / \ 212 Extract 64 LSBs 214 Figure 1: Using RFC7217 to generate IID 216 If DAD fails, the 6LBR will use public values for Prefix, Interface 217 Index, and Network ID; the remaining two variables (DAD Counter, 218 Randomized Secret Key) are local values. Neighbor solicitation using 219 link-local address cannot be avoided, but only the newly generated 220 IID needs to be forwarded to the LN. 222 6LN 6LR 6LBR 223 | | | 224 1. | --- NS with Address Reg --> | | 225 | [ARO + SLLAO] | | 226 | | | 227 2. | | ---------- EDAR --------> | 228 | | | 229 3. | | <--------- EDAC --------- | 230 | | | 231 4. | <-- NA with Address Reg --- | | 232 | [EARO with Status] | | 234 Figure 2: DAD cycle when 6LBR generates an IID 236 The approach in this draft is reactive rather than proactive; 6LBR 237 only replies with a locally generated IID when DAD fails. 239 Appendix A [RFC7217] states that a Net_Iface parameter can either be: 241 o Interface Index, 242 o Interface Name, 244 o Link-Layer Address, or 246 o Logical Network Service Identity. 248 EUI-64 of 6LN would be sent to 6LBR via 6LR within EARO and using 249 that, a Link-Layer Address can be derived at 6LBR to input in PRF. 250 For multiple interfaces, DAD_counter would be incremented as soon as 251 the collision occurs. 253 4.1. Advantages of proposed algorithm 255 By reference to the algorithm in [RFC7217], the resulting IID offers 256 the following advantages: 258 o For a given interface, same prefix and subnet would always result 259 in same IID, 261 o It would always be a different IID generated when a different 262 prefix is used, and 264 o The DAD_Counter parameter is incremented in case of address 265 collision, so that the resulting address would be different than 266 the previous address. 268 4.2. Extended Duplicate Address Request (EDAR) 270 The Prefix is the same throughout each LoWPAN network. This draft 271 uses that feature to reduce the size of the DAR: 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type | Code | Checksum | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Status | Rsrv | Cycle | Registration Lifetime | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | | 281 + EUI-64 + 282 | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | 285 + Registered IID + 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Figure 3: Extended Duplicate Address Request 291 The fields are similar to DAR in [RFC6775] except: 293 o Type: 159 (TBD) 295 o Cycle: 4 out of 8 reserved bits to identify the DAD cycle between 296 given 6LR and 6LBR. The reference is used later by 6LR to extract 297 IID provided by 6LBR. 299 o Unlike the DAR, the Registered IID (64 bit) is returned instead of 300 Registered Address (128 bit). 302 4.3. Extended Duplicate Address Confirmation (EDAC) 304 EDAC reduces the space needed for returning the EUI-64: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type | Code | Checksum | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Status | Rsrv | Cycle | Registration Lifetime | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 + EUI-64/XOR Encoding + 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 4: Extended Duplicate Address Confirmation 320 The fields are similar to DAC in [RFC6775] except: 322 o Type: 160 (TBD) 324 o Cycle: 4 out of 8 reserved bits identify the DAD cycle between the 325 6LR and 6LBR. These bits are used later by 6LR to extract the IID 326 supplied by 6LBR. 328 o In case of a failed DAD, a 6LBR-generated IID is encoded using XOR 329 with EUI-64; otherwise the same EUI-64 occupies the 64 bits. 331 4.4. Extended Address Registration Option 333 ARO and EARO can ONLY be initiated by host and 6LR, respectively. 334 [RFC6775] expects the reply of a host initiated ARO from 6LR with the 335 same ARO except for changing the status bit to indicate the 336 duplication detection. EARO is introduced in this document; 6LR can 337 send out this option if it receives EDAC instead of DAC from 6LBR. 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Type | Length = 2 | Status | Reserved | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Reserved | Registration Lifetime | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | | 347 + EUI-64/XOR Encoding + 348 | | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Figure 5: Extended Address Registration Option 353 o The fields are similar to ARO in [RFC6775] except: 355 o Type: 36 (TBD) 357 o EUI-64/XOR Encoding: a 64 bit IID generated by 6LBR is XOR'ed with 358 EUI-64. 360 5. Multiple DAD cycles 362 In [RFC6775], 6LN is expected to generate an IID; so 6LR only acts on 363 the first unique IID claim and silently discards any later claims for 364 the same IID. In contrast, this document enables 6LBR to assign a 365 unique IID in case of a duplicate IID claim by 6LR. For this 366 purpose, a "Cycle" field is introduced to enable multiple concurrent 367 DAD cycles that will be helpful for large-scale networks [RFC5548]. 368 At 6LN, this "Cycle" field is also used when extracting both IID and 369 EUI-64 that are XOR'ed by 6LBR. See Figure 3 and Figure 4 for the 370 format of the Cycle field. 372 6. XOR Encoding 374 Each iteration of DAR and DAC [RFC6775] carries the entire 128 bit 375 Registered Address during the DAD routine, even though the network 376 Prefix is the same throughout each LoWPAN. This document enables 377 eliding the network prefix part of the Registered Address as well in 378 EDAC and EARO using simple XOR encoding. The encoded 64 bit field 379 carries EUI-64 and randomized IID. See Figure 4 and Figure 5 for the 380 format of the EUI-64/XOR encoding. 382 Under the proposed arrangement, 6LBR would only encode values, 6LN 383 would only extract values and 6LR would do both. 385 At 6LR before sending EDAR to 6LBR: 387 o 6LR would use the 4 out of 8 Reserved "Cycle" bits of EDAR to keep 388 track of multiple DAD cycles. These iterations are recorded at 6LR 389 and that information is used to extract IID/EUI-64 from EDAC to be 390 forwarded to the appropriate 6LN. 392 At 6LBR before sending to 6LR: 394 o If Status = 0 (Success), then 6LBR returns EDAC using all the 395 values as received from EDAR. 397 o If Status = 1 (Duplicate), then 6LBR generates IID and XORs it with 398 EUI-64 to return in the EDAC to 6LR. 400 At 6LR before sending to 6LN: 402 o If Status = 0 (Success) then keep the claimed address of 6LN as 403 Destination Address for ARO to 6LN. 405 o If Status = 1 (Duplicate), then match the "Cycle" bits of EDAC to 406 extract (using XOR) the EUI-64 address and use the extracted address 407 as the Destination Address for EARO to 6LN. 409 Finally, at 6LN: 411 o If Status = 0 (Success), 6LN starts using the address that it 412 claimed. 414 o If Status = 1 (Duplicate) then 6LN XORs the received EUI-64 address 415 with its claimed EUI-64, which results in the newly generated IID 416 sent by 6LBR. 418 7. IANA Considerations 420 7.1. EDAR and EDAC Messages, and EARO Option 422 The document requires two new ICMPv6 type numbers under the 423 subregistry 'ICMPv6 "type" Numbers': 425 o Extended Duplicate Address Request (159) 427 o Extended Duplicate Address Confirmation (160) 429 This document requires a new ND option type under the subregistry 430 "IPv6 Neighbor Discovery Option Formats": 432 o Extended Address Registration Option (36) 434 7.2. Additions to Status Field 436 One new value is required for the "Address Registration Option Status 437 Values" sub-registry under the "IPv6 Neighbor Discovery Option 438 Formats": 440 +--------+--------------------------------------------+ 441 | Status | Description | 442 +--------+--------------------------------------------+ 443 | 0 | Success | 444 | 1 | Duplicate Address | 445 | 2 | Neighbor Cache Full | 446 | 3 | 6LBR generated IID | 447 | 4-255 | Allocated using Standards Action [RFC5226] | 448 +--------+--------------------------------------------+ 449 Addition to Status bits 451 8. Security Considerations 453 TBD 455 9. References 457 9.1. Normative References 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, 461 DOI 10.17487/RFC2119, March 1997, 462 . 464 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 465 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 466 . 468 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 469 Address Autoconfiguration", RFC 4862, 470 DOI 10.17487/RFC4862, September 2007, 471 . 473 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 474 Extensions for Stateless Address Autoconfiguration in 475 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 476 . 478 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 479 Bormann, "Neighbor Discovery Optimization for IPv6 over 480 Low-Power Wireless Personal Area Networks (6LoWPANs)", 481 RFC 6775, DOI 10.17487/RFC6775, November 2012, 482 . 484 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 485 Interface Identifiers with IPv6 Stateless Address 486 Autoconfiguration (SLAAC)", RFC 7217, 487 DOI 10.17487/RFC7217, April 2014, 488 . 490 9.2. Informative References 492 [I-D.ietf-6lo-backbone-router] 493 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 494 backbone-router-03 (work in progress), January 2017. 496 [I-D.vyncke-6man-mcast-not-efficient] 497 Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. 498 Yourtchenko, "Why Network-Layer Multicast is Not Always 499 Efficient At Datalink Layer", draft-vyncke-6man-mcast-not- 500 efficient-01 (work in progress), February 2014. 502 [MAC-Duplication] 503 Moore, HD., "The Wild West", September 2012, 504 . 506 [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and 507 D. Barthel, Ed., "Routing Requirements for Urban Low-Power 508 and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May 509 2009, . 511 [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and 512 P. Hurtig, "Early Retransmit for TCP and Stream Control 513 Transmission Protocol (SCTP)", RFC 5827, 514 DOI 10.17487/RFC5827, May 2010, 515 . 517 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 518 Considerations for IPv6 Address Generation Mechanisms", 519 RFC 7721, DOI 10.17487/RFC7721, March 2016, 520 . 522 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 523 "Recommendation on Stable IPv6 Interface Identifiers", 524 RFC 8064, DOI 10.17487/RFC8064, February 2017, 525 . 527 Authors' Addresses 529 Abdur Rashid Sangi 530 Huawei Technologies 531 No.156 Beiqing Rd. Haidian District 532 Beijing 100095 533 P.R. China 535 Email: sangi_bahrian@yahoo.com 537 Mach(Guoyi) Chen 538 Huawei Technologies 539 No.156 Beiqing Rd. Haidian District 540 Beijing 100095 541 P.R. China 543 Email: mach.chen@huawei.com 545 Charles E. Perkins 546 Futurewei 547 2330 Central Expressway 548 Santa Clara 95050 549 USA 551 Email: charliep@computer.org