idnits 2.17.1 draft-ietf-6man-default-iids-10.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 abstract seems to indicate that this document updates RFC4291, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC4391, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC4338, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC3146, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC5072, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC2590, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC3315, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC3572, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC2497, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2464, updated by this document, for RFC5378 checks: 1997-03-24) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 17, 2016) is 2992 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: 'AARCH' is mentioned on line 527, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 733, but not defined == Missing Reference: 'IPSEC' is mentioned on line 393, but not defined == Missing Reference: 'IPSEC-Auth' is mentioned on line 393, but not defined == Missing Reference: 'IPSEC-ESP' is mentioned on line 393, but not defined == Missing Reference: 'IPv6-ND' is mentioned on line 394, but not defined == Missing Reference: 'IND' is mentioned on line 394, but not defined == Missing Reference: 'ACONF' is mentioned on line 514, but not defined -- Looks like a reference, but probably isn't: '5' on line 708 == Missing Reference: 'ETHER' is mentioned on line 499, but not defined == Missing Reference: 'FDDI' is mentioned on line 499, but not defined -- Looks like a reference, but probably isn't: '3' on line 721 -- Looks like a reference, but probably isn't: '1' on line 613 -- Looks like a reference, but probably isn't: '8' on line 700 == Missing Reference: 'RFC4861' is mentioned on line 742, but not defined == Unused Reference: 'RFC7428' is defined on line 920, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Updates: 2464, 2467, 2470, 2491, 2492, A. Cooper 5 2497, 2590, 3146, 3315, 3572, Cisco 6 4291, 4338, 4391, 5072, 5121 D. Thaler 7 (if approved) Microsoft 8 Intended status: Standards Track W. Liu 9 Expires: August 20, 2016 Huawei Technologies 10 February 17, 2016 12 Recommendation on Stable IPv6 Interface Identifiers 13 draft-ietf-6man-default-iids-10 15 Abstract 17 This document changes the default Interface Identifier generation 18 scheme for SLAAC to that specified in RFC7217, and recommends against 19 embedding link-layer addresses in IPv6 Interface Identifiers. It 20 formally updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, 21 RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, 22 RFC5072, and RFC5121, by removing the text in these RFCs that 23 required the IPv6 Interface Identifiers to be derived from the 24 underlying link-layer address, and replacing the aforementioned text 25 with a pointer to this document. Additionally, this document updates 26 RFC3315 by specifying additional requirements on the generation of 27 Interface Identifiers used in Dynamic Host Configuration Protocol 28 version 6 (DHCPv6). It also provides advice to system administrators 29 who employ manual configuration. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 20, 2016. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Generation of IPv6 Interface Identifiers with SLAAC . . . . . 3 68 4. Generation of IPv6 Interface Identifiers with DHCPv6 . . . . 4 69 5. Generation of IPv6 Interface Identifiers with Manual 70 Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5 71 6. Update to existing RFCs . . . . . . . . . . . . . . . . . . . 5 72 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 79 1. Introduction 81 [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for 82 IPv6 [RFC2460], which typically results in hosts configuring one or 83 more "stable" addresses composed of a network prefix advertised by a 84 local router, and an Interface Identifier (IID) [RFC4291] that 85 typically embeds a link-layer address (e.g., an IEEE LAN MAC 86 address). 88 In some network technologies and adaptation layers, the use of an IID 89 based on a link-layer address may offer some advantages. For 90 example, the IP-over-IEEE802.15.4 standard in [RFC6775] allows for 91 compression of IPv6 addresses when the IID is based on the underlying 92 link-layer address. 94 The security and privacy implications of embedding a link-layer 95 address in an IPv6 IID have been known for some time now, and are 96 discussed in great detail in 97 [I-D.ietf-6man-ipv6-address-generation-privacy]; they include: 99 o Network activity correlation 101 o Location tracking 103 o Address scanning 105 o Device-specific vulnerability exploitation 107 Some popular IPv6 implementations have already deviated from the 108 traditional stable IID generation scheme to mitigate the 109 aforementioned security and privacy implications [Microsoft]. 111 As a result of the aforementioned issues, this document changes the 112 default Interface Identifier generation scheme for SLAAC to that 113 specified in [RFC7217], and recommends against embedding link-layer 114 addresses in IPv6 Interface Identifiers, such that the aforementioned 115 issues are mitigated. 117 NOTE: [RFC4291] defines the "Modified EUI-64 format" for IIDs. 118 Appendix A of [RFC4291] then describes how to transform an IEEE 119 EUI-64 identifier, or an IEEE 802 48-bit MAC address from which an 120 EUI-64 identifier is derived, into an IID in the Modified EUI-64 121 format. 123 Finally this document updates [RFC3315] by specifying additional 124 requirements on the generation of Interface Identifiers used in 125 Dynamic Host Configuration Protocol version 6 (DHCPv6), and also 126 provides advice to system administrators who employ manual 127 configuration. 129 2. Terminology 131 Stable address: 132 An address that does not vary over time within the same network 133 (as defined in [I-D.ietf-6man-ipv6-address-generation-privacy]). 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 3. Generation of IPv6 Interface Identifiers with SLAAC 141 Link layers MUST define a mechanism that provides mitigation of the 142 security and privacy implications discussed in Section 1. Such 143 mechanism MUST meet the following requirements: 145 1. The resulting Interface Identifiers remain stable for each prefix 146 used with SLAAC within each subnet for the same network 147 interface. That is, the algorithm generates the same Interface 148 Identifier when configuring an address (for the same interface) 149 belonging to the same prefix within the same subnet 151 2. The resulting Interface Identifiers must change when addresses 152 are configured for different prefixes. That is, if different 153 autoconfiguration prefixes are used to configure addresses for 154 the same network interface card, the resulting Interface 155 Identifiers must be (statistically) different. This means that, 156 given two addresses, it must be difficult for an outside entity 157 to tell whether the addresses have been generated by the same 158 host. 160 3. It must be difficult for an outside entity to predict the 161 Interface Identifiers that will be generated by the algorithm, 162 even with knowledge of the Interface Identifiers generated for 163 configuring other addresses. 165 4. The resulting Interface Identifiers must be semantically opaque. 167 Nodes SHOULD implement and employ [RFC7217] as the default scheme for 168 generating stable IPv6 addresses with SLAAC. A link layer MAY also 169 define a mechanism that is more efficient and does not comply with 170 the aforementioned requirements. The choice of whether to enable the 171 security- and privacy-preserving mechanism or not SHOULD be 172 configurable in such a case. 174 By default, nodes SHOULD NOT employ IPv6 address generation schemes 175 that embed the underlying link-layer address in the IID. In 176 particular, this document RECOMMENDS that nodes do not generate IIDs 177 with the schemes specified in [RFC2464], [RFC2467], [RFC2470], 178 [RFC2491], [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], 179 [RFC4338], [RFC4391], [RFC5121], and [RFC5072]. The recommendations 180 in this document override any other recommendations on the generation 181 of IIDs in the updated RFCs. The specific updates to these documents 182 to effectuate this recommendation are included in Section 6. 184 4. Generation of IPv6 Interface Identifiers with DHCPv6 186 By default, DHCPv6 server implementations SHOULD NOT generate 187 predictable IPv6 addresses (such as IPv6 addresses where the IIDs are 188 consecutive small numbers). [I-D.ietf-dhc-stable-privacy-addresses] 189 specifies one possible algorithm that could be employed to comply 190 with this requirement. Another possible algorithm would be to select 191 a pseudo-random value chosen from a discrete uniform distribution, 192 while avoiding the reserved IPv6 Interface Identifiers [RFC5453] 193 [IANA-RESERVED-IID]. 195 5. Generation of IPv6 Interface Identifiers with Manual Configuration 197 Network administrators should be aware of the security implications 198 of predictable Interface Identifiers 199 [I-D.ietf-6man-ipv6-address-generation-privacy], and avoid the use of 200 predictable addresses when the aforementioned issues are of concern. 202 6. Update to existing RFCs 204 The following subsections clarify how each of the RFCs affected by 205 this document are updated. 207 Note to the RFC Editor: 208 In the following subsections, the legend "[RFCXXXX]" should be 209 replaced with the RFC number assigned to this document, and this 210 note to the RFC Editor should be removed before publication of 211 this document as an RFC. 213 6.1. Update to RFC2464 215 The entire text of Section 4 of [RFC2464] is replaced with the 216 following text: 218 ---------------- cut here -------------- cut here ---------------- 219 The Interface Identifier [AARCH] for an Ethernet interface MUST be 220 generated as specified in [RFCXXXX]. 221 ---------------- cut here -------------- cut here ---------------- 223 The following text from Section 6 of [RFC2464]: 225 ---------------- cut here -------------- cut here ---------------- 226 Ethernet Address 227 The 48 bit Ethernet IEEE 802 address, in canonical bit 228 order. This is the address the interface currently 229 responds to, and may be different from the built-in 230 address used to derive the Interface Identifier. 231 ---------------- cut here -------------- cut here ---------------- 233 is formally replaced with: 235 ---------------- cut here -------------- cut here ---------------- 236 Ethernet Address 237 The 48 bit Ethernet IEEE 802 address, in canonical bit 238 order. This is the address the interface currently 239 responds to. 240 ---------------- cut here -------------- cut here ---------------- 242 6.2. Update to RFC2467 244 The entire text of Section 5 of [RFC2467] is replaced with the 245 following text: 247 ---------------- cut here -------------- cut here ---------------- 248 The Interface Identifier [AARCH] for an FDDI interface MUST be 249 generated as specified in [RFCXXXX]. 250 ---------------- cut here -------------- cut here ---------------- 252 The following text from Section 7 of [RFC2467]: 254 ---------------- cut here -------------- cut here ---------------- 255 FDDI Address 256 The 48 bit FDDI IEEE 802 address, in canonical bit order. 257 This is the address the interface currently responds to, 258 and may be different from the built-in address used to 259 derive the Interface Identifier. 260 ---------------- cut here -------------- cut here ---------------- 262 is formally replaced with: 264 ---------------- cut here -------------- cut here ---------------- 265 FDDI Address 266 The 48 bit FDDI IEEE 802 address, in canonical bit order. 267 This is the address the interface currently responds to. 268 ---------------- cut here -------------- cut here ---------------- 270 6.3. Update to RFC2470 272 The entire text of Section 4 of [RFC2470] is replaced with the 273 following text: 275 ---------------- cut here -------------- cut here ---------------- 276 The Interface Identifier [AARCH] for a Token Ring interface MUST be 277 generated as specified in [RFCXXXX]. 278 ---------------- cut here -------------- cut here ---------------- 280 The following text from Section 6 of [RFC2470]: 282 ---------------- cut here -------------- cut here ---------------- 283 Token Ring Address: The 48 bit Token Ring IEEE 802 284 address, in canonical bit order. This is the address the 285 interface currently responds to, and may be different from 286 the built-in address used to derive the Interface 287 Identifier. 288 ---------------- cut here -------------- cut here ---------------- 290 is formally replaced with: 292 ---------------- cut here -------------- cut here ---------------- 293 Token Ring Address: The 48 bit Token Ring IEEE 802 294 address, in canonical bit order. This is the address the 295 interface currently responds to. 296 ---------------- cut here -------------- cut here ---------------- 298 6.4. Update to RFC2491 300 The entire text of Section 5.1, Section 5.1.1, and Section 5.1.2 of 301 [RFC2491] is replaced with the following text: 303 ---------------- cut here -------------- cut here ---------------- 304 5.1 Interface Tokens 306 The Interface Token (or Interface Identifier [AARCH]) for each IPv6 307 interface MUST be generated as specified in [RFCXXXX]. 309 All implementations MUST support manual configuration of interface 310 tokens to allow operators to manually change a interface token on 311 a per-LL basis. Operators may choose to manually set interface 312 tokens for reasons other than eliminating duplicate addresses. 314 All interface tokens MUST be 64 bits in length. 315 ---------------- cut here -------------- cut here ---------------- 317 6.5. Update to RFC2492 319 The entire text of Section 5 (and all the corresponding subsections) 320 of of [RFC2492] is replaced with the following text: 322 ---------------- cut here -------------- cut here ---------------- 323 5.1 Interface Tokens 325 The Interface Token (or Interface Identifier [AARCH]) for each IPv6 326 interface MUST be generated as specified in [RFCXXXX]. 328 All implementations MUST support manual configuration of interface 329 tokens to allow operators to manually change a interface token on 330 a per-LL basis. Operators may choose to manually set interface 331 tokens for reasons other than eliminating duplicate addresses. 333 All interface tokens MUST be 64 bits in length. 334 ---------------- cut here -------------- cut here ---------------- 336 6.6. Update to RFC2497 338 The entire text of Section 4 of [RFC2497] is replaced with the 339 following text: 341 ---------------- cut here -------------- cut here ---------------- 342 The Interface Identifier [AARCH] for an ARCnet interface MUST be 343 generated as specified in [RFCXXXX]. 344 ---------------- cut here -------------- cut here ---------------- 346 The entire text of Section 8 of [RFC2497] is replaced with the 347 following text: 349 ---------------- cut here -------------- cut here ---------------- 350 Interface Identifiers generated as specified in [RFCXXXX] mitigate 351 the security and privacy implications discussed in Section 1 of 352 such document. 353 ---------------- cut here -------------- cut here ---------------- 355 6.7. Update to RFC2590 357 The entire Section 4 and Section 4.1 of [RFC2590] is replaced with 358 the following text: 360 ---------------- cut here -------------- cut here ---------------- 361 4. Stateless Autoconfiguration 363 An interface identifier [AARCH] for an IPv6 Frame Relay interface 364 MUST be unique on a Frame Relay link [AARCH], and MUST be unique on 365 each of the virtual links represented by the VCs terminated on the 366 interface. 368 The interface identifier for the Frame Relay interface MUST be 369 generated as specified in [RFCXXXX]. 371 We note that each virtual circuit in a Frame Relay network is uniquely 372 identified on a Frame Relay interface by a DLCI. Furthermore, a DLCI 373 can be seen as an identification of the end point of a virtual circuit 374 on a Frame Relay interface. Since each Frame Relay VC is configured or 375 established separately, and acts like an independent virtual-link 376 from other VCs in the network, or on the interface, link, wire or 377 fiber, it seems beneficial to view each VC's termination point on the 378 Frame Relay interface as a "pseudo-interface" or "logical-interface" 379 overlaid on the Frame Relay interface. Furthermore, it seems 380 beneficial to be able to generate and associate an IPv6 381 autoconfigured address (including an IPv6 link local address) to each 382 "pseudo-interface", i.e. end-point of a VC, i.e. to each DLCI on a 383 Frame Relay interface. 384 ---------------- cut here -------------- cut here ---------------- 386 The entire Section 9 of [RFC2590] is replaced as follows: 388 ---------------- cut here -------------- cut here ---------------- 389 9. Security Considerations 391 Security protection against forgery or accident at the level of 392 the mechanisms described here is provided by the IPv6 security 393 mechanisms [IPSEC], [IPSEC-Auth], [IPSEC-ESP] applied to Neighbor 394 Discovery [IPv6-ND] or Inverse Neighbor Discovery [IND] messages. 396 To avoid an IPsec Authentication verification failure, the Frame 397 Relay specific preprocessing of a Neighbor Discovery Solicitation 398 message that contains a DLCI format Source link-layer address option, 399 MUST be done by the receiver node after it completed IP Security 400 processing. 401 ---------------- cut here -------------- cut here ---------------- 403 6.8. Update to RFC3146 405 The entire Section 6 of [RFC3146] is replaced with the following 406 text: 408 ---------------- cut here -------------- cut here ---------------- 409 6. STATELESS AUTOCONFIGURATION 411 The Interface Identifier [AARCH] for an IEEE1394 interface MUST be 412 generated as specified in [RFCXXXX]. 414 An IPv6 address prefix used for stateless autoconfiguration [ACONF] 415 of an IEEE1394 interface MUST have a length of 64 bits. 416 ---------------- cut here -------------- cut here ---------------- 418 6.9. Update to RFC3315 420 The following text in Section 11 of of [RFC3315]: 422 ---------------- cut here -------------- cut here ---------------- 423 Any address assigned by a server that is based on an EUI-64 424 identifier MUST include an interface identifier with the "u" 425 (universal/local) and "g" (individual/group) bits of the interface 426 identifier set appropriately, as indicated in section 2.5.1 of RFC 427 2373 [5]. 428 ---------------- cut here -------------- cut here ---------------- 430 is formally replaced with: 432 ---------------- cut here -------------- cut here ---------------- 433 By default, DHCPv6 server implementations SHOULD NOT generate 434 predictable IPv6 addresses (such as IPv6 addresses where the IIDs are 435 consecutive small numbers). [I-D.ietf-dhc-stable-privacy-addresses] 436 specifies one possible algorithm that could be employed to comply 437 with this requirement. Another possible algorithm would be to select 438 a pseudo-random value chosen from a discrete uniform distribution, 439 while avoiding the reserved IPv6 Interface Identifiers [RFC5453] 440 [IANA-RESERVED-IID]. 441 ---------------- cut here -------------- cut here ---------------- 443 Additionally, the following references should be added to Section 26 444 of [RFC3315]: 446 ---------------- cut here -------------- cut here ---------------- 447 [IANA-RESERVED-IID] 448 IANA, "Reserved IPv6 Interface Identifiers", 449 . 451 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 452 RFC 5453, DOI 10.17487/RFC5453, February 2009, 453 . 455 [I-D.ietf-dhc-stable-privacy-addresses] 456 Gont, F. and S. LIU, "A Method for Generating Semantically 457 Opaque Interface Identifiers with Dynamic Host 458 Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc- 459 stable-privacy-addresses-02 (work in progress), April 460 2015. 461 ---------------- cut here -------------- cut here ---------------- 463 6.10. Update to RFC3572 465 The entire text of Section 3 of [RFC3572] is replaced as follows: 467 ---------------- cut here -------------- cut here ---------------- 468 3. Interface Identifier 470 The Interface Identifier [AARCH] for a MAPOS interface MUST be 471 generated as specified in [RFCXXXX]. 472 ---------------- cut here -------------- cut here ---------------- 474 Additionally, Section 6.2 ("Uniqueness of Interface Identifiers") of 475 [RFC3572] is entirely eliminated. 477 6.11. Update to RFC4291 479 The entire text of Section 2.5.1 of [RFC4291] is replaced with the 480 following text: 482 ---------------- cut here -------------- cut here ---------------- 483 2.5.1. Interface Identifiers 485 Interface identifiers in IPv6 unicast addresses are used to identify 486 interfaces on a link. They are required to be unique within a subnet 487 prefix. It is recommended that the same interface identifier not be 488 assigned to different nodes on a link. They may also be unique over 489 a broader scope. The same interface identifier may be used on 490 multiple interfaces on a single node, as long as they are attached to 491 different subnets. 493 For all unicast addresses, except those that start with the binary 494 value 000, Interface IDs are required to be 64 bits long, and MUST be 495 generated as specified in [RFCXXXX]. 497 The details of forming interface identifiers are defined in the 498 appropriate "IPv6 over " specification, such as "IPv6 over 499 Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI]. 500 ---------------- cut here -------------- cut here ---------------- 502 6.12. Update to RFC4338 504 The entire text of Section 5 (and of all the corresponding 505 subsections) of [RFC4338] is replaced with the following text: 507 ---------------- cut here -------------- cut here ---------------- 508 5. IPv6 Stateless Address Autoconfiguration 510 The IPv6 Interface ID [AARCH] for an Nx_Port MUST be generated 511 as specified in [RFCXXXX]. 513 IPv6 stateless address autoconfiguration MUST be performed as 514 specified in [ACONF]. An IPv6 Address Prefix used for stateless 515 address autoconfiguration of an Nx_Port MUST have a length of 64 516 bits. 517 ---------------- cut here -------------- cut here ---------------- 519 6.13. Update to RFC4391 521 The entire text of Section 8 of [RFC4391] is replaced with the 522 following text: 524 ---------------- cut here -------------- cut here ---------------- 525 8. IPv6 Stateless Autoconfiguration 527 The IPv6 Interface ID [AARCH] MUST be generated as specified in 528 [RFCXXXX]. 529 ---------------- cut here -------------- cut here ---------------- 531 6.14. Update to RFC5072 533 The entire text of Section 4.1 of [RFC5072] is replaced with the 534 following text: 536 ---------------- cut here -------------- cut here ---------------- 537 4.1. Interface Identifier 539 Description 541 This Configuration Option provides a way to negotiate a unique, 64- 542 bit interface identifier to be used for the address autoconfiguration 543 [3] at the local end of the link (see Section 5). A Configure- 544 Request MUST contain exactly one instance of the interface-identifier 545 option [1]. The interface identifier MUST be unique within the PPP 546 link; i.e., upon completion of the negotiation, different interface- 547 identifier values are to be selected for the ends of the PPP link. 549 Before this Configuration Option is requested, an implementation 550 chooses its tentative interface identifier. The non-zero value of 551 the tentative interface identifier SHOULD be chosen such that the 552 value is unique to the link and, preferably, consistently 553 reproducible across initializations of the IPV6CP finite state 554 machine (administrative Close and reOpen, reboots, etc.). The 555 rationale for preferring a consistently reproducible unique interface 556 identifier to a completely random interface identifier is to provide 557 stability to global scope addresses (see Appendix A) that can be 558 formed from the interface identifier. Additionally, the tentative 559 interface identifier SHOULD be generated as specified in [RFCXXXX]. 561 If neither a unique number nor a random number can be generated, it 562 is recommended that a zero value be used for the interface identifier 563 transmitted in the Configure-Request. In this case, the PPP peer may 564 provide a valid non-zero interface identifier in its response as 565 described below. Note that if at least one of the PPP peers is able 566 to generate separate non-zero numbers for itself and its peer, the 567 identifier negotiation will succeed. 569 When a Configure-Request is received with the Interface-Identifier 570 Configuration Option and the receiving peer implements this option, 571 the received interface identifier is compared with the interface 572 identifier of the last Configure-Request sent to the peer. Depending 573 on the result of the comparison, an implementation MUST respond in 574 one of the following ways: 576 If the two interface identifiers are different but the received 577 interface identifier is zero, a Configure-Nak is sent with a non-zero 578 interface-identifier value suggested for use by the remote peer. 580 Such a suggested interface identifier MUST be different from the 581 interface identifier of the last Configure-Request sent to the peer. 582 It is recommended that the value suggested be consistently 583 reproducible across initializations of the IPV6CP finite state 584 machine (administrative Close and reOpen, reboots, etc). 585 Additionally, the value suggested SHOULD be generated as specified 586 in [RFCXXXX]. 588 If the two interface identifiers are different and the received 589 interface identifier is not zero, the interface identifier MUST be 590 acknowledged, i.e., a Configure-Ack is sent with the requested 591 interface identifier, meaning that the responding peer agrees with 592 the interface identifier requested. 594 If the two interface identifiers are equal and are not zero, 595 Configure-Nak MUST be sent specifying a different non-zero 596 interface-identifier value suggested for use by the remote peer. It 597 is recommended that the value suggested be consistently reproducible 598 across initializations of the IPV6CP finite state machine 599 (administrative Close and reOpen, reboots, etc). Additionally, the 600 value suggested SHOULD be generated as specified in [RFCXXXX]. 602 If the two interface identifiers are equal to zero, the interface 603 identifier's negotiation MUST be terminated by transmitting the 604 Configure-Reject with the interface-identifier value set to zero. In 605 this case, a unique interface identifier cannot be negotiated. 607 If a Configure-Request is received with the Interface-Identifier 608 Configuration Option and the receiving peer does not implement this 609 option, Configure-Reject is sent. 611 A new Configure-Request SHOULD NOT be sent to the peer until normal 612 processing would cause it to be sent (that is, until a Configure-Nak 613 is received or the Restart timer runs out [1]). 615 A new Configure-Request MUST NOT contain the interface-identifier 616 option if a valid Interface-Identifier Configure-Reject is received. 618 Reception of a Configure-Nak with a suggested interface identifier 619 different from that of the last Configure-Nak sent to the peer 620 indicates a unique interface identifier. In this case, a new 621 Configure-Request MUST be sent with the identifier value suggested in 622 the last Configure-Nak from the peer. But if the received interface 623 identifier is equal to the one sent in the last Configure-Nak, a new 624 interface identifier MUST be chosen. In this case, a new Configure- 625 Request SHOULD be sent with the new tentative interface identifier. 626 This sequence (transmit Configure-Request, receive Configure-Request, 627 transmit Configure-Nak, receive Configure-Nak) might occur a few 628 times, but it is extremely unlikely to occur repeatedly. More 629 likely, the interface identifiers chosen at either end will quickly 630 diverge, terminating the sequence. 632 If negotiation of the interface identifier is required, and the peer 633 did not provide the option in its Configure-Request, the option 634 SHOULD be appended to a Configure-Nak. The tentative value of the 635 interface identifier given must be acceptable as the remote interface 636 identifier; i.e., it should be different from the identifier value 637 selected for the local end of the PPP link. The next Configure- 638 Request from the peer may include this option. If the next 639 Configure-Request does not include this option, the peer MUST NOT 640 send another Configure-Nak with this option included. It should 641 assume that the peer's implementation does not support this option. 643 By default, an implementation SHOULD attempt to negotiate the 644 interface identifier for its end of the PPP connection. 646 A summary of the Interface-Identifier Configuration Option format is 647 shown below. The fields are transmitted from left to right. 649 0 1 2 3 650 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 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Type | Length | Interface-Identifier (MS Bytes) 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Interface-Identifier (cont) 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Interface-Identifier (LS Bytes) | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 Type 661 1 663 Length 665 10 667 Interface-Identifier 669 The 64-bit interface identifier, which is very likely to be 670 unique on the link, or zero if a good source of uniqueness 671 cannot be found. 673 Default 675 If no valid interface identifier can be successfully 676 negotiated, no default interface-identifier value should be 677 assumed. The procedures for recovering from such a case will 678 depend on the algorithm employed to generate the interface 679 identifier. One approach is to manually configure the 680 interface identifier of the interface. 681 ---------------- cut here -------------- cut here ---------------- 683 Additionally, the following text of Section 5 of [RFC5072]: 685 ---------------- cut here -------------- cut here ---------------- 686 5. Stateless Autoconfiguration and Link-Local Addresses 688 The interface identifier of IPv6 unicast addresses [5] of a PPP 689 interface SHOULD be negotiated in the IPV6CP phase of the PPP 690 connection setup (see Section 4.1). If no valid interface identifier 691 has been successfully negotiated, procedures for recovering from such 692 a case are unspecified. One approach is to manually configure the 693 interface identifier of the interface. 694 The negotiated interface identifier is used by the local end of the 695 PPP link to autoconfigure an IPv6 link-local unicast address for the 696 PPP interface. However, it SHOULD NOT be assumed that the same 697 interface identifier is used in configuring global unicast addresses 698 for the PPP interface using IPv6 stateless address autoconfiguration 699 [3]. The PPP peer MAY generate one or more interface identifiers, 700 for instance, using a method described in [8], to autoconfigure one 701 or more global unicast addresses. 703 is formally replaced with the following text: 705 ---------------- cut here -------------- cut here ---------------- 706 5. Stateless Autoconfiguration and Link-Local Addresses 708 The interface identifier of IPv6 unicast addresses [5] of a PPP 709 interface SHOULD be negotiated in the IPV6CP phase of the PPP 710 connection setup (see Section 4.1). If no valid interface identifier 711 has been successfully negotiated, procedures for recovering from such 712 a case will depend on the algorithm employed to generate the interface 713 identifier. One approach is to manually configure the interface 714 identifier of the interface. 716 The negotiated interface identifier is used by the local end of the 717 PPP link to autoconfigure an IPv6 link-local unicast address for the 718 PPP interface. However, it SHOULD NOT be assumed that the same 719 interface identifier is used in configuring global unicast addresses 720 for the PPP interface using IPv6 stateless address autoconfiguration 721 [3]. 722 ---------------- cut here -------------- cut here ---------------- 724 6.15. Update to RFC5121 726 The entire text of Section 9.1 of [RFC5121] is replaced with the 727 following text: 729 ---------------- cut here -------------- cut here ---------------- 730 9.1. Interface Identifier 732 The MS SHOULD generate interface identifiers as specified in 733 [RFCXXXX]. 734 ---------------- cut here -------------- cut here ---------------- 736 Additionally, Section 9.2 is replaced as follows: 738 ---------------- cut here -------------- cut here ---------------- 739 9.2. Duplicate Address Detection 741 DAD SHOULD be performed as per "Neighbor Discovery for IP Version 6 742 (IPv6)", [RFC4861] and "IPv6 Stateless Address Autoconfiguration" 743 [RFC4862]. The IPv6 link over 802.16 is specified in this document 744 as a point-to-point link. Based on this criteria, it may be 745 redundant to perform DAD on a global unicast address that is 746 configured as part of the IPv6 Stateless Address Autoconfiguration 747 Protocol [RFC4862] as long as the following two conditions are met: 749 1. The prefixes advertised through the router advertisement messages 750 by the access router terminating the 802.16 IPv6 link are unique 751 to that link. 753 2. The access router terminating the 802.16 IPv6 link does not 754 autoconfigure any IPv6 global unicast addresses from the prefix 755 that it advertises. 756 ---------------- cut here -------------- cut here ---------------- 758 7. Future Work 760 At the time of this writing, the mechanisms specified in the 761 following documents might require updates to be fully compatible with 762 the recommendations in this document: 764 o "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based 765 Networks" [RFC6282] 767 o "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" 768 [RFC4944] 770 o "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 771 Personal Area Networks (6LoWPANs)"[RFC6775] 773 o "Transmission of IPv6 Packets over ITU-T G.9959 Networks"[RFC7428] 775 Future revisions or updates of these documents should take the issues 776 of privacy and security mentioned in Section 1 and explain any design 777 and engineering considerations that lead to the use of IIDs based on 778 a node's link-layer address. 780 8. IANA Considerations 782 There are no IANA registries within this document. The RFC-Editor 783 can remove this section before publication of this document as an 784 RFC. 786 9. Security Considerations 788 This recommends against the (default) use of predictable Interface 789 Identifiers in IPv6 addresses. It recommends [RFC7217] as the 790 default scheme for generating IPv6 stable addresses with SLAAC, such 791 that the security and privacy issues of IIDs that embed link-layer 792 addresses are mitigated. Additionally, it recommends against 793 predictable IIDs in DHCPv6 and manual configuration 795 10. Acknowledgements 797 The authors would like to thank (in alphabetical order) Bob Hinden, 798 Ray Hunter and Erik Nordmark, for providing a detailed review of this 799 document. 801 The authors would like to thank (in alphabetical order) Fred Baker, 802 Carsten Bormann, Scott Brim, Brian Carpenter, Samita Chakrabarti, Tim 803 Chown, Lorenzo Colitti, Jean-Michel Combes, Greg Daley, Esko Dijk, 804 Ralph Droms, David Farmer, Brian Haberman, Ulrich Herberg, Philip 805 Homburg, Jahangir Hossain, Jonathan Hui, Christian Huitema, Ray 806 Hunter, Erik Kline, Sheng Jiang, Roger Jorgensen, Dan Luedtke, Kerry 807 Lynn, George Mitchel, Gabriel Montenegro, Erik Nordmark, Simon 808 Perreault, Tom Petch, Alexandru Petrescu, Michael Richardson, Arturo 809 Servin, Mark Smith, Tom Taylor, Ole Troan, Tina Tsou, Glen Turner, 810 Randy Turner, and James Woodyatt, for providing valuable comments on 811 earlier versions of this document. 813 11. References 815 11.1. Normative References 817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 818 Requirement Levels", BCP 14, RFC 2119, 819 DOI 10.17487/RFC2119, March 1997, 820 . 822 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 823 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 824 December 1998, . 826 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 827 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 828 . 830 [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI 831 Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998, 832 . 834 [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of 835 IPv6 Packets over Token Ring Networks", RFC 2470, 836 DOI 10.17487/RFC2470, December 1998, 837 . 839 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 840 over Non-Broadcast Multiple Access (NBMA) networks", 841 RFC 2491, DOI 10.17487/RFC2491, January 1999, 842 . 844 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 845 Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, 846 . 848 [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet 849 Networks", RFC 2497, DOI 10.17487/RFC2497, January 1999, 850 . 852 [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of 853 IPv6 Packets over Frame Relay Networks Specification", 854 RFC 2590, DOI 10.17487/RFC2590, May 1999, 855 . 857 [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets 858 over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146, 859 October 2001, . 861 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 862 C., and M. Carney, "Dynamic Host Configuration Protocol 863 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 864 2003, . 866 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 867 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 868 2006, . 870 [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of 871 IPv6, IPv4, and Address Resolution Protocol (ARP) Packets 872 over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338, 873 January 2006, . 875 [RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over 876 InfiniBand (IPoIB)", RFC 4391, DOI 10.17487/RFC4391, April 877 2006, . 879 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 880 Address Autoconfiguration", RFC 4862, 881 DOI 10.17487/RFC4862, September 2007, 882 . 884 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 885 "Transmission of IPv6 Packets over IEEE 802.15.4 886 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 887 . 889 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 890 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 891 . 893 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 894 Madanapalli, "Transmission of IPv6 via the IPv6 895 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 896 DOI 10.17487/RFC5121, February 2008, 897 . 899 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 900 RFC 5453, DOI 10.17487/RFC5453, February 2009, 901 . 903 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 904 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 905 DOI 10.17487/RFC6282, September 2011, 906 . 908 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 909 Bormann, "Neighbor Discovery Optimization for IPv6 over 910 Low-Power Wireless Personal Area Networks (6LoWPANs)", 911 RFC 6775, DOI 10.17487/RFC6775, November 2012, 912 . 914 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 915 Interface Identifiers with IPv6 Stateless Address 916 Autoconfiguration (SLAAC)", RFC 7217, 917 DOI 10.17487/RFC7217, April 2014, 918 . 920 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 921 over ITU-T G.9959 Networks", RFC 7428, 922 DOI 10.17487/RFC7428, February 2015, 923 . 925 11.2. Informative References 927 [I-D.ietf-6man-ipv6-address-generation-privacy] 928 Cooper, A., Gont, F., and D. Thaler, "Privacy 929 Considerations for IPv6 Address Generation Mechanisms", 930 draft-ietf-6man-ipv6-address-generation-privacy-08 (work 931 in progress), September 2015. 933 [I-D.ietf-dhc-stable-privacy-addresses] 934 Gont, F. and S. LIU, "A Method for Generating Semantically 935 Opaque Interface Identifiers with Dynamic Host 936 Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc- 937 stable-privacy-addresses-02 (work in progress), April 938 2015. 940 [IANA-RESERVED-IID] 941 IANA, "Reserved IPv6 Interface Identifiers", 942 . 944 [Microsoft] 945 Davies, J., "Understanding IPv6, 3rd. ed", page 83, 946 Microsoft Press, 2012, . 948 [RFC3572] Ogura, T., Maruyama, M., and T. Yoshida, "Internet 949 Protocol Version 6 over MAPOS (Multiple Access Protocol 950 Over SONET/SDH)", RFC 3572, DOI 10.17487/RFC3572, July 951 2003, . 953 Authors' Addresses 954 Fernando Gont 955 SI6 Networks / UTN-FRH 956 Evaristo Carriego 2644 957 Haedo, Provincia de Buenos Aires 1706 958 Argentina 960 Phone: +54 11 4650 8472 961 Email: fgont@si6networks.com 962 URI: http://www.si6networks.com 964 Alissa Cooper 965 Cisco 966 707 Tasman Drive 967 Milpitas, CA 95035 968 US 970 Phone: +1-408-902-3950 971 Email: alcoop@cisco.com 972 URI: https://www.cisco.com/ 974 Dave Thaler 975 Microsoft 976 Microsoft Corporation 977 One Microsoft Way 978 Redmond, WA 98052 980 Phone: +1 425 703 8835 981 Email: dthaler@microsoft.com 983 Will Liu 984 Huawei Technologies 985 Bantian, Longgang District 986 Shenzhen 518129 987 P.R. China 989 Email: liushucheng@huawei.com