idnits 2.17.1 draft-petrescu-6man-ll-prefix-len-21.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 676 has weird spacing: '... region code...' == Line 684 has weird spacing: '... Region code...' -- The document date (June 6, 2019) is 1784 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN Working Group A. Petrescu 3 Internet-Draft CEA, LIST 4 Updates: RFC4291, RFC4007 (if approved) L. Velvindron 5 Intended status: Standards Track Cyberstorm.mu 6 Expires: December 8, 2019 N. Kottapalli 7 Benu Networks 8 G. Mishra 9 Verizon Communications Inc. (VZ) 10 D. Mudric 11 Avaya 12 June 6, 2019 14 The length of the prefix of an IPv6 link-local address ranges from 10 to 15 127 16 draft-petrescu-6man-ll-prefix-len-21 18 Abstract 20 A rejected Erratum to RFC4291 "IPv6 Addr Archi" on the topic of link- 21 local addresses 'would need' a draft. This draft is an answer to 22 that need. 24 The length of the prefix of an IPv6 link-local address is variable. 25 The minimal value is 10 decimal. The maximum value is 127 decimal. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 8, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Definitions and Statements . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Justification . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Kinds of Solutions . . . . . . . . . . . . . . . . . . . . . 5 66 6. Context of Documents . . . . . . . . . . . . . . . . . . . . 6 67 7. Context of OS Behaviour . . . . . . . . . . . . . . . . . . . 8 68 8. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 9 69 9. Example of use of LL Prefix Length 32 . . . . . . . . . . . . 9 70 10. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 10.1. Use-Case Convoy . . . . . . . . . . . . . . . . . . . . 10 72 10.2. Intuitive Next-Hop . . . . . . . . . . . . . . . . . . . 12 73 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 76 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 77 15. Normative References . . . . . . . . . . . . . . . . . . . . 13 78 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Definitions and Statements 83 The prefix of an IP address is formed by the n leftmost bits of the 84 address. (in a left-to-right writing system). 86 The prefix of an IP address is used for goals such as: identify the 87 type of an IPv6 address (link-local, global, others), identify the 88 belonging of an IP address to a particular subnetwork, assist the 89 forwarding (or not forwarding) decisions, and others. 91 The minimal length of the prefix of an IPv6 link-local address (the 92 value of n) is equal to 10 decimal. The maximum is 127. 94 The prefix of an IPv6 link-local address is represented textually as 95 "fe80::/n", where n MAY be any value between 10 and 127. 97 Regardless of the prefix length, the leftmost 10 bits of an IPv6 98 link-local address MUST be set to binary 1111111010 (hexadecimal 99 fe80). 101 The RFC 4291 illustration of an IPv6 link-local address is: 103 | 10 | 104 | bits | 54 bits | 64 bits | 105 +----------+-------------------------+----------------------------+ 106 |1111111010| 0 | interface ID | 107 +----------+-------------------------+----------------------------+ 109 Figure 1: The IPv6 link-local address 111 There is an error in this RFC 4291 illustration. The error is in 112 requiring the 54 bits to be 0. The bits at position 11 to 16 are not 113 0 (the first 6 bits of the 54 bits). If they were 0 then 114 0xFEAF::1/10 were an invalid link-local address, whereas it is. 116 The better illustration of an IPv6 link-local address is: 118 | leftmost | Subnet ID and Interface ID 119 | 10 bits | 118 bits | 120 +----------+------------------------------------------------------+ 121 |1111111010+ Bits that MAY be either 0 or 1 | 122 +----------+------------------------------------------------------+ 124 Figure 2: The IPv6 link-local address, better illustration 126 Examples: fe80::1/10, fe80:1::1/32, fe80::1:1/64 are all IPv6 link- 127 local addresses; their prefix lengths are 10, 32 and 64 respectively. 128 Also, 0xfeaf::1/10, 0xfebf:1::1/82 are also valid IPv6 link-local 129 addresses (remark no 'fe80'). Each such IPv6 address has the 130 leftmost 10 bits equal to binary 1111111010. 132 A notation difficulty: the number binary 1111111010 can not be 133 written in hexadecimal without specifying the number of significant 134 bits (fe80::/10); yet that does not make it a 'prefix'. Converting 135 1111111010 to hexadecimal leads to 3FA (because in a left-to-right 136 writing system the leading 0s before comma are irrelevant); yet '3FA' 137 is not commonly known to be the leading bits of an IPv6 link-local 138 address, fe80::/10 is. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 prefix: a contiguous string of bits valid for forwarding operations 147 and for subnet formation. A prefix, in general, MUST have an integer 148 length value from 1 to 127 (except when the prefix length is for 149 default route, in which case the value is 0) and a prefix length must 150 be indicated in its textual representation (e.g. 2001:db8::/32 is the 151 prefix and 32 is the prefix length). 153 textual representation of a prefix: e.g. fe80::/64. 155 n leading bits: the first n bits in a string of bits read from left 156 to right in a writing system that is read left-to-right. E.g. the 10 157 leading bits of the fe80::/64 textual representation of the IPv6 158 link-local prefix are 1111111010. 160 3. Justification 162 One justification is the following: in a managed network the 163 administrator configures link-local addresses with the 54 bits set. 164 The network runs dynamic routing protocols OSPF, ISIS and EIGRP. The 165 adjacency must work in a mixed vendor environment. 167 4. Problem Statement 169 IPv6 link-local addresses are typically self-configured according to 170 4 RFCs and relying on the fe80::/10 IANA allocation, RFC4291 54 0 171 bits, and RFC2464 MAC-based 64bit Interface IDs. 173 In some cases, it is advantageous to manually configure link-local 174 addresses. Manual configuration is useful for easy remembering by 175 humans, and for parameter resilience during network interface 176 replacement (set addresses in computer startup configuration files). 177 Further, the manual configuration of addresses can be scripted by 178 automated software for rapid prototyping; still, this automated 179 formation of addresses is not the 'self-configuration' described in 180 the 4 RFCs mentioned previously. 182 A self-configured link-local address according to the 4 RFCs is of 183 the form fe80::64bitIID; an example of such address is 184 fe80::dabc:fe13:5246:7109. This address is difficult to remember for 185 humans because each of the 16 hex characters appears, and the 186 appearance is disordered. Not only it is difficult to remember but 187 it takes long to type. This is a problem on small screens and mouse- 188 less keyboards. An easy to remember and type link-local address is, 189 for example, fe80:1::1. 191 Manual configuration of an LL address may use short IID and Subnet 192 ID. The Subnet ID presence in the link-local address is useful in 193 some wireless settings where the subnet structure parameters depend 194 on the link locality. Other settings may also benefit. 196 When manually setting the link-local address it is necessary to know 197 the length of the prefix of the subnet on which this link-local 198 address is present. This length is necessary for on-link 199 determination. 201 The problem is: manually setting a prefix length other than 64 to 202 link-local addresses may provoke glitches. 204 5. Kinds of Solutions 206 Some solutions to the problem are: use an address of the form 207 fe80:1::2/32, or use an address of the form fe80::1:2/64, where 1 is 208 the Subnet ID and 2 is the Interface ID. Other solutions involve a 209 hidden 'scope_id' and the use of special syntax ('%') to denote an 210 interface. Each of these solutions have other problems of their own: 211 set some of the 54 mandatorily reset bits of RFC4291, not 212 implementable on some OS; invade the IID with a Subnet ID, and 213 potentially others. 215 Invading the IID with a Subnet ID happens in the following situation: 216 if fe80::1:2 assumes fe80::/64 as prefix length, then it is 217 impossible for '1' to be a Subnet ID. A Subnet ID must be covered by 218 a prefix length, otherwise routing and on-link determination dont 219 work. One cant have fe80::/64 as prefix, and '1' as prefix, and a 220 64bit ::1:2 Interface ID. 222 The 'scope_id' is 'hidden' in some operating systems; this hide is 223 known by noticing that the use of 'scope_id' is not mandatory for LL 224 addresses; instead of using 'scope_id' it is possible to rely on the 225 interface name. Some ifconfig commands on some OSs rely on the 226 interface name and dont require the use of a 'scope_id' (%) 227 parameter. It is the case for linux and Windows. 229 In practice, the use of fe80::1:2 was tried. It used the 64bit 230 prefix length. But it does not perform on-link determination 231 meanigfully (the '1' is part of IID, not of Subnet ID). 233 Another solution is: use Unique Local Addresses RFC 4193. For 234 example: Car1-front interface uses fc00:1::1, Car1-rear fc00:1::2, 235 Car2-front fc00:2::1. A pseudo random number would rather be 236 generated for Global ID, when in production. A kind of solution 237 involving ULAs has interesting properties, yet the ULA-addressed 238 packets may be forwarded across subnets. This forwarding may be an 239 inconvenient in some setting. The use of other than LL addresses, 240 i.e. GUAs or ULAs; this has some advantages and some inconvenients 241 (cant put LL in src of RA). 243 Other solutions involve the use of an 'fe80' prefix in the RA such 244 that to configure link-local prefixes by a similar means than GUAs/ 245 ULAs. This also has advantages and drawbacks. 247 Another solution is: use DNS to hold long interface IDs and Subnet 248 IDs. Such solutions recommend the use of name-to-address mapping, 249 instead of easy to remember LLs; DNS is such tool; can be used in 250 order to facilitate the remembering by humans. However, this has 251 some advantages and some inconvenients (e.g. needs DNS-SD, mDNS and 252 IP multicast routing for multi-subnets; chicken-and-egg between 253 formation of LLs needing these DNS tools to work in the first place). 254 A particular inconvenient is the movement of the problem instead of 255 solving it: upon interface change (replace faulty interface with a 256 new one) one has configure the DNS configuration files with a new 257 pair name-address, instead of needing to configure startup scripts. 259 6. Context of Documents 261 draft-bourbaki-6man-classless-ipv6-05 describes the motivation of 262 considering IPv6 to be classless. It gives a little bit of history 263 of why it is how it is. It proposes the rigid 64 IID length to be 264 probably the last remnant of the boundary. 266 draft-farmer-6man-routing-64-02 describes the relationship between 267 routing and the 64-bit boundary; mainly GUA, no LL; t is ambiguous in 268 its recommendation. 270 draft-farmer-6man-exceptions-64-09 describes the exceptions to the 271 standard subnet boundary in IPv6 addressing; mainly about GUA, not 272 about LL; the exceptions are: GUA with the first 3 bits 0, manually 273 config'ed addresses, DHCPv6 assigned addresses, ND on-link 274 determination, IPv6-over-foo. 276 A memo describes the use of IPv6 link-local addresses in 277 applications. The filename of the Internet Draft is draft-smith- 278 ipv6-link-locals-apps-00. 280 RFC7404 describes "Using Only Link-Local Addressing inside an IPv6 281 Network". 283 The RFC "IPv6 Address Archi" illustrates the format of the link-local 284 addresses. From the illustration it MAY be understood that the 285 length of the link-local prefix is 10 bits of value 1111111010 and 54 286 0 bits. 288 IANA lists the "IPv6 prefix", and "Address Block", to be "fe80::/10" 289 on its website. It is possible that in the future the IETF could 290 decide to use the bits 11-53. 292 The RFC 2464 "IPv6-over-Ethernet" states that the prefix for link- 293 local addresses is "fe80::/64". 295 RFC 6874, "Representing IPv6 Zone Identifiers in Address Literals and 296 Uniform Resource Identifiers" specifies the link-local addresses to 297 be under prefix "fe80::/10". 299 RFC 8415 "DHCPv6" considers that link-local addresses are designated 300 by the prefix fe80::/10. 302 RFC 4007 "IPv6 Scoped Address Architecture" discusses Zone ID. A 303 Zone ID may be used - internally - in the 54bits of a link-local 304 address, even though these 54bits appear to be reset. The document 305 mentions at a point that fe80::1 could be used in two separate 306 physical links (not virtual, like the loopback). 308 RFC4291 requires that an IPv6 link-local address be assigned on each 309 interface. Yet, it does not require the link-local prefix to be 310 associated to an interface. 312 RFC4861 requires that the link local prefix be present in the Prefix 313 List associated with an interface, although it does not specify the 314 length of the link local prefix. 316 RFC4862 "SLAAC" defines how GUAs and LLs self-configure. Whereas the 317 GUA gets its prefix length from the RA (not from an RFC), the LL gets 318 it from RFC4291 (not from RA). They are independent choices based on 319 distinct sources. 321 Several knowledgeable interpretations state that, generally speaking, 322 the prefix length of link-local addresses is 10, but it is 64 in the 323 particular case of Stateless Address-Autoconfiguration (SLAAC). In 324 this latter case, the prefix is named a "subnet prefix", or "prefix 325 on a link", and it is "fe80::/64". 327 The term "link-local prefix" is sometimes used to mean the prefix for 328 on-link determination, and is sometimes used to mean the reserved 329 address space for link-local addresses (including all current and 330 future use). The latter is fe80::/10. Of which the address 331 architecture spec only gives the addresses that match fe80::/64 the 332 standard format (by specifying intermediate 54 bits are all 0). As a 333 result the former is (currently) only fe80::/64. 335 For people in the RIR world it's a common thing: you get a prefix 336 from the RIR and then make assignments from it for specific purposes. 337 You can route the aggregate allocation, but you're not allowed to use 338 the unassigned parts (until you make an assignment). In this case 339 fe80::/10 is the allocation and fe80::/64 is the assignment. 341 7. Context of OS Behaviour 343 Interpretations of the situation of linux working ok with fe80:1::1 344 call it a violation of standards. 346 Independent testing shows that 'ifconfig add fe80:1::1' works on 347 linux but fails on openbsd. 349 A command to assign fe80:1::1 on a Cisco router works ok. 351 On Cisco platforms IOS, XE ver 16.x, XR and NXOS it is possible to 352 populate the entire set of 54 bits with one's (instead of the 0s 353 requested by RFC 4291). A test was performed between such Cisco 354 routers running OSPF. The OSPF neighbors were still coming up. The 355 error that was expected (and that did not happen) was that some 356 glitches may appear due to the lack of textual compression of 54bits 357 into '::'. However, there is a caveat: it is unknown what might 358 happen with OSPF in a mixed environment, where not only Cisco is 359 used. 361 The address fe80::1/128 is present on the loopback interface of BSD. 363 Implementations of an IPv6 stack in a particular operating system 364 (linux) allow for the manual configuration of both prefix lengths 64 365 and 10 for link-local addresses. 367 In another operating system the prefix length for link-local 368 addresses can not be explicitely specified by the end user, but may 369 be indirectly derived from two distinct textual formats by using an 370 unspecified rule. 372 In yet another operating system (FreeBSD) an end user can not use a 373 link-local address whose value is fe80:1::1; because in that OS the 374 hosts drop incoming packets whose source or destination address 375 matches fe80::/10 and contains a non-0 value in bits 15-31 (like 376 fe80:1::1 does). The URL of the C code in OpenBSD that leads to make 377 that packet drop is 378 https://github.com/openbsd/src/blob/master/sys/netinet6/ip6_input.c 379 In a particular operating system (openbsd), it is possible to run 380 SLAAC with Interface IDentifiers of length different than 64, e.g. 381 100; this implements RFC7217. In that same operating system it is 382 not possible to use an Interface Identifier of length 100. At the 383 same time, in another operating system (linux) it is possible to use 384 Interface IDentifiers of length 100, yet SLAAC does not work with IID 385 that is not 64. In an ideal linux-bsd operating system any length of 386 IID would be possible. 388 On Windows 10 Operating System it is accepted to set fe80:1::1/32 389 address on a physical network interface, by using the Graphical User 390 Interface. 392 On MAC OS Operating System it is not possible to set fe80:1::1/32 in 393 the command line; the 'ifconfig en1 fe80:1::1/32' command reports 394 'bad value'. It also reports 'bad value' with just 'fe80:1::1' 395 (remark - no prefix length specified; note that on linux OS, when the 396 user does not specify the prefix length to an ifconfig command, the 397 OS will make a prefix length of value 128, and the ifconfig command 398 will succeed.) 400 The loopback interface is required to have a link-local address too 401 (RFC4291), although some OSs dont (linux). The RFC4007 clarifies 402 that, somehow. 404 Misconfigurations and lack of interoperability MAY arise between 405 computers that use mixed prefix lengths for link-local addresses. 407 8. Historical Note 409 Historical note: earlier, the link-local prefix fe80::/10 and site- 410 local prefix fec0::/10 were grouped into a common fe80::/9. If bits 411 10-64 were 0 then the prefix was a link-local, otherwise a site- 412 local. The site-local addresses were later deprecated by RFC 3879. 414 9. Example of use of LL Prefix Length 32 416 This figure shows two routers each with two interfaces; one such 417 interface is connected to the other router; there are two interfaces 418 that point elsewhere. 420 i1 ------- i2 i3-------i4 421 --|Router1|---------|Router2|--- 422 ------- ------- 424 i2 address is fe80:12::1:1/32 ('12' means subnet between R1 and R2, 425 '1' is R1, 2nd '1' is 'front' interface) 426 i3 address is fe80:12::2:2/32 428 Figure 3: Figure 430 One router's interface (connected to the other router) uses address 431 fe80:12::1:1/32 and the other router's corresponding interface uses 432 address fe80:12::2:2/32. 434 10. Use-Cases 436 10.1. Use-Case Convoy 438 The topology in a linear convoy of cars, in V2V manner is like this: 440 car1 car2 car3 441 --------- --------- --------- 442 | IP-OBU1 | ---subnet1 ---- | IP-OBU2 | --- subnet2--- | IP-OBU3 | 443 --------- --------- --------- 444 |in-car | | 445 |subnets: Ethernet, WiFi, CAN, BT, etc 447 (subnet1 is on 5880 MHz, subnet2 is on 5890 MHz) 449 (in the triangular convoy the figure is different) 451 Figure 4: Figure 453 Details about the restrictions with the current LL definition in the 454 above topology: 456 In the above topology the restrictions with RFC4291 definitions, and 457 the FreeBSD implementations are the following: 459 - RFC4291 needs 64bit MAC-based IIDs on the LLs on subnet1 and subnet2. 460 The inconvenients of these restrictions are the following: 461 - 64bit IIDs are too long to remember and type; easy to remember 462 addresses are good for network debugging. 463 - MAC-based IIDs may have some privacy risk; attackers on the road 464 may listen to these IIDs (they are sent outside the car) and make 465 associations that may help tracking users, like web cookies do. 466 - RFC 4291 54 0 bits make it impossible to assign subnet-specific 467 link-local addresses to subnet1 and subnet2. 468 A RFC4291-compliant link-local address, like fe80::IID/64, assigned 469 to 470 an interface on subnet2, and replying from a ping from subnet1, does 471 not give ensurance that subnets (on 5880 MHz or on 5890 MHz) are set 472 up wrongly. It may be that the channels are set wrong (subnets are 473 set up wrongly) as much as it may be that that fe80::IID/64 is in 474 the 475 same subnet as the pinger and the channels are right. 477 On another hand, if the LL addresses were like 478 fe80:1::X on subnet1 and fe80:2::Y on subnet 2, then a ping issued 479 from subnet1 to fe80:2::X and replying OK means clearly that the 480 channels are set wrongly. 482 RFC4291 54 0 bits prevent this use of subnet-specific LL addresses. 484 - FreeBSD OS: 485 - forbids the manual assignment of LL addresses on interfaces (it is 486 impossible to ifconfig add fe80::2 on an interface). 487 - FreeBSD OS does not implement OCB mode. OCB mode is an 488 essential kind of link in vehicular communications. 490 Figure 5: Restrictions 492 Expected improvements: 494 - human users type short LL addresses, like fe80:1::1 instead of long 495 to type addresses like fe80::IID64bit 497 - use fe80:1::1 and fe80:2::1 in two distinct subnets; if a ping from 498 fe80:1::1 to fe80:1::2 that does not reply means the channels are 499 wrong; otherwise (with fe80::IID) it is impossible to say whether the 500 channels are wrong or that wrong address was used to ping (all 501 fe80::IID64bit) look the same to a human - they are 'random'). 503 - BSD allowing manual configuration of LL addresses may have other 504 benefits outside the OCB context 506 Figure 6: Improvements 508 10.2. Intuitive Next-Hop 510 In some IP networks only link-local addresses are used as next hops, 511 as described in RFC 7404. The next hop is part of an entry in the 512 routing table. Make the next hop intuitive. The next hop is 513 routinely used by sysadmin to ping and check whether it is reachable. 514 Making the next hop intuitive can be achieved by mapping the global 515 unicast address into both the subnet and interface id fields; in the 516 past, experience shown that substituting just 'fe80' for the first 16 517 bytes of a GUA (such that to transform a GUA into an LL, to be used 518 as next hop) ended up bleeding into the 54 0 bits required by RFC 519 4291. 521 11. Security Considerations 523 The clarification of the definition of the prefix length of the IPv6 524 link-local prefix at IANA is: call it 'leading bits' and not 525 'prefix', or state that the IPv6 prefix length of link-local 526 addresses is 10 decimal. This clarification has beneficial impact in 527 the algorithm implementation for calculation of the opaque and stable 528 Interface Identifiers for IPv6 link-local addresses. It also 529 positively impacts some implementations of IPv6 forwarding. 531 A prefix length of value 65 would lead to an Interface ID length of 532 value 63; a 63 bit IID would provide less privacy protection than a 533 64 bit IID, but more than a 62 bit IID. A prefix length of value 127 534 would lead to a 1 bit IID which would provide almost no privacy 535 protection. 537 12. IANA Considerations 539 IANA is requested to change the name of the column head in the table 540 that depicts the "Internet Protocol Version 6 Address Space". The 541 name should be "The n leading bits of an address" instead of "IPv6 542 Prefix". 544 The desired effect of this change is that the IPv6 link-local prefix 545 be "fe80::/n" and that the 10 leading bits of this prefix be 546 1111111010. A second effect would be that the textual representation 547 "fe80::/10" as an IPv6 link-local prefix would disappear from that 548 IANA page. 550 13. Contributors 552 Listed from 6man WG discussion. 554 14. Acknowledgements 556 The following persons are acknowledged for the discussion that is 557 reflected in this draft. Not all points are reflected. Some points 558 are copied almost entirely. 560 Ole Troan, Scott Timothy Morizot, Brian Carpenter, Fred Baker, Mark 561 Smith, Peter Occil, Philip Homburg, Albert Manfredi, _–3/4 562 ’BAE (TATUYA Jinmei), Fernando Gont, Christian Huitema, 563 Simon Hobson, Matthew Petach, Yucel Guven, Sander Steffann, Dennis 564 Ferguson, Musa Stephen Honlue, Fred Templin, Gyan Mishra, Yu 565 Tianpeng, Darren Dukes, Dusan Mudric. 567 Peter Paluch submitted the Erratum suggestion to RFC 4291 about link- 568 local addresses, and Brian Haberman rejected it, by noting 'would 569 need' a draft. Igor Lubashev pointed to that Erratum. 571 15. Normative References 573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 574 Requirement Levels", BCP 14, RFC 2119, 575 DOI 10.17487/RFC2119, March 1997, 576 . 578 Appendix A. ChangeLog 580 The changes are listed in reverse chronological order, most recent 581 changes appearing at the top of the list. 583 -21: clarified that the prefix length ranges from 1 to 127 - in 584 general (in other cases than link local prefix). 586 -20: added brief explanation of IID len and privacy; added more 587 examples of valid IPv6 link-local addresses; added an explanation of 588 why the RFC 4291 figure of a link local address has errors. 590 -19: updated authorship. 592 -18: updated an author address; added a justification about the 593 support of 54 set bits in LL addresses in a mixed vendor environment; 594 added an illustration of the RFC4291 link-local address. 596 -17: added a new use-case for sysadmins in need of an intuitive LL 597 address (to check with ping) used for next-hop of routing protocols. 599 -16: added a description of the behaviour of ifconfig fe80:1::1/32 on 600 MAC and Windows 10 Operating Systems; added a suggestion about the 601 use of ULA prefixes instead of LL prefixes; added a reference to an 602 RFC 7404 about the use of only LL addresses in an IPv6 network; 603 explained the result from practice of the use of 'fe80::1:2/64'; 604 explained why the text says 'hidden' for '%' on some OSs; mentioned 605 the DNS kind of solutions; added explanation of manual configuration 606 and automation; added exaplanation of an example of complex to 607 remember and type link-local addresses; added explanation of why DNS 608 solution is a problem mouvement, not problem resolution. 610 -15: added references to draft-farmer-6man-exceptions-64-09 and 611 draft-farmer-6man-routing-64-02, and interpreted them; added 612 explanations of the solutions mentioned in WG discussion; added a 613 use-case of car convoy with details about current restrictions of LL 614 addressing and how a variable len plen for LL can improve the 615 situation. 617 -14: updated authorship. 619 -13: added a Problem Statement section; added the name of the 620 Organisation of one co-author; distinguished between 'need' and 621 'would need' a draft. 623 -12: the '64' in GUA vs '64' in LL issued by distinct sources: RA vs 624 RFC4291 respectively; the address fe80::1/128 is present on the 625 loopback interface of BSD; detailed, again, the distinction for 'on- 626 link' determination; detailed, again, the distinction between 627 'assignment' and 'allocation'; added the fact that Cisco supports 628 manual assignment of fe80:1::1. 630 -11: trying the attribute updates=RFC4291,RFC4007 in the rfc tag. 632 -10: syntax error corrected; more explanation about how FreeBSD C 633 code blocks fe80:1::1; clarification in IANA section, but doubtful. 635 -09: added a reference to RFC 4007 about Zone ID in LL; added a 636 reference to draft-bourbaki about IPv6 being classless; added the 637 result of independent testing showing ifconfig add fe80:1::1 works on 638 linux but fails on BSD; added URL to C code in BSD flavor that may be 639 in charge of dropping packets whose src/dst is an LL like fe80:1::1; 640 added two co-authors. 642 -08: added explanation of which RFC requires the LL address to be 643 present, and which requires the LL prefix to be present; named the 644 OSs, instead of staying generic; explained that the lack of 645 requirement of ll address on lo in RFC4291 is covered by another 646 RFC4007; explained that openbsd allows variable len IID for GUAs but 647 not for LLs, yet linux allows the reverse, and concluded on an 648 obvious ideal. 650 -07: added the fact that DHCPv6 spec considers the link-local 651 addresses to be fe80::/10; added a valuable explanation of ll 652 behaviour of a particularly important OS. 654 -04: added an example advantage of using prefix length 32. 656 -03: 658 -02: corrected a typo in "fe80::/1" and added a 7-bit encoding for 659 one persons name (in addition to the japanese-shift-jis encoding 660 which is not understood by xml2rfc.) 662 Authors' Addresses 664 Alexandre Petrescu 665 CEA, LIST 666 CEA Saclay 667 Gif-sur-Yvette , Ile-de-France 91190 668 France 670 Phone: +33169089223 671 Email: Alexandre.Petrescu@cea.fr 673 Loganaden Velvindron 674 Cyberstorm.mu 675 street 676 city , region code 677 Mauritius 679 Phone: +phonenumber 680 Email: loganaden@gmail.com 681 Naveen Kottapalli 682 Benu Networks 683 street 684 City , Region code 685 United States 687 Phone: +phonenumber 688 Email: naveen.sarma@gmail.com 690 Gyan S. Mishra 691 Verizon Communications Inc. (VZ) 692 13101 Columbia Pike FDC1 Rm 304-D 693 Silver Spring MD 20904 694 United States 696 Phone: 301 502-1347 697 Email: gyan.s.mishra@verizon.com 699 Dusan Mudric 700 Avaya 702 Email: dmudric@avaya.com