idnits 2.17.1 draft-ietf-6man-ug-05.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 (November 14, 2013) is 3809 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: May 18, 2014 November 14, 2013 8 Significance of IPv6 Interface Identifiers 9 draft-ietf-6man-ug-05 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 May 18, 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 . . . . . . . . . . . . . . . . . . . 8 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 Hash-Based Addresses (HBAs) [RFC5535], and ISATAP addresses 134 [RFC5214]. Other methods have been proposed, such as stable privacy 135 addresses [I-D.ietf-6man-stable-privacy-addresses], and mapped 136 addresses for 4rd [I-D.ietf-softwire-4rd]. In each case, the 137 question of how to set the "u" and "g" bits has to be decided. For 138 example, RFC 3972 specifies that they are both zero in CGAs, and the 139 same applies to HBAs. On the other hand, RFC 4941 specifies that "u" 140 must be zero but leaves "g" variable. The NAT64 addressing format 141 [RFC6052] sets the whole byte containing "u" and "g" to zero. 143 Another case where the "u" and "g" bits are specified is in the 144 Reserved IPv6 Subnet Anycast Address format [RFC2526], which states 145 that "for interface identifiers in EUI-64 format, the universal/local 146 bit in the interface identifier MUST be set to 0" (i.e., local) and 147 requires that "g" bit to be set to 1. However, the text neither 148 states nor implies any semantics for these bits in anycast addresses. 150 A common operational practice for well-known servers is to manually 151 assign a small number as the IID, in which case "u" and "g" are both 152 zero. 154 These cases illustrate that the statement quoted above from RFC 4291 155 requiring "Modified EUI-64 format" is inapplicable when applied to 156 forms of IID that are not in fact based on an underlying EUI-64 157 address. In practice, the IETF has chosen to assign some 64-bit IIDs 158 that have nothing to do with EUI-64. 160 A particular case is that of /127 prefixes for point-to-point links 161 between routers, as standardised by [RFC6164]. The addresses on 162 these links are undoubtedly global unicast addresses, but they do not 163 have a 64-bit IID. The bits in the positions named "u" and "g" in 164 such an IID have no special significance and their values are not 165 specified. 167 Each time a new IID format is proposed, the question arises whether 168 these bits have any meaning. Section 2.2.1 of RFC 7042 discusses the 169 mechanics of the bit allocations but does not explain the purpose or 170 usefulness of these bits in an IID. There is an IANA registry for 171 reserved IID values [RFC5453] but again there is no explanation of 172 the purpose of the "u" and "g" bits. 174 There was a presumption when IPv6 was designed and the IID format was 175 first specified that a universally unique IID might prove to be very 176 useful, for example to contribute to solving the multihoming problem. 177 Indeed, the addressing architecture [RFC4291] states this explicitly: 179 "The use of the universal/local bit in the Modified EUI-64 format 180 identifier is to allow development of future technology that can take 181 advantage of interface identifiers with universal scope." 183 However, this has not so far proved to be the case. Also, there is 184 evidence from the field that MAC addresses with universal scope are 185 sometimes assigned to multiple MAC interfaces. There are recurrent 186 reports of manufacturers assigning the same MAC address to multiple 187 devices, and 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 282 This section describes clarifications to the IPv6 specifications that 283 result from the above discussion. Their aim is to reduce confusion 284 while retaining the useful aspects of the "u" and "g" bits in IIDs. 286 The EUI-64 to IID transformation defined in the IPv6 addressing 287 architecture [RFC4291] MUST be used for all cases where an IPv6 IID 288 is derived from an IEEE MAC or EUI-64 address. With any other form 289 of link layer address, an equivalent transformation SHOULD be used. 291 Specifications of other forms of 64-bit IID MUST specify how all 64 292 bits are set, but a generic semantic meaning for the "u" and "g" bits 293 MUST NOT be defined. However, the method of generating IIDs for 294 specific link types MAY define some local significance for certain 295 bits. 297 In all cases, the bits in an IID have no generic semantics; in other 298 words, they have opaque values. In fact, the whole IID value MUST be 299 viewed as an opaque bit string by third parties, except possibly in 300 the local context. 302 The following statement in section 2.5.1 of the IPv6 addressing 303 architecture [RFC4291]: 305 "For all unicast addresses, except those that start with the binary 306 value 000, Interface IDs are required to be 64 bits long and to be 307 constructed in Modified EUI-64 format." 309 is replaced by: 311 "For all unicast addresses, except those that start with the binary 312 value 000, Interface IDs are required to be 64 bits long. If derived 313 from an IEEE MAC-layer address, they must be constructed in Modified 314 EUI-64 format." 316 The following statement in section 2.5.1 of the IPv6 addressing 317 architecture [RFC4291] is obsoleted: 319 "The use of the universal/local bit in the Modified EUI-64 format 320 identifier is to allow development of future technology that can take 321 advantage of interface identifiers with universal scope." 323 As far as is known, no existing implementation will be affected by 324 these changes. The benefit is that future design discussions are 325 simplified. 327 6. Security Considerations 329 No new security exposures or issues are raised by this document. 331 In some contexts, unpredictable IID values are considered beneficial 332 to enhance privacy and defeat scanning attacks. The recognition that 333 the IID value should be regarded as an opaque bit string is 334 consistent with methods of IID formation that result in 335 unpredictable, pseudo-random values. 337 7. IANA Considerations 339 This document requests no immediate action by IANA. However, the 340 following should be noted when considering any future proposed 341 addition to the registry of reserved IID values, which requires 342 Standards Action according to [RFC5453]. 344 Full deployment of a new reserved IID value would require updates to 345 IID generation code in every deployed IPv6 stack, so the technical 346 justification for such a Standards Action would need to be extremely 347 strong. 349 8. Acknowledgements 351 Valuable comments were received from Ran Atkinson, Remi Despres, 352 Ralph Droms, Fernando Gont, Eric Gray, Brian Haberman, Joel Halpern, 353 Bob Hinden, Christian Huitema, Ray Hunter, Tatuya Jinmei, Mark Smith, 354 Bernie Volz and other participants in the 6MAN working group. 356 Brian Carpenter was a visitor at the Computer Laboratory, Cambridge 357 University during part of this work. 359 This document was produced using the xml2rfc tool [RFC2629]. 361 9. Change log [RFC Editor: Please remove] 363 draft-ietf-6man-ug-05: AD comments - clarifications, 2013-11-14. 365 draft-ietf-6man-ug-04: corrected interpretation of 802.1, removed a 366 content-free paragraph, minor fixes, 2013-10-02. 368 draft-ietf-6man-ug-03: some clarifications, text on unpredictable 369 IIDs, minor corrections, 2013-08-26. 371 draft-ietf-6man-ug-02: incorporated WG Last Call comments: removed 372 open issue, clarified IEEE bit names, clarified DAD text, updated 373 references, minor editorial corrections, 2013-08-06. 375 draft-ietf-6man-ug-01: emphasised "opaque" nature of IID, added text 376 about DAD failures, expanded IANA considerations, 2013-05-25. 378 draft-ietf-6man-ug-00: first WG version, text clarified, added 379 possibility of link-local significance, 2013-03-28. 381 draft-carpenter-6man-ug-01: numerous clarifications following WG 382 comments, discussed DAD, added new section on the usefulness of the u 383 /g bits, expanded IANA considerations, set intended status, 384 2013-02-21. 386 draft-carpenter-6man-ug-00: original version, 2013-01-31. 388 10. References 390 10.1. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 396 Architecture", RFC 4291, February 2006. 398 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 399 Address Autoconfiguration", RFC 4862, September 2007. 401 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 402 5453, February 2009. 404 [RFC7042] Eastlake, D. and J. Abley, "IANA Considerations and IETF 405 Protocol and Documentation Usage for IEEE 802 Parameters", 406 BCP 141, RFC 7042, October 2013. 408 10.2. Informative References 410 [I-D.ietf-6man-stable-privacy-addresses] 411 Gont, F., "A Method for Generating Semantically Opaque 412 Interface Identifiers with IPv6 Stateless Address 413 Autoconfiguration (SLAAC)", draft-ietf-6man-stable- 414 privacy-addresses-14 (work in progress), October 2013. 416 [I-D.ietf-softwire-4rd] 417 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 418 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 419 Solution (4rd)", draft-ietf-softwire-4rd-07 (work in 420 progress), October 2013. 422 [IEEE802] , "IEEE Standard for Local and Metropolitan Area Networks: 423 Overview and Architecture", IEEE Std 802-2001 (R2007), 424 2007. 426 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 427 Addresses", RFC 2526, March 1999. 429 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 430 June 1999. 432 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 433 Multicast Addresses", RFC 3306, August 2002. 435 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 436 Addresses", RFC 3307, August 2002. 438 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 439 RFC 3972, March 2005. 441 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 442 Extensions for Stateless Address Autoconfiguration in 443 IPv6", RFC 4941, September 2007. 445 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 446 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 447 March 2008. 449 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 450 2009. 452 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 453 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 454 October 2010. 456 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 457 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 458 Router Links", RFC 6164, April 2011. 460 [RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol 461 (ILNP) Engineering Considerations", RFC 6741, November 462 2012. 464 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 465 "Neighbor Discovery Optimization for IPv6 over Low-Power 466 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 467 November 2012. 469 [RFC6957] Costa, F., Combes, J-M., Pougnard, X., and H. Li, 470 "Duplicate Address Detection Proxy", RFC 6957, June 2013. 472 Authors' Addresses 474 Brian Carpenter 475 Department of Computer Science 476 University of Auckland 477 PB 92019 478 Auckland 1142 479 New Zealand 481 Email: brian.e.carpenter@gmail.com 483 Sheng Jiang 484 Huawei Technologies Co., Ltd 485 Q14, Huawei Campus 486 No.156 Beiqing Road 487 Hai-Dian District, Beijing 100095 488 P.R. China 490 Email: jiangsheng@huawei.com