idnits 2.17.1 draft-ietf-6man-ug-00.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 (March 28, 2013) is 4046 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-05 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-04 -- 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. E. Carpenter 3 Internet-Draft Univ. of Auckland 4 Updates: 4291 (if approved) S. Jiang 5 Intended status: Standards Track Huawei Technologies Co., Ltd 6 Expires: September 28, 2013 March 28, 2013 8 The U and G bits in IPv6 Interface Identifiers 9 draft-ietf-6man-ug-00 11 Abstract 13 The IPv6 addressing architecture defines a method by which the 14 Universal and Group bits of an IEEE link-layer address are mapped 15 into an IPv6 unicast interface identifier. This document clarifies 16 the status of those bits for interface identifiers that are not 17 derived from an IEEE link-layer address, and updates RFC 4291 18 accordingly. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 28, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Usefulness of the U and G Bits . . . . . . . . . . . . . . . 5 58 4. Clarification of Specifications . . . . . . . . . . . . . . . 5 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 62 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 9.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 According to the IPv6 addressing architecture [RFC4291], when a 71 64-bit IPv6 unicast Interface Identifier (IID) is formed on the basis 72 of an IEEE EUI-64 address, usually itself expanded from a 48-bit MAC 73 address, a particular format must be used: 75 "For all unicast addresses, except those that start with the binary 76 value 000, Interface IDs are required to be 64 bits long and to be 77 constructed in Modified EUI-64 format." 79 The specification assumes that that the normal case is to transform 80 an Ethernet-style address into an IID, preserving the information 81 provided by two bits in particular: 83 o The "u" bit in an IEEE address is set to 0 to indicate universal 84 scope (implying uniqueness) or to 1 to indicate local scope 85 (without implying uniqueness). In an IID this bit is inverted, 86 i.e., 1 for universal scope and 0 for local scope. According to 87 [RFC5342], the reason for this was "to make it easier for network 88 operators to type in local-scope identifiers". 90 In an IID, this bit is in position 6, i.e., position 70 in the 91 complete IPv6 address. 93 o The "g" bit in an IEEE address is set to 1 to indicate group 94 addressing (link-layer multicast). The value of this bit is 95 preserved in an IID. 97 In an IID, this bit is in position 7, i.e., position 71 in the 98 complete IPv6 address. 100 This document discusses problems observed with the "u" and "g" bits 101 as a result of the above requirements. It then discusses the 102 usefulness of the two bits, and updates RFC 4291 accordingly. 104 1.1. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. Problem statement 112 In addition to IIDs formed from IEEE EUI-64 addresses, various new 113 forms of IID have been defined or proposed, such as temporary 114 addresses [RFC4941], Cryptographically Generated Addresses (CGAs) 115 [RFC3972], Hash-Based Addresses (HBAs) [RFC5535], stable privacy 116 addresses [I-D.ietf-6man-stable-privacy-addresses], or mapped 117 addresses for 4rd [I-D.ietf-softwire-4rd]. In each case, the 118 question of how to set the "u" and "g" bits has to be decided. For 119 example, RFC 3972 specifies that they are both zero in CGAs, and the 120 same applies to HBAs. On the other hand, RFC 4941 specifies that "u" 121 must be zero but leaves "g" variable. The NAT64 addressing format 122 [RFC6052] sets the whole byte containing "u" and "g" to zero. 124 Another case where the "u" and "g" bits are specified is in the 125 Reserved IPv6 Subnet Anycast Address format [RFC2526], which states 126 that "for interface identifiers in EUI-64 format, the universal/local 127 bit in the interface identifier MUST be set to 0" (i.e., local) and 128 requires that "g" bit to be set to 1. However, the text neither 129 states nor implies any semantics for these bits in anycast addresses. 131 A common operational practice for well-known servers is to manually 132 assign a small number as the IID, in which case "u" and "g" are both 133 zero. 135 These cases illustrate that the statement quoted above from RFC 4291 136 requiring "Modified EUI-64 format" is rather meaningless when applied 137 to forms of IID that are not in fact based on an underlying EUI-64 138 address. In practice, the IETF has chosen to assign some 64-bit IIDs 139 that have nothing to do with EUI-64. 141 A particular case is that of /127 prefixes for point-to-point links 142 between routers, as standardised by [RFC6164]. The addresses on 143 these links are undoubtedly global unicast addresses, but they do not 144 have a 64-bit IID. The bits in the positions named "u" and "g" in 145 such an IID have no special significance and their values are not 146 specified. 148 Each time a new IID format is proposed, the question arises whether 149 these bits have any meaning. Section 2.2.1 of RFC 5342 discusses the 150 mechanics of the bit allocations but does not explain the purpose or 151 usefulness of these bits in an IID. There is an IANA registry for 152 reserved IID values [RFC5453] but again there is no explanation of 153 the purpose of the "u" and "g" bits. 155 There was a presumption when IPv6 was designed and the IID format was 156 first specified that a universally unique IID might prove to be very 157 useful, for example to contribute to solving the multihoming problem. 158 Indeed, the addressing architecture [RFC4291] states this explicitly: 160 "The use of the universal/local bit in the Modified EUI-64 format 161 identifier is to allow development of future technology that can take 162 advantage of interface identifiers with universal scope." 164 However, this has not so far proved to be the case. Also, there is 165 evidence from the field that IEEE MAC addresses with "u" = 0 are 166 sometime incorrectly assigned to multiple MAC interfaces. Firstly, 167 there are recurrent reports of manufacturers assigning the same MAC 168 address to multiple devices. Secondly, significant re-use of the 169 same virtual MAC address is reported in virtual machine environments. 170 Once transformed into IID format (with "u" = 1) these identifiers 171 would purport to be universally unique but would in fact be 172 ambiguous. This has no known harmful effect as long as the 173 replicated MAC addresses and IIDs are used on different layer 2 174 links. If they are used on the same link, of course there will be a 175 problem, to be detected by duplicate address detection [RFC4862], but 176 such a problem can usually only be resolved by human intervention. 178 The conclusion from this is that the "u" bit is not a reliable 179 indicator of universal uniqueness. 181 We note that Identifier-Locator Network Protocol (ILNP), a 182 multihoming solution that might be expected to benefit from 183 universally unique IIDs in modified EUI-64 format, does not in fact 184 rely on them. ILNP uses its own format, defined as a Node Identifier 185 [RFC6741]. ILNP has the constraint that a given Node Identifier must 186 be unique within the context of a given Locator (i.e. within a 187 single given IPv6 subnetwork). As we have just shown, the state of 188 the "u" bit does not in any way guarantee such uniqueness, but 189 duplicate address detection is available. 191 Thus, we can conclude that the value of the "u" bit in IIDs has no 192 particular meaning. In the case of an IID created from a MAC address 193 according to RFC 4291, its value is determined by the MAC address, 194 but that is all. 196 An IPv6 IID should not be created from a MAC group address, so the 197 "g" bit will normally be zero, but this value also has no particular 198 meaning. Additionally, the "u" and the "g" bits are both meaningless 199 in the format of an IPv6 multicast group ID [RFC3306], [RFC3307]. 201 None of the above implies that there is a problem with using the "u" 202 and "g" bits in MAC addresses as part of the process of generating 203 IIDs from MAC addresses, or with specifying their values in other 204 methods of generating IIDs. What it does imply is that, after an IID 205 is generated by any method, no reliable deductions can be made from 206 the state of the "u" and "g" bits; in other words, these bits have no 207 useful semantics in an IID. 209 Once this is recognised, we can avoid the problematic confusion 210 caused by these bits each time that a new form of IID is proposed. 212 3. Usefulness of the U and G Bits 214 Given that the "u" and "g" bits do not have a reliable meaning in an 215 IID, it is relevant to consider what usefulness they do have. 217 If an IID is known or guessed to have been created according to RFC 218 4291, it could be transformed back into a MAC address. This can be 219 very helpful during operational fault diagnosis. For that reason, 220 mapping the IEEE "u" and "g" bits into the IID has operational 221 usefulness. However, it should be stressed that "u" = "g" = 0 does 222 not prove that an IID was formed from a MAC address; on the contrary, 223 it might equally result from another method. With other methods, 224 there is no reverse transformation available. 226 To the extent that each method of IID creation specifies the values 227 of the "u" and "g" bits, and that each new method is carefully 228 designed in the light of its predecessors, these bits tend to reduce 229 the chances of duplicate IIDs. 231 4. Clarification of Specifications 233 This section describes clarifications to the IPv6 specifications that 234 result from the above discussion. Their aim is to reduce confusion 235 while retaining the useful aspects of the "u" and "g" bits in IIDs. 237 The EUI-64 to IID transformation defined in the IPv6 addressing 238 architecture [RFC4291] MUST be used for all cases where an IPv6 IID 239 is derived from an IEEE MAC or EUI-64 address. With any other form 240 of link layer address, an equivalent transformation SHOULD be used. 242 Specifications of other forms of 64-bit IID MUST specify how all 64 243 bits are set, but need not treat the "u" and "g" bits in any special 244 way. A general semantic meaning for these bits MUST NOT be defined. 245 However, the method of generating IIDs for specific link types may 246 define some local significance for certain bits. 248 In all cases, the bits in an IID have no general semantics; in other 249 words, they have opaque values. In fact, the whole IID should be 250 viewed as opaque by third parties, except possibly in the local 251 context. 253 The following statement in section 2.5.1 of the IPv6 addressing 254 architecture [RFC4291]: 256 "For all unicast addresses, except those that start with the binary 257 value 000, Interface IDs are required to be 64 bits long and to be 258 constructed in Modified EUI-64 format." 260 is replaced by: 262 "For all unicast addresses, except those that start with the binary 263 value 000, Interface IDs are required to be 64 bits long. If derived 264 from an IEEE MAC-layer address, they must be constructed in Modified 265 EUI-64 format." 267 The following statement in section 2.5.1 of the IPv6 addressing 268 architecture [RFC4291] is obsoleted: 270 "The use of the universal/local bit in the Modified EUI-64 format 271 identifier is to allow development of future technology that can take 272 advantage of interface identifiers with universal scope." 274 As far as is known, no existing implementation will be affected by 275 these changes. The benefit is that future design discussions are 276 simplified. 278 5. Security Considerations 280 No new security exposures or issues are raised by this document. 282 6. IANA Considerations 283 This document requests no immediate action by IANA. However, the 284 following should be noted when considering future proposed additions 285 to the registry of reserved IID values, which requires Standards 286 Action according to [RFC5453]. A reserved IID, or a range of 287 reserved IIDs, will most likely specify values for both "u" and "g", 288 since they are among the high-order bits. At the present time, none 289 of the known methods of generating IIDs will generate "u" = "g" = 1. 290 Reserved IIDs with "u" = "g" = 1 are therefore unlikely to collide 291 with automatically generated IIDs. 293 7. Acknowledgements 295 Valuable comments were received from Ran Atkinson, Remi Despres, 296 Fernando Gont, Brian Haberman, Joel Halpern, Ray Hunter, Mark Smith, 297 and other participants in the 6MAN working group. 299 Brian Carpenter was a visitor at the Computer Laboratory, Cambridge 300 University during part of this work. 302 This document was produced using the xml2rfc tool [RFC2629]. 304 8. Change log [RFC Editor: Please remove] 306 draft-ietf-6man-ug-00: first WG version, text clarified, added 307 possibility of link-local significance, 2013-02-28. 309 draft-carpenter-6man-ug-01: numerous clarifications following WG 310 comments, discussed DAD, added new section on the usefulness of the u 311 /g bits, expanded IANA considerations, set intended status, 312 2013-02-21. 314 draft-carpenter-6man-ug-00: original version, 2013-01-31. 316 9. References 318 9.1. Normative References 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, March 1997. 323 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 324 Architecture", RFC 4291, February 2006. 326 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 327 for IEEE 802 Parameters", BCP 141, RFC 5342, September 328 2008. 330 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 331 5453, February 2009. 333 9.2. Informative References 335 [I-D.ietf-6man-stable-privacy-addresses] 336 Gont, F., "A method for Generating Stable Privacy-Enhanced 337 Addresses with IPv6 Stateless Address Autoconfiguration 338 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-05 339 (work in progress), March 2013. 341 [I-D.ietf-softwire-4rd] 342 Jiang, S., Despres, R., Penno, R., Lee, Y., Chen, G., and 343 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 344 Solution (4rd)", draft-ietf-softwire-4rd-04 (work in 345 progress), October 2012. 347 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 348 Addresses", RFC 2526, March 1999. 350 [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, 351 June 1999. 353 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 354 Multicast Addresses", RFC 3306, August 2002. 356 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 357 Addresses", RFC 3307, August 2002. 359 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 360 RFC 3972, March 2005. 362 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 363 Address Autoconfiguration", RFC 4862, September 2007. 365 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 366 Extensions for Stateless Address Autoconfiguration in 367 IPv6", RFC 4941, September 2007. 369 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 370 2009. 372 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 373 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 374 October 2010. 376 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 377 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 378 Router Links", RFC 6164, April 2011. 380 [RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol 381 (ILNP) Engineering Considerations", RFC 6741, November 382 2012. 384 Authors' Addresses 386 Brian Carpenter 387 Department of Computer Science 388 University of Auckland 389 PB 92019 390 Auckland 1142 391 New Zealand 393 Email: brian.e.carpenter@gmail.com 395 Sheng Jiang 396 Huawei Technologies Co., Ltd 397 Q14, Huawei Campus 398 No.156 Beiqing Road 399 Hai-Dian District, Beijing 100095 400 P.R. China 402 Email: jiangsheng@huawei.com