idnits 2.17.1 draft-ietf-6man-ug-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 : ---------------------------------------------------------------------------- ** 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 (August 26, 2013) is 3895 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: A later version (-17) exists of draft-ietf-6man-stable-privacy-addresses-12 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-06 -- 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 (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN B. 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: February 27, 2014 August 26, 2013 8 Significance of IPv6 Interface Identifiers 9 draft-ietf-6man-ug-03 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 two bits are significant only in interface identifiers 22 that are derived from an IEEE link-layer address, and updates RFC 23 4291 accordingly. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 27, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Usefulness of the U and G Bits . . . . . . . . . . . . . . . 6 63 4. The Role of Duplicate Address Detection . . . . . . . . . . . 6 64 5. Clarification of Specifications . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 10.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 IPv6 unicast addresses consist of a prefix followed by an Interface 77 Identifier (IID). The IID is supposed to be unique on the links 78 reached by routing to that prefix, giving a globally unique address. 79 According to the IPv6 addressing architecture [RFC4291], when a 80 64-bit IPv6 unicast IID is formed on the basis of an IEEE EUI-64 81 address, usually itself expanded from a 48-bit MAC address, a 82 particular format must be used: 84 "For all unicast addresses, except those that start with the binary 85 value 000, Interface IDs are required to be 64 bits long and to be 86 constructed in Modified EUI-64 format." 88 Thus the specification assumes that the normal case is to transform 89 an Ethernet-style address into an IID, but in practice, there are 90 various methods of forming such an interface identifier. 92 The Modified EUI-64 format preserves the information provided by two 93 particular bits in the MAC address: 95 o The "u/l" bit in a MAC address [IEEE802] is set to 0 to indicate 96 universal scope (implying uniqueness) or to 1 to indicate local 97 scope (without implying uniqueness). In an IID formed from a MAC 98 address, this bit is simply known as the "u" bit and its value is 99 inverted, i.e., 1 for universal scope and 0 for local scope. 100 According to RFC 4291 and [RFC5342], the reason for this was to 101 make it easier for network operators to manually configure local- 102 scope IIDs. 104 In an IID, this bit is in position 6, i.e., position 70 in the 105 complete IPv6 address. 107 o The "i/g" bit in a MAC address is set to 1 to indicate group 108 addressing (link-layer multicast). The value of this bit is 109 preserved in an IID, where it is known as the "g" bit. 111 In an IID, this bit is in position 7, i.e., position 71 in the 112 complete IPv6 address. 114 This document discusses problems observed with the "u" and "g" bits 115 as a result of the above requirements and the fact that various other 116 methods of forming an IID have been defined, quite independently of 117 the method described in Appendix A of RFC 4291. It then discusses 118 the usefulness of these two bits and the significance of the bits in 119 an IID in general. Finally, it updates RFC 4291 accordingly. 121 1.1. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 2. Problem statement 129 In addition to IIDs formed from IEEE EUI-64 addresses, various new 130 forms of IID have been defined, including temporary addresses 131 [RFC4941], Cryptographically Generated Addresses (CGAs) [RFC3972], 132 Hash-Based Addresses (HBAs) [RFC5535], and ISATAP addresses 133 [RFC5214]. Other methods have been proposed, such as stable privacy 134 addresses [I-D.ietf-6man-stable-privacy-addresses], and mapped 135 addresses for 4rd [I-D.ietf-softwire-4rd]. In each case, the 136 question of how to set the "u" and "g" bits has to be decided. For 137 example, RFC 3972 specifies that they are both zero in CGAs, and the 138 same applies to HBAs. On the other hand, RFC 4941 specifies that "u" 139 must be zero but leaves "g" variable. The NAT64 addressing format 140 [RFC6052] sets the whole byte containing "u" and "g" to zero. 142 Another case where the "u" and "g" bits are specified is in the 143 Reserved IPv6 Subnet Anycast Address format [RFC2526], which states 144 that "for interface identifiers in EUI-64 format, the universal/local 145 bit in the interface identifier MUST be set to 0" (i.e., local) and 146 requires that "g" bit to be set to 1. However, the text neither 147 states nor implies any semantics for these bits in anycast addresses. 149 A common operational practice for well-known servers is to manually 150 assign a small number as the IID, in which case "u" and "g" are both 151 zero. 153 These cases illustrate that the statement quoted above from RFC 4291 154 requiring "Modified EUI-64 format" is inapplicable when applied to 155 forms of IID that are not in fact based on an underlying EUI-64 156 address. In practice, the IETF has chosen to assign some 64-bit IIDs 157 that have nothing to do with EUI-64. 159 A particular case is that of /127 prefixes for point-to-point links 160 between routers, as standardised by [RFC6164]. The addresses on 161 these links are undoubtedly global unicast addresses, but they do not 162 have a 64-bit IID. The bits in the positions named "u" and "g" in 163 such an IID have no special significance and their values are not 164 specified. 166 Each time a new IID format is proposed, the question arises whether 167 these bits have any meaning. Section 2.2.1 of RFC 5342 discusses the 168 mechanics of the bit allocations but does not explain the purpose or 169 usefulness of these bits in an IID. There is an IANA registry for 170 reserved IID values [RFC5453] but again there is no explanation of 171 the purpose of the "u" and "g" bits. 173 There was a presumption when IPv6 was designed and the IID format was 174 first specified that a universally unique IID might prove to be very 175 useful, for example to contribute to solving the multihoming problem. 176 Indeed, the addressing architecture [RFC4291] states this explicitly: 178 "The use of the universal/local bit in the Modified EUI-64 format 179 identifier is to allow development of future technology that can take 180 advantage of interface identifiers with universal scope." 182 However, this has not so far proved to be the case. Also, there is 183 evidence from the field that despite the IEEE standard [IEEE802], MAC 184 addresses with universal scope are sometime incorrectly assigned to 185 multiple MAC interfaces. Firstly, there are recurrent reports of 186 manufacturers assigning the same MAC address to multiple devices. 187 Secondly, significant re-use of the same virtual MAC address is 188 reported in virtual machine environments. Once transformed into IID 189 format (with "u" = 1) these identifiers would purport to be 190 universally unique but would in fact be ambiguous. This has no known 191 harmful effect as long as the replicated MAC addresses and IIDs are 192 used on different layer 2 links. If they are used on the same link, 193 of course there will be a problem, very likely interfering with link- 194 layer transmission. If not, the problem will be detected by 195 duplicate address detection [RFC4862] [RFC6775], but such an error 196 can usually only be resolved by human intervention. 198 The conclusion from this is that the "u" bit is not a reliable 199 indicator of universal uniqueness. 201 We note that Identifier-Locator Network Protocol (ILNP), a 202 multihoming solution that might be expected to benefit from 203 universally unique IIDs in modified EUI-64 format, does not in fact 204 rely on them. ILNP uses its own format, defined as a Node Identifier 205 [RFC6741]. ILNP has the constraint that a given Node Identifier must 206 be unique within the context of a given Locator (i.e. within a single 207 given IPv6 subnetwork). As we have just shown, the state of the "u" 208 bit does not in any way guarantee such uniqueness, but duplicate 209 address detection is available. 211 Thus, we can conclude that the value of the "u" bit in IIDs has no 212 particular meaning. In the case of an IID created from a MAC address 213 according to RFC 4291, its value is determined by the MAC address, 214 but that is all. 216 An IPv6 IID should not be created from a MAC group address, so the 217 "g" bit will normally be zero, but this value also has no particular 218 meaning. Additionally, the "u" and the "g" bits are both meaningless 219 in the format of an IPv6 multicast group ID [RFC3306] [RFC3307]. 221 None of the above implies that there is a problem with using the "u" 222 and "g" bits in MAC addresses as part of the process of generating 223 IIDs from MAC addresses, or with specifying their values in other 224 methods of generating IIDs. What it does imply is that, after an IID 225 is generated by any method, no reliable deductions can be made from 226 the state of the "u" and "g" bits; in other words, these bits have no 227 useful semantics in an IID. 229 Once this is recognised, we can avoid the problematic confusion 230 caused by these bits each time that a new form of IID is proposed. 232 3. Usefulness of the U and G Bits 234 Given that the "u" and "g" bits do not have a reliable meaning in an 235 IID, it is relevant to consider what usefulness they do have. 237 If an IID is known or guessed to have been created according to RFC 238 4291, it could be transformed back into a MAC address. This can be 239 very helpful during operational fault diagnosis. For that reason, 240 mapping the IEEE "u" and "g" bits into the IID has operational 241 usefulness. However, it should be stressed that an IID with "u" = 1 242 and "g" = 0 might not be formed from a MAC address; on the contrary, 243 it might equally result from another method. With other methods, 244 there is no reverse transformation available. 246 Given that the values of the "u" and "g" bits in an IID have no 247 particular meaning, new methods of IID formation are at liberty to 248 use them as they wish, for example as additional pseudo-random bits 249 to reduce the chances of duplicate IIDs. 251 4. The Role of Duplicate Address Detection 253 As mentioned above, Duplicate Address Detection (DAD) [RFC4862] is 254 able to detect any case where a collision of two IIDs on the same 255 link leads to a duplicated IPv6 address. The scope of DAD may be 256 extended to a set of links by a DAD proxy [RFC6957] or by Neighbor 257 Discovery Optimization [RFC6775]. Since DAD is mandatory for all 258 nodes, there will be almost no case in which an IID collision, 259 however unlikely it may be, is not detected. It is out of scope of 260 most existing specifications to define the recovery action after a 261 DAD failure, which is an implementation issue. If a manually created 262 IID, or an IID derived from a MAC address according to RFC 4291, 263 leads to a DAD failure, human intervention will most likely be 264 required. However, as mentioned above, some methods of IID formation 265 might produce IID values with "u" = 1 and "g" = 0 that are not based 266 on a MAC address. With very low probability, such a value might 267 collide with an IID based on a MAC address. 269 As stated in RFC 4862: 271 "On the other hand, if the duplicate link-local address is not formed 272 from an interface identifier based on the hardware address, which is 273 supposed to be uniquely assigned, IP operation on the interface MAY 274 be continued." 276 Continued operation is only possible if a new IID is created. The 277 best procedure to follow for this will depend on the IID formation 278 method in use. For example, if an IID is formed by a pseudo-random 279 process, that process could simply be repeated. 281 5. Clarification of Specifications 283 This section describes clarifications to the IPv6 specifications that 284 result from the above discussion. Their aim is to reduce confusion 285 while retaining the useful aspects of the "u" and "g" bits in IIDs. 287 The EUI-64 to IID transformation defined in the IPv6 addressing 288 architecture [RFC4291] MUST be used for all cases where an IPv6 IID 289 is derived from an IEEE MAC or EUI-64 address. With any other form 290 of link layer address, an equivalent transformation SHOULD be used. 292 Specifications of other forms of 64-bit IID MUST specify how all 64 293 bits are set, but need not treat the "u" and "g" bits in any special 294 way. A generic semantic meaning for these bits MUST NOT be defined. 295 However, the method of generating IIDs for specific link types MAY 296 define some local significance for certain bits. 298 In all cases, the bits in an IID have no generic semantics; in other 299 words, they have opaque values. In fact, the whole IID value MUST be 300 viewed as an opaque bit string by third parties, except possibly in 301 the local context. 303 The following statement in section 2.5.1 of the IPv6 addressing 304 architecture [RFC4291]: 306 "For all unicast addresses, except those that start with the binary 307 value 000, Interface IDs are required to be 64 bits long and to be 308 constructed in Modified EUI-64 format." 310 is replaced by: 312 "For all unicast addresses, except those that start with the binary 313 value 000, Interface IDs are required to be 64 bits long. If derived 314 from an IEEE MAC-layer address, they must be constructed in Modified 315 EUI-64 format." 317 The following statement in section 2.5.1 of the IPv6 addressing 318 architecture [RFC4291] is obsoleted: 320 "The use of the universal/local bit in the Modified EUI-64 format 321 identifier is to allow development of future technology that can take 322 advantage of interface identifiers with universal scope." 324 As far as is known, no existing implementation will be affected by 325 these changes. The benefit is that future design discussions are 326 simplified. 328 6. Security Considerations 330 No new security exposures or issues are raised by this document. 332 In some contexts, unpredictable IID values are considered beneficial 333 to enhance privacy and defeat scanning attacks. The recognition that 334 the IID value should be regarded as an opaque bit string is 335 consistent with methods of IID formation that result in 336 unpredictable, pseudo-random values. 338 7. IANA Considerations 340 This document requests no immediate action by IANA. However, the 341 following should be noted when considering any future proposed 342 addition to the registry of reserved IID values, which requires 343 Standards Action according to [RFC5453]. 345 Full deployment of a new reserved IID value would require updates to 346 IID generation code in every deployed IPv6 stack, so the technical 347 justification for such a Standards Action would need to be extremely 348 strong. 350 A reserved IID, or a range of reserved IIDs, will most likely specify 351 values for both "u" and "g", since they are among the high-order 352 bits. At the present time, none of the standard methods of 353 generating IIDs will generate "u" = "g" = 1. Reserved IIDs with "u" 354 = "g" = 1 are therefore unlikely to collide with automatically 355 generated IIDs. 357 8. Acknowledgements 359 Valuable comments were received from Ran Atkinson, Remi Despres, 360 Ralph Droms, Fernando Gont, Brian Haberman, Joel Halpern, Bob Hinden, 361 Christian Huitema, Ray Hunter, Tatuya Jinmei, Mark Smith, Bernie Volz 362 and other participants in the 6MAN working group. 364 Brian Carpenter was a visitor at the Computer Laboratory, Cambridge 365 University during part of this work. 367 This document was produced using the xml2rfc tool [RFC2629]. 369 9. Change log [RFC Editor: Please remove] 371 draft-ietf-6man-ug-03: some clarifications, text on unpredictable 372 IIDs, minor corrections, 2013-08-26. 374 draft-ietf-6man-ug-02: incorporated WG Last Call comments: removed 375 open issue, clarified IEEE bit names, clarified DAD text, updated 376 references, minor editorial corrections, 2013-08-06. 378 draft-ietf-6man-ug-01: emphasised "opaque" nature of IID, added text 379 about DAD failures, expanded IANA considerations, 2013-05-25. 381 draft-ietf-6man-ug-00: first WG version, text clarified, added 382 possibility of link-local significance, 2013-03-28. 384 draft-carpenter-6man-ug-01: numerous clarifications following WG 385 comments, discussed DAD, added new section on the usefulness of the u 386 /g bits, expanded IANA considerations, set intended status, 387 2013-02-21. 389 draft-carpenter-6man-ug-00: original version, 2013-01-31. 391 10. References 393 10.1. Normative References 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 399 Architecture", RFC 4291, February 2006. 401 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 402 Address Autoconfiguration", RFC 4862, September 2007. 404 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 405 for IEEE 802 Parameters", BCP 141, RFC 5342, September 406 2008. 408 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 409 5453, February 2009. 411 10.2. Informative References 413 [I-D.ietf-6man-stable-privacy-addresses] 414 Gont, F., "A Method for Generating Semantically Opaque 415 Interface Identifiers with IPv6 Stateless Address 416 Autoconfiguration (SLAAC)", draft-ietf-6man-stable- 417 privacy-addresses-12 (work in progress), August 2013. 419 [I-D.ietf-softwire-4rd] 420 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 421 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 422 Solution (4rd)", draft-ietf-softwire-4rd-06 (work in 423 progress), July 2013. 425 [IEEE802] , "IEEE Standard for Local and Metropolitan Area Networks: 426 Overview and Architecture", IEEE Std 802-2001 (R2007) , 427 2007. 429 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 430 Addresses", RFC 2526, March 1999. 432 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 433 June 1999. 435 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 436 Multicast Addresses", RFC 3306, August 2002. 438 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 439 Addresses", RFC 3307, August 2002. 441 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 442 RFC 3972, March 2005. 444 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 445 Extensions for Stateless Address Autoconfiguration in 446 IPv6", RFC 4941, September 2007. 448 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 449 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 450 March 2008. 452 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 453 2009. 455 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 456 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 457 October 2010. 459 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 460 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 461 Router Links", RFC 6164, April 2011. 463 [RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol 464 (ILNP) Engineering Considerations", RFC 6741, November 465 2012. 467 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 468 "Neighbor Discovery Optimization for IPv6 over Low-Power 469 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 470 November 2012. 472 [RFC6957] Costa, F., Combes, J-M., Pougnard, X., and H. Li, 473 "Duplicate Address Detection Proxy", RFC 6957, June 2013. 475 Authors' Addresses 477 Brian Carpenter 478 Department of Computer Science 479 University of Auckland 480 PB 92019 481 Auckland 1142 482 New Zealand 484 Email: brian.e.carpenter@gmail.com 486 Sheng Jiang 487 Huawei Technologies Co., Ltd 488 Q14, Huawei Campus 489 No.156 Beiqing Road 490 Hai-Dian District, Beijing 100095 491 P.R. China 493 Email: jiangsheng@huawei.com