idnits 2.17.1 draft-gont-6man-non-stable-iids-00.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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document updates RFC4941, 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 -- The document date (May 23, 2016) is 2895 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: 'TBD' is mentioned on line 203, but not defined == Unused Reference: 'RFC2460' is defined on line 221, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 225, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-6man-default-iids-11 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-03) exists of draft-gont-predictable-numeric-ids-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 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: RFC4941 (if approved) W. Liu 5 Intended status: Standards Track Huawei Technologies 6 Expires: November 24, 2016 May 23, 2016 8 Recommendation on Non-Stable IPv6 Interface Identifiers 9 draft-gont-6man-non-stable-iids-00 11 Abstract 13 This document clarifies the stability requirements for IP6 addresses, 14 and provides recommendations regarding the generation of non-stable 15 addresses. Finally, it formally updates RFC4941 such that nodes are 16 allowed to configure only temporary addresses. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 24, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Stability Requirements for IPv6 Addresses . . . . . . . . . . 3 55 4. Requirements for Non-Stable IPv6 Addresses . . . . . . . . . 3 56 5. Generation of Non-Stable IPv6 Addresses . . . . . . . . . . . 4 57 6. Update to existing RFCs . . . . . . . . . . . . . . . . . . . 4 58 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 IPv6 StateLess Address AutoConfiguration (SLAAC) [RFC4862] has 68 traditionally resulted in stable addresses, since the Interface 69 Identifier (IID) has been generated by embedding a stable layer-2 70 numeric identifier (e.g., a MAC address). [RFC4941] implies, 71 throughout the specification, that temporary addresses are generated 72 and employed along with temporary addresses. 74 While the use of stable addresses (only) or mixed stable and 75 temporary addresses can be desirable in a number of scenarios, there 76 are other scenarios in which, for security and privacy reasons, a 77 node may want to use only non-stable address (e.g., a temporary 78 address). 80 This document clarifies the requirements for stability of IPv6 81 addresses, such that nodes are not required to configure stable 82 addresses. It also specifies a set of requirements for the 83 generation of non-stable addresses. Finally, it formally updates 84 [RFC4941] such that temporary addresses can be employed without the 85 need to configure a stable address along side. 87 2. Terminology 89 This document employs the terms defined in [RFC7721]. 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 3. Stability Requirements for IPv6 Addresses 97 Nodes are not required to generate addresses with any specific 98 stability properties. That is, the generation of stable addresses is 99 OPTIONAL. This means that a node may end up configuring only stable 100 addresses, only non-stable, or both stable and non-stable addresses. 102 4. Requirements for Non-Stable IPv6 Addresses 104 The requirements for non-stable IPv6 addresses are as follows: 106 1. The resulting Interface Identifiers MUST be different when 107 addresses are configured for different prefixes. That is, if 108 different autoconfiguration prefixes are used to configure 109 addresses for the same network interface card, the resulting 110 Interface Identifiers must be (statistically) different. This 111 means that, given two addresses, it must be difficult for an 112 outside entity to tell whether the addresses have been generated 113 by the same host. 115 2. The resulting interface identifiers MUST NOT embed layer-2 116 identifiers (e.g. MAC addresses). 118 3. It must be difficult for an outside entity to predict the 119 Interface Identifiers that will be generated by the algorithm, 120 even with knowledge of the Interface Identifiers generated for 121 configuring other addresses. 123 4. The resulting Interface Identifiers must be semantically opaque 124 and must not follow any specific patterns. 126 The IIDs of addresses configured for different autoconfiguration 127 prefixes must be different, such that traffic for those addresses 128 cannot be correlated. 130 The reuse of identifiers that have their own semantics or properties 131 across different contexts or scopes can be detrimental for security 132 and privacy [I-D.gont-predictable-numeric-ids] [RFC6973] [RFC4941]. 133 For example, if two different layer-3 protocols generate their 134 addresses by embedding a layer-2 identifier (e.g., a MAC address), 135 then the traffic for such protocols could be correlated (irrespective 136 of whether the aforementioned layer-2 identifier has been randomized 137 or not). Besides, a node that generates an IPv6 address by embedding 138 a link-layer address in the IPv6 address will, when configuring 139 addresses for different prefixes, result in the same IID being used 140 for such prefixes, thus allowing the corresponding traffic to be 141 correlated. 143 For security and privacy reasons, the IIDs generated for non-stable 144 addresses must not be predictable. Otherwise, the node may be 145 subject to many (if not all) of the security and privacy issues that 146 are meant to be mitigated (please see [RFC7721]. 148 Any semantics or patterns in an IID might be leveraged by an attacker 149 to e.g. reduce the search space when performing address-scanning 150 attacks, infer the identity of the node, etc. 152 5. Generation of Non-Stable IPv6 Addresses 154 One possible algorithm for generating non-stable IPv6 addresses is 155 that specified in [RFC4941]. 157 Another possible approach would be to select a random IID when 158 performing SLAAC. In this case, a node that disconnects from the 159 network and subsequently reconnects would employ a (statistically 160 different) IID for the same prefix. A different (random) IID should 161 be employed for each autoconfiguration prefix. These addresses, as 162 opposed to the temporary addresses specified in RFC4941, would be 163 stable for as long as the node stays attached (without disconnecting) 164 to the network, but would change when a node reconnects. 166 6. Update to existing RFCs 168 The following subsections clarify how each of the RFCs affected by 169 this document are updated. 171 6.1. Update to RFC4941 173 The temporary addresses specified in [RFC4941] MAY be used in 174 replacement of the stable addresses [I-D.ietf-6man-default-iids]. 175 That is, a node MAY configure temporary addresses only, without 176 configuring any stable addresses. 178 7. Future Work 180 This document clarifies the requirements for stability requirements 181 for IPv6 addresses. A subsequent document will discuss the tradeoffs 182 involved when considering different stability properties of IPv6 183 addresses, and and the different configuration setups such as: stable 184 addresses only, non-stable addresses only, or mixed stable and non- 185 stable addresses. 187 8. IANA Considerations 189 There are no IANA registries within this document. The RFC-Editor 190 can remove this section before publication of this document as an 191 RFC. 193 9. Security Considerations 195 This document clarifies the stability requirements for IPv6 196 addresses, and specifies requirements for the generation of non- 197 stable addresses. Additionally, it formally updates [RFC4941] such 198 that stable addresses are not required to be configured along with 199 the temporary addresses. 201 10. Acknowledgements 203 The authors would like to thank (in alphabetical order) [TBD] for 204 providing a detailed review of this document. 206 11. References 208 11.1. Normative References 210 [I-D.ietf-6man-default-iids] 211 Gont, F., Cooper, A., Thaler, D., and S. LIU, 212 "Recommendation on Stable IPv6 Interface Identifiers", 213 draft-ietf-6man-default-iids-11 (work in progress), April 214 2016. 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, 218 DOI 10.17487/RFC2119, March 1997, 219 . 221 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 222 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 223 December 1998, . 225 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 226 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 227 2006, . 229 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 230 Address Autoconfiguration", RFC 4862, 231 DOI 10.17487/RFC4862, September 2007, 232 . 234 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 235 Extensions for Stateless Address Autoconfiguration in 236 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 237 . 239 11.2. Informative References 241 [I-D.gont-predictable-numeric-ids] 242 Gont, F. and I. Arce, "Security and Privacy Implications 243 of Numeric Identifiers Employed in Network Protocols", 244 draft-gont-predictable-numeric-ids-00 (work in progress), 245 February 2016. 247 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 248 Morris, J., Hansen, M., and R. Smith, "Privacy 249 Considerations for Internet Protocols", RFC 6973, 250 DOI 10.17487/RFC6973, July 2013, 251 . 253 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 254 Considerations for IPv6 Address Generation Mechanisms", 255 RFC 7721, DOI 10.17487/RFC7721, March 2016, 256 . 258 Authors' Addresses 260 Fernando Gont 261 SI6 Networks / UTN-FRH 262 Evaristo Carriego 2644 263 Haedo, Provincia de Buenos Aires 1706 264 Argentina 266 Phone: +54 11 4650 8472 267 Email: fgont@si6networks.com 268 URI: http://www.si6networks.com 270 Will Liu 271 Huawei Technologies 272 Bantian, Longgang District 273 Shenzhen 518129 274 P.R. China 276 Email: liushucheng@huawei.com