idnits 2.17.1 draft-schoen-intarea-unicast-0-00.txt: -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The draft header indicates that this document updates RFC3704, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1812, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1122, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2827, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1122, updated by this document, for RFC5378 checks: 1989-10-01) -- 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 (7 November 2021) is 900 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) == Unused Reference: 'RFC4541' is defined on line 469, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA4' ** Obsolete normative reference: RFC 3338 (Obsoleted by RFC 6535) ** Downref: Normative reference to an Informational RFC: RFC 4541 ** Downref: Normative reference to an Experimental RFC: RFC 6235 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S.D. Schoen 3 Internet-Draft J. Gilmore 4 Updates: 1122, 1812, 2827, 3704 (if approved) D. Täht 5 Intended status: Standards Track IPv4 Unicast Extensions Project 6 Expires: 11 May 2022 7 November 2021 8 Unicast Use of the Formerly Reserved 0/8 9 draft-schoen-intarea-unicast-0-00 11 Abstract 13 This document redesignates 0/8, the lowest block in the IPv4 address 14 space, so that this space is no longer reserved. It asks 15 implementers to make addresses in this range fully usable for unicast 16 use on the Internet. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 11 May 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Present situation . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Change in Status of 0/8 . . . . . . . . . . . . . . . . . . . 4 56 4.1. No Change to Interpretations of 0.0.0.0 . . . . . . . . . 4 57 5. Other Existing Uses of 0/8 . . . . . . . . . . . . . . . . . 5 58 6. Compatibility and Interoperability . . . . . . . . . . . . . 6 59 7. Unofficial uses of 0/8 . . . . . . . . . . . . . . . . . . . 8 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 11.2. Informative References . . . . . . . . . . . . . . . . . 11 66 Appendix A. Implementation Status . . . . . . . . . . . . . . . 12 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 With ever-increasing pressure to conserve IP address space on the 72 Internet, it makes sense to consider where relatively minor changes 73 can be made to fielded practice to improve numbering efficiency. One 74 such change, proposed by this document, is to allow the use of more 75 than 16 million historically reserved addresses at the bottom of the 76 IPv4 address space. 78 This document provides history and rationale to change the status of 79 the "0/8" or "zeroth" region of the IPv4 address space (historically 80 known as "unspecified network" or "this network") from reserved to 81 unreserved. These addresses are already usable for unicast traffic 82 in some popular TCP/IP implementations today. Standardization as 83 unicast addresses will eventually allow them to be later deployed by 84 Internet stewardship organizations to relieve address space scarcity. 86 1.1. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. Background 94 The early Internet reserved many kinds of IPv4 addresses for special 95 purposes. One important such designation involves every IPv4 address 96 beginning with the octet 0 (now "0/8"); all these addresses were 97 designated for use in potential device autoconfiguration features 98 that were to use ICMP messages [RFC0792]. This function was 99 eventually entirely supplanted by other protocols, which, in IPv4, 100 now use only the single address 0.0.0.0. 102 Autodiscovery of a network-provided configuration came to be handled 103 for IPv4 by DHCP [RFC2131], and formerly by its predecessors BOOTP 104 [RFC0951] and RARP [RFC0903]. In modern practice, the source address 105 of a device seeking an IPv4 configuration from the local network is 106 indicated with a link-layer broadcast in which the network-layer 107 source address 0.0.0.0 and the network-layer destination address is 108 255.255.255.255. 110 The reservation of 0/8, despite its obsolescence, has been reiterated 111 in all subsequent IPv4 address allocation RFCs and IANA documents. 112 By 1989, [RFC1122], section 3.2.2.7, for example, noted that this 113 mechanism was already obsolete, even as section 3.2.1.3 continued to 114 expressly prohibit the use of network number 0 for other purposes. 116 The single special address 0.0.0.0(/32) acquired a variety of related 117 meanings including "unspecified address", "unknown address", "address 118 not set", "address not applicable", etc., while 0.0.0.0/0 means "the 119 default route", which contains every IPv4 host. This single address 120 has remained sufficient for these purposes. 122 3. Present situation 124 Today, 0/8 addresses (except for the special address 0.0.0.0) are no 125 longer used in any autoconfiguration protocols. All of this 126 functionality is handled using other distinctly-specified mechanisms 127 and address space, both in IPv4 and IPv6. 129 The designation of 0/8 as reserved address space is tracked by IANA 130 in the IPv4 Special-Purpose Address Registry [IANA4], as provided for 131 by 6890 [RFC6890]. No known software makes use of this address space 132 in the headers of IPv4 packets transmitted over the wire. While some 133 software already treats it as a potentially valid address, the most 134 common behavior by host and router software when encountering any 135 address within 0/8 is to reject it as a Martian address. These and 136 all other known uses are discussed in the sections "Other Existing 137 Uses of 0/8" and "Compatibility and Interoperability", below. 139 Since this address space has no existing widespread practical use or 140 interpretation, it can be used for other purposes and help alleviate 141 the shortage of IPv4 addresses. This memo therefore unreserves it, 142 redesignating it as unassigned unicast addresses, available for 143 potential global unicast or other allocation. 145 4. Change in Status of 0/8 147 The purpose of this document is to make addresses in the range 0/8 148 available for active unicast use on the public Internet. This 149 includes supporting them for numbering and addressing networks and 150 hosts, like any other unicast address. 152 As an exception, the address 0.0.0.0 retains its existing special 153 meanings, as described in the subsection "No Change to 154 Interpretations of 0.0.0.0". 156 Host and router software SHOULD treat addresses in the 0/8 range, 157 except the host address 0.0.0.0, in the same way that they would 158 treat other unicast IPv4 addresses. Software SHOULD be capable of 159 accepting datagrams from, and generating datagrams to, addresses 160 within this range. 162 Clients for autoconfiguration mechanisms such as DHCP [RFC2131] 163 SHOULD accept a lease or assignment of an address within 0/8, except 164 the host address 0.0.0.0, whenever the underlying operating system is 165 capable of accepting it. 167 4.1. No Change to Interpretations of 0.0.0.0 169 The unqualified address 0.0.0.0 or the individual host address 170 0.0.0.0/32 has many special meanings which are described in a section 171 "Other Existing Uses of 0/8", below. This document does not make 172 this all-zero address an individually valid unicast address, and it 173 should still not be taken to identify an individual device. As 174 described in prior Internet standards, the address 0.0.0.0 MUST NOT 175 be assigned to an individual interface. This address is valid to 176 appear in both source and destination addresses, with special 177 meanings, in protocols already defined or to be defined in the 178 future. 180 The network identifier 0.0.0.0/0 also continues to be used to refer 181 to an IPv4 default route (a route which matches any Internet host). 182 This is not inconsistent with the use of explicit routes to 183 individual networks within 0.0.0.0/8. Existing CIDR-based routing 184 logic is readily capable of distinguishing an object like 0.0.0.0/8 185 (a route referring to a specific /8 whose leftmost octet is always 0) 186 from one like 0.0.0.0/0 (a route including to any IPv4 host); in 187 current routing practice, the default route 0.0.0.0/0 already always 188 overlaps every more-specific route, regardless of how many zero bits 189 appear at the beginning of a more-specific route's destination. 191 For avoidance of doubt, we note that all routing implementations MUST 192 permit routes to overlap, and MUST distinguish the default route 193 0.0.0.0/0 from a more-specific CIDR route such as 0.0.0.0/8 or 194 0.0.0.0/10, as well as from a leading-zero-octet route such as 195 0.1.0.0/16. These distinctions are already implied by [RFC4632], 196 section 3.1 (since neither "n" nor "x" is ever stated to be nonzero), 197 and sections 5.1 and 5.2 (describing and requiring generality in the 198 treatment of arbitrary routes, including the default route). 200 5. Other Existing Uses of 0/8 202 There are a handful of other uses of 0/8 with special meanings in 203 existing Internet protocols and standards. 205 A large number of protocols and environments use the special address 206 0.0.0.0 to mean "unspecified", "unknown", "unset", "not applicable", 207 "any address", "no address", or, as 0.0.0.0/0, the default route 208 containing every IPv4 network. (Two examples, among dozens, are 209 [RFC2131]'s use of 0.0.0.0 in DHCP packets to mean "my IP source 210 address is unknown" and [RFC4541]'s use of 0.0.0.0 to mean "proxied 211 IGMP membership report from a non-Querier".) 213 All these uses of the address 0.0.0.0 are unchanged by this memo. 214 Due to its variety of special meanings, the address 0.0.0.0 MUST NOT 215 be allocated exclusively to a specific organization or network. 216 Existing standards significantly constrain, but do not preclude, 217 circumstances in which it may appear on the wire. 219 There are three known non-unicast uses of the 0/8 block as a whole in 220 the RFC series. 222 * RFC 3338 [RFC3338] (an IPv6 transition mechanism) used 0/8 223 addresses as synthetic addresses representing surrogate IPv6 224 addresses, but this practice has already been deprecated by 225 [RFC6535], which indicated that this transition mechanism should 226 switch to RFC 1918 private addresses. 228 * RFC 7453 [RFC7453] (an MPLS-related SNMP MIB definition) overloads 229 the meaning of addresses in 0/8 by designating them as local 230 identifiers, contrasting with IPv4 addresses. Before production 231 use of 0/8 on the global Internet occurs, this MIB should be 232 updated to provide a separate field for local identifiers and to 233 deprecate the old semantics. 235 * RFC 6235 [RFC6235] and RFC 8932 [RFC8932] both provide mechanisms 236 for anonymizing network flow datasets that can map addresses into 237 0/8 in order to obscure them. Implementers SHOULD take into 238 account that source addresses in the future may already lie in 239 this range and will still require anonymization; an IPv4 address 240 SHOULD NOT be assumed to have been anonymized already merely 241 because it is within 0/8. 243 6. Compatibility and Interoperability 245 Older Internet standards counseled implementations in varying ways to 246 reject packets from, and not to generate packets to, addresses within 247 0/8. 249 Among several standards calling for this behavior, RFC 1122, section 250 3.2.1.3, and RFC 1812, section 4.2.2.11, say that hosts and routers, 251 respectively, MUST NOT send packets using these addresses, outside of 252 configuration-discovery processes. RFC 1122 implies hosts MUST 253 discard, and RFC 1812 implies routers SHOULD NOT forward, packets 254 whose source address is within 0/8. 256 RFC 3704 [RFC3704] (BCP 84) cites RFC 2827 [RFC2827] (BCP 38) in 257 asking providers to filter based on source address: 259 | RFC 2827 recommends that ISPs police their customers' traffic by 260 | dropping traffic entering their networks that is coming from a 261 | source address not legitimately in use by the customer network. 262 | The filtering includes but is in no way limited to the traffic 263 | whose source address is a so-called "Martian Address" - an address 264 | that is reserved, including any address within 0.0.0.0/8, 265 | 10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 266 | 224.0.0.0/4, or 240.0.0.0/4. 268 Other RFCs such as 3964, 4380, and 6491 have reiterated specific 269 lists of Martian ranges for other purposes, rather than referring to 270 the subsequently-created IANA Special-Purpose Address Registry. We 271 encourage future RFC authors and implementers to refer to the 272 Special-Purpose Address Registry rather than explicitly providing or 273 using a list of reserved addresses within their documentation. 275 In this context, RFC 3704 specifies filtering of these addresses as 276 source (not destination) addresses at a network ingress point as a 277 countermeasure against forged source addresses, limiting forwarded 278 packets' source addresses to only the set which have been actually 279 assigned to the customer's network. The RFC's mention of these 280 "Martian Addresses" is based on the assumption that they could never 281 be legitimately in use by the customer network. 283 Because the 0/8 address space is no longer reserved as a whole, an 284 address within this space is no longer inherently a "Martian" 285 address. Both hosts and routers MUST NOT hard-code a policy of 286 always rejecting such addresses. Hosts and routers SHOULD NOT be 287 configured to apply Martian address filtering to any packet solely on 288 the basis of its reference to a source (or destination) address in 289 0/8. Maintainers of lists of "Martian addresses" MUST NOT designate 290 addresses from this range as "Martian". As noted elsewhere, the 291 address 0.0.0.0 retains its special meaning, but is also not a 292 "Martian" address. 294 The filtering recommended by RFC 3704 is designed for border routers, 295 not for hosts. To the extent that an ISP had allocated an address 296 range from within 0/8 to its customer, RFC 3704 would already not 297 require packets with those source addresses to be filtered out by the 298 ISP's border router. 300 Since deployed implementations' willingness to accept 0/8 addresses 301 as valid unicast addresses varies, a host to which an address from 302 this range has been assigned may also have a varying ability to 303 communicate with other hosts. 305 Such a host might be inaccessible by some devices either on its local 306 network segment or elsewhere on the Internet, due to a combination of 307 host software limitations or reachability limitations in the network. 308 IPv4 unicast interoperability with 0/8 can be expected to improve 309 over time following the publication of this document. Before or 310 after allocations are eventually made within this range, 311 "debogonization" efforts for allocated ranges can improve 312 reachability to the whole address block. Similar efforts have 313 already been done by Cloudflare on 1.1.1.1 [Cloudflare], and by RIPE 314 Labs on 1/8 [RIPElabs18], 2a10::/12 [RIPElabs2a1012], and 128.0/16 315 [RIPElabs128016]. The Internet community can use network probing 316 with any of several measurement-oriented platforms to investigate how 317 usable these addresses are at any particular point in time, as well 318 as to localize medium-to-large-scale routing problems. (Examples are 319 described in [Huston], [NLNOGRing], and [Atlas].) Any network 320 operator to whom such addresses are made available by a future 321 allocation will have to examine the situation in detail to determine 322 how well its interoperability requirements will be met. 324 7. Unofficial uses of 0/8 326 Some organizations may be using portions of 0/8 internally as RFC 327 1918-type private-use address space, for example for internal 328 communications within datacenters. We currently have no publicly- 329 documented examples of this practice. However, future allocations of 330 0/8 could result in use of this space on the public Internet in ways 331 that overlap these unofficial private-use addresses, creating 332 ambiguity about whether a particular host intended to use such an 333 address to refer to a private or public network (since the address 334 would then have two distinct interpretations with different 335 addressing scopes). Among other unintended outcomes, hosts or 336 firewalls that have extended greater trust to other hosts based on 337 their use of a certain unofficial network number (that was considered 338 to imply presence on a LAN or within an organization) may eventually 339 receive legitimate traffic from an external network to which this 340 address space has been allocated. 342 Operators of networks that are making unofficial uses of portions of 343 0/8 may wish to plan to discontinue these uses and renumber their 344 internal networks, or to request that IANA formally designate certain 345 ranges as additional Private-Use areas. 347 8. IANA Considerations 349 This memo unreserves the address block 0/8. It therefore requests 350 IANA to update the IANA IPv4 Special-Purpose Address Registry [IANA4] 351 by removing the entry for 0/8, whose existing authority is RFC 791 352 [RFC0791], Section 3.2. Additionally, it requests IANA to update the 353 IANA IPv4 Address Space Registry by changing the entry for 000/8 from 354 "IANA - Local Identification, 1981-09, RESERVED" to "Unallocated, 355 Former IANA - Local Identification, [Date of this RFC], UNALLOCATED". 356 Finally, IANA is requested to prepare for this address space to be 357 addressed in the reverse DNS space in in-addr.arpa. 359 This memo does not effect a registration, transfer, allocation, or 360 authorization for use of these addresses by any specific entity. 361 This memo's scope is to require IPv4 software implementations to 362 support the ordinary unicast use of addresses in the newly 363 unallocated range 0.0.0.1 through 0.255.255.255. During a 364 significant transition period, it would only be prudent for the 365 global Internet to use those addresses for experimental purposes such 366 as de-bogonization testing. After that transition period, a 367 responsible entity such as IETF or IANA could later consider whether, 368 how and when to allocate those addresses to entities or to other 369 protocol functions. 371 9. Security Considerations 373 The change specified by this document could create a period of 374 ambiguity about historical and future interpretations of the meaning 375 of host and network addresses in 0/8. Some networks and hosts 376 currently discard all IPv4 packets bearing these addresses, pursuant 377 to statements in prior standards that packets containing these 378 addresses have no agreed-upon meaning and ought not to be sent over 379 the wire. 381 Disparate filtering processes and rules at present, and in response 382 to the adoption of this document, could make it easier for rogue 383 network operators to hijack or spoof portions of this address space 384 in order to send malicious traffic. 386 Live traffic, accepted and processed by other devices, may 387 legitimately originate from 0/8 addresses in the future. Network 388 operators, firewalls, and intrusion-detection systems may need to 389 take account of this change in various regards, including so as to 390 avoid permitting either more or less traffic from such addresses than 391 they expected. 393 Automated systems generating reports, and human beings reading those 394 reports, SHOULD NOT assume that the use of a 0/8 source address 395 indicates spoofing, an attack, or a new incompatible packet format. 396 At the same time, they SHOULD NOT assume that the use of 0/8 is 397 impossible or will be precluded by other systems' behavior. 399 Since the Linux kernel has already defaulted to the specified 400 behavior for two years (see "Implementation Status"), it is already 401 possible for deployed systems to disagree about whether packets 402 containing 0/8 may validly appear on the wire. This document offers 403 an opportunity to move to a new consensus in which implementations 404 widely agree that these packets are potentially valid, while giving 405 implementers considerable advance notice ahead of any future 406 deployment of these addresses on the public Internet. 408 10. Acknowledgements 410 This document directly builds on prior work by Dave Täht and 411 John Gilmore as part of the IPv4 Unicast Extensions Project. 412 Acknowledgements of contributions to their drafts still need to be 413 transposed here. 415 11. References 417 11.1. Normative References 419 [IANA4] Internet Assigned Numbers Authority, "IANA IPv4 Special- 420 Purpose Address Registry", 421 . 424 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 425 DOI 10.17487/RFC0791, September 1981, 426 . 428 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 429 RFC 792, DOI 10.17487/RFC0792, September 1981, 430 . 432 [RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 433 Reverse Address Resolution Protocol", STD 38, RFC 903, 434 DOI 10.17487/RFC0903, June 1984, 435 . 437 [RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, 438 DOI 10.17487/RFC0951, September 1985, 439 . 441 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 442 Communication Layers", STD 3, RFC 1122, 443 DOI 10.17487/RFC1122, October 1989, 444 . 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, 448 DOI 10.17487/RFC2119, March 1997, 449 . 451 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 452 RFC 2131, DOI 10.17487/RFC2131, March 1997, 453 . 455 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 456 Defeating Denial of Service Attacks which employ IP Source 457 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 458 May 2000, . 460 [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. 461 Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", 462 RFC 3338, DOI 10.17487/RFC3338, October 2002, 463 . 465 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 466 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 467 2004, . 469 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 470 "Considerations for Internet Group Management Protocol 471 (IGMP) and Multicast Listener Discovery (MLD) Snooping 472 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 473 . 475 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 476 (CIDR): The Internet Address Assignment and Aggregation 477 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 478 2006, . 480 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 481 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, 482 . 484 [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts 485 Using "Bump-in-the-Host" (BIH)", RFC 6535, 486 DOI 10.17487/RFC6535, February 2012, 487 . 489 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 490 "Special-Purpose IP Address Registries", BCP 153, 491 RFC 6890, DOI 10.17487/RFC6890, April 2013, 492 . 494 [RFC7453] Mahalingam, V., Sampath, K., Aldrin, S., and T. Nadeau, 495 "MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) 496 Management Information Base (MIB)", RFC 7453, 497 DOI 10.17487/RFC7453, February 2015, 498 . 500 [RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and 501 A. Mankin, "Recommendations for DNS Privacy Service 502 Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932, 503 October 2020, . 505 11.2. Informative References 507 [Atlas] RIPE Network Coordination Centre, "RIPE Atlas", 508 . 510 [Cloudflare] 511 Strong, M., "Fixing reachability to 1.1.1.1, GLOBALLY!", 4 512 April 2018, . 515 [Huston] Huston, G., "Detecting IP Address Filters", 13 January 516 2012, . 519 [NLNOGRing] 520 NLNOG RING, "10 Years of NLNOG RING", 521 . 523 [RIPElabs128016] 524 Aben, E., "The Curious Case of 128.0/16", 6 December 2011, 525 . 528 [RIPElabs18] 529 Schwarzinger, F., "Pollution in 1/8", 3 February 2010, 530 . 532 [RIPElabs2a1012] 533 Aben, E., "The Debogonisation of 2a10::/12", 17 January 534 2020, . 537 Appendix A. Implementation Status 539 The behavior specified by this document has been implemented by the 540 Linux kernel since version 5.2, released in July 2019. Accordingly, 541 it has been included in various operating system releases. 543 To our knowledge, the behavior specified by this document is not 544 currently the default in any other TCP/IP implementation. We have 545 prepared and tested a small patch to the FreeBSD kernel, and achieved 546 interoperability between a patched FreeBSD system and a released 547 Linux system when numbered with 0/8 addresses. 549 Authors' Addresses 551 Seth David Schoen 552 IPv4 Unicast Extensions Project 553 San Francisco, CA 554 United States of America 556 Email: schoen@loyalty.org 557 John Gilmore 558 IPv4 Unicast Extensions Project 559 PO Box 170640-rfc 560 San Francisco, CA 94117-0640 561 United States of America 563 Email: gnu@rfc.toad.com 565 David M. Täht 566 IPv4 Unicast Extensions Project 567 Half Moon Bay, CA 568 United States of America 570 Email: dave@taht.net