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