idnits 2.17.1 draft-petrescu-6man-ll-prefix-len-08.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 17, 2019) is 1836 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 (~~), 1 warning (==), 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 Intended status: Standards Track April 17, 2019 5 Expires: October 19, 2019 7 The length of the prefix of an IPv6 link-local address ranges from 10 to 8 127 9 draft-petrescu-6man-ll-prefix-len-08 11 Abstract 13 A rejected Errata to RFC4291 "IPv6 Addr Archi" on the topic of link- 14 local addresses 'needs' a draft. This is an answer to that need. 16 The length of the prefix of an IPv6 link-local address is variable. 17 The minimal value is 10 decimal. The maximum value is 127 decimal. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 19, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Definitions and Statements . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Example of use of LL Prefix Length 32 . . . . . . . . . . . . 5 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 61 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 62 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Definitions and Statements 67 The prefix of an IP address is formed by the n leftmost bits of the 68 address. (in a left-to-right writing system). 70 The prefix of an IP address is used for goals such as: identify the 71 type of an IPv6 address (link-local, global, others), identify the 72 belonging of an IP address to a particular subnetwork, assist the 73 forwarding (or not forwarding) decisions, and others. 75 The minimal length of the prefix of an IPv6 link-local address (the 76 value of n) is equal to 10 decimal. The maximum is 127. 78 The prefix of an IPv6 link-local address is represented textually as 79 "fe80::/n", where n MAY be any value between 10 and 127. 81 Regardless of the prefix length, the leftmost 10 bits of an IPv6 82 link-local address MUST be set to binary 1111111010 (hexadecimal 83 fe80). 85 The illustration of an IPv6 link-local address is: 87 | leftmost | Subnet ID and Interface ID 88 | 10 bits | 118 bits | 89 +----------+------------------------------------------------------+ 90 |1111111010+ Bits that MAY be either 0 or 1 | 91 +----------+------------------------------------------------------+ 93 Figure 1: The IPv6 link-local address 95 Examples: fe80::1/10, fe80:1::1/32 and fe80::1:1/64 are all IPv6 96 link-local addresses; their prefix lengths are 10, 32 and 64 97 respectively. Each such IPv6 address has the leftmost 10 bits equal 98 to binary 1111111010. 100 The Difficulty: the number binary 1111111010 can not be written in 101 hexadecimal without specifying the number of significant bits 102 (fe80::/10); yet that does not make it a 'prefix'. Converting 103 1111111010 to hexadecimal leads to 3FA (because in a left-to-right 104 writing system the leading 0s before comma are irrelevant); yet '3FA' 105 is not commonly known to be the leading bits of an IPv6 link-local 106 address, fe80::/10 is. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 prefix: a contiguous string of bits valid for forwarding operations 115 and for subnet formation. A prefix MUST have an integer length value 116 from 1 to 127 (except when the prefix length is for default route, in 117 which case the value is 0) and a prefix length must be indicated in 118 its textual representation (e.g. 2001:db8::/32 is the prefix and 32 119 is the prefix length). 121 textual representation of a prefix: e.g. fe80::/64. 123 n leading bits: the first n bits in a string of bits read from left 124 to right in a writing system that is read left-to-right. E.g. the 10 125 leading bits of the fe80::/64 textual representation of the IPv6 126 link-local prefix are 1111111010. 128 3. Context 130 The RFC "IPv6 Address Archi" illustrates the format of the link-local 131 addresses. From the illustration it MAY be understood that the 132 length of the link-local prefix is 10 bits of value 1111111010 and 54 133 0 bits. 135 IANA lists the "IPv6 prefix", and "Address Block", to be "fe80::/10" 136 on its website. It is possible that in the future the IETF could 137 decide to use the bits 11-53. 139 The RFC 2464 "IPv6-over-Ethernet" states that the prefix for link- 140 local addresses is "fe80::/64". 142 RFC 6874, "Representing IPv6 Zone Identifiers in Address Literals and 143 Uniform Resource Identifiers" specifies the link-local addresses to 144 be under prefix "fe80::/10". 146 RFC 8415 "DHCPv6" considers link-local addresses are indicated by the 147 prefix fe80::/10. 149 RFC4291 requires that an IPv6 link-local address be assigned on each 150 interface. Yet, it does not require the link-local prefix to be 151 associated to an interface. 153 RFC4861 requires that the link local prefix be present in the Prefix 154 List associated with an interface, although it does not specify the 155 length of the link local prefix. 157 Several knowledgeable interpretations state that, generally speaking, 158 the prefix length of link-local addresses is 10, but it is 64 in the 159 particular case of Stateless Address-Autoconfiguration (SLAAC). In 160 this latter case, the prefix is named a "subnet prefix", or "prefix 161 on a link", and it is "fe80::/64". 163 Implementations of an IPv6 stack in a particular operating system 164 (linux) allow for the manual configuration of both prefix lengths 64 165 and 10 for link-local addresses. 167 In another operating system the prefix length for link-local 168 addresses can not be explicitely specified by the end user, but may 169 be indirectly derived from two distinct textual formats by using an 170 unspecified rule. 172 In yet another operating system (BSD) an end user can not use a link- 173 local address whose value is fe80:1::1; because in that OS the hosts 174 drop incoming packets whose or destination address matches fe80::/10 175 and contains a non-0 value in bits 15-31 (like fe80:1::1 does). 177 In a particular operating system (openbsd), it is possible to run 178 SLAAC with Interface IDentifiers of length different than 64, e.g. 179 100; this implements RFC7217. In that same operating system it is 180 not possible to use an Interface Identifier of length 100. At the 181 same time, in another operating system (linux) it is possible to use 182 Interface IDentifiers of length 100, yet SLAAC does not work with IID 183 that is not 64. In an ideal linux-bsd operating system any length of 184 IID would be possible. 186 The loopback interface is required to have a link-local address too 187 (RFC4291), although some OSs dont (linux). The RFC4007 clarifies 188 that, somehow. 190 Misconfigurations and lack of interoperability MAY arise between 191 computers that use mixed prefix lengths for link-local addresses. 193 A memo describes the use of IPv6 link-local addresses in 194 applications. The filename of the Internet Draft is draft-smith- 195 ipv6-link-locals-apps-00. 197 Historical note: earlier, the link-local prefix fe80::/10 and site- 198 local prefix fec0::/10 were grouped into a common fe80::/9. If bits 199 10-64 were 0 then the prefix was a link-local, otherwise a site- 200 local. The site-local addresses were later deprecated by RFC 3879. 202 4. Example of use of LL Prefix Length 32 204 This figure shows two routers each with two interfaces; one such 205 interface is connected to the other router; there are two interfaces 206 that point elsewhere. 208 i1 ------- i2 i3-------i4 209 --|Router1|---------|Router2|--- 210 ------- ------- 212 i2 address is fe80:12::1:1/32 ('12' means subnet between R1 and R2, 213 '1' is R1, 2nd '1' is 'front' interface) 214 i3 address is fe80:12::2:2/32 216 Figure 2: Figure 218 One router's interface (connected to the other router) uses address 219 fe80:12::1:1/32 and the other router's corresponding interface uses 220 address fe80:12::2:2/32. 222 5. Security Considerations 224 The clarification of the definition of the prefix length of the IPv6 225 link-local prefix at IANA is: call it 'leading bits' and not 226 'prefix', or state that the IPv6 prefix length of link-local 227 addresses is 10 decimal. This clarification has beneficial impact in 228 the algorithm implementation for calculation of the opaque and stable 229 Interface Identifiers for IPv6 link-local addresses. It also 230 positively impacts some implementations of IPv6 forwarding. 232 6. IANA Considerations 234 IANA is requested to change the name of the column head in the table 235 that depicts the "Internet Protocol Version 6 Address Space". The 236 name should be "The n leading bits of an address" instead of "IPv6 237 Prefix". 239 The desired effect of this change is that the IPv6 link-local prefix 240 be "fe80::/n" and that the 10 leading bits of this prefix be 241 1111111010. A second effect is that the textual representation 242 "fe80::/10" as an IPv6 link-local prefix should disappear from that 243 IANA page, because it is wrong. 245 7. Contributors 247 Listed from 6man WG discussion. 249 8. Acknowledgements 251 The following persons are acknowledged for the discussion that is 252 reflected in this draft. Not all points are reflected. Some points 253 are copied almost entirely. 255 Ole Troan, Scott Timothy Morizot, Brian Carpenter, Fred Baker, Mark 256 Smith, Peter Occil, Philip Homburg, Albert Manfredi, _–3/4 257 ’BAE (TATUYA Jinmei), Fernando Gont, Christian Huitema, 258 Simon Hobson, Matthew Petach, Yucel Guven, Sander Steffann, Dennis 259 Ferguson, Musa Stephen Honlue, Fred Templin. 261 Peter Paluch submitted the Errata suggestion to RFC 4291 about link- 262 local addresses, and Brian Haberman rejected it, by requiring a 263 draft. Igor Lubashev pointed to that Errata. 265 9. Normative References 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, 269 DOI 10.17487/RFC2119, March 1997, 270 . 272 Appendix A. ChangeLog 274 The changes are listed in reverse chronological order, most recent 275 changes appearing at the top of the list. 277 -08: added explanation of which RFC requires the LL address to be 278 present, and which requires the LL prefix to be present; named the 279 OSs, instead of staying generic; explained that the lack of 280 requirement of ll address on lo in RFC4291 is covered by another 281 RFC4007; explained that openbsd allows variable len IID for GUAs but 282 not for LLs, yet linux allows the reverse, and concluded on an 283 obvious ideal. 285 -07: added the fact that DHCPv6 spec considers the link-local 286 addresses to be fe80::/10; added a valuable explanation of ll 287 behaviour of a particularly important OS. 289 -04: added an example advantage of using prefix length 32. 291 -03: 293 -02: corrected a typo in "fe80::/1" and added a 7-bit encoding for 294 one persons name (in addition to the japanese-shift-jis encoding 295 which is not understood by xml2rfc.) 297 Author's Address 299 Alexandre Petrescu 300 CEA, LIST 301 CEA Saclay 302 Gif-sur-Yvette , Ile-de-France 91190 303 France 305 Phone: +33169089223 306 Email: Alexandre.Petrescu@cea.fr