CEA, LIST

CEA Saclay Gif-sur-Yvette Ile-de-France 91190 France +33169089223 Alexandre.Petrescu@cea.fr

Cyberstorm.mu

street city region code Mauritius +phonenumber loganaden@gmail.com

Benu Networks

street City Region code United States +phonenumber naveen.sarma@gmail.com

Verizon Communications

street City Region code United States cell 202 734-1000 hayabusagsm@gmail.com

Internet 6MAN Working Group IPv6, link-local, subnet, IANA, fe80 A rejected Erratum to RFC4291 "IPv6 Addr Archi" on the topic of link-local addresses 'would need' a draft. This draft is an answer to that need. The length of the prefix of an IPv6 link-local address is variable. The minimal value is 10 decimal. The maximum value is 127 decimal.

The prefix of an IP address is formed by the n leftmost bits of the address. (in a left-to-right writing system). The prefix of an IP address is used for goals such as: identify the type of an IPv6 address (link-local, global, others), identify the belonging of an IP address to a particular subnetwork, assist the forwarding (or not forwarding) decisions, and others. The minimal length of the prefix of an IPv6 link-local address (the value of n) is equal to 10 decimal. The maximum is 127. The prefix of an IPv6 link-local address is represented textually as "fe80::/n", where n MAY be any value between 10 and 127. Regardless of the prefix length, the leftmost 10 bits of an IPv6 link-local address MUST be set to binary 1111111010 (hexadecimal fe80). The illustration of an IPv6 link-local address is:

Examples: fe80::1/10, fe80:1::1/32 and fe80::1:1/64 are all IPv6 link-local addresses; their prefix lengths are 10, 32 and 64 respectively. Each such IPv6 address has the leftmost 10 bits equal to binary 1111111010. A notation difficulty: the number binary 1111111010 can not be written in hexadecimal without specifying the number of significant bits (fe80::/10); yet that does not make it a 'prefix'. Converting 1111111010 to hexadecimal leads to 3FA (because in a left-to-right writing system the leading 0s before comma are irrelevant); yet '3FA' is not commonly known to be the leading bits of an IPv6 link-local address, fe80::/10 is.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. prefix: a contiguous string of bits valid for forwarding operations and for subnet formation. A prefix MUST have an integer length value from 1 to 127 (except when the prefix length is for default route, in which case the value is 0) and a prefix length must be indicated in its textual representation (e.g. 2001:db8::/32 is the prefix and 32 is the prefix length). textual representation of a prefix: e.g. fe80::/64. n leading bits: the first n bits in a string of bits read from left to right in a writing system that is read left-to-right. E.g. the 10 leading bits of the fe80::/64 textual representation of the IPv6 link-local prefix are 1111111010.

IPv6 link-local addresses are typically self-configured according to 4 RFCs and relying on the fe80::/10 IANA allocation, RFC4291 54 0 bits, and RFC2464 MAC-based 64bit Interface IDs. In some cases, it is advantageous to manually configure link-local addresses. Manual configuration is useful for easy remembering by humans, and for parameter resilience during network interface replacement (set addresses in computer startup configuration files). Further, the manual configuration of addresses can be scripted by automated software for rapid prototyping; still, this automated formation of addresses is not the 'self-configuration' described in the 4 RFCs mentioned previously. A self-configured link-local address according to the 4 RFCs is of the form fe80::64bitIID; an example of such address is fe80::dabc:fe13:5246:7109. This address is difficult to remember for humans because each of the 16 hex characters appears, and the appearance is disordered. Not only it is difficult to remember but it takes long to type. This is a problem on small screens and mouse-less keyboards. An easy to remember and type link-local address is, for example, fe80:1::1. Manual configuration of an LL address may use short IID and Subnet ID. The Subnet ID presence in the link-local address is useful in some wireless settings where the subnet structure parameters depend on the link locality. Other settings may also benefit. When manually setting the link-local address it is necessary to know the length of the prefix of the subnet on which this link-local address is present. This length is necessary for on-link determination. The problem is: manually setting a prefix length other than 64 to link-local addresses may provoke glitches.

