idnits 2.17.1 draft-ietf-6man-ug-02.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 06, 2013) is 3909 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-10 == 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 07, 2014 August 06, 2013 8 Significance of IPv6 Interface Identifiers 9 draft-ietf-6man-ug-02 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 February 07, 2014. 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/l" bit in a MAC address [IEEE802] is set to 0 to indicate 94 universal scope (implying uniqueness) or to 1 to indicate local 95 scope (without implying uniqueness). In an IID formed from a MAC 96 address, this bit is simply known as the "u" bit and its value is 97 inverted, i.e., 1 for universal scope and 0 for local scope. 98 According to RFC 4291 and [RFC5342], the reason for this was to 99 make it easier for network operators to manually configure local- 100 scope IIDs. 102 In an IID, this bit is in position 6, i.e., position 70 in the 103 complete IPv6 address. 105 o The "i/g" bit in a MAC address is set to 1 to indicate group 106 addressing (link-layer multicast). The value of this bit is 107 preserved in an IID, where it is known as the "g" bit. 109 In an IID, this bit is in position 7, i.e., position 71 in the 110 complete IPv6 address. 112 This document discusses problems observed with the "u" and "g" bits 113 as a result of the above requirements and the fact that various other 114 methods of forming an IID have been defined, quite independently of 115 the method described in Appendix A of RFC 4291. It then discusses 116 the usefulness of these two bits and the significance of the bits in 117 an IID in general. Finally it updates RFC 4291 accordingly. 119 1.1. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 2. Problem statement 127 In addition to IIDs formed from IEEE EUI-64 addresses, various new 128 forms of IID have been defined, including temporary addresses 129 [RFC4941], Cryptographically Generated Addresses (CGAs) [RFC3972], 130 Hash-Based Addresses (HBAs) [RFC5535], and ISATAP addresses 131 [RFC5214]. Other methods have been proposed, such as stable privacy 132 addresses [I-D.ietf-6man-stable-privacy-addresses], and mapped 133 addresses for 4rd [I-D.ietf-softwire-4rd]. In each case, the 134 question of how to set the "u" and "g" bits has to be decided. For 135 example, RFC 3972 specifies that they are both zero in CGAs, and the 136 same applies to HBAs. On the other hand, RFC 4941 specifies that "u" 137 must be zero but leaves "g" variable. The NAT64 addressing format 138 [RFC6052] sets the whole byte containing "u" and "g" to zero. 140 Another case where the "u" and "g" bits are specified is in the 141 Reserved IPv6 Subnet Anycast Address format [RFC2526], which states 142 that "for interface identifiers in EUI-64 format, the universal/local 143 bit in the interface identifier MUST be set to 0" (i.e., local) and 144 requires that "g" bit to be set to 1. However, the text neither 145 states nor implies any semantics for these bits in anycast addresses. 147 A common operational practice for well-known servers is to manually 148 assign a small number as the IID, in which case "u" and "g" are both 149 zero. 151 These cases illustrate that the statement quoted above from RFC 4291 152 requiring "Modified EUI-64 format" is rather meaningless when applied 153 to forms of IID that are not in fact based on an underlying EUI-64 154 address. In practice, the IETF has chosen to assign some 64-bit IIDs 155 that have nothing to do with EUI-64. 157 A particular case is that of /127 prefixes for point-to-point links 158 between routers, as standardised by [RFC6164]. The addresses on 159 these links are undoubtedly global unicast addresses, but they do not 160 have a 64-bit IID. The bits in the positions named "u" and "g" in 161 such an IID have no special significance and their values are not 162 specified. 164 Each time a new IID format is proposed, the question arises whether 165 these bits have any meaning. Section 2.2.1 of RFC 5342 discusses the 166 mechanics of the bit allocations but does not explain the purpose or 167 usefulness of these bits in an IID. There is an IANA registry for 168 reserved IID values [RFC5453] but again there is no explanation of 169 the purpose of the "u" and "g" bits. 171 There was a presumption when IPv6 was designed and the IID format was 172 first specified that a universally unique IID might prove to be very 173 useful, for example to contribute to solving the multihoming problem. 174 Indeed, the addressing architecture [RFC4291] states this explicitly: 176 "The use of the universal/local bit in the Modified EUI-64 format 177 identifier is to allow development of future technology that can take 178 advantage of interface identifiers with universal scope." 180 However, this has not so far proved to be the case. Also, there is 181 evidence from the field that IEEE MAC addresses with universal scope 182 are sometime incorrectly assigned to multiple MAC interfaces. 183 Firstly, there are recurrent reports of manufacturers assigning the 184 same MAC address to multiple devices. Secondly, significant re-use 185 of the same virtual MAC address is reported in virtual machine 186 environments. Once transformed into IID format (with "u" = 1) these 187 identifiers would purport to be universally unique but would in fact 188 be ambiguous. This has no known harmful effect as long as the 189 replicated MAC addresses and IIDs are used on different layer 2 190 links. If they are used on the same link, of course there will be a 191 problem, very likely interfering with link-layer transmission. If 192 not, the problem will be detected by duplicate address detection 193 [RFC4862], [RFC6775], but such an error can usually only be resolved 194 by human intervention. 196 The conclusion from this is that the "u" bit is not a reliable 197 indicator of universal uniqueness. 199 We note that Identifier-Locator Network Protocol (ILNP), a 200 multihoming solution that might be expected to benefit from 201 universally unique IIDs in modified EUI-64 format, does not in fact 202 rely on them. ILNP uses its own format, defined as a Node Identifier 203 [RFC6741]. ILNP has the constraint that a given Node Identifier must 204 be unique within the context of a given Locator (i.e. within a single 205 given IPv6 subnetwork). As we have just shown, the state of the "u" 206 bit does not in any way guarantee such uniqueness, but duplicate 207 address detection is available. 209 Thus, we can conclude that the value of the "u" bit in IIDs has no 210 particular meaning. In the case of an IID created from a MAC address 211 according to RFC 4291, its value is determined by the MAC address, 212 but that is all. 214 An IPv6 IID should not be created from a MAC group address, so the 215 "g" bit will normally be zero, but this value also has no particular 216 meaning. Additionally, the "u" and the "g" bits are both meaningless 217 in the format of an IPv6 multicast group ID [RFC3306], [RFC3307]. 219 None of the above implies that there is a problem with using the "u" 220 and "g" bits in MAC addresses as part of the process of generating 221 IIDs from MAC addresses, or with specifying their values in other 222 methods of generating IIDs. What it does imply is that, after an IID 223 is generated by any method, no reliable deductions can be made from 224 the state of the "u" and "g" bits; in other words, these bits have no 225 useful semantics in an IID. 227 Once this is recognised, we can avoid the problematic confusion 228 caused by these bits each time that a new form of IID is proposed. 230 3. Usefulness of the U and G Bits 232 Given that the "u" and "g" bits do not have a reliable meaning in an 233 IID, it is relevant to consider what usefulness they do have. 235 If an IID is known or guessed to have been created according to RFC 236 4291, it could be transformed back into a MAC address. This can be 237 very helpful during operational fault diagnosis. For that reason, 238 mapping the IEEE "u" and "g" bits into the IID has operational 239 usefulness. However, it should be stressed that an IID with "u" = 1 240 and "g" = 0 might not be formed from a MAC address; on the contrary, 241 it might equally result from another method. With other methods, 242 there is no reverse transformation available. 244 To the extent that each method of IID creation specifies the values 245 of the "u" and "g" bits, and that each new method is carefully 246 designed in the light of its predecessors, these bits tend to reduce 247 the chances of duplicate IIDs. 249 4. The Role of Duplicate Address Detection 251 As mentioned above, Duplicate Address Detection (DAD) [RFC4862] is 252 able to detect any case where a collision of two IIDs on the same 253 link leads to a duplicated IPv6 address. The scope of DAD may be 254 extended to a set of links by a DAD proxy [RFC6957] or by Neighbor 255 Discovery Optimization [RFC6775]. Since DAD is mandatory for all 256 nodes, there will be no case in which an IID collision, however 257 unlikely it may be, is not detected. It is out of scope of most 258 existing specifications to define the recovery action after a DAD 259 failure, which is an implementation issue. If a manually created 260 IID, or an IID derived from a MAC address according to RFC 4291, 261 leads to a DAD failure, human intervention will most likely be 262 required. However, as mentioned above, some methods of IID formation 263 might produce IID values with "u" = 1 and "g" = 0 that are not based 264 on a MAC address. With very low probability, such a value might 265 collide with an IID based on a MAC address. 267 As stated in RFC 4862: 269 "On the other hand, if the duplicate link-local address is not formed 270 from an interface identifier based on the hardware address, which is 271 supposed to be uniquely assigned, IP operation on the interface MAY 272 be continued." 274 Continued operation is only possible if a new IID is created. The 275 best procedure to follow for this will depend on the IID formation 276 method in use. For example, if an IID is formed by a pseudo-random 277 process, that process could simply be repeated. 279 5. Clarification of Specifications 281 This section describes clarifications to the IPv6 specifications that 282 result from the above discussion. Their aim is to reduce confusion 283 while retaining the useful aspects of the "u" and "g" bits in IIDs. 285 The EUI-64 to IID transformation defined in the IPv6 addressing 286 architecture [RFC4291] MUST be used for all cases where an IPv6 IID 287 is derived from an IEEE MAC or EUI-64 address. With any other form 288 of link layer address, an equivalent transformation SHOULD be used. 290 Specifications of other forms of 64-bit IID MUST specify how all 64 291 bits are set, but need not treat the "u" and "g" bits in any special 292 way. A general semantic meaning for these bits MUST NOT be defined. 293 However, the method of generating IIDs for specific link types MAY 294 define some local significance for certain bits. 296 In all cases, the bits in an IID have no general semantics; in other 297 words, they have opaque values. In fact, the whole IID value MUST be 298 viewed as an opaque bit string by third parties, except possibly in 299 the local context. 301 The following statement in section 2.5.1 of the IPv6 addressing 302 architecture [RFC4291]: 304 "For all unicast addresses, except those that start with the binary 305 value 000, Interface IDs are required to be 64 bits long and to be 306 constructed in Modified EUI-64 format." 308 is replaced by: 310 "For all unicast addresses, except those that start with the binary 311 value 000, Interface IDs are required to be 64 bits long. If derived 312 from an IEEE MAC-layer address, they must be constructed in Modified 313 EUI-64 format." 315 The following statement in section 2.5.1 of the IPv6 addressing 316 architecture [RFC4291] is obsoleted: 318 "The use of the universal/local bit in the Modified EUI-64 format 319 identifier is to allow development of future technology that can take 320 advantage of interface identifiers with universal scope." 322 As far as is known, no existing implementation will be affected by 323 these changes. The benefit is that future design discussions are 324 simplified. 326 6. Security Considerations 328 No new security exposures or issues are raised by this document. 330 7. IANA Considerations 332 This document requests no immediate action by IANA. However, the 333 following should be noted when considering any future proposed 334 addition to the registry of reserved IID values, which requires 335 Standards Action according to [RFC5453]. 337 Full deployment of a new reserved IID value would require updates to 338 IID generation code in every deployed IPv6 stack, so the technical 339 justification for such a Standards Action would need to be extremely 340 strong. 342 A reserved IID, or a range of reserved IIDs, will most likely specify 343 values for both "u" and "g", since they are among the high-order 344 bits. At the present time, none of the standard methods of 345 generating IIDs will generate "u" = "g" = 1. Reserved IIDs with "u" 346 = "g" = 1 are therefore unlikely to collide with automatically 347 generated IIDs. 349 8. Acknowledgements 351 Valuable comments were received from Ran Atkinson, Remi Despres, 352 Ralph Droms, Fernando Gont, Brian Haberman, Joel Halpern, Bob Hinden, 353 Christian Huitema, Ray Hunter, Tatuya Jinmei, Mark Smith, Bernie Volz 354 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-02: incorporated WG Last Call comments: removed 364 open issue, clarified IEEE bit names, clarified DAD text, updated 365 references, minor editorial corrections, 2013-08-06. 367 draft-ietf-6man-ug-01: emphasised "opaque" nature of IID, added text 368 about DAD failures, expanded IANA considerations, 2013-05-25. 370 draft-ietf-6man-ug-00: first WG version, text clarified, added 371 possibility of link-local significance, 2013-03-28. 373 draft-carpenter-6man-ug-01: numerous clarifications following WG 374 comments, discussed DAD, added new section on the usefulness of the u 375 /g bits, expanded IANA considerations, set intended status, 376 2013-02-21. 378 draft-carpenter-6man-ug-00: original version, 2013-01-31. 380 10. References 382 10.1. Normative References 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997. 387 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 388 Architecture", RFC 4291, February 2006. 390 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 391 Address Autoconfiguration", RFC 4862, September 2007. 393 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 394 for IEEE 802 Parameters", BCP 141, RFC 5342, September 395 2008. 397 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 398 5453, February 2009. 400 10.2. Informative References 402 [I-D.ietf-6man-stable-privacy-addresses] 403 Gont, F., "A method for Generating Stable Privacy-Enhanced 404 Addresses with IPv6 Stateless Address Autoconfiguration 405 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-10 406 (work in progress), June 2013. 408 [I-D.ietf-softwire-4rd] 409 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 410 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 411 Solution (4rd)", draft-ietf-softwire-4rd-06 (work in 412 progress), July 2013. 414 [IEEE802] , "IEEE Standard for Local and Metropolitan Area Networks: 415 Overview and Architecture", IEEE Std 802-2001 (R2007) , 416 2007. 418 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 419 Addresses", RFC 2526, March 1999. 421 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 422 June 1999. 424 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 425 Multicast Addresses", RFC 3306, August 2002. 427 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 428 Addresses", RFC 3307, August 2002. 430 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 431 RFC 3972, March 2005. 433 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 434 Extensions for Stateless Address Autoconfiguration in 435 IPv6", RFC 4941, September 2007. 437 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 438 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 439 March 2008. 441 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 442 2009. 444 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 445 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 446 October 2010. 448 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 449 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 450 Router Links", RFC 6164, April 2011. 452 [RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol 453 (ILNP) Engineering Considerations", RFC 6741, November 454 2012. 456 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 457 "Neighbor Discovery Optimization for IPv6 over Low-Power 458 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 459 November 2012. 461 [RFC6957] Costa, F., Combes, J-M., Pougnard, X., and H. Li, 462 "Duplicate Address Detection Proxy", RFC 6957, June 2013. 464 Authors' Addresses 466 Brian Carpenter 467 Department of Computer Science 468 University of Auckland 469 PB 92019 470 Auckland 1142 471 New Zealand 473 Email: brian.e.carpenter@gmail.com 474 Sheng Jiang 475 Huawei Technologies Co., Ltd 476 Q14, Huawei Campus 477 No.156 Beiqing Road 478 Hai-Dian District, Beijing 100095 479 P.R. China 481 Email: jiangsheng@huawei.com