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