Some solutions to the problem are: use an address of the form fe80:1::2/32, or use an address of the form fe80::1:2/64, where 1 is the Subnet ID and 2 is the Interface ID. Other solutions involve a hidden 'scope_id' and the use of special syntax ('%') to denote an interface. Each of these solutions have other problems of their own: set some of the 54 mandatorily reset bits of RFC4291, not implementable on some OS; invade the IID with a Subnet ID, and potentially others. Invading the IID with a Subnet ID happens in the following situation: if fe80::1:2 assumes fe80::/64 as prefix length, then it is impossible for '1' to be a Subnet ID. A Subnet ID must be covered by a prefix length, otherwise routing and on-link determination dont work. One cant have fe80::/64 as prefix, and '1' as prefix, and a 64bit ::1:2 Interface ID. The 'scope_id' is 'hidden' in some operating systems; this hide is known by noticing that the use of 'scope_id' is not mandatory for LL addresses; instead of using 'scope_id' it is possible to rely on the interface name. Some ifconfig commands on some OSs rely on the interface name and dont require the use of a 'scope_id' (%) parameter. It is the case for linux and Windows. In practice, the use of fe80::1:2 was tried. It used the 64bit prefix length. But it does not perform on-link determination meanigfully (the '1' is part of IID, not of Subnet ID). Another solution is: use Unique Local Addresses RFC 4193. For example: Car1-front interface uses fc00:1::1, Car1-rear fc00:1::2, Car2-front fc00:2::1. A pseudo random number would rather be generated for Global ID, when in production. A kind of solution involving ULAs has interesting properties, yet the ULA-addressed packets may be forwarded across subnets. This forwarding may be an inconvenient in some setting. The use of other than LL addresses, i.e. GUAs or ULAs; this has some advantages and some inconvenients (cant put LL in src of RA). Other solutions involve the use of an 'fe80' prefix in the RA such that to configure link-local prefixes by a similar means than GUAs/ULAs. This also has advantages and drawbacks. Another solution is: use DNS to hold long interface IDs and Subnet IDs. Such solutions recommend the use of name-to-address mapping, instead of easy to remember LLs; DNS is such tool; can be used in order to facilitate the remembering by humans. However, this has some advantages and some inconvenients (e.g. needs DNS-SD, mDNS and IP multicast routing for multi-subnets; chicken-and-egg between formation of LLs needing these DNS tools to work in the first place). A particular inconvenient is the movement of the problem instead of solving it: upon interface change (replace faulty interface with a new one) one has configure the DNS configuration files with a new pair name-address, instead of needing to configure startup scripts.

