idnits 2.17.1 draft-ietf-6man-default-iids-02.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 (January 20, 2015) is 3382 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 3572 == Outdated reference: A later version (-08) exists of draft-ietf-6man-ipv6-address-generation-privacy-03 Summary: 2 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, 3572, 4291, Cisco 6 4338, 4391, 4944, 5072, 5121 D. Thaler 7 (if approved) Microsoft 8 Intended status: Standards Track W. Liu 9 Expires: July 24, 2015 Huawei Technologies 10 January 20, 2015 12 Recommendation on Stable IPv6 Interface Identifiers 13 draft-ietf-6man-default-iids-02 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 to that 27 specified in RFC7217, and recommends against embedding link-layer 28 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. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 24, 2015. 50 Copyright Notice 52 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Generation of IPv6 Interface Identifiers . . . . . . . . . . 3 70 4. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 76 8.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for 82 IPv6 [RFC2460], which typically results in hosts configuring one or 83 more "stable" addresses composed of a network prefix advertised by a 84 local router, and an Interface Identifier (IID) [RFC4291] that 85 typically embeds a link-layer address (e.g., an IEEE LAN MAC 86 address). 88 In some network technologies and adaptation layers, the use of an 89 Interface-ID based on a link-layer address may offer some advantages. 90 For example, the IP-over-IEEE802.15.4 standard in [RFC6775] allows 91 for compression of IPv6 addresses when the Interface-ID is based on 92 the underlying link-layer address. 94 The security and privacy implications of embedding a link-layer 95 address in an IPv6 Interface ID have been known for some time now, 96 and are discussed in great detail in 97 [I-D.ietf-6man-ipv6-address-generation-privacy]; they include: 99 o Network activity correlation 101 o Location tracking 103 o Address scanning 105 o Device-specific vulnerability exploitation 107 Some popular IPv6 implementations have already deviated from the 108 traditional stable IID generation scheme to mitigate the 109 aforementioned security and privacy implications [Microsoft]. 111 As a result of the aforementioned issues, this document recommends 112 the implementation of an alternative scheme ([RFC7217]) as the 113 default stable Interface-ID generation scheme, such that the 114 aforementioned issues are mitigated. 116 NOTE: [RFC4291] defines the "Modified EUI-64 format" for Interface 117 identifiers. Appendix A of [RFC4291] then describes how to transform 118 an IEEE EUI-64 identifier, or an IEEE 802 48-bit MAC address from 119 which an EUI-64 identifier is derived, into an interface identifier 120 in the Modified EUI-64 format. 122 2. Terminology 124 Stable address: 125 An address that does not vary over time within the same network 126 (as defined in [I-D.ietf-6man-ipv6-address-generation-privacy]. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 3. Generation of IPv6 Interface Identifiers 134 Nodes SHOULD implement and employ [RFC7217] as the default scheme for 135 generating stable IPv6 addresses with SLAAC. Link layers MUST define 136 a mechanism that provides that mitigates the security and privacy 137 implications discussed in Section 1. A link layer MAY also define a 138 mechanism that is more efficient and does not address the security 139 and privacy considerations discussed in Section 1. The choice of 140 whether to enable privacy or not SHOULD be configurable in such a 141 case. 143 Nodes SHOULD NOT employ IPv6 address generation schemes that embed 144 the underlying link-layer address in the Interface Identifier. In 145 particular, this document RECOMMENDS that nodes do not generate 146 Interface Identifiers with the schemes specified in [RFC2464], 147 [RFC2467], [RFC2470], [RFC2491], [RFC2492], [RFC2497], [RFC2590], 148 [RFC3146], [RFC3572], [RFC4338], [RFC4391], [RFC4944], [RFC5121], and 149 [RFC5072], and updates these documents with this recommendation. 151 It is RECOMMENDED by this document that future specifications do not 152 specify IPv6 address generation schemes that embed the underlying 153 link-layer address in the Interface Identifier. Future 154 specifications MAY use a an IID based on a node's link-layer address 155 if design and engineering considerations warrant. 157 4. Future Work 159 At the time of this writing, the mechanisms specified in the 160 following documents are not compatible with the recommendations in 161 this document: 163 o RFC 6282 [RFC6282] 165 o RFC 4944 [RFC4944] 167 o RFC 6755 [RFC6775] 169 Future revisions or updates of these documents should take the issues 170 of privacy and security mentioned in Section 1 1 and explain any 171 design and engineering considerations that lead to the use of IIDs 172 based on a node's link-layer address. 174 5. IANA Considerations 176 There are no IANA registries within this document. The RFC-Editor 177 can remove this section before publication of this document as an 178 RFC. 180 6. Security Considerations 182 This document recommends [RFC7217] as the default scheme for 183 generating IPv6 stable addresses with SLAAC, such that the security 184 and privacy issues of Interface IDs that embed link-layer addresses 185 are mitigated. 187 7. Acknowledgements 189 The authors would like to thank Erik Nordmark and Ray Hunter for 190 providing a detailed review of this document. 192 The authors would like to thank (in alphabetical order) Fred Baker, 193 Carsten Bormann, Scott Brim, Brian Carpenter, Samita Chakrabarti, Tim 194 Chown, Lorenzo Colitti, Jean-Michel Combes, Greg Daley, Esko Dijk, 195 Ralph Droms, David Farmer, Brian Haberman, Ulrich Herberg, Bob 196 Hinden, Jahangir Hossain, Jonathan Hui, Ray Hunter, Sheng Jiang, 197 Roger Jorgensen, Dan Luedtke, Kerry Lynn, George Mitchel, Erik 198 Nordmark, Simon Perreault, Tom Petch, Alexandru Petrescu, Michael 199 Richardson, Arturo Servin, Mark Smith, Tom Taylor, Ole Troan, Tina 200 Tsou, Glen Turner, and Randy Turner, for providing valuable comments 201 on earlier versions of this document. 203 8. References 205 8.1. Normative References 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, March 1997. 210 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 211 (IPv6) Specification", RFC 2460, December 1998. 213 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 214 Networks", RFC 2464, December 1998. 216 [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI 217 Networks", RFC 2467, December 1998. 219 [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of 220 IPv6 Packets over Token Ring Networks", RFC 2470, December 221 1998. 223 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 224 Networks", RFC 2492, January 1999. 226 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 227 Architecture", RFC 4291, February 2006. 229 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 230 Address Autoconfiguration", RFC 4862, September 2007. 232 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 233 Interface Identifiers with IPv6 Stateless Address 234 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 236 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 237 over Non-Broadcast Multiple Access (NBMA) networks", RFC 238 2491, January 1999. 240 [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet 241 Networks", RFC 2497, January 1999. 243 [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of 244 IPv6 Packets over Frame Relay Networks Specification", RFC 245 2590, May 1999. 247 [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets 248 over IEEE 1394 Networks", RFC 3146, October 2001. 250 [RFC3572] Ogura, T., Maruyama, M., and T. Yoshida, "Internet 251 Protocol Version 6 over MAPOS (Multiple Access Protocol 252 Over SONET/SDH)", RFC 3572, July 2003. 254 [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of 255 IPv6, IPv4, and Address Resolution Protocol (ARP) Packets 256 over Fibre Channel", RFC 4338, January 2006. 258 [RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over 259 InfiniBand (IPoIB)", RFC 4391, April 2006. 261 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 262 "Transmission of IPv6 Packets over IEEE 802.15.4 263 Networks", RFC 4944, September 2007. 265 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 266 Madanapalli, "Transmission of IPv6 via the IPv6 267 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 268 February 2008. 270 [RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over 271 PPP", RFC 5072, September 2007. 273 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 274 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 275 September 2011. 277 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 278 "Neighbor Discovery Optimization for IPv6 over Low-Power 279 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 280 November 2012. 282 8.2. Informative References 284 [I-D.ietf-6man-ipv6-address-generation-privacy] 285 Cooper, A., Gont, F., and D. Thaler, "Privacy 286 Considerations for IPv6 Address Generation Mechanisms", 287 draft-ietf-6man-ipv6-address-generation-privacy-03 (work 288 in progress), January 2015. 290 [Microsoft] 291 Davies, J., "Understanding IPv6, 3rd. ed", page 83, 292 Microsoft Press, 2012, . 294 Authors' Addresses 296 Fernando Gont 297 SI6 Networks / UTN-FRH 298 Evaristo Carriego 2644 299 Haedo, Provincia de Buenos Aires 1706 300 Argentina 302 Phone: +54 11 4650 8472 303 Email: fgont@si6networks.com 304 URI: http://www.si6networks.com 306 Alissa Cooper 307 Cisco 308 707 Tasman Drive 309 Milpitas, CA 95035 310 US 312 Phone: +1-408-902-3950 313 Email: alcoop@cisco.com 314 URI: https://www.cisco.com/ 316 Dave Thaler 317 Microsoft 318 Microsoft Corporation 319 One Microsoft Way 320 Redmond, WA 98052 322 Phone: +1 425 703 8835 323 Email: dthaler@microsoft.com 324 Will Liu 325 Huawei Technologies 326 Bantian, Longgang District 327 Shenzhen 518129 328 P.R. China 330 Email: liushucheng@huawei.com