idnits 2.17.1 draft-ietf-6man-default-iids-03.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 (May 6, 2015) is 3278 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 256, 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-05 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: November 7, 2015 Huawei Technologies 10 May 6, 2015 12 Recommendation on Stable IPv6 Interface Identifiers 13 draft-ietf-6man-default-iids-03 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 November 7, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 77 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 83 10.2. Informative References . . . . . . . . . . . . . . . . . 7 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 It is RECOMMENDED by this document that future specifications do not 164 specify IPv6 address generation schemes that embed the underlying 165 link-layer address in the IID. Future specifications MAY use an IID 166 based on a node's link-layer address if design and engineering 167 considerations warrant. 169 4. Generation of IPv6 Interface Identifiers with DHCPv6 171 By default, DHCPv6 server implementations SHOULD NOT generate 172 predictable IPv6 addresses (such as IPv6 addresses where the IIDs are 173 consecutive small numbers). [I-D.ietf-dhc-stable-privacy-addresses] 174 specifies one possible algorithm that could be employed to comply 175 with this requirement. Another possible algorithm would be to select 176 a pseudo-random value chosen from a discrete uniform distribution, 177 while avoiding the reserved IPv6 Interface Identifiers [RFC5453] 178 [IANA-RESERVED-IID]. 180 5. Generation of IPv6 Interface Identifiers with Manual Configuration 182 Network administrators should be aware of the security implications 183 of predictable Interface Identifiers 184 [I-D.ietf-6man-ipv6-address-generation-privacy], and avoid the use of 185 predictable addresses when the aforementioned issues are of concern. 187 6. Future Work 189 At the time of this writing, the mechanisms specified in the 190 following documents might require updates to be fully compatible with 191 the recommendations in this document: 193 o RFC 6282 [RFC6282] 195 o RFC 4944 [RFC4944] 197 o RFC 6755 [RFC6775] 199 Future revisions or updates of these documents should take the issues 200 of privacy and security mentioned in Section 1 and explain any design 201 and engineering considerations that lead to the use of IIDs based on 202 a node's link-layer address. 204 7. IANA Considerations 206 There are no IANA registries within this document. The RFC-Editor 207 can remove this section before publication of this document as an 208 RFC. 210 8. Security Considerations 212 This document recommends [RFC7217] as the default scheme for 213 generating IPv6 stable addresses with SLAAC, such that the security 214 and privacy issues of IIDs that embed link-layer addresses are 215 mitigated. 217 9. Acknowledgements 219 The authors would like to thank Erik Nordmark and Ray Hunter for 220 providing a detailed review of this document. 222 The authors would like to thank (in alphabetical order) Fred Baker, 223 Carsten Bormann, Scott Brim, Brian Carpenter, Samita Chakrabarti, Tim 224 Chown, Lorenzo Colitti, Jean-Michel Combes, Greg Daley, Esko Dijk, 225 Ralph Droms, David Farmer, Brian Haberman, Ulrich Herberg, Bob 226 Hinden, Jahangir Hossain, Jonathan Hui, Ray Hunter, Sheng Jiang, 227 Roger Jorgensen, Dan Luedtke, Kerry Lynn, George Mitchel, Erik 228 Nordmark, Simon Perreault, Tom Petch, Alexandru Petrescu, Michael 229 Richardson, Arturo Servin, Mark Smith, Tom Taylor, Ole Troan, Tina 230 Tsou, Glen Turner, Randy Turner, and James Woodyatt, for providing 231 valuable comments on earlier versions of this document. 233 10. References 235 10.1. Normative References 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, March 1997. 240 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 241 (IPv6) Specification", RFC 2460, December 1998. 243 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 244 Networks", RFC 2464, December 1998. 246 [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI 247 Networks", RFC 2467, December 1998. 249 [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of 250 IPv6 Packets over Token Ring Networks", RFC 2470, December 251 1998. 253 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 254 Networks", RFC 2492, January 1999. 256 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 257 and M. Carney, "Dynamic Host Configuration Protocol for 258 IPv6 (DHCPv6)", RFC 3315, July 2003. 260 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 261 Architecture", RFC 4291, February 2006. 263 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 264 Address Autoconfiguration", RFC 4862, September 2007. 266 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 267 Interface Identifiers with IPv6 Stateless Address 268 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 270 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 271 over Non-Broadcast Multiple Access (NBMA) networks", RFC 272 2491, January 1999. 274 [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet 275 Networks", RFC 2497, January 1999. 277 [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of 278 IPv6 Packets over Frame Relay Networks Specification", RFC 279 2590, May 1999. 281 [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets 282 over IEEE 1394 Networks", RFC 3146, October 2001. 284 [RFC3572] Ogura, T., Maruyama, M., and T. Yoshida, "Internet 285 Protocol Version 6 over MAPOS (Multiple Access Protocol 286 Over SONET/SDH)", RFC 3572, July 2003. 288 [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of 289 IPv6, IPv4, and Address Resolution Protocol (ARP) Packets 290 over Fibre Channel", RFC 4338, January 2006. 292 [RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over 293 InfiniBand (IPoIB)", RFC 4391, April 2006. 295 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 296 "Transmission of IPv6 Packets over IEEE 802.15.4 297 Networks", RFC 4944, September 2007. 299 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 300 Madanapalli, "Transmission of IPv6 via the IPv6 301 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 302 February 2008. 304 [RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over 305 PPP", RFC 5072, September 2007. 307 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 308 5453, February 2009. 310 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 311 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 312 September 2011. 314 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 315 "Neighbor Discovery Optimization for IPv6 over Low-Power 316 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 317 November 2012. 319 10.2. Informative References 321 [IANA-RESERVED-IID] 322 IANA, "Reserved IPv6 Interface Identifiers", 323 . 325 [I-D.ietf-6man-ipv6-address-generation-privacy] 326 Cooper, A., Gont, F., and D. Thaler, "Privacy 327 Considerations for IPv6 Address Generation Mechanisms", 328 draft-ietf-6man-ipv6-address-generation-privacy-05 (work 329 in progress), April 2015. 331 [I-D.ietf-dhc-stable-privacy-addresses] 332 Gont, F. and W. Will, "A Method for Generating 333 Semantically Opaque Interface Identifiers with Dynamic 334 Host Configuration Protocol for IPv6 (DHCPv6)", draft- 335 ietf-dhc-stable-privacy-addresses-02 (work in progress), 336 April 2015. 338 [Microsoft] 339 Davies, J., "Understanding IPv6, 3rd. ed", page 83, 340 Microsoft Press, 2012, . 342 Authors' Addresses 344 Fernando Gont 345 SI6 Networks / UTN-FRH 346 Evaristo Carriego 2644 347 Haedo, Provincia de Buenos Aires 1706 348 Argentina 350 Phone: +54 11 4650 8472 351 Email: fgont@si6networks.com 352 URI: http://www.si6networks.com 354 Alissa Cooper 355 Cisco 356 707 Tasman Drive 357 Milpitas, CA 95035 358 US 360 Phone: +1-408-902-3950 361 Email: alcoop@cisco.com 362 URI: https://www.cisco.com/ 364 Dave Thaler 365 Microsoft 366 Microsoft Corporation 367 One Microsoft Way 368 Redmond, WA 98052 370 Phone: +1 425 703 8835 371 Email: dthaler@microsoft.com 372 Will Liu 373 Huawei Technologies 374 Bantian, Longgang District 375 Shenzhen 518129 376 P.R. China 378 Email: liushucheng@huawei.com