idnits 2.17.1 draft-schoen-intarea-unicast-240-02.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 6 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 RFC1122, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6890, 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 March 2022) is 774 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: 'RFC1918' is defined on line 516, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA4' ** Obsolete normative reference: RFC 870 (Obsoleted by RFC 900) -- Obsolete informational reference (is this intentional?): RFC 988 (Obsoleted by RFC 1054, RFC 1112) -- Obsolete informational reference (is this intentional?): RFC 1519 (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 9 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, 3704, 6890 (if approved) D. Täht 5 Intended status: Standards Track IPv4 Unicast Extensions Project 6 Expires: 8 September 2022 7 March 2022 8 Unicast Use of the Formerly Reserved 240/4 9 draft-schoen-intarea-unicast-240-02 11 Abstract 13 This document redesignates 240/4, the region of the IPv4 address 14 space historically known as "Experimental," "Future Use," or "Class 15 E" address space, so that this space is no longer reserved. It asks 16 implementers to make addresses in this range fully usable for unicast 17 use on the Internet. 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 8 September 2022. 36 Copyright Notice 38 Copyright (c) 2022 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 (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2.1. History of IPv4 Address Types . . . . . . . . . . . . . . 3 56 2.2. Reserved IPv4 Addresses in the RFC Series . . . . . . . . 4 57 2.3. Attempts to Use the "Future Use" Addresses . . . . . . . 4 58 2.4. Recent Use as Ordinary Unicast Addresses . . . . . . . . 5 59 3. Change in Status of 240/4 . . . . . . . . . . . . . . . . . . 6 60 3.1. Continued Special Treatment for 255.255.255.255/32 . . . 7 61 4. Compatibility and Interoperability . . . . . . . . . . . . . 7 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 6.1. Existing Unofficial Uses of 240/4 . . . . . . . . . . . . 11 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 8.2. Informative References . . . . . . . . . . . . . . . . . 12 69 Appendix A. Implementation Status . . . . . . . . . . . . . . . 15 70 A.1. Operating systems . . . . . . . . . . . . . . . . . . . . 15 71 A.2. Other implementations . . . . . . . . . . . . . . . . . . 16 72 A.3. Internet of Things . . . . . . . . . . . . . . . . . . . 16 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 With ever-increasing pressure to conserve IP address space on the 78 Internet, it makes sense to consider where relatively minor changes 79 can be made to fielded practice to improve numbering efficiency. One 80 such change, proposed by this document, is to redefine the 81 "Experimental" or "Future Use" 240/4 region (historically known as 82 "Class E" addresses) as ordinary unicast addresses. These 268 83 million IPv4 addresses are already usable for unicast traffic in many 84 popular implementations today. Standardization as unicast addresses 85 will eventually allow them to be later deployed by Internet 86 stewardship organizations to relieve address space scarcity. 88 1.1. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 2. Background 95 2.1. History of IPv4 Address Types 97 When the Internet Protocol was being designed, it was unclear whether 98 it would be a success, or which of its features might be the key 99 features that led to success. The bulk of its address space was 100 dedicated to ordinary "host addresses". Other blocks and corners of 101 the address space were reserved, either for particular protocol 102 functions such as loopback, LAN broadcasting, or host bootstrapping, 103 or for future definition. A major allocation of 268 million 104 addresses was later made for multicasting [RFC0988], while leaving 105 another 268 million reserved for "future use". After the invention 106 of broadcast and multicast, the original ordinary host addresses were 107 later described as unicast addresses, which is now the usual 108 terminology. 110 With decades of hindsight, we can now see that unicast has been the 111 success story of the Internet. Trillions of unicast packets now move 112 around the world daily. By contrast, the non-unicast addresses are 113 seldom used. The use of routable broadcast packets in denial of 114 service attacks has now limited broadcast packets to local-area 115 networks [RFC2644], and to critical but highly-specialized protocol 116 functions such as DHCP [RFC2131], routing updates [RFC1256], or 117 neighbor discovery. 119 Wide-area multicast packets had a brief research heyday, but never 120 reached critical mass. Today, the overwhelming majority of multiply- 121 replicated media streams (such as popular songs and videos, 122 television programs, conference calls, and video meetings) are 123 carried in unicast packets mediated by application-level replication 124 rather than IP-protocol-level multicasting or broadcasting. 126 The Internet became a rapid worldwide success. Partly due to the 127 reduction in experimentation that accompanied that success, little 128 effort has been paid to looking back at the historical allocations of 129 reserved addresses. The success of unicast traffic has led to a huge 130 demand for unicast addresses. By contrast, there is far more supply 131 of reserved, ignored, loopback, and multicast addresses than any 132 foreseeable IPv4 Internet will demand. Most of these historical 133 accidents were not carried forward into the IPv6 protocol [RFC4291]. 134 We propose simple, compatible changes to existing IPv4 135 implementations that will increase the supply of unicast addresses by 136 redesignating addresses that today are almost completely unused on 137 the Internet. The best and easiest "future use" of many of today's 138 formerly reserved IPv4 addresses is as ordinary unicast addresses. 140 2.2. Reserved IPv4 Addresses in the RFC Series 142 The Assigned Numbers RFC series reserved various IP addresses or 143 assigned them special meanings, starting in 1977 and continuing 144 through the early 1990s. The detailed behavioral requirements for 145 IPv4 implementations based on these designations are set out in 146 October 1989's RFC 1122 [RFC1122]. As other special cases continued 147 to be introduced on occasion, RFC 3232 [RFC3232] announced that IANA 148 would track such information in an online database; the present-day 149 version of this mechanism is the IPv4 Special-Purpose Address 150 Registry [IANA4], as provided for by RFC 6890 [RFC6890]. A wide 151 range of host and network software follows these designations by 152 treating these Internet addresses specially. 154 This document is concerned with the largest special case in RFC 1122: 155 the designation of an entire /4 block for Future Use. In retrospect, 156 the flexibility offered by keeping these addresses unused was 157 insightful for its time, but since they ended up never being needed 158 for any special purposes, they have become the least productive 159 portion of the Internet address space. 161 The largest block of original addresses reserved for future use in 162 1983 was called "Class D" in RFC 870 [RFC0870], and contained what 163 would now be called 224/3. This contained about 536 million 164 addresses, about 12.5% of the total available address space. By 165 1986, RFC 988 [RFC0988] split the former Class D in half, designating 166 a multicast Class D block, now called 224/4, and a future-use Class E 167 block, now called 240/4. Following the 1993 implementation of CIDR 168 [RFC1519] and its 2006 clarification [RFC4632], we no longer speak of 169 any IPv4 address as having an "address class," but the reservations 170 of these specific addresses that were made by RFC 1122, were 171 unaffected by the CIDR change in terminology and routing technology. 173 2.3. Attempts to Use the "Future Use" Addresses 175 Through the 1980s, there were many reasons to suppose that new forms 176 of Internet addressing could emerge, so reserving a substantial 177 number of addresses for them was prudent. 179 One likely candidate for some time was protocol translation methods 180 between IP and other protocols using special surrogate IP addresses. 181 This possibility was particularly significant during the time frame 182 when IP coexisted widely on heterogeneous networks with other 183 protocols. Special number ranges could have been used to facilitate 184 interoperability, protocol translation, or encapsulation between IP 185 and non-IP protocols. 187 This prospect received new salience with the adoption of IPv6, where 188 some deployed or proposed transition mechanisms use special-purpose 189 IPv4 addresses with a distinctive meaning in the context of IPv6 190 transition, such as NAT64 [RFC7050] and the deprecated 6to4 191 [RFC3068]. While IPv6 transition mechanisms could conceivably have 192 used portions of 240/4, they ended up instead using very small 193 amounts of special address space from the IETF Protocol Assignments 194 block 192.0.0.0/24 or elsewhere within the unicast space. 196 Another form of addressing that was novel in 1989 is anycast 197 addressing, in which the same address is used to identify servers at 198 physically distinct locations and connected to the Internet at 199 different points. It would have been possible to designate a new 200 "class" of addresses for anycast operations. RFC 1546 [RFC1546], 201 which first defined anycast, concluded that this would be a possible 202 and even desirable approach: 204 | There appear to be a number of ways to support anycast addresses, 205 | some of which use small pieces of the existing address space, 206 | others of which require that a special class of IP addresses be 207 | assigned. [...] In the balance it seems wiser to use a separate 208 | class of addresses. 210 But anycast services turned out to work fine in most respects by 211 using existing unicast routing protocols, existing unicast datagram 212 delivery protocols, and ordinary unicast addresses. They are now 213 widely used for specific applications [RFC7094] such as the 214 Internet's root nameservers. 216 2.4. Recent Use as Ordinary Unicast Addresses 218 Overall, 30 years of experience have demonstrated that no new 219 addressing mechanism requires the use of 240/4; nor is any likely to 220 require it in the future, particularly in light of the IPv6 221 transition. Other explicit reservations such as the IETF Protocol 222 Assignments block at 192.0.0.0/24 have been sufficient. While it was 223 reasonable to plan for an unknown future, the reserved block at 240/4 224 did not ultimately aid Internet innovation or functionality. The 225 future has arrived, and it wants IPv4 unicast addresses far more than 226 it wants permanently unusable IPv4 addresses. 228 The idea of making 240/4 addresses available for unicast addressing 229 is not new. It was suggested by Lear on the influential TCP-IP 230 mailing list in 1988 [Lear]. It was formally proposed to IETF more 231 than a decade ago, both by Fuller, Lear, and Mayer [FLM], and by 232 Wilson, Michaelson, and Huston [WMH]. While the idea of unicast use 233 of 240/4 was merely being considered at IETF, the "running code" 234 required was simple enough and compatible enough that this behavior 235 change was implemented at that time in several operating systems. 236 Then, when the protocol change was ultimately not standardized, those 237 implementations remained, but were largely forgotten. (They are 238 summarized in the "Implementation Status" section of this document.) 240 The unicast support created in about 2008 in those implementations is 241 now running in millions of nodes on the Internet, and has not caused 242 any problems over the past decade. As a result, the 240/4 space has 243 been attracting "wildcat" use in private networks; see [VPC]. 245 Although software support for unicast use of 240/4 is widespread, it 246 is not yet universal. The present document moves this process 247 further along by confirming the consensus that unicast is the 248 preferred use for 240/4, documenting the exact behavior changes 249 required for maximum interoperability, and calling on all vendors and 250 implementers to adopt this behavior. Doing so will prepare for a 251 future in which use of these addresses is anticipated and 252 unsurprising, so that their allocation can be considered. 254 Implementations generally treat public and private addresses 255 identically, with the differences occurring only in how routes, 256 firewalls, and DNS servers are configured. The earlier draft [WMH] 257 suggested designating the unreserved 240/4 range as [RFC1918]-style 258 private address space. Like the [FLM] draft, this document does not 259 attempt to decide or designate whether future allocations from this 260 address range will be public or private addresses. Both options 261 require that both hosts and routers be able to use these addresses, 262 so the next section fully defines both host and router behavior. 264 3. Change in Status of 240/4 266 The purpose of this document is to make addresses in the range 240/4 267 available for active unicast use on the public Internet. This 268 includes supporting them for numbering and addressing networks and 269 hosts, like any other unicast address. 271 Host and router software SHOULD treat addresses in the 240/4 range in 272 the same way that they would treat other unicast IPv4 addresses. 273 Software SHOULD be capable of accepting datagrams from, and 274 generating datagrams to, addresses within this range. 276 Clients for autoconfiguration mechanisms such as DHCP [RFC2131] 277 SHOULD accept a lease or assignment of an address within 240/4 278 whenever the underlying operating system is capable of accepting it. 280 Other interoperability details related to address-based filtering are 281 discussed in a separate section, below. 283 3.1. Continued Special Treatment for 255.255.255.255/32 285 The address 255.255.255.255/32 was given a special meaning as a local 286 segment limited broadcast address by numerous prior Internet 287 standards, starting with RFC 919 [RFC0919] and continuing 288 consistently up to the present day. For example, 255.255.255.255 is 289 used as a network-layer destination address in BOOTP [RFC0951] and 290 DHCP [RFC2131] for address autoconfiguration broadcasts by hosts that 291 don't yet know anything about the networks to which they are 292 connected. While some newer autoconfiguration or autodiscovery 293 protocols use other addresses, the use of 255.255.255.255 remains 294 widespread. 296 The special meaning of 255.255.255.255 was never restricted or 297 affected by the reservation of 240/4. Accordingly, the existing 298 distinctive meaning of 255.255.255.255 is unchanged by this document. 299 This single address MUST NOT be assigned to an individual host, or 300 interpreted as the address of an individual host, even if it would 301 otherwise be part of an allocated or announced network block. 303 4. Compatibility and Interoperability 305 Older Internet standards counseled implementations in varying ways to 306 reject packets from, and not to generate packets to, addresses within 307 240/4. 309 RFC 1122 [RFC1122], section 3.2.1.3, states that a "host MUST 310 silently discard an incoming datagram containing an IP source address 311 that is invalid by the rules of this section." The same section 312 states that Class E addresses are "reserved" (which might be taken, 313 in context, to imply that they are "invalid"); the section further 314 treats Class A, B, and C as the only possibly relevant address ranges 315 for unicast addressing. 317 RFC1812 [RFC1812], section 5.3.7, states that a "router SHOULD NOT 318 forward" a packet with such a destination address. (If section 319 4.2.2.11's reference to these addresses as "reserved" is taken to 320 imply that they are "special," section 5.3.7 would also imply that a 321 "router SHOULD NOT forward" a packet with such a source address.) 323 RFC 3704 [RFC3704] (BCP 84) cites RFC 2827 [RFC2827] (BCP 38) in 324 asking providers to filter based on source address: 326 | RFC 2827 recommends that ISPs police their customers' traffic by 327 | dropping traffic entering their networks that is coming from a 328 | source address not legitimately in use by the customer network. 329 | The filtering includes but is in no way limited to the traffic 330 | whose source address is a so-called "Martian Address" - an address 331 | that is reserved, including any address within 0.0.0.0/8, 332 | 10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 333 | 224.0.0.0/4, or 240.0.0.0/4. 335 In this context, RFC 3704 specifies filtering of these addresses as 336 source (not destination) addresses at a network ingress point as a 337 countermeasure against forged source addresses, limiting forwarded 338 packets' source addresses to only the set which have been actually 339 assigned to the customer's network. The RFC's mention of these 340 "Martian Addresses" is based on the assumption that they could never 341 be legitimately in use by the customer network. 343 Because the 240/4 address space is no longer reserved as a whole, an 344 address within this space is no longer inherently a "Martian" 345 address. Both hosts and routers MUST NOT hard-code a policy of 346 always rejecting such addresses. Hosts and routers SHOULD NOT be 347 configured to apply Martian address filtering to any packet solely on 348 the basis of its reference to a source (or destination) address in 349 240/4. Maintainers of lists of "Martian addresses" MUST NOT 350 designate addresses from this range as "Martian". As noted 351 elsewhere, the address 255.255.255.255 retains its special meaning, 352 but is also not a "Martian" address. 354 The filtering recommended by RFC 3704 is designed for border routers, 355 not for hosts. To the extent that an ISP had allocated an address 356 range from within 240/4 to its customer, RFC 3704 would already not 357 require packets with those source addresses to be filtered out by the 358 ISP's border router. 360 Since deployed implementations' willingness to accept 240/4 addresses 361 as valid unicast addresses varies, a host to which an address from 362 this range has been assigned may also have a varying ability to 363 communicate with other hosts. 365 Such a host might be inaccessible by some devices either on its local 366 network segment or elsewhere on the Internet, due to a combination of 367 host software limitations or reachability limitations in the network. 368 IPv4 unicast interoperability with 240/4 can be expected to improve 369 over time following the publication of this document. Before or 370 after allocations are eventually made within this range, 371 "debogonization" efforts for allocated ranges can improve 372 reachability to the whole address block. Similar efforts have 373 already been done by Cloudflare on 1.1.1.1 [Cloudflare], and by RIPE 374 Labs on 1/8 [RIPElabs18], 2a10::/12 [RIPElabs2a1012], and 128.0/16 375 [RIPElabs128016]. The Internet community can use network probing 376 with any of several measurement-oriented platforms to investigate how 377 usable these addresses are at any particular point in time, as well 378 as to localize medium-to-large-scale routing problems. (Examples are 379 described in [Huston], [NLNOGRing], and [Atlas].) Any network 380 operator to whom such addresses are made available by a future 381 allocation will have to examine the situation in detail to determine 382 how well its interoperability requirements will be met. 384 5. IANA Considerations 386 This memo unreserves the address block 240/4. It therefore requests 387 IANA to update the IANA Special-Purpose Address Registry by removing 388 the entry for 240/4, whose existing authority is RFC 1122, Section 4. 389 Additionally, it requests IANA to update the IANA IPv4 Address Space 390 Registry by changing the status of each /8 entry from 240/8 through 391 255/8 from "Future Use, 1981-09, RESERVED" to "Unallocated, [Date of 392 this RFC], UNALLOCATED". Finally, IANA is requested to prepare for 393 this address space to be addressed in the reverse DNS space in in- 394 addr.arpa. 396 This memo does not effect a registration, transfer, allocation, or 397 authorization for use of these addresses by any specific entity. 398 This memo's scope is to require IPv4 software implementations to 399 support the ordinary unicast use of addresses in the newly 400 unallocated range 240.0.0.0 through 255.255.255.254. During a 401 significant transition period, it would only be prudent for the 402 global Internet to use those addresses for experimental purposes such 403 as debogonization and testing. After that transition period, a 404 responsible entity such as IETF or IANA could later consider whether, 405 how and when to allocate those addresses to entities or to other 406 protocol functions such as private addresses. 408 6. Security Considerations 410 The change specified by this document could create a period of 411 ambiguity about historical and future interpretations of the meaning 412 of host and network addresses in 240/4. Some networks and hosts 413 currently discard all IPv4 packets bearing these addresses, pursuant 414 to statements in prior standards that packets containing these 415 addresses have no agreed-upon meaning. Such implementations have 416 protected themselves from possible incompatible future packet formats 417 that might have eventually used these addresses. 419 Disparate filtering processes and rules, both at present, and in 420 response to the adoption of this document, could make it easier for 421 rogue network operators to hijack or spoof portions of this address 422 space in order to send malicious traffic. 424 Live traffic, accepted and processed by other devices, may 425 legitimately originate from these addresses in the future. Network 426 operators, firewalls, and intrusion-detection systems may need to 427 take account of this change in various regards, to avoid permitting 428 either more or less traffic from such addresses than they expected. 430 Automated systems generating reports, and human beings reading those 431 reports, SHOULD NOT assume that the use of a 240/4 source address 432 indicates spoofing, an attack, or a new incompatible packet format. 433 At the same time, they SHOULD NOT assume that the use of 240/4 is 434 impossible or will be precluded by other systems' behavior. 436 An important concern about the [FLM] and [WMH] drafts was that 437 discrepant behavior between systems could create security problems, 438 as when a middlebox fails to detect or report an attack or policy 439 violation because it believes that an address involved cannot be used 440 or cannot be relevant. Similarly, a logging system could fail to log 441 traffic related to 240/4 addresses because it incorporates an 442 assumption that no such traffic can ever occur. Such discrepancies 443 between multiple systems' views of communication semantics are a 444 common security antipattern. (Compare [Sherr], exploiting 445 discrepancies in telephony equipment's recognition and interpretation 446 of DTMF signals.) Any change to the meaning or status of a group of 447 addresses can introduce such a discrepancy. 449 In this case, because 240/4 is already commonly supported by several 450 widely-used implementations, and is already used for private network 451 communications, such discrepancies are already a reality. If routers 452 follow this document's request to cease filtering this address range, 453 they will increase the variety of contexts in which implementations 454 may receive ordinary unicast packets containing these addresses. 455 (Such packets are still unlikely to arrive from distant hosts until 456 some of these addresses are eventually allocated for experimental or 457 production use, and until the global routing table receives 458 announcements for subnets in this range.) 460 The adoption of this document will converge on an explicitly shared 461 understanding that implementations should prepare for this 462 possibility. Since unofficial private use of 240/4 addresses is a 463 reality today, while any public allocations from this range are still 464 distant and contingent on further study, implementers are receiving 465 considerable advance notice of this issue. 467 6.1. Existing Unofficial Uses of 240/4 469 Some organizations are reportedly using portions of 240/4 internally 470 as RFC 1918-type private-use address space, for example for internal 471 communications within datacenters. Google has advised hosting 472 customers [VPC] that they may use this address space this way. 473 Future allocations of 240/4 could result in use of this space on the 474 public Internet in ways that overlap these unofficial private-use 475 addresses, creating ambiguity about whether a particular host 476 intended to use such an address to refer to a private or public 477 network. Among other unintended outcomes, hosts or firewalls that 478 have extended greater trust to other hosts based on their use of a 479 certain unofficial network number (that was considered to imply 480 presence on a LAN or within an organization) may eventually receive 481 legitimate traffic from an external network to which this address 482 space has been allocated. 484 Operators of networks that are making unofficial uses of portions of 485 240/4 may wish to plan to discontinue these uses and renumber their 486 internal networks, or to request that IANA formally designate certain 487 ranges as additional Private-Use areas. 489 7. Acknowledgements 491 This document directly builds on prior work by Dave Täht and 492 John Gilmore as part of the IPv4 Unicast Extensions Project. 494 8. References 496 8.1. Normative References 498 [IANA4] Internet Assigned Numbers Authority, "IANA IPv4 Special- 499 Purpose Address Registry", 500 . 503 [RFC0870] Reynolds, J. and J. Postel, "Assigned numbers", RFC 870, 504 DOI 10.17487/RFC0870, October 1983, 505 . 507 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 508 Communication Layers", STD 3, RFC 1122, 509 DOI 10.17487/RFC1122, October 1989, 510 . 512 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 513 RFC 1812, DOI 10.17487/RFC1812, June 1995, 514 . 516 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 517 J., and E. Lear, "Address Allocation for Private 518 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 519 February 1996, . 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, 523 DOI 10.17487/RFC2119, March 1997, 524 . 526 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 527 Defeating Denial of Service Attacks which employ IP Source 528 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 529 May 2000, . 531 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 532 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 533 2004, . 535 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 536 (CIDR): The Internet Address Assignment and Aggregation 537 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 538 2006, . 540 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 541 "Special-Purpose IP Address Registries", BCP 153, 542 RFC 6890, DOI 10.17487/RFC6890, April 2013, 543 . 545 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 546 the IPv6 Prefix Used for IPv6 Address Synthesis", 547 RFC 7050, DOI 10.17487/RFC7050, November 2013, 548 . 550 8.2. Informative References 552 [Atlas] RIPE Network Coordination Centre, "RIPE Atlas", 553 . 555 [Cloudflare] 556 Strong, M., "Fixing reachability to 1.1.1.1, GLOBALLY!", 4 557 April 2018, . 560 [FLM] Fuller, V., Lear, E., and D. Meyer, "Reclassifying 240/4 561 as usable unicast address space", Work in Progress, 562 Internet-Draft, draft-fuller-240space-02, 25 March 2008, 563 . 566 [Huston] Huston, G., "Detecting IP Address Filters", 13 January 567 2012, . 570 [Lear] Lear, E., "Re: Running out of Internet addresses?", TCP-IP 571 mailing list, 27 November 1988, 572 . 576 [NLNOGRing] 577 NLNOG RING, "10 Years of NLNOG RING", 578 . 580 [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, 581 RFC 919, DOI 10.17487/RFC0919, October 1984, 582 . 584 [RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, 585 DOI 10.17487/RFC0951, September 1985, 586 . 588 [RFC0988] Deering, S., "Host extensions for IP multicasting", 589 RFC 988, DOI 10.17487/RFC0988, July 1986, 590 . 592 [RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", 593 RFC 1256, DOI 10.17487/RFC1256, September 1991, 594 . 596 [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless 597 Inter-Domain Routing (CIDR): an Address Assignment and 598 Aggregation Strategy", RFC 1519, DOI 10.17487/RFC1519, 599 September 1993, . 601 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 602 Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, 603 November 1993, . 605 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 606 RFC 2131, DOI 10.17487/RFC2131, March 1997, 607 . 609 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 610 in Routers", BCP 34, RFC 2644, DOI 10.17487/RFC2644, 611 August 1999, . 613 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 614 RFC 3068, DOI 10.17487/RFC3068, June 2001, 615 . 617 [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced 618 by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, 619 January 2002, . 621 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 622 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 623 2006, . 625 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 626 "Architectural Considerations of IP Anycast", RFC 7094, 627 DOI 10.17487/RFC7094, January 2014, 628 . 630 [RIPElabs128016] 631 Aben, E., "The Curious Case of 128.0/16", 6 December 2011, 632 . 635 [RIPElabs18] 636 Schwarzinger, F., "Pollution in 1/8", 3 February 2010, 637 . 639 [RIPElabs2a1012] 640 Aben, E., "The Debogonisation of 2a10::/12", 17 January 641 2020, . 644 [Sherr] Sherr, M., Cronin, E., Clark, S., and M. Blaze, "Signaling 645 vulnerabilities in wiretapping systems", IEEE Security & 646 Privacy November-December 2005, 647 . 649 [VPC] Google Inc., "VPC Network Overview: Valid Ranges", 650 . 652 [WMH] Wilson, P., Michaelson, G., and G. Huston, "Redesignation 653 of 240/4 from "Future Use" to "Private Use"", Work in 654 Progress, Internet-Draft, draft-wilson-class-e-02, 29 655 September 2008, . 658 Appendix A. Implementation Status 660 The IPv4 protocol update proposed by this document has already been 661 implemented in a variety of widely-used software platforms. In many 662 cases, implementers were persuaded of the value of the suggestions 663 contained in [FLM] and [WMH]. 665 All known TCP/IP implementations either interoperate properly with 666 packets with sources or destinations in the 240/4 range, or ignore 667 these packets entirely, except FreeBSD, which has support for 240/4 668 for some purposes while blocking it for others. 670 A.1. Operating systems 672 240/4 has been supported for transmitting and receiving ordinary 673 unicast packets in Linux kernels since linux-2.6.25 was released in 674 January 2008. Creating interfaces in the 240/4 range also worked 675 fine using the iproute2 api (as used by the "ip" command) in that 676 release. A kernel patch that allows properly configuring interfaces 677 in the 240/4 range using the busybox ifconfig command was released in 678 linux-4.20 and linux-5.0 in December 2018. 680 240/4 has been supported as ordinary unicast in the Android mobile 681 operating system since Android 1.5 Cupcake (April 2009, using linux- 682 2.6.27). 684 240/4 has been supported as ordinary unicast in the OpenWRT router OS 685 since OpenWRT 8.09 (September 2008, using linux-2.6.26). A December 686 2018 kernel patch that allows properly configuring interfaces in the 687 240/4 range using the ifconfig command was merged into OpenWRT 19.01, 688 along with two other patches to netifd and BCP38 that improve support 689 for 240/4. 691 240/4 has been supported as ordinary unicast in Apple's macOS 692 (formerly OS X) operating system and iOS mobile operating system 693 since about 2008. 695 240/4 has been supported as ordinary unicast in Sun's Solaris 696 operating system since about 2008. 698 240/4 has been tested to interoperate as ordinary unicast in 2019 in 699 a Cisco router using IOS release 6.5.2.28I, which was also released 700 in 2019. Older and newer releases are also likely to work. 702 240/4 traffic is blocked by default in Juniper's JUNOS router 703 operating system, but can be enabled with a simple configuration 704 switch. 706 240/4 traffic is partly supported for local interface assignment in 707 the FreeBSD operating system. However, ICMP and packet forwarding 708 are not supported. Small patches that fully enable FreeBSD support 709 for 240/4 have been tested and are fully interoperable. 711 240/4 traffic is blocked by default in all versions of the Microsoft 712 Windows operating system. Windows will not assign an interface 713 address in this range, if one is offered by DHCP. 715 A.2. Other implementations 717 Routing of subnets in the 240/4 range is fully supported by the Babel 718 routing protocol and by its main implementation, as of 2020 (or 719 earlier). 721 Routing of subnets in the 240/4 range is supported by the Gobgp 722 routing daemon, as of release 3.0.0 in 2022-03 (or earlier). 724 A.3. Internet of Things 726 Popular embedded Internet-of-Things environments such as RIOT and 727 FreeRTOS already support 240/4 as unicast. 729 Authors' Addresses 731 Seth David Schoen 732 IPv4 Unicast Extensions Project 733 San Francisco, CA 734 United States of America 735 Email: schoen@loyalty.org 737 John Gilmore 738 IPv4 Unicast Extensions Project 739 PO Box 170640-rfc 740 San Francisco, CA 94117-0640 741 United States of America 742 Email: gnu@rfc.toad.com 744 David M. Täht 745 IPv4 Unicast Extensions Project 746 Half Moon Bay, CA 747 United States of America 748 Email: dave@taht.net