idnits 2.17.1 draft-ietf-6man-default-iids-08.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 RFC4944, 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 (October 14, 2015) is 3110 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) == Unused Reference: 'RFC3315' is defined on line 274, 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) ** Downref: Normative reference to an Informational RFC: RFC 3572 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 11 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, 4944, 5072, D. Thaler 7 5121 (if approved) Microsoft 8 Intended status: Standards Track W. Liu 9 Expires: April 16, 2016 Huawei Technologies 10 October 14, 2015 12 Recommendation on Stable IPv6 Interface Identifiers 13 draft-ietf-6man-default-iids-08 15 Abstract 17 This document changes the recommended default Interface Identifier 18 generation scheme for 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, RFC4944, RFC5072, and RFC5121, which require IPv6 Interface 23 Identifiers to be derived from the underlying link-layer address. 24 Additionally, this document provides advice about the generation of 25 Interface Identifiers with Dynamic Host Configuration Protocol 26 version 6 (DHCPv6) (thus updating RFC3315) and manual configuration. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 16, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Generation of IPv6 Interface Identifiers with SLAAC . . . . . 3 65 4. Generation of IPv6 Interface Identifiers with DHCPv6 . . . . 4 66 5. Generation of IPv6 Interface Identifiers with Manual 67 Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5 68 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 10.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for 80 IPv6 [RFC2460], which typically results in hosts configuring one or 81 more "stable" addresses composed of a network prefix advertised by a 82 local router, and an Interface Identifier (IID) [RFC4291] that 83 typically embeds a link-layer address (e.g., an IEEE LAN MAC 84 address). 86 In some network technologies and adaptation layers, the use of an IID 87 based on a link-layer address may offer some advantages. For 88 example, the IP-over-IEEE802.15.4 standard in [RFC6775] allows for 89 compression of IPv6 addresses when the IID is based on the underlying 90 link-layer address. 92 The security and privacy implications of embedding a link-layer 93 address in an IPv6 IID have been known for some time now, and are 94 discussed in great detail in 95 [I-D.ietf-6man-ipv6-address-generation-privacy]; they include: 97 o Network activity correlation 99 o Location tracking 101 o Address scanning 103 o Device-specific vulnerability exploitation 105 Some popular IPv6 implementations have already deviated from the 106 traditional stable IID generation scheme to mitigate the 107 aforementioned security and privacy implications [Microsoft]. 109 As a result of the aforementioned issues, this document recommends 110 the implementation of an alternative scheme ([RFC7217]) as the 111 default stable IID generation scheme for SLAAC, such that the 112 aforementioned issues are mitigated. 114 NOTE: [RFC4291] defines the "Modified EUI-64 format" for IIDs. 115 Appendix A of [RFC4291] then describes how to transform an IEEE 116 EUI-64 identifier, or an IEEE 802 48-bit MAC address from which an 117 EUI-64 identifier is derived, into an IID in the Modified EUI-64 118 format. 120 Finally this document provides advice about the generation of 121 Interface Identifiers with other address configuration mechanisms, 122 such as Dynamic Host Configuration Protocol version 6 (DHCPv6) and 123 manual configuration. 125 2. Terminology 127 Stable address: 128 An address that does not vary over time within the same network 129 (as defined in [I-D.ietf-6man-ipv6-address-generation-privacy]). 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 3. Generation of IPv6 Interface Identifiers with SLAAC 137 Link layers MUST define a mechanism that provides mitigation of the 138 security and privacy implications discussed in Section 1. Nodes 139 SHOULD implement and employ [RFC7217] as the default scheme for 140 generating stable IPv6 addresses with SLAAC. A link layer MAY also 141 define a mechanism that is more efficient and does not address the 142 security and privacy considerations discussed in Section 1. The 143 choice of whether to enable privacy or not SHOULD be configurable in 144 such a case. 146 By default, nodes SHOULD NOT employ IPv6 address generation schemes 147 that embed the underlying link-layer address in the IID. In 148 particular, this document RECOMMENDS that nodes do not generate IIDs 149 with the schemes specified in [RFC2464], [RFC2467], [RFC2470], 150 [RFC2491], [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], 151 [RFC4338], [RFC4391], [RFC4944], [RFC5121], and [RFC5072], and 152 updates these documents with this recommendation. The 153 recommendations in this document override any other recommendations 154 on the generation of IIDs in the updated RFCs. 156 Some link-layers support locally assigned link-layer addresses 157 [IEEE-802], such as [IEEE-802.3] and [IEEE-802.11], or random 158 addresses [BLUETOOTH]. Where IPv6 IIDs are to be derived from link- 159 layer addresses, it is RECOMMENDED that the random addresses 160 supported by the link-layer are used, or that pseudo-random locally 161 assigned link-layer addresses are generated, assigned and used. 163 Future specifications SHOULD NOT specify IPv6 address generation 164 schemes that embed the underlying link-layer address in the IID. In 165 some cases, embedding the link-layer address in the IID may reduce 166 resource requirements such as energy, bandwidth and number of frames 167 to carry a given IPv6 packet by facilitating header compression in 168 constrained devices. In such cases, future specifications MAY 169 include IPv6 address generation schemes that embed the link-layer 170 address in the IID, but MUST also specify an alternative IPv6 address 171 generation scheme that provides mitigation of the security and 172 privacy implications discussed in Section 1. 174 4. Generation of IPv6 Interface Identifiers with DHCPv6 176 By default, DHCPv6 server implementations SHOULD NOT generate 177 predictable IPv6 addresses (such as IPv6 addresses where the IIDs are 178 consecutive small numbers). [I-D.ietf-dhc-stable-privacy-addresses] 179 specifies one possible algorithm that could be employed to comply 180 with this requirement. Another possible algorithm would be to select 181 a pseudo-random value chosen from a discrete uniform distribution, 182 while avoiding the reserved IPv6 Interface Identifiers [RFC5453] 183 [IANA-RESERVED-IID]. 185 5. Generation of IPv6 Interface Identifiers with Manual Configuration 187 Network administrators should be aware of the security implications 188 of predictable Interface Identifiers 189 [I-D.ietf-6man-ipv6-address-generation-privacy], and avoid the use of 190 predictable addresses when the aforementioned issues are of concern. 192 6. Future Work 194 At the time of this writing, the mechanisms specified in the 195 following documents might require updates to be fully compatible with 196 the recommendations in this document: 198 o "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based 199 Networks" [RFC6282] 201 o "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" 202 [RFC4944] 204 o "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 205 Personal Area Networks (6LoWPANs)"[RFC6775] 207 Future revisions or updates of these documents should take the issues 208 of privacy and security mentioned in Section 1 and explain any design 209 and engineering considerations that lead to the use of IIDs based on 210 a node's link-layer address. 212 7. IANA Considerations 214 There are no IANA registries within this document. The RFC-Editor 215 can remove this section before publication of this document as an 216 RFC. 218 8. Security Considerations 220 This recommends against the (default) use of predictable Interface 221 Identifiers in IPv6 addresses. It recommends [RFC7217] as the 222 default scheme for generating IPv6 stable addresses with SLAAC, such 223 that the security and privacy issues of IIDs that embed link-layer 224 addresses are mitigated, and recommends against predictable IIDs in 225 DHCPv6 and manual configuration 227 9. Acknowledgements 229 The authors would like to thank Erik Nordmark and Ray Hunter for 230 providing a detailed review of this document. 232 The authors would like to thank (in alphabetical order) Fred Baker, 233 Carsten Bormann, Scott Brim, Brian Carpenter, Samita Chakrabarti, Tim 234 Chown, Lorenzo Colitti, Jean-Michel Combes, Greg Daley, Esko Dijk, 235 Ralph Droms, David Farmer, Brian Haberman, Ulrich Herberg, Bob 236 Hinden, Philip Homburg, Jahangir Hossain, Jonathan Hui, Christian 237 Huitema, Ray Hunter, Sheng Jiang, Roger Jorgensen, Dan Luedtke, Kerry 238 Lynn, George Mitchel, Gabriel Montenegro, Erik Nordmark, Simon 239 Perreault, Tom Petch, Alexandru Petrescu, Michael Richardson, Arturo 240 Servin, Mark Smith, Tom Taylor, Ole Troan, Tina Tsou, Glen Turner, 241 Randy Turner, and James Woodyatt, for providing valuable comments on 242 earlier versions of this document. 244 10. References 246 10.1. Normative References 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, 250 DOI 10.17487/RFC2119, March 1997, 251 . 253 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 254 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 255 December 1998, . 257 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 258 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 259 . 261 [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI 262 Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998, 263 . 265 [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of 266 IPv6 Packets over Token Ring Networks", RFC 2470, 267 DOI 10.17487/RFC2470, December 1998, 268 . 270 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 271 Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, 272 . 274 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 275 C., and M. Carney, "Dynamic Host Configuration Protocol 276 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 277 2003, . 279 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 280 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 281 2006, . 283 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 284 Address Autoconfiguration", RFC 4862, 285 DOI 10.17487/RFC4862, September 2007, 286 . 288 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 289 Interface Identifiers with IPv6 Stateless Address 290 Autoconfiguration (SLAAC)", RFC 7217, 291 DOI 10.17487/RFC7217, April 2014, 292 . 294 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 295 over Non-Broadcast Multiple Access (NBMA) networks", 296 RFC 2491, DOI 10.17487/RFC2491, January 1999, 297 . 299 [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet 300 Networks", RFC 2497, DOI 10.17487/RFC2497, January 1999, 301 . 303 [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of 304 IPv6 Packets over Frame Relay Networks Specification", 305 RFC 2590, DOI 10.17487/RFC2590, May 1999, 306 . 308 [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets 309 over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146, 310 October 2001, . 312 [RFC3572] Ogura, T., Maruyama, M., and T. Yoshida, "Internet 313 Protocol Version 6 over MAPOS (Multiple Access Protocol 314 Over SONET/SDH)", RFC 3572, DOI 10.17487/RFC3572, July 315 2003, . 317 [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of 318 IPv6, IPv4, and Address Resolution Protocol (ARP) Packets 319 over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338, 320 January 2006, . 322 [RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over 323 InfiniBand (IPoIB)", RFC 4391, DOI 10.17487/RFC4391, April 324 2006, . 326 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 327 "Transmission of IPv6 Packets over IEEE 802.15.4 328 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 329 . 331 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 332 Madanapalli, "Transmission of IPv6 via the IPv6 333 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 334 DOI 10.17487/RFC5121, February 2008, 335 . 337 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 338 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 339 . 341 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 342 RFC 5453, DOI 10.17487/RFC5453, February 2009, 343 . 345 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 346 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 347 DOI 10.17487/RFC6282, September 2011, 348 . 350 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 351 Bormann, "Neighbor Discovery Optimization for IPv6 over 352 Low-Power Wireless Personal Area Networks (6LoWPANs)", 353 RFC 6775, DOI 10.17487/RFC6775, November 2012, 354 . 356 10.2. Informative References 358 [IEEE-802] 359 IEEE, "802-2014 - IEEE Standard for Local and Metropolitan 360 Area Networks: Overview and Architecture", 2014, 361 . 364 [IEEE-802.3] 365 IEEE, "802.3-2012 - IEEE Standard for Ethernet", 2012, 366 . 369 [IEEE-802.11] 370 IEEE, "IEEE Standard for Information technology -- 371 Telecommunications and information exchange between 372 systems -- Local and metropolitan area networks -- 373 Specific requirements -- Part 11: Wireless LAN Medium 374 Access Control (MAC) and Physical Layer (PHY) 375 Specifications", 2012, 376 . 379 [BLUETOOTH] 380 Bluetooth SIG, "BLUETOOTH SPECIFICATION Version 4.2", 381 2014, . 384 [IANA-RESERVED-IID] 385 IANA, "Reserved IPv6 Interface Identifiers", 386 . 388 [I-D.ietf-6man-ipv6-address-generation-privacy] 389 Cooper, A., Gont, F., and D. Thaler, "Privacy 390 Considerations for IPv6 Address Generation Mechanisms", 391 draft-ietf-6man-ipv6-address-generation-privacy-08 (work 392 in progress), September 2015. 394 [I-D.ietf-dhc-stable-privacy-addresses] 395 Gont, F. and S. LIU, "A Method for Generating Semantically 396 Opaque Interface Identifiers with Dynamic Host 397 Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc- 398 stable-privacy-addresses-02 (work in progress), April 399 2015. 401 [Microsoft] 402 Davies, J., "Understanding IPv6, 3rd. ed", page 83, 403 Microsoft Press, 2012, . 405 Authors' Addresses 407 Fernando Gont 408 SI6 Networks / UTN-FRH 409 Evaristo Carriego 2644 410 Haedo, Provincia de Buenos Aires 1706 411 Argentina 413 Phone: +54 11 4650 8472 414 Email: fgont@si6networks.com 415 URI: http://www.si6networks.com 416 Alissa Cooper 417 Cisco 418 707 Tasman Drive 419 Milpitas, CA 95035 420 US 422 Phone: +1-408-902-3950 423 Email: alcoop@cisco.com 424 URI: https://www.cisco.com/ 426 Dave Thaler 427 Microsoft 428 Microsoft Corporation 429 One Microsoft Way 430 Redmond, WA 98052 432 Phone: +1 425 703 8835 433 Email: dthaler@microsoft.com 435 Will Liu 436 Huawei Technologies 437 Bantian, Longgang District 438 Shenzhen 518129 439 P.R. China 441 Email: liushucheng@huawei.com