draft-bourbaki-6man-classless-ipv6-05 describes the motivation of considering IPv6 to be classless. It gives a little bit of history of why it is how it is. It proposes the rigid 64 IID length to be probably the last remnant of the boundary. draft-farmer-6man-routing-64-02 describes the relationship between routing and the 64-bit boundary; mainly GUA, no LL; t is ambiguous in its recommendation. draft-farmer-6man-exceptions-64-09 describes the exceptions to the standard subnet boundary in IPv6 addressing; mainly about GUA, not about LL; the exceptions are: GUA with the first 3 bits 0, manually config'ed addresses, DHCPv6 assigned addresses, ND on-link determination, IPv6-over-foo. A memo describes the use of IPv6 link-local addresses in applications. The filename of the Internet Draft is draft-smith-ipv6-link-locals-apps-00. RFC7404 describes "Using Only Link-Local Addressing inside an IPv6 Network". The RFC "IPv6 Address Archi" illustrates the format of the link-local addresses. From the illustration it MAY be understood that the length of the link-local prefix is 10 bits of value 1111111010 and 54 0 bits. IANA lists the "IPv6 prefix", and "Address Block", to be "fe80::/10" on its website. It is possible that in the future the IETF could decide to use the bits 11-53. The RFC 2464 "IPv6-over-Ethernet" states that the prefix for link-local addresses is "fe80::/64". RFC 6874, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers" specifies the link-local addresses to be under prefix "fe80::/10". RFC 8415 "DHCPv6" considers that link-local addresses are designated by the prefix fe80::/10. RFC 4007 "IPv6 Scoped Address Architecture" discusses Zone ID. A Zone ID may be used - internally - in the 54bits of a link-local address, even though these 54bits appear to be reset. The document mentions at a point that fe80::1 could be used in two separate physical links (not virtual, like the loopback). RFC4291 requires that an IPv6 link-local address be assigned on each interface. Yet, it does not require the link-local prefix to be associated to an interface. RFC4861 requires that the link local prefix be present in the Prefix List associated with an interface, although it does not specify the length of the link local prefix. RFC4862 "SLAAC" defines how GUAs and LLs self-configure. Whereas the GUA gets its prefix length from the RA (not from an RFC), the LL gets it from RFC4291 (not from RA). They are independent choices based on distinct sources. Several knowledgeable interpretations state that, generally speaking, the prefix length of link-local addresses is 10, but it is 64 in the particular case of Stateless Address-Autoconfiguration (SLAAC). In this latter case, the prefix is named a "subnet prefix", or "prefix on a link", and it is "fe80::/64". The term "link-local prefix" is sometimes used to mean the prefix for on-link determination, and is sometimes used to mean the reserved address space for link-local addresses (including all current and future use). The latter is fe80::/10. Of which the address architecture spec only gives the addresses that match fe80::/64 the standard format (by specifying intermediate 54 bits are all 0). As a result the former is (currently) only fe80::/64. For people in the RIR world it's a common thing: you get a prefix from the RIR and then make assignments from it for specific purposes. You can route the aggregate allocation, but you're not allowed to use the unassigned parts (until you make an assignment). In this case fe80::/10 is the allocation and fe80::/64 is the assignment. Independent testing shows that 'ifconfig add fe80:1::1' works on linux but fails on openbsd. The same command works on a Cisco router. Interpretations of the situation of linux working ok with fe80:1::1 call it a violation of standards. The address fe80::1/128 is present on the loopback interface of BSD. Implementations of an IPv6 stack in a particular operating system (linux) allow for the manual configuration of both prefix lengths 64 and 10 for link-local addresses. In another operating system the prefix length for link-local addresses can not be explicitely specified by the end user, but may be indirectly derived from two distinct textual formats by using an unspecified rule. In yet another operating system (FreeBSD) an end user can not use a link-local address whose value is fe80:1::1; because in that OS the hosts drop incoming packets whose source or destination address matches fe80::/10 and contains a non-0 value in bits 15-31 (like fe80:1::1 does). The URL of the C code in OpenBSD that leads to make that packet drop is https://github.com/openbsd/src/blob/master/sys/netinet6/ip6_input.c In a particular operating system (openbsd), it is possible to run SLAAC with Interface IDentifiers of length different than 64, e.g. 100; this implements RFC7217. In that same operating system it is not possible to use an Interface Identifier of length 100. At the same time, in another operating system (linux) it is possible to use Interface IDentifiers of length 100, yet SLAAC does not work with IID that is not 64. In an ideal linux-bsd operating system any length of IID would be possible. On Windows 10 Operating System it is accepted to set fe80:1::1/32 address on a physical network interface, by using the Graphical User Interface. On MAC OS Operating System it is not possible to set fe80:1::1/32 in the command line; the 'ifconfig en1 fe80:1::1/32' command reports 'bad value'. It also reports 'bad value' with just 'fe80:1::1' (remark - no prefix length specified; note that on linux OS, when the user does not specify the prefix length to an ifconfig command, the OS will make a prefix length of value 128, and the ifconfig command will succeed.) The loopback interface is required to have a link-local address too (RFC4291), although some OSs dont (linux). The RFC4007 clarifies that, somehow. Misconfigurations and lack of interoperability MAY arise between computers that use mixed prefix lengths for link-local addresses. Historical note: earlier, the link-local prefix fe80::/10 and site-local prefix fec0::/10 were grouped into a common fe80::/9. If bits 10-64 were 0 then the prefix was a link-local, otherwise a site-local. The site-local addresses were later deprecated by RFC 3879.

This figure shows two routers each with two interfaces; one such interface is connected to the other router; there are two interfaces that point elsewhere.

One router's interface (connected to the other router) uses address fe80:12::1:1/32 and the other router's corresponding interface uses address fe80:12::2:2/32.

The topology in a linear convoy of cars, in V2V manner is like this:

Details about the restrictions with the current LL definition in the above topology:

Expected improvements:

