idnits 2.17.1 draft-ietf-6man-ug-06.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 (December 2, 2013) is 3795 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 7042 (Obsoleted by RFC 9542) == Outdated reference: A later version (-17) exists of draft-ietf-6man-stable-privacy-addresses-14 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-07 -- 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: June 5, 2014 December 2, 2013 8 Significance of IPv6 Interface Identifiers 9 draft-ietf-6man-ug-06 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 meaning and that the entire identifier should be treated as an opaque 18 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 the process of deriving 22 interface identifiers from an IEEE link-layer address, and updates 23 RFC 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 June 5, 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 . . . . . . . . . . . . . . . 5 63 4. The Role of Duplicate Address Detection . . . . . . . . . . . 6 64 5. Clarification of Specifications . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8 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 an IPv6 address that is 79 unique within the applicable scope (link local or global). According 80 to the IPv6 addressing architecture [RFC4291], when a 64-bit IPv6 81 unicast IID is formed on the basis of an IEEE EUI-64 address, usually 82 itself expanded from a 48-bit MAC address, a particular format must 83 be used: 85 "For all unicast addresses, except those that start with the binary 86 value 000, Interface IDs are required to be 64 bits long and to be 87 constructed in Modified EUI-64 format." 89 Thus the specification assumes that the normal case is to transform 90 an Ethernet-style address into an IID, but in practice, there are 91 various methods of forming such an interface identifier. 93 The Modified EUI-64 format preserves the information provided by two 94 particular bits in the MAC address: 96 o The "u/l" bit in a MAC address [IEEE802] is set to 0 to indicate 97 universal scope (implying uniqueness) or to 1 to indicate local 98 scope (without implying uniqueness). In an IID formed from a MAC 99 address, this bit is simply known as the "u" bit and its value is 100 inverted, i.e., 1 for universal scope and 0 for local scope. 101 According to RFC 4291 and [RFC7042], the reason for this was to 102 make it easier for network operators to manually configure local- 103 scope IIDs. 105 In an IID, this bit is in position 6, i.e., position 70 in the 106 complete IPv6 address. 108 o The "i/g" bit in a MAC address is set to 1 to indicate group 109 addressing (link-layer multicast). The value of this bit is 110 preserved in an IID, where it is known as the "g" bit. 112 In an IID, this bit is in position 7, i.e., position 71 in the 113 complete IPv6 address. 115 This document discusses problems observed with the "u" and "g" bits 116 as a result of the above requirements and the fact that various other 117 methods of forming an IID have been defined, quite independently of 118 the method described in Appendix A of RFC 4291. It then discusses 119 the usefulness of these two bits and the significance of the bits in 120 an IID in general. Finally, it updates RFC 4291 accordingly. 122 1.1. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2. Problem statement 130 In addition to IIDs formed from IEEE EUI-64 addresses, various new 131 forms of IID have been defined, including temporary addresses 132 [RFC4941], Cryptographically Generated Addresses (CGAs) [RFC3972] 133 [RFC4982], Hash-Based Addresses (HBAs) [RFC5535], and ISATAP 134 addresses [RFC5214]. Other methods have been proposed, such as 135 stable privacy addresses [I-D.ietf-6man-stable-privacy-addresses], 136 and mapped addresses for 4rd [I-D.ietf-softwire-4rd]. In each case, 137 the question of how to set the "u" and "g" bits has to be decided. 138 For example, RFC 3972 specifies that they are both zero in CGAs, and 139 RFC 4982 describes them as if they were reserved bits. The same 140 applies to HBAs. On the other hand, RFC 4941 specifies that "u" must 141 be zero but leaves "g" variable. The NAT64 addressing format 142 [RFC6052] sets the whole byte containing "u" and "g" to zero. 144 Another case where the "u" and "g" bits are specified is in the 145 Reserved IPv6 Subnet Anycast Address format [RFC2526], which states 146 that "for interface identifiers in EUI-64 format, the universal/local 147 bit in the interface identifier MUST be set to 0" (i.e., local) and 148 requires that "g" bit to be set to 1. However, the text neither 149 states nor implies any semantics for these bits in anycast addresses. 151 A common operational practice for well-known servers is to manually 152 assign a small number as the IID, in which case "u" and "g" are both 153 zero. 155 These cases illustrate that the statement quoted above from RFC 4291 156 requiring "Modified EUI-64 format" is inapplicable when applied to 157 forms of IID that are not in fact based on an underlying EUI-64 158 address. In practice, the IETF has chosen to assign some 64-bit IIDs 159 that have nothing to do with EUI-64. 161 A particular case is that of /127 prefixes for point-to-point links 162 between routers, as standardised by [RFC6164]. The addresses on 163 these links are undoubtedly global unicast addresses, but they do not 164 have a 64-bit IID. The bits in the positions named "u" and "g" in 165 such an IID have no special significance and their values are not 166 specified. 168 Each time a new IID format is proposed, the question arises whether 169 these bits have any meaning. Section 2.2.1 of RFC 7042 discusses the 170 mechanics of the bit allocations but does not explain the purpose or 171 usefulness of these bits in an IID. There is an IANA registry for 172 reserved IID values [RFC5453] but again there is no explanation of 173 the purpose of the "u" and "g" bits. 175 There was a presumption when IPv6 was designed and the IID format was 176 first specified that a universally unique IID might prove to be very 177 useful, for example to contribute to solving the multihoming problem. 178 Indeed, the addressing architecture [RFC4291] states this explicitly: 180 "The use of the universal/local bit in the Modified EUI-64 format 181 identifier is to allow development of future technology that can take 182 advantage of interface identifiers with universal scope." 184 However, this has not so far proved to be the case. Also, there is 185 evidence from the field that MAC addresses with universal scope are 186 sometimes assigned to multiple MAC interfaces. There are recurrent 187 reports of manufacturers assigning the same MAC address to multiple 188 devices, and significant re-use of the same virtual MAC address is 189 reported in virtual machine environments. Once transformed into IID 190 format (with "u" = 1) these identifiers would purport to be 191 universally unique but would in fact be ambiguous. This has no known 192 harmful effect as long as the replicated MAC addresses and IIDs are 193 used on different layer 2 links. If they are used on the same link, 194 of course there will be a problem, very likely interfering with link- 195 layer transmission. If not, the problem will be detected by 196 duplicate address detection [RFC4862] [RFC6775], but such an error 197 can usually only be resolved by human intervention. 199 The conclusion from this is that the "u" bit is not a reliable 200 indicator of universal uniqueness. 202 We note that Identifier-Locator Network Protocol (ILNP), a 203 multihoming solution that might be expected to benefit from 204 universally unique IIDs in modified EUI-64 format, does not in fact 205 rely on them. ILNP uses its own format, defined as a Node Identifier 206 [RFC6741]. ILNP has the constraint that a given Node Identifier must 207 be unique within the context of a given Locator (i.e. within a single 208 given IPv6 subnetwork). As we have just shown, the state of the "u" 209 bit does not in any way guarantee such uniqueness, but duplicate 210 address detection is available. 212 Thus, we can conclude that the value of the "u" bit in IIDs has no 213 particular meaning. In the case of an IID created from a MAC address 214 according to RFC 4291, its value is determined by the MAC address, 215 but that is all. 217 An IPv6 IID should not be created from a MAC group address, so the 218 "g" bit will normally be zero, but this value also has no particular 219 meaning. Additionally, the "u" and the "g" bits are both meaningless 220 in the format of an IPv6 multicast group ID [RFC3306] [RFC3307]. 222 None of the above implies that there is a problem with using the "u" 223 and "g" bits in MAC addresses as part of the process of generating 224 IIDs from MAC addresses, or with specifying their values in other 225 methods of generating IIDs. What it does imply is that, after an IID 226 is generated by any method, no reliable deductions can be made from 227 the state of the "u" and "g" bits; in other words, these bits have no 228 useful semantics in an IID. 230 Once this is recognised, we can avoid the problematic confusion 231 caused by these bits each time that a new form of IID is proposed. 233 3. Usefulness of the U and G Bits 235 Given that the "u" and "g" bits do not have a reliable meaning in an 236 IID, it is relevant to consider what usefulness they do have. 238 If an IID is known or guessed to have been created according to RFC 239 4291, it could be transformed back into a MAC address. This can be 240 very helpful during operational fault diagnosis. For that reason, 241 mapping the IEEE "u" and "g" bits into the IID has operational 242 usefulness. However, it should be stressed that an IID with "u" = 1 243 and "g" = 0 might not be formed from a MAC address; on the contrary, 244 it might equally result from another method. With other methods, 245 there is no reverse transformation available. 247 Given that the values of the "u" and "g" bits in an IID have no 248 particular meaning, new methods of IID formation are at liberty to 249 use them as they wish, for example as additional pseudo-random bits 250 to reduce the chances of duplicate IIDs. 252 4. The Role of Duplicate Address Detection 254 As mentioned above, Duplicate Address Detection (DAD) [RFC4862] is 255 able to detect any case where a collision of two IIDs on the same 256 link leads to a duplicated IPv6 address. The scope of DAD may be 257 extended to a set of links by a DAD proxy [RFC6957] or by Neighbor 258 Discovery Optimization [RFC6775]. Since DAD is mandatory for all 259 nodes, there will be almost no case in which an IID collision, 260 however unlikely it may be, is not detected. It is out of scope of 261 most existing specifications to define the recovery action after a 262 DAD failure, which is an implementation issue. If a manually created 263 IID, or an IID derived from a MAC address according to RFC 4291, 264 leads to a DAD failure, human intervention will most likely be 265 required. However, as mentioned above, some methods of IID formation 266 might produce IID values with "u" = 1 and "g" = 0 that are not based 267 on a MAC address. With very low probability, such a value might 268 collide with an IID based on a MAC address. 270 As stated in RFC 4862: 272 "On the other hand, if the duplicate link-local address is not formed 273 from an interface identifier based on the hardware address, which is 274 supposed to be uniquely assigned, IP operation on the interface MAY 275 be continued." 277 Continued operation is only possible if a new IID is created. The 278 best procedure to follow for this will depend on the IID formation 279 method in use. For example, if an IID is formed by a pseudo-random 280 process, that process could simply be repeated. 282 5. Clarification of Specifications 284 This section describes clarifications to the IPv6 specifications that 285 result from the above discussion. Their aim is to reduce confusion 286 while retaining the useful aspects of the "u" and "g" bits in IIDs. 288 The EUI-64 to IID transformation defined in the IPv6 addressing 289 architecture [RFC4291] MUST be used for all cases where an IPv6 IID 290 is derived from an IEEE MAC or EUI-64 address. With any other form 291 of link layer address, an equivalent transformation SHOULD be used. 293 Specifications of other forms of 64-bit IID MUST specify how all 64 294 bits are set, but a generic semantic meaning for the "u" and "g" bits 295 MUST NOT be defined. However, the method of generating IIDs for 296 specific link types MAY define some local significance for certain 297 bits. 299 In all cases, the bits in an IID have no generic semantics; in other 300 words, they have opaque values. In fact, the whole IID value MUST be 301 viewed as an opaque bit string by third parties, except possibly in 302 the local context. 304 The following statement in section 2.5.1 of the IPv6 addressing 305 architecture [RFC4291]: 307 "For all unicast addresses, except those that start with the binary 308 value 000, Interface IDs are required to be 64 bits long and to be 309 constructed in Modified EUI-64 format." 311 is replaced by: 313 "For all unicast addresses, except those that start with the binary 314 value 000, Interface IDs are required to be 64 bits long. If derived 315 from an IEEE MAC-layer address, they must be constructed in Modified 316 EUI-64 format." 318 The following statement in section 2.5.1 of the IPv6 addressing 319 architecture [RFC4291] is obsoleted: 321 "The use of the universal/local bit in the Modified EUI-64 format 322 identifier is to allow development of future technology that can take 323 advantage of interface identifiers with universal scope." 325 As far as is known, no existing implementation will be affected by 326 these changes. The benefit is that future design discussions are 327 simplified. 329 6. Security Considerations 331 No new security exposures or issues are raised by this document. 333 In some contexts, unpredictable IID values are considered beneficial 334 to enhance privacy and defeat scanning attacks. The recognition that 335 the IID value should be regarded as an opaque bit string is 336 consistent with methods of IID formation that result in 337 unpredictable, pseudo-random values. 339 7. IANA Considerations 341 This document requests no immediate action by IANA. However, the 342 following should be noted when considering any future proposed 343 addition to the registry of reserved IID values, which requires 344 Standards Action according to [RFC5453]. 346 Full deployment of a new reserved IID value would require updates to 347 IID generation code in every deployed IPv6 stack, so the technical 348 justification for such a Standards Action would need to be extremely 349 strong. 351 The preceding sentence and a reference to this document should be 352 added to the Reserved IPv6 Interface Identifiers registry. 354 8. Acknowledgements 356 Valuable comments were received from Ran Atkinson, Remi Despres, 357 Ralph Droms, Fernando Gont, Eric Gray, Brian Haberman, Joel Halpern, 358 Bob Hinden, Christian Huitema, Ray Hunter, Tatuya Jinmei, Roger 359 Jorgensen, Mark Smith, Bernie Volz and other participants in the 6MAN 360 working group. 362 Brian Carpenter was a visitor at the Computer Laboratory, Cambridge 363 University during part of this work. 365 This document was produced using the xml2rfc tool [RFC2629]. 367 9. Change log [RFC Editor: Please remove] 369 draft-ietf-6man-ug-06: IETF Last Call comments - clarifications, 370 2013-12-02. 372 draft-ietf-6man-ug-05: AD comments - clarifications, 2013-11-14. 374 draft-ietf-6man-ug-04: corrected interpretation of 802.1, removed a 375 content-free paragraph, minor fixes, 2013-10-02. 377 draft-ietf-6man-ug-03: some clarifications, text on unpredictable 378 IIDs, minor corrections, 2013-08-26. 380 draft-ietf-6man-ug-02: incorporated WG Last Call comments: removed 381 open issue, clarified IEEE bit names, clarified DAD text, updated 382 references, minor editorial corrections, 2013-08-06. 384 draft-ietf-6man-ug-01: emphasised "opaque" nature of IID, added text 385 about DAD failures, expanded IANA considerations, 2013-05-25. 387 draft-ietf-6man-ug-00: first WG version, text clarified, added 388 possibility of link-local significance, 2013-03-28. 390 draft-carpenter-6man-ug-01: numerous clarifications following WG 391 comments, discussed DAD, added new section on the usefulness of the u 392 /g bits, expanded IANA considerations, set intended status, 393 2013-02-21. 395 draft-carpenter-6man-ug-00: original version, 2013-01-31. 397 10. References 399 10.1. Normative References 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 404 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 405 Architecture", RFC 4291, February 2006. 407 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 408 Address Autoconfiguration", RFC 4862, September 2007. 410 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 411 5453, February 2009. 413 [RFC7042] Eastlake, D. and J. Abley, "IANA Considerations and IETF 414 Protocol and Documentation Usage for IEEE 802 Parameters", 415 BCP 141, RFC 7042, October 2013. 417 10.2. Informative References 419 [I-D.ietf-6man-stable-privacy-addresses] 420 Gont, F., "A Method for Generating Semantically Opaque 421 Interface Identifiers with IPv6 Stateless Address 422 Autoconfiguration (SLAAC)", draft-ietf-6man-stable- 423 privacy-addresses-14 (work in progress), October 2013. 425 [I-D.ietf-softwire-4rd] 426 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 427 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 428 Solution (4rd)", draft-ietf-softwire-4rd-07 (work in 429 progress), October 2013. 431 [IEEE802] , "IEEE Standard for Local and Metropolitan Area Networks: 432 Overview and Architecture", IEEE Std 802-2001 (R2007), 433 2007. 435 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 436 Addresses", RFC 2526, March 1999. 438 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 439 June 1999. 441 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 442 Multicast Addresses", RFC 3306, August 2002. 444 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 445 Addresses", RFC 3307, August 2002. 447 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 448 RFC 3972, March 2005. 450 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 451 Extensions for Stateless Address Autoconfiguration in 452 IPv6", RFC 4941, September 2007. 454 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 455 Algorithms in Cryptographically Generated Addresses 456 (CGAs)", RFC 4982, July 2007. 458 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 459 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 460 March 2008. 462 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 463 2009. 465 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 466 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 467 October 2010. 469 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 470 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 471 Router Links", RFC 6164, April 2011. 473 [RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol 474 (ILNP) Engineering Considerations", RFC 6741, November 475 2012. 477 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 478 "Neighbor Discovery Optimization for IPv6 over Low-Power 479 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 480 November 2012. 482 [RFC6957] Costa, F., Combes, J-M., Pougnard, X., and H. Li, 483 "Duplicate Address Detection Proxy", RFC 6957, June 2013. 485 Authors' Addresses 487 Brian Carpenter 488 Department of Computer Science 489 University of Auckland 490 PB 92019 491 Auckland 1142 492 New Zealand 494 Email: brian.e.carpenter@gmail.com 496 Sheng Jiang 497 Huawei Technologies Co., Ltd 498 Q14, Huawei Campus 499 No.156 Beiqing Road 500 Hai-Dian District, Beijing 100095 501 P.R. China 503 Email: jiangsheng@huawei.com