idnits 2.17.00 (12 Aug 2021) /tmp/idnits1559/draft-ietf-6man-ug-01.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4291, updated by this document, for RFC5378 checks: 2003-10-10) -- 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 25, 2013) is 3282 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 5342 (Obsoleted by RFC 7042) == Outdated reference: draft-ietf-6man-dad-proxy has been published as RFC 6957 == Outdated reference: draft-ietf-6man-stable-privacy-addresses has been published as RFC 7217 == Outdated reference: draft-ietf-softwire-4rd has been published as RFC 7600 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN B. E. Carpenter 3 Internet-Draft Univ. of Auckland 4 Updates: 4291 (if approved) S. Jiang 5 Intended status: Standards Track Huawei Technologies Co., Ltd 6 Expires: November 26, 2013 May 25, 2013 8 Significance of IPv6 Interface Identifiers 9 draft-ietf-6man-ug-01 11 Abstract 13 The IPv6 addressing architecture includes a unicast interface 14 identifier that is used in the creation of many IPv6 addresses. 15 Interface identifiers are formed by a variety of methods. This 16 document clarifies that the bits in an interface identifier have no 17 generic meaning and that the identifier should be treated as an 18 opaque value. In particular, RFC 4291 defines a method by which the 19 Universal and Group bits of an IEEE link-layer address are mapped 20 into an IPv6 unicast interface identifier. This document clarifies 21 that those bits apply only to interface identifiers that are derived 22 from an IEEE link-layer address. It updates RFC 4291 accordingly. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 26, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Usefulness of the U and G Bits . . . . . . . . . . . . . . . 5 62 4. The Role of Duplicate Address Detection . . . . . . . . . . . 6 63 5. Clarification of Specifications . . . . . . . . . . . . . . . 6 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 10.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 IPv6 unicast addresses consist of a subnet prefix followed by an 76 Interface Identifier (IID), the latter supposedly unique on the links 77 reached by routing to that prefix. According to the IPv6 addressing 78 architecture [RFC4291], when a 64-bit IPv6 unicast IID is formed on 79 the basis of an IEEE EUI-64 address, usually itself expanded from a 80 48-bit MAC address, a particular format must be used: 82 "For all unicast addresses, except those that start with the binary 83 value 000, Interface IDs are required to be 64 bits long and to be 84 constructed in Modified EUI-64 format." 86 Thus the specification assumes that that the normal case is to 87 transform an Ethernet-style address into an IID, but in practice, 88 there are various methods of forming such an interface identifier. 90 The Modified EUI-64 format preserves the information provided by two 91 particular bits in the MAC address: 93 o The "u" bit in an IEEE address is set to 0 to indicate universal 94 scope (implying uniqueness) or to 1 to indicate local scope 95 (without implying uniqueness). In an IID this bit is inverted, 96 i.e., 1 for universal scope and 0 for local scope. According to 97 RFC 4291 and [RFC5342], the reason for this was to make it easier 98 for network operators to manually configure local-scope IIDs. 100 In an IID, this bit is in position 6, i.e., position 70 in the 101 complete IPv6 address. 103 o The "g" bit in an IEEE address is set to 1 to indicate group 104 addressing (link-layer multicast). The value of this bit is 105 preserved in an IID. 107 In an IID, this bit is in position 7, i.e., position 71 in the 108 complete IPv6 address. 110 This document discusses problems observed with the "u" and "g" bits 111 as a result of the above requirements and the fact that various other 112 methods of forming an IID have been defined, quite independently of 113 the method described in Appendix A of RFC 4291. It then discusses 114 the usefulness of these two bits and the significance of the bits in 115 an IID in general. Finally it updates RFC 4291 accordingly. 117 1.1. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. Problem statement 125 In addition to IIDs formed from IEEE EUI-64 addresses, various new 126 forms of IID have been defined or proposed, such as temporary 127 addresses [RFC4941], Cryptographically Generated Addresses (CGAs) 128 [RFC3972], Hash-Based Addresses (HBAs) [RFC5535], stable privacy 129 addresses [I-D.ietf-6man-stable-privacy-addresses], or mapped 130 addresses for 4rd [I-D.ietf-softwire-4rd]. In each case, the 131 question of how to set the "u" and "g" bits has to be decided. For 132 example, RFC 3972 specifies that they are both zero in CGAs, and the 133 same applies to HBAs. On the other hand, RFC 4941 specifies that "u" 134 must be zero but leaves "g" variable. The NAT64 addressing format 135 [RFC6052] sets the whole byte containing "u" and "g" to zero. 137 Another case where the "u" and "g" bits are specified is in the 138 Reserved IPv6 Subnet Anycast Address format [RFC2526], which states 139 that "for interface identifiers in EUI-64 format, the universal/local 140 bit in the interface identifier MUST be set to 0" (i.e., local) and 141 requires that "g" bit to be set to 1. However, the text neither 142 states nor implies any semantics for these bits in anycast addresses. 144 A common operational practice for well-known servers is to manually 145 assign a small number as the IID, in which case "u" and "g" are both 146 zero. 148 These cases illustrate that the statement quoted above from RFC 4291 149 requiring "Modified EUI-64 format" is rather meaningless when applied 150 to forms of IID that are not in fact based on an underlying EUI-64 151 address. In practice, the IETF has chosen to assign some 64-bit IIDs 152 that have nothing to do with EUI-64. 154 A particular case is that of /127 prefixes for point-to-point links 155 between routers, as standardised by [RFC6164]. The addresses on 156 these links are undoubtedly global unicast addresses, but they do not 157 have a 64-bit IID. The bits in the positions named "u" and "g" in 158 such an IID have no special significance and their values are not 159 specified. 161 Each time a new IID format is proposed, the question arises whether 162 these bits have any meaning. Section 2.2.1 of RFC 5342 discusses the 163 mechanics of the bit allocations but does not explain the purpose or 164 usefulness of these bits in an IID. There is an IANA registry for 165 reserved IID values [RFC5453] but again there is no explanation of 166 the purpose of the "u" and "g" bits. 168 There was a presumption when IPv6 was designed and the IID format was 169 first specified that a universally unique IID might prove to be very 170 useful, for example to contribute to solving the multihoming problem. 171 Indeed, the addressing architecture [RFC4291] states this explicitly: 173 "The use of the universal/local bit in the Modified EUI-64 format 174 identifier is to allow development of future technology that can take 175 advantage of interface identifiers with universal scope." 177 However, this has not so far proved to be the case. Also, there is 178 evidence from the field that IEEE MAC addresses with "u" = 0 are 179 sometime incorrectly assigned to multiple MAC interfaces. Firstly, 180 there are recurrent reports of manufacturers assigning the same MAC 181 address to multiple devices. Secondly, significant re-use of the 182 same virtual MAC address is reported in virtual machine environments. 183 Once transformed into IID format (with "u" = 1) these identifiers 184 would purport to be universally unique but would in fact be 185 ambiguous. This has no known harmful effect as long as the 186 replicated MAC addresses and IIDs are used on different layer 2 187 links. If they are used on the same link, of course there will be a 188 problem, to be detected by duplicate address detection [RFC4862], but 189 such a problem can usually only be resolved by human intervention. 191 The conclusion from this is that the "u" bit is not a reliable 192 indicator of universal uniqueness. 194 We note that Identifier-Locator Network Protocol (ILNP), a 195 multihoming solution that might be expected to benefit from 196 universally unique IIDs in modified EUI-64 format, does not in fact 197 rely on them. ILNP uses its own format, defined as a Node Identifier 198 [RFC6741]. ILNP has the constraint that a given Node Identifier must 199 be unique within the context of a given Locator (i.e. within a 200 single given IPv6 subnetwork). As we have just shown, the state of 201 the "u" bit does not in any way guarantee such uniqueness, but 202 duplicate address detection is available. 204 Thus, we can conclude that the value of the "u" bit in IIDs has no 205 particular meaning. In the case of an IID created from a MAC address 206 according to RFC 4291, its value is determined by the MAC address, 207 but that is all. 209 An IPv6 IID should not be created from a MAC group address, so the 210 "g" bit will normally be zero, but this value also has no particular 211 meaning. Additionally, the "u" and the "g" bits are both meaningless 212 in the format of an IPv6 multicast group ID [RFC3306], [RFC3307]. 214 None of the above implies that there is a problem with using the "u" 215 and "g" bits in MAC addresses as part of the process of generating 216 IIDs from MAC addresses, or with specifying their values in other 217 methods of generating IIDs. What it does imply is that, after an IID 218 is generated by any method, no reliable deductions can be made from 219 the state of the "u" and "g" bits; in other words, these bits have no 220 useful semantics in an IID. 222 Once this is recognised, we can avoid the problematic confusion 223 caused by these bits each time that a new form of IID is proposed. 225 3. Usefulness of the U and G Bits 227 Given that the "u" and "g" bits do not have a reliable meaning in an 228 IID, it is relevant to consider what usefulness they do have. 230 If an IID is known or guessed to have been created according to RFC 231 4291, it could be transformed back into a MAC address. This can be 232 very helpful during operational fault diagnosis. For that reason, 233 mapping the IEEE "u" and "g" bits into the IID has operational 234 usefulness. However, it should be stressed that "u" = "g" = 0 does 235 not prove that an IID was formed from a MAC address; on the contrary, 236 it might equally result from another method. With other methods, 237 there is no reverse transformation available. 239 To the extent that each method of IID creation specifies the values 240 of the "u" and "g" bits, and that each new method is carefully 241 designed in the light of its predecessors, these bits tend to reduce 242 the chances of duplicate IIDs. 244 4. The Role of Duplicate Address Detection 246 As mentioned above, Duplicate Address Detection (DAD) [RFC4862] is 247 able to detect any case where a collision of two IIDs on the same 248 link leads to a duplicated IPv6 address. The scope of DAD may be 249 extended to a set of links by a DAD proxy [I-D.ietf-6man-dad-proxy]. 250 Since DAD is mandatory for all nodes, there will be no case in which 251 an IID collision, however unlikely it may be, is not detected. It is 252 out of scope of most existing specifications to define the recovery 253 action after a DAD failure, which is an implementation issue. The 254 best procedure to follow will depend on the IID formation method in 255 use. For example, if an IID is formed by some pseudo-random process, 256 that process could simply be repeated. If a manually created IID, or 257 an IID derived from a MAC address according to RFC 4291, leads to a 258 DAD failure, human intervention will most likely be required. 260 There is one case in RFC 4862 that requires additional consideration: 262 "On the other hand, if the duplicate link-local address is not formed 263 from an interface identifier based on the hardware address, which is 264 supposed to be uniquely assigned, IP operation on the interface MAY 265 be continued." 267 However, as mentioned above, some methods of IID formation might 268 produce IID values with "u" = "g" = 0 that are not based on a MAC 269 (hardware) address. With very low probability, such a value might 270 collide with an IID based on a MAC address. There is no algorithm 271 for determining whether this case has arisen, rather than a genuine 272 MAC address collision. Implementers should carefully consider the 273 consequences of continuing IPv6 operation on the interface in this 274 unlikely situation. 276 5. Clarification of Specifications 278 This section describes clarifications to the IPv6 specifications that 279 result from the above discussion. Their aim is to reduce confusion 280 while retaining the useful aspects of the "u" and "g" bits in IIDs. 282 The EUI-64 to IID transformation defined in the IPv6 addressing 283 architecture [RFC4291] MUST be used for all cases where an IPv6 IID 284 is derived from an IEEE MAC or EUI-64 address. With any other form 285 of link layer address, an equivalent transformation SHOULD be used. 287 Specifications of other forms of 64-bit IID MUST specify how all 64 288 bits are set, but need not treat the "u" and "g" bits in any special 289 way. A general semantic meaning for these bits MUST NOT be defined. 290 However, the method of generating IIDs for specific link types MAY 291 define some local significance for certain bits. 293 In all cases, the bits in an IID have no general semantics; in other 294 words, they have opaque values. In fact, the whole IID value MUST be 295 viewed as an opaque bit string by third parties, except possibly in 296 the local context. 298 The following statement in section 2.5.1 of the IPv6 addressing 299 architecture [RFC4291]: 301 "For all unicast addresses, except those that start with the binary 302 value 000, Interface IDs are required to be 64 bits long and to be 303 constructed in Modified EUI-64 format." 305 is replaced by: 307 "For all unicast addresses, except those that start with the binary 308 value 000, Interface IDs are required to be 64 bits long. If derived 309 from an IEEE MAC-layer address, they must be constructed in Modified 310 EUI-64 format." 312 The following statement in section 2.5.1 of the IPv6 addressing 313 architecture [RFC4291] is obsoleted: 315 "The use of the universal/local bit in the Modified EUI-64 format 316 identifier is to allow development of future technology that can take 317 advantage of interface identifiers with universal scope." 319 As far as is known, no existing implementation will be affected by 320 these changes. The benefit is that future design discussions are 321 simplified. 323 6. Security Considerations 325 No new security exposures or issues are raised by this document. 327 7. IANA Considerations 329 This document requests no immediate action by IANA. However, the 330 following should be noted when considering future proposed additions 331 to the registry of reserved IID values, which requires Standards 332 Action according to [RFC5453]. 334 Full deployment of a new reserved IID value would require updates to 335 IID generation code in every deployed IPv6 stack, so the technical 336 justification for such a Standards Action would need to be extremely 337 strong. 339 OPEN ISSUE: Alternatively, we could decide to close the reserved IID 340 registry completely (which would also mean formally updating RFC 341 5453). If we choose this approach, the following point can be 342 deleted. Comments welcome. 344 A reserved IID, or a range of reserved IIDs, will most likely specify 345 values for both "u" and "g", since they are among the high-order 346 bits. At the present time, none of the known methods of generating 347 IIDs will generate "u" = "g" = 1. Reserved IIDs with "u" = "g" = 1 348 are therefore unlikely to collide with automatically generated IIDs. 350 8. Acknowledgements 352 Valuable comments were received from Ran Atkinson, Remi Despres, 353 Fernando Gont, Brian Haberman, Joel Halpern, Bob Hinden, Christian 354 Huitema, Ray Hunter, Mark Smith, and other participants in the 6MAN 355 working group. 357 Brian Carpenter was a visitor at the Computer Laboratory, Cambridge 358 University during part of this work. 360 This document was produced using the xml2rfc tool [RFC2629]. 362 9. Change log [RFC Editor: Please remove] 364 draft-ietf-6man-ug-01: emphasised "opaque" nature of IID, added text 365 about DAD failures, expanded IANA considerations, 2013-05-25. 367 draft-ietf-6man-ug-00: first WG version, text clarified, added 368 possibility of link-local significance, 2013-03-28. 370 draft-carpenter-6man-ug-01: numerous clarifications following WG 371 comments, discussed DAD, added new section on the usefulness of the u 372 /g bits, expanded IANA considerations, set intended status, 373 2013-02-21. 375 draft-carpenter-6man-ug-00: original version, 2013-01-31. 377 10. References 379 10.1. Normative References 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, March 1997. 384 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 385 Architecture", RFC 4291, February 2006. 387 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 388 Address Autoconfiguration", RFC 4862, September 2007. 390 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 391 for IEEE 802 Parameters", BCP 141, RFC 5342, September 392 2008. 394 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 395 5453, February 2009. 397 10.2. Informative References 399 [I-D.ietf-6man-dad-proxy] 400 Costa, F., Combes, J., Pougnard, X., and L. Hongyu, 401 "Duplicate Address Detection Proxy", draft-ietf-6man-dad- 402 proxy-07 (work in progress), April 2013. 404 [I-D.ietf-6man-stable-privacy-addresses] 405 Gont, F., "A method for Generating Stable Privacy-Enhanced 406 Addresses with IPv6 Stateless Address Autoconfiguration 407 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-07 408 (work in progress), May 2013. 410 [I-D.ietf-softwire-4rd] 411 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 412 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 413 Solution (4rd)", draft-ietf-softwire-4rd-05 (work in 414 progress), April 2013. 416 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 417 Addresses", RFC 2526, March 1999. 419 [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, 420 June 1999. 422 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 423 Multicast Addresses", RFC 3306, August 2002. 425 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 426 Addresses", RFC 3307, August 2002. 428 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 429 RFC 3972, March 2005. 431 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 432 Extensions for Stateless Address Autoconfiguration in 433 IPv6", RFC 4941, September 2007. 435 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 436 2009. 438 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 439 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 440 October 2010. 442 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 443 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 444 Router Links", RFC 6164, April 2011. 446 [RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol 447 (ILNP) Engineering Considerations", RFC 6741, November 448 2012. 450 Authors' Addresses 452 Brian Carpenter 453 Department of Computer Science 454 University of Auckland 455 PB 92019 456 Auckland 1142 457 New Zealand 459 Email: brian.e.carpenter@gmail.com 461 Sheng Jiang 462 Huawei Technologies Co., Ltd 463 Q14, Huawei Campus 464 No.156 Beiqing Road 465 Hai-Dian District, Beijing 100095 466 P.R. China 468 Email: jiangsheng@huawei.com