The clarification of the definition of the prefix length of the IPv6 link-local prefix at IANA is: call it 'leading bits' and not 'prefix', or state that the IPv6 prefix length of link-local addresses is 10 decimal. This clarification has beneficial impact in the algorithm implementation for calculation of the opaque and stable Interface Identifiers for IPv6 link-local addresses. It also positively impacts some implementations of IPv6 forwarding.

IANA is requested to change the name of the column head in the table that depicts the "Internet Protocol Version 6 Address Space". The name should be "The n leading bits of an address" instead of "IPv6 Prefix". The desired effect of this change is that the IPv6 link-local prefix be "fe80::/n" and that the 10 leading bits of this prefix be 1111111010. A second effect would be that the textual representation "fe80::/10" as an IPv6 link-local prefix would disappear from that IANA page.

Listed from 6man WG discussion.

The following persons are acknowledged for the discussion that is reflected in this draft. Not all points are reflected. Some points are copied almost entirely. Ole Troan, Scott Timothy Morizot, Brian Carpenter, Fred Baker, Mark Smith, Peter Occil, Philip Homburg, Albert Manfredi, �_�� �B�� (TATUYA Jinmei), Fernando Gont, Christian Huitema, Simon Hobson, Matthew Petach, Yucel Guven, Sander Steffann, Dennis Ferguson, Musa Stephen Honlue, Fred Templin, Gyan Mishra, Yu Tianpeng, Darren Dukes, Dusan Mudric. Peter Paluch submitted the Erratum suggestion to RFC 4291 about link-local addresses, and Brian Haberman rejected it, by noting 'would need' a draft. Igor Lubashev pointed to that Erratum.

The changes are listed in reverse chronological order, most recent changes appearing at the top of the list. -16: added a description of the behaviour of ifconfig fe80:1::1/32 on MAC and Windows 10 Operating Systems; added a suggestion about the use of ULA prefixes instead of LL prefixes; added a reference to an RFC 7404 about the use of only LL addresses in an IPv6 network; explained the result from practice of the use of 'fe80::1:2/64'; explained why the text says 'hidden' for '%' on some OSs; mentioned the DNS kind of solutions; added explanation of manual configuration and automation; added exaplanation of an example of complex to remember and type link-local addresses; added explanation of why DNS solution is a problem mouvement, not problem resolution. -15: added references to draft-farmer-6man-exceptions-64-09 and draft-farmer-6man-routing-64-02, and interpreted them; added explanations of the solutions mentioned in WG discussion; added a use-case of car convoy with details about current restrictions of LL addressing and how a variable len plen for LL can improve the situation. -14: updated authorship. -13: added a Problem Statement section; added the name of the Organisation of one co-author; distinguished between 'need' and 'would need' a draft. -12: the '64' in GUA vs '64' in LL issued by distinct sources: RA vs RFC4291 respectively; the address fe80::1/128 is present on the loopback interface of BSD; detailed, again, the distinction for 'on-link' determination; detailed, again, the distinction between 'assignment' and 'allocation'; added the fact that Cisco supports manual assignment of fe80:1::1. -11: trying the attribute updates=RFC4291,RFC4007 in the rfc tag. -10: syntax error corrected; more explanation about how FreeBSD C code blocks fe80:1::1; clarification in IANA section, but doubtful. -09: added a reference to RFC 4007 about Zone ID in LL; added a reference to draft-bourbaki about IPv6 being classless; added the result of independent testing showing ifconfig add fe80:1::1 works on linux but fails on BSD; added URL to C code in BSD flavor that may be in charge of dropping packets whose src/dst is an LL like fe80:1::1; added two co-authors. -08: added explanation of which RFC requires the LL address to be present, and which requires the LL prefix to be present; named the OSs, instead of staying generic; explained that the lack of requirement of ll address on lo in RFC4291 is covered by another RFC4007; explained that openbsd allows variable len IID for GUAs but not for LLs, yet linux allows the reverse, and concluded on an obvious ideal. -07: added the fact that DHCPv6 spec considers the link-local addresses to be fe80::/10; added a valuable explanation of ll behaviour of a particularly important OS. -04: added an example advantage of using prefix length 32. -03: -02: corrected a typo in "fe80::/1" and added a 7-bit encoding for one persons name (in addition to the japanese-shift-jis encoding which is not understood by xml2rfc.)