idnits 2.17.1 draft-ietf-6man-default-iids-13.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 == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (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 (July 8, 2016) is 2847 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 551, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 762, but not defined == Missing Reference: 'IPSEC' is mentioned on line 413, but not defined == Missing Reference: 'IPSEC-Auth' is mentioned on line 413, but not defined == Missing Reference: 'IPSEC-ESP' is mentioned on line 413, but not defined == Missing Reference: 'IPv6-ND' is mentioned on line 414, but not defined == Missing Reference: 'IND' is mentioned on line 414, but not defined == Missing Reference: 'ACONF' is mentioned on line 538, but not defined -- Looks like a reference, but probably isn't: '5' on line 736 == Missing Reference: 'ETHER' is mentioned on line 522, but not defined == Missing Reference: 'FDDI' is mentioned on line 522, but not defined -- Looks like a reference, but probably isn't: '3' on line 749 -- Looks like a reference, but probably isn't: '1' on line 642 -- Looks like a reference, but probably isn't: '8' on line 728 == Missing Reference: 'RFC4861' is mentioned on line 771, but not defined == Unused Reference: 'RFC7428' is defined on line 954, 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) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-03) exists of draft-gont-predictable-numeric-ids-00 Summary: 3 errors (**), 0 flaws (~~), 15 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: January 9, 2017 Huawei Technologies 10 July 8, 2016 12 Recommendation on Stable IPv6 Interface Identifiers 13 draft-ietf-6man-default-iids-13 15 Abstract 17 This document changes the recommended default IID generation scheme 18 for cases where SLAAC is used to generate a stable IPv6 address. It 19 recommends using the mechanism specified in RFC7217 in such cases, 20 and recommends against embedding stable link-layer addresses in IPv6 21 Interface Identifiers. It formally updates RFC2464, RFC2467, 22 RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, 23 RFC4291, RFC4338, RFC4391, RFC5072, and RFC5121, by removing the text 24 in these RFCs that required the IPv6 Interface Identifiers to be 25 derived from the underlying stable link-layer address, and replacing 26 this text with recommendations consistent with those in this 27 document. Additionally, this document updates RFC3315 by specifying 28 additional requirements on the generation of Interface Identifiers 29 used in Dynamic Host Configuration Protocol version 6 (DHCPv6). It 30 also provides advice to system administrators who employ manual 31 configuration. This document does not change any existing 32 recommendations concerning the use of temporary addresses as 33 specified in RFC 4941. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 9, 2017. 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Generation of IPv6 Interface Identifiers with SLAAC . . . . . 4 71 4. Generation of IPv6 Interface Identifiers with DHCPv6 . . . . 5 72 5. Generation of IPv6 Interface Identifiers with Manual 73 Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5 74 6. Update to existing RFCs . . . . . . . . . . . . . . . . . . . 5 75 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 82 1. Introduction 84 [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for 85 IPv6 [RFC2460], which typically results in hosts configuring one or 86 more "stable" addresses composed of a network prefix advertised by a 87 local router, and an Interface Identifier (IID) [RFC4291] that 88 typically embeds a stable link-layer address (e.g., an IEEE LAN MAC 89 address). 91 In some network technologies and adaptation layers, the use of an IID 92 based on a link-layer address may offer some advantages. For 93 example, the IP-over-IEEE802.15.4 standard in [RFC6775] allows for 94 compression of IPv6 addresses when the IID is based on the underlying 95 link-layer address. 97 The security and privacy implications of embedding a stable link- 98 layer address in an IPv6 IID have been known for some time now, and 99 are discussed in great detail in [RFC7721]. They include: 101 o Network activity correlation 103 o Location tracking 105 o Address scanning 107 o Device-specific vulnerability exploitation 109 More generally, the reuse of identifiers that have their own 110 semantics or properties across different contexts or scopes can be 111 detrimental for security and privacy 112 [I-D.gont-predictable-numeric-ids]. In the case of traditional 113 stable IPv6 IIDs, some of the security and privacy implications are 114 dependent on the properties of the underlying link-layer addresses 115 (e.g., whether the link-layer address is ephemeral or randomly 116 generated), while other implications (e.g., reduction of the entropy 117 of the IID) depend on the algorithm for generating the IID itself. 118 In standardized recommendations for stable IPv6 IID generation meant 119 to achieve particular security and privacy properties, it is 120 therefore necessary to recommend against embedding stable link-layer 121 addresses in IPv6 IIDs. 123 Furthermore, some popular IPv6 implementations have already deviated 124 from the traditional stable IID generation scheme to mitigate the 125 aforementioned security and privacy implications [Microsoft]. 127 As a result of the aforementioned issues, this document changes the 128 recommended default IID generation scheme for generating stable IPv6 129 addresses with SLAAC to that specified in [RFC7217], and recommends 130 against embedding stable link-layer addresses in IPv6 Interface 131 Identifiers, such that the aforementioned issues are mitigated. That 132 is, this document simply replaces the default algorithm that is 133 recommended to be employed when generating stable IPv6 IIDs. 135 NOTE: [RFC4291] defines the "Modified EUI-64 format" for IIDs. 136 Appendix A of [RFC4291] then describes how to transform an IEEE 137 EUI-64 identifier, or an IEEE 802 48-bit MAC address from which an 138 EUI-64 identifier is derived, into an IID in the Modified EUI-64 139 format. 141 In a variety of scenarios, addresses that remain stable for the 142 lifetime of a host's connection to a single subnet, are viewed as 143 desirable. For example, stable addresses may be viewed as beneficial 144 for network management, event logging, enforcement of access control, 145 provision of quality of service, or for server or routing interfaces. 146 Similarly, stable addresses (as opposed to temporary addresses 147 [RFC4941]) allow for long-lived TCP connections, and are also usually 148 desirable when performing server-like functions (i.e., receiving 149 incoming connections). 151 The recommendations in this document apply only in cases where 152 implementations otherwise would have configured a stable IPv6 IID 153 containing a link layer address. For example, this document does not 154 change any existing recommendations concerning the use of temporary 155 addresses as specified in [RFC4941], nor do the recommendations apply 156 to cases where SLAAC is employed to generate non-stable IPv6 157 addresses (e.g. by embedding a link-layer address that is 158 periodically randomized), nor does it introduce any new requirements 159 regarding when stable addresses are to be configured. Thus, the 160 recommendations in this document simply improve the security and 161 privacy properties of stable addresses. 163 Finally this document updates [RFC3315] by specifying additional 164 requirements on the generation of Interface Identifiers used in 165 Dynamic Host Configuration Protocol version 6 (DHCPv6), and also 166 provides advice to system administrators who employ manual 167 configuration. 169 2. Terminology 171 Stable address: 172 An address that does not vary over time within the same network 173 (as defined in [RFC7721]). 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119 [RFC2119]. 179 3. Generation of IPv6 Interface Identifiers with SLAAC 181 Nodes SHOULD implement and employ [RFC7217] as the default scheme for 182 generating stable IPv6 addresses with SLAAC. A link layer MAY also 183 define a mechanism for stable IPv6 address generation that is more 184 efficient and does not address the security and privacy 185 considerations discussed in Section 1. The choice of whether to 186 enable the security- and privacy-preserving mechanism or not SHOULD 187 be configurable in such a case. 189 By default, nodes SHOULD NOT employ IPv6 address generation schemes 190 that embed a stable link-layer address in the IID. In particular, 191 this document RECOMMENDS that nodes do not generate stable IIDs with 192 the schemes specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491], 194 [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338], 195 [RFC4391], [RFC5121], and [RFC5072]. The specific updates to these 196 documents to effectuate this recommendation are included in 197 Section 6. 199 4. Generation of IPv6 Interface Identifiers with DHCPv6 201 By default, DHCPv6 server implementations SHOULD NOT generate 202 predictable IPv6 addresses (such as IPv6 addresses where the IIDs are 203 consecutive small numbers). 204 [I-D.gont-dhcpv6-stable-privacy-addresses] specifies one possible 205 algorithm that could be employed to comply with this requirement. 206 Another possible algorithm would be to select a pseudo-random value 207 chosen from a discrete uniform distribution, while avoiding the 208 reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]. 210 5. Generation of IPv6 Interface Identifiers with Manual Configuration 212 Network administrators should be aware of the security implications 213 of predictable Interface Identifiers [RFC7721], and avoid the use of 214 predictable addresses when the aforementioned issues are of concern. 216 6. Update to existing RFCs 218 The following subsections clarify how each of the RFCs affected by 219 this document are updated. 221 Note to the RFC Editor: 222 In the following subsections, the legend "[RFCXXXX]" should be 223 replaced with the RFC number assigned to this document, and this 224 note to the RFC Editor should be removed before publication of 225 this document as an RFC. 227 6.1. Update to RFC2464 229 The entire text of Section 4 of [RFC2464] is replaced with the 230 following text: 232 ---------------- cut here -------------- cut here ---------------- 233 The Interface Identifier [AARCH] for an Ethernet interface SHOULD 234 be generated as specified in [RFC7217]. Embedding a stable 235 link-layer address in the IID is NOT RECOMMENDED [RFCXXXX]. 236 ---------------- cut here -------------- cut here ---------------- 238 The following text from Section 6 of [RFC2464]: 240 ---------------- cut here -------------- cut here ---------------- 241 Ethernet Address 242 The 48 bit Ethernet IEEE 802 address, in canonical bit 243 order. This is the address the interface currently 244 responds to, and may be different from the built-in 245 address used to derive the Interface Identifier. 246 ---------------- cut here -------------- cut here ---------------- 248 is formally replaced with: 250 ---------------- cut here -------------- cut here ---------------- 251 Ethernet Address 252 The 48 bit Ethernet IEEE 802 address, in canonical bit 253 order. This is the address the interface currently 254 responds to. 255 ---------------- cut here -------------- cut here ---------------- 257 6.2. Update to RFC2467 259 The entire text of Section 5 of [RFC2467] is replaced with the 260 following text: 262 ---------------- cut here -------------- cut here ---------------- 263 The Interface Identifier [AARCH] for an FDDI interface SHOULD 264 be generated as specified in [RFC7217]. Embedding a stable 265 link-layer address in the IID is NOT RECOMMENDED [RFCXXXX]. 266 ---------------- cut here -------------- cut here ---------------- 268 The following text from Section 7 of [RFC2467]: 270 ---------------- cut here -------------- cut here ---------------- 271 FDDI Address 272 The 48 bit FDDI IEEE 802 address, in canonical bit order. 273 This is the address the interface currently responds to, 274 and may be different from the built-in address used to 275 derive the Interface Identifier. 276 ---------------- cut here -------------- cut here ---------------- 278 is formally replaced with: 280 ---------------- cut here -------------- cut here ---------------- 281 FDDI Address 282 The 48 bit FDDI IEEE 802 address, in canonical bit order. 283 This is the address the interface currently responds to. 284 ---------------- cut here -------------- cut here ---------------- 286 6.3. Update to RFC2470 288 The entire text of Section 4 of [RFC2470] is replaced with the 289 following text: 291 ---------------- cut here -------------- cut here ---------------- 292 The Interface Identifier [AARCH] for a Token Ring interface SHOULD 293 be generated as specified in [RFC7217]. Embedding a stable 294 link-layer address in the IID is NOT RECOMMENDED [RFCXXXX]. 295 ---------------- cut here -------------- cut here ---------------- 297 The following text from Section 6 of [RFC2470]: 299 ---------------- cut here -------------- cut here ---------------- 300 Token Ring Address: The 48 bit Token Ring IEEE 802 301 address, in canonical bit order. This is the address the 302 interface currently responds to, and may be different from 303 the built-in address used to derive the Interface 304 Identifier. 305 ---------------- cut here -------------- cut here ---------------- 307 is formally replaced with: 309 ---------------- cut here -------------- cut here ---------------- 310 Token Ring Address: The 48 bit Token Ring IEEE 802 311 address, in canonical bit order. This is the address the 312 interface currently responds to. 313 ---------------- cut here -------------- cut here ---------------- 315 6.4. Update to RFC2491 317 The entire text of Section 5.1, Section 5.1.1, and Section 5.1.2 of 318 [RFC2491] is replaced with the following text: 320 ---------------- cut here -------------- cut here ---------------- 321 5.1 Interface Tokens 323 The Interface Token (or Interface Identifier [AARCH]) for each IPv6 324 interface SHOULD be generated as specified in [RFC7217]. Embedding 325 a stable link-layer address in the IID is NOT RECOMMENDED [RFCXXXX]. 327 All implementations MUST support manual configuration of interface 328 tokens to allow operators to manually change a interface token on 329 a per-LL basis. Operators may choose to manually set interface 330 tokens for reasons other than eliminating duplicate addresses. 332 All interface tokens MUST be 64 bits in length. 333 ---------------- cut here -------------- cut here ---------------- 335 6.5. Update to RFC2492 337 The entire text of Section 5 (and all the corresponding subsections) 338 of of [RFC2492] is replaced with the following text: 340 ---------------- cut here -------------- cut here ---------------- 341 5.1 Interface Tokens 343 The Interface Token (or Interface Identifier [AARCH]) for each IPv6 344 interface SHOULD be generated as specified in [RFC7217]. Embedding 345 a stable link-layer address in the IID is NOT RECOMMENDED [RFCXXXX]. 347 All implementations MUST support manual configuration of interface 348 tokens to allow operators to manually change a interface token on 349 a per-LL basis. Operators may choose to manually set interface 350 tokens for reasons other than eliminating duplicate addresses. 352 All interface tokens MUST be 64 bits in length. 353 ---------------- cut here -------------- cut here ---------------- 355 6.6. Update to RFC2497 357 The entire text of Section 4 of [RFC2497] is replaced with the 358 following text: 360 ---------------- cut here -------------- cut here ---------------- 361 The Interface Identifier [AARCH] for an ARCnet interface SHOULD be 362 generated as specified in [RFC7217]. Embedding a stable link-layer 363 address in the IID is NOT RECOMMENDED [RFCXXXX]. 364 ---------------- cut here -------------- cut here ---------------- 365 The entire text of Section 8 of [RFC2497] is replaced with the 366 following text: 368 ---------------- cut here -------------- cut here ---------------- 369 Interface Identifiers generated as specified in [RFCXXXX] mitigate 370 the security and privacy implications discussed in Section 1 of 371 such document. 372 ---------------- cut here -------------- cut here ---------------- 374 6.7. Update to RFC2590 376 The entire Section 4 and Section 4.1 of [RFC2590] is replaced with 377 the following text: 379 ---------------- cut here -------------- cut here ---------------- 380 4. Stateless Autoconfiguration 382 An interface identifier [AARCH] for an IPv6 Frame Relay interface 383 MUST be unique on a Frame Relay link [AARCH], and MUST be unique on 384 each of the virtual links represented by the VCs terminated on the 385 interface. 387 The interface identifier for the Frame Relay interface SHOULD be 388 generated as specified in [RFC7217]. Embedding a stable link-layer 389 address in the IID is NOT RECOMMENDED [RFCXXXX]. 391 We note that each virtual circuit in a Frame Relay network is uniquely 392 identified on a Frame Relay interface by a DLCI. Furthermore, a DLCI 393 can be seen as an identification of the end point of a virtual circuit 394 on a Frame Relay interface. Since each Frame Relay VC is configured or 395 established separately, and acts like an independent virtual-link 396 from other VCs in the network, or on the interface, link, wire or 397 fiber, it seems beneficial to view each VC's termination point on the 398 Frame Relay interface as a "pseudo-interface" or "logical-interface" 399 overlaid on the Frame Relay interface. Furthermore, it seems 400 beneficial to be able to generate and associate an IPv6 401 autoconfigured address (including an IPv6 link local address) to each 402 "pseudo-interface", i.e. end-point of a VC, i.e. to each DLCI on a 403 Frame Relay interface. 404 ---------------- cut here -------------- cut here ---------------- 406 The entire Section 9 of [RFC2590] is replaced as follows: 408 ---------------- cut here -------------- cut here ---------------- 409 9. Security Considerations 411 Security protection against forgery or accident at the level of 412 the mechanisms described here is provided by the IPv6 security 413 mechanisms [IPSEC], [IPSEC-Auth], [IPSEC-ESP] applied to Neighbor 414 Discovery [IPv6-ND] or Inverse Neighbor Discovery [IND] messages. 416 To avoid an IPsec Authentication verification failure, the Frame 417 Relay specific preprocessing of a Neighbor Discovery Solicitation 418 message that contains a DLCI format Source link-layer address option, 419 MUST be done by the receiver node after it completed IP Security 420 processing. 421 ---------------- cut here -------------- cut here ---------------- 423 6.8. Update to RFC3146 425 The entire Section 6 of [RFC3146] is replaced with the following 426 text: 428 ---------------- cut here -------------- cut here ---------------- 429 6. STATELESS AUTOCONFIGURATION 431 The Interface Identifier [AARCH] for an IEEE1394 interface SHOULD 432 be generated as specified in [RFC7217]. Embedding a stable 433 link-layer address in the IID is NOT RECOMMENDED [RFCXXXX]. 435 An IPv6 address prefix used for stateless autoconfiguration [ACONF] 436 of an IEEE1394 interface MUST have a length of 64 bits. 437 ---------------- cut here -------------- cut here ---------------- 439 6.9. Update to RFC3315 441 The following text in Section 11 of of [RFC3315]: 443 ---------------- cut here -------------- cut here ---------------- 444 Any address assigned by a server that is based on an EUI-64 445 identifier MUST include an interface identifier with the "u" 446 (universal/local) and "g" (individual/group) bits of the interface 447 identifier set appropriately, as indicated in section 2.5.1 of RFC 448 2373 [5]. 449 ---------------- cut here -------------- cut here ---------------- 451 is formally replaced with: 453 ---------------- cut here -------------- cut here ---------------- 454 By default, DHCPv6 server implementations SHOULD NOT generate 455 predictable IPv6 addresses (such as IPv6 addresses where the IIDs are 456 consecutive small numbers). [I-D.gont-dhcpv6-stable-privacy-addresses] 457 specifies one possible algorithm that could be employed to comply 458 with this requirement. Another possible algorithm would be to select 459 a pseudo-random value chosen from a discrete uniform distribution, 460 while avoiding the reserved IPv6 Interface Identifiers [RFC5453] 461 [IANA-RESERVED-IID]. 462 ---------------- cut here -------------- cut here ---------------- 464 Additionally, the following references should be added to Section 26 465 of [RFC3315]: 467 ---------------- cut here -------------- cut here ---------------- 468 [IANA-RESERVED-IID] 469 IANA, "Reserved IPv6 Interface Identifiers", 470 . 472 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 473 RFC 5453, DOI 10.17487/RFC5453, February 2009, 474 . 476 [I-D.gont-dhcpv6-stable-privacy-addresses] 477 Gont, F. and S. LIU, "A Method for Generating Semantically 478 Opaque Interface Identifiers with Dynamic Host 479 Configuration Protocol for IPv6 (DHCPv6)", 480 draft-gont-dhcpv6-stable-privacy-addresses-02 (work in 481 progress), June 2016. 482 ---------------- cut here -------------- cut here ---------------- 484 6.10. Update to RFC3572 486 The entire text of Section 3 of [RFC3572] is replaced as follows: 488 ---------------- cut here -------------- cut here ---------------- 489 3. Interface Identifier 491 The Interface Identifier [AARCH] for a MAPOS interface SHOULD 492 be generated as specified in [RFC7217]. Embedding a stable 493 link-layer address in the IID is NOT RECOMMENDED [RFCXXXX]. 494 ---------------- cut here -------------- cut here ---------------- 496 Additionally, Section 6.2 ("Uniqueness of Interface Identifiers") of 497 [RFC3572] is entirely eliminated. 499 6.11. Update to RFC4291 501 The entire text of Section 2.5.1 of [RFC4291] is replaced with the 502 following text: 504 ---------------- cut here -------------- cut here ---------------- 505 2.5.1. Interface Identifiers 507 Interface identifiers in IPv6 unicast addresses are used to identify 508 interfaces on a link. They are required to be unique within a subnet 509 prefix. It is recommended that the same interface identifier not be 510 assigned to different nodes on a link. They may also be unique over 511 a broader scope. The same interface identifier may be used on 512 multiple interfaces on a single node, as long as they are attached to 513 different subnets. 515 For all unicast addresses, except those that start with the binary 516 value 000, Interface IDs are required to be 64 bits long, and SHOULD 517 be generated as specified in [RFC7217]. Embedding a stable link-layer 518 address in the IID is NOT RECOMMENDED [RFCXXXX]. 520 The details of forming interface identifiers are defined in the 521 appropriate "IPv6 over " specification, such as "IPv6 over 522 Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI]. 523 ---------------- cut here -------------- cut here ---------------- 525 6.12. Update to RFC4338 527 The entire text of Section 5 (and of all the corresponding 528 subsections) of [RFC4338] is replaced with the following text: 530 ---------------- cut here -------------- cut here ---------------- 531 5. IPv6 Stateless Address Autoconfiguration 533 The IPv6 Interface ID [AARCH] for an Nx_Port SHOULD be generated 534 as specified in [RFC7217]. Embedding a stable link-layer address 535 in the IID is NOT RECOMMENDED [RFCXXXX]. 537 IPv6 stateless address autoconfiguration MUST be performed as 538 specified in [ACONF]. An IPv6 Address Prefix used for stateless 539 address autoconfiguration of an Nx_Port MUST have a length of 64 540 bits. 541 ---------------- cut here -------------- cut here ---------------- 543 6.13. Update to RFC4391 545 The entire text of Section 8 of [RFC4391] is replaced with the 546 following text: 548 ---------------- cut here -------------- cut here ---------------- 549 8. IPv6 Stateless Autoconfiguration 551 The IPv6 Interface ID [AARCH] SHOULD be generated as specified in 552 [RFC7217]. Embedding a stable link-layer address in the IID is NOT 553 RECOMMENDED [RFCXXXX]. 554 ---------------- cut here -------------- cut here ---------------- 556 6.14. Update to RFC5072 558 The entire text of Section 4.1 of [RFC5072] is replaced with the 559 following text: 561 ---------------- cut here -------------- cut here ---------------- 562 4.1. Interface Identifier 564 Description 566 This Configuration Option provides a way to negotiate a unique, 64- 567 bit interface identifier to be used for the address autoconfiguration 568 [3] at the local end of the link (see Section 5). A Configure- 569 Request MUST contain exactly one instance of the interface-identifier 570 option [1]. The interface identifier MUST be unique within the PPP 571 link; i.e., upon completion of the negotiation, different interface- 572 identifier values are to be selected for the ends of the PPP link. 574 Before this Configuration Option is requested, an implementation 575 chooses its tentative interface identifier. The non-zero value of 576 the tentative interface identifier SHOULD be chosen such that the 577 value is unique to the link and, preferably, consistently 578 reproducible across initializations of the IPV6CP finite state 579 machine (administrative Close and reOpen, reboots, etc.). The 580 rationale for preferring a consistently reproducible unique interface 581 identifier to a completely random interface identifier is to provide 582 stability to global scope addresses (see Appendix A) that can be 583 formed from the interface identifier. Additionally, the tentative 584 interface identifier SHOULD be generated as specified in [RFC7217]. 585 Embedding a stable link-layer address in the IID is NOT 586 RECOMMENDED [RFCXXXX]. 588 If neither a unique number nor a random number can be generated, it 589 is recommended that a zero value be used for the interface identifier 590 transmitted in the Configure-Request. In this case, the PPP peer may 591 provide a valid non-zero interface identifier in its response as 592 described below. Note that if at least one of the PPP peers is able 593 to generate separate non-zero numbers for itself and its peer, the 594 identifier negotiation will succeed. 596 When a Configure-Request is received with the Interface-Identifier 597 Configuration Option and the receiving peer implements this option, 598 the received interface identifier is compared with the interface 599 identifier of the last Configure-Request sent to the peer. Depending 600 on the result of the comparison, an implementation MUST respond in 601 one of the following ways: 603 If the two interface identifiers are different but the received 604 interface identifier is zero, a Configure-Nak is sent with a non-zero 605 interface-identifier value suggested for use by the remote peer. 606 Such a suggested interface identifier MUST be different from the 607 interface identifier of the last Configure-Request sent to the peer. 608 It is recommended that the value suggested be consistently 609 reproducible across initializations of the IPV6CP finite state 610 machine (administrative Close and reOpen, reboots, etc). 611 Additionally, the value suggested SHOULD be generated as specified 612 in [RFC7217]. Embedding a stable link-layer address in the IID is 613 NOT RECOMMENDED [RFCXXXX]. 615 If the two interface identifiers are different and the received 616 interface identifier is not zero, the interface identifier MUST be 617 acknowledged, i.e., a Configure-Ack is sent with the requested 618 interface identifier, meaning that the responding peer agrees with 619 the interface identifier requested. 621 If the two interface identifiers are equal and are not zero, 622 Configure-Nak MUST be sent specifying a different non-zero 623 interface-identifier value suggested for use by the remote peer. It 624 is recommended that the value suggested be consistently reproducible 625 across initializations of the IPV6CP finite state machine 626 (administrative Close and reOpen, reboots, etc). Additionally, the 627 value suggested SHOULD be generated as specified in [RFC7217]. 628 Embedding a stable link-layer address in the IID is NOT RECOMMENDED 629 [RFCXXXX]. 631 If the two interface identifiers are equal to zero, the interface 632 identifier's negotiation MUST be terminated by transmitting the 633 Configure-Reject with the interface-identifier value set to zero. In 634 this case, a unique interface identifier cannot be negotiated. 636 If a Configure-Request is received with the Interface-Identifier 637 Configuration Option and the receiving peer does not implement this 638 option, Configure-Reject is sent. 640 A new Configure-Request SHOULD NOT be sent to the peer until normal 641 processing would cause it to be sent (that is, until a Configure-Nak 642 is received or the Restart timer runs out [1]). 644 A new Configure-Request MUST NOT contain the interface-identifier 645 option if a valid Interface-Identifier Configure-Reject is received. 647 Reception of a Configure-Nak with a suggested interface identifier 648 different from that of the last Configure-Nak sent to the peer 649 indicates a unique interface identifier. In this case, a new 650 Configure-Request MUST be sent with the identifier value suggested in 651 the last Configure-Nak from the peer. But if the received interface 652 identifier is equal to the one sent in the last Configure-Nak, a new 653 interface identifier MUST be chosen. In this case, a new Configure- 654 Request SHOULD be sent with the new tentative interface identifier. 655 This sequence (transmit Configure-Request, receive Configure-Request, 656 transmit Configure-Nak, receive Configure-Nak) might occur a few 657 times, but it is extremely unlikely to occur repeatedly. More 658 likely, the interface identifiers chosen at either end will quickly 659 diverge, terminating the sequence. 661 If negotiation of the interface identifier is required, and the peer 662 did not provide the option in its Configure-Request, the option 663 SHOULD be appended to a Configure-Nak. The tentative value of the 664 interface identifier given must be acceptable as the remote interface 665 identifier; i.e., it should be different from the identifier value 666 selected for the local end of the PPP link. The next Configure- 667 Request from the peer may include this option. If the next 668 Configure-Request does not include this option, the peer MUST NOT 669 send another Configure-Nak with this option included. It should 670 assume that the peer's implementation does not support this option. 672 By default, an implementation SHOULD attempt to negotiate the 673 interface identifier for its end of the PPP connection. 675 A summary of the Interface-Identifier Configuration Option format is 676 shown below. The fields are transmitted from left to right. 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Type | Length | Interface-Identifier (MS Bytes) 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 Interface-Identifier (cont) 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 Interface-Identifier (LS Bytes) | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 Type 689 1 691 Length 693 10 695 Interface-Identifier 697 The 64-bit interface identifier, which is very likely to be 698 unique on the link, or zero if a good source of uniqueness 699 cannot be found. 701 Default 703 If no valid interface identifier can be successfully 704 negotiated, no default interface-identifier value should be 705 assumed. The procedures for recovering from such a case will 706 depend on the algorithm employed to generate the interface 707 identifier. One approach is to manually configure the 708 interface identifier of the interface. 709 ---------------- cut here -------------- cut here ---------------- 711 Additionally, the following text of Section 5 of [RFC5072]: 713 ---------------- cut here -------------- cut here ---------------- 714 5. Stateless Autoconfiguration and Link-Local Addresses 716 The interface identifier of IPv6 unicast addresses [5] of a PPP 717 interface SHOULD be negotiated in the IPV6CP phase of the PPP 718 connection setup (see Section 4.1). If no valid interface identifier 719 has been successfully negotiated, procedures for recovering from such 720 a case are unspecified. One approach is to manually configure the 721 interface identifier of the interface. 722 The negotiated interface identifier is used by the local end of the 723 PPP link to autoconfigure an IPv6 link-local unicast address for the 724 PPP interface. However, it SHOULD NOT be assumed that the same 725 interface identifier is used in configuring global unicast addresses 726 for the PPP interface using IPv6 stateless address autoconfiguration 727 [3]. The PPP peer MAY generate one or more interface identifiers, 728 for instance, using a method described in [8], to autoconfigure one 729 or more global unicast addresses. 731 is formally replaced with the following text: 733 ---------------- cut here -------------- cut here ---------------- 734 5. Stateless Autoconfiguration and Link-Local Addresses 736 The interface identifier of IPv6 unicast addresses [5] of a PPP 737 interface SHOULD be negotiated in the IPV6CP phase of the PPP 738 connection setup (see Section 4.1). If no valid interface identifier 739 has been successfully negotiated, procedures for recovering from such 740 a case will depend on the algorithm employed to generate the interface 741 identifier. One approach is to manually configure the interface 742 identifier of the interface. 744 The negotiated interface identifier is used by the local end of the 745 PPP link to autoconfigure an IPv6 link-local unicast address for the 746 PPP interface. However, it SHOULD NOT be assumed that the same 747 interface identifier is used in configuring global unicast addresses 748 for the PPP interface using IPv6 stateless address autoconfiguration 749 [3]. 750 ---------------- cut here -------------- cut here ---------------- 752 6.15. Update to RFC5121 754 The entire text of Section 9.1 of [RFC5121] is replaced with the 755 following text: 757 ---------------- cut here -------------- cut here ---------------- 758 9.1. Interface Identifier 760 The MS SHOULD generate interface identifiers as specified in 761 [RFC7217]. Embedding a stable link-layer address in the IID is 762 NOT RECOMMENDED [RFCXXXX]. 763 ---------------- cut here -------------- cut here ---------------- 765 Additionally, Section 9.2 is replaced as follows: 767 ---------------- cut here -------------- cut here ---------------- 768 9.2. Duplicate Address Detection 770 DAD SHOULD be performed as per "Neighbor Discovery for IP Version 6 771 (IPv6)", [RFC4861] and "IPv6 Stateless Address Autoconfiguration" 772 [RFC4862]. The IPv6 link over 802.16 is specified in this document 773 as a point-to-point link. Based on this criteria, it may be 774 redundant to perform DAD on a global unicast address that is 775 configured as part of the IPv6 Stateless Address Autoconfiguration 776 Protocol [RFC4862] as long as the following two conditions are met: 778 1. The prefixes advertised through the router advertisement messages 779 by the access router terminating the 802.16 IPv6 link are unique 780 to that link. 782 2. The access router terminating the 802.16 IPv6 link does not 783 autoconfigure any IPv6 global unicast addresses from the prefix 784 that it advertises. 785 ---------------- cut here -------------- cut here ---------------- 787 7. Future Work 789 At the time of this writing, the mechanisms specified in the 790 following documents might require updates to be fully compatible with 791 the recommendations in this document: 793 o "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based 794 Networks" [RFC6282] 796 o "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" 797 [RFC4944] 799 o "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 800 Personal Area Networks (6LoWPANs)"[RFC6775] 802 o "Transmission of IPv6 Packets over ITU-T G.9959 Networks"[RFC7428] 804 Future revisions or updates of these documents should take the issues 805 of privacy and security mentioned in Section 1 and explain any design 806 and engineering considerations that lead to the use of stable IIDs 807 based on a node's link-layer address. 809 8. IANA Considerations 811 There are no IANA registries within this document. The RFC-Editor 812 can remove this section before publication of this document as an 813 RFC. 815 9. Security Considerations 817 This recommends against the (default) use of predictable Interface 818 Identifiers in IPv6 addresses. It recommends [RFC7217] as the 819 default scheme for generating IPv6 stable addresses with SLAAC, such 820 that the security and privacy issues of IIDs that embed stable link- 821 layer addresses are mitigated. Additionally, it recommends against 822 predictable IIDs in DHCPv6 and manual configuration 824 10. Acknowledgements 826 The authors would like to thank (in alphabetical order) Bob Hinden, 827 Ray Hunter and Erik Nordmark, for providing a detailed review of this 828 document. 830 The authors would like to thank (in alphabetical order) Fred Baker, 831 Carsten Bormann, Scott Brim, Brian Carpenter, Samita Chakrabarti, Tim 832 Chown, Lorenzo Colitti, Jean-Michel Combes, Greg Daley, Esko Dijk, 833 Ralph Droms, David Farmer, Brian Haberman, Ulrich Herberg, Philip 834 Homburg, Jahangir Hossain, Jonathan Hui, Christian Huitema, Ray 835 Hunter, Erik Kline, Sheng Jiang, Roger Jorgensen, Dan Luedtke, Kerry 836 Lynn, George Mitchel, Gabriel Montenegro, Erik Nordmark, Simon 837 Perreault, Tom Petch, Alexandru Petrescu, Michael Richardson, Arturo 838 Servin, Mark Smith, Tom Taylor, Ole Troan, Tina Tsou, Glen Turner, 839 Randy Turner, James Woodyatt, and Juan Carlos Zuniga, for providing 840 valuable comments on earlier versions of this document. 842 11. References 844 11.1. Normative References 846 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 847 Requirement Levels", BCP 14, RFC 2119, 848 DOI 10.17487/RFC2119, March 1997, 849 . 851 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 852 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 853 December 1998, . 855 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 856 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 857 . 859 [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI 860 Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998, 861 . 863 [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of 864 IPv6 Packets over Token Ring Networks", RFC 2470, 865 DOI 10.17487/RFC2470, December 1998, 866 . 868 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 869 over Non-Broadcast Multiple Access (NBMA) networks", 870 RFC 2491, DOI 10.17487/RFC2491, January 1999, 871 . 873 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 874 Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, 875 . 877 [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet 878 Networks", RFC 2497, DOI 10.17487/RFC2497, January 1999, 879 . 881 [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of 882 IPv6 Packets over Frame Relay Networks Specification", 883 RFC 2590, DOI 10.17487/RFC2590, May 1999, 884 . 886 [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets 887 over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146, 888 October 2001, . 890 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 891 C., and M. Carney, "Dynamic Host Configuration Protocol 892 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 893 2003, . 895 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 896 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 897 2006, . 899 [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of 900 IPv6, IPv4, and Address Resolution Protocol (ARP) Packets 901 over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338, 902 January 2006, . 904 [RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over 905 InfiniBand (IPoIB)", RFC 4391, DOI 10.17487/RFC4391, April 906 2006, . 908 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 909 Address Autoconfiguration", RFC 4862, 910 DOI 10.17487/RFC4862, September 2007, 911 . 913 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 914 Extensions for Stateless Address Autoconfiguration in 915 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 916 . 918 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 919 "Transmission of IPv6 Packets over IEEE 802.15.4 920 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 921 . 923 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 924 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 925 . 927 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 928 Madanapalli, "Transmission of IPv6 via the IPv6 929 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 930 DOI 10.17487/RFC5121, February 2008, 931 . 933 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 934 RFC 5453, DOI 10.17487/RFC5453, February 2009, 935 . 937 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 938 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 939 DOI 10.17487/RFC6282, September 2011, 940 . 942 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 943 Bormann, "Neighbor Discovery Optimization for IPv6 over 944 Low-Power Wireless Personal Area Networks (6LoWPANs)", 945 RFC 6775, DOI 10.17487/RFC6775, November 2012, 946 . 948 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 949 Interface Identifiers with IPv6 Stateless Address 950 Autoconfiguration (SLAAC)", RFC 7217, 951 DOI 10.17487/RFC7217, April 2014, 952 . 954 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets 955 over ITU-T G.9959 Networks", RFC 7428, 956 DOI 10.17487/RFC7428, February 2015, 957 . 959 11.2. Informative References 961 [I-D.gont-dhcpv6-stable-privacy-addresses] 962 Gont, F. and S. (Will), "A Method for Generating 963 Semantically Opaque Interface Identifiers with Dynamic 964 Host Configuration Protocol for IPv6 (DHCPv6)", draft- 965 gont-dhcpv6-stable-privacy-addresses-02 (work in 966 progress), June 2016. 968 [I-D.gont-predictable-numeric-ids] 969 Gont, F. and I. Arce, "Security and Privacy Implications 970 of Numeric Identifiers Employed in Network Protocols", 971 draft-gont-predictable-numeric-ids-00 (work in progress), 972 February 2016. 974 [IANA-RESERVED-IID] 975 IANA, "Reserved IPv6 Interface Identifiers", 976 . 978 [Microsoft] 979 Davies, J., "Understanding IPv6, 3rd. ed", page 83, 980 Microsoft Press, 2012, . 982 [RFC3572] Ogura, T., Maruyama, M., and T. Yoshida, "Internet 983 Protocol Version 6 over MAPOS (Multiple Access Protocol 984 Over SONET/SDH)", RFC 3572, DOI 10.17487/RFC3572, July 985 2003, . 987 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 988 Considerations for IPv6 Address Generation Mechanisms", 989 RFC 7721, DOI 10.17487/RFC7721, March 2016, 990 . 992 Authors' Addresses 993 Fernando Gont 994 SI6 Networks / UTN-FRH 995 Evaristo Carriego 2644 996 Haedo, Provincia de Buenos Aires 1706 997 Argentina 999 Phone: +54 11 4650 8472 1000 Email: fgont@si6networks.com 1001 URI: http://www.si6networks.com 1003 Alissa Cooper 1004 Cisco 1005 707 Tasman Drive 1006 Milpitas, CA 95035 1007 US 1009 Phone: +1-408-902-3950 1010 Email: alcoop@cisco.com 1011 URI: https://www.cisco.com/ 1013 Dave Thaler 1014 Microsoft 1015 Microsoft Corporation 1016 One Microsoft Way 1017 Redmond, WA 98052 1019 Phone: +1 425 703 8835 1020 Email: dthaler@microsoft.com 1022 Will Liu 1023 Huawei Technologies 1024 Bantian, Longgang District 1025 Shenzhen 518129 1026 P.R. China 1028 Email: liushucheng@huawei.com