idnits 2.17.1 draft-schoen-intarea-unicast-127-01.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 13 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 March 2022) is 780 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA4' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA4SP' ** Obsolete normative reference: RFC 776 (Obsoleted by RFC 790) ** Obsolete normative reference: RFC 990 (Obsoleted by RFC 1010) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 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: 8 September 2022 7 March 2022 8 Unicast Use of the Formerly Reserved 127/8 9 draft-schoen-intarea-unicast-127-01 11 Abstract 13 This document redefines the IPv4 local loopback network as consisting 14 only of the 65,536 addresses 127.0.0.0 to 127.0.255.255 15 (127.0.0.0/16). It asks implementers to make addresses in the prior 16 loopback range 127.1.0.0 to 127.255.255.255 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Change in Status of Addresses Within 127/8 . . . . . . . . . 4 56 4. Compatibility and Interoperability . . . . . . . . . . . . . 4 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 62 8.2. Informative References . . . . . . . . . . . . . . . . . 9 63 Appendix A. Implementation Status . . . . . . . . . . . . . . . 10 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 With ever-increasing pressure to conserve IP address space on the 69 Internet, it makes sense to consider where relatively minor changes 70 can be made to fielded practice to improve numbering efficiency. One 71 such change, proposed by this document, is to allow the unicast use 72 of more than 16 million historically reserved addresses in the middle 73 of the IPv4 address space. 75 This document provides history and rationale to reduce the size of 76 the IPv4 local loopback network ("localnet") from /8 to /16, freeing 77 up over 16 million IPv4 addresses for other possible uses. 79 When all of 127.0.0.0/8 was reserved for loopback addressing, IPv4 80 addresses were not yet recognized as scarce. Today, there is no 81 justification for allocating 1/256 of all IPv4 addresses for this 82 purpose, when only one of these addresses is commonly used and only a 83 handful are regularly used at all. Unreserving the majority of these 84 addresses provides a large number of additional IPv4 host addresses 85 for possible use, alleviating some of the pressure of IPv4 address 86 exhaustion. 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 96 The IPv4 network 127/8 was first reserved by Jon Postel in 1981 97 [RFC0776]. Postel's policy was to reserve the first and last network 98 of each class, and it does not appear that he had a specific plan for 99 how to use 127/8. Apparently, the first operating systems to support 100 a loopback interface as we understand it today were experimental 101 Berkeley Unix releases by Bill Joy and Sam Leffler at the University 102 of California at Berkeley. The choice of 127.0.0.1 as loopback 103 address was made in 1983 by Joy and Leffler in the code base that was 104 eventually released as 4.2BSD. Their earliest experimental code 105 bases used 254.0.0.0 and 127.0.0.0 as loopback addresses. Three 106 years later, Postel and Joyce Reynolds documented the loopback 107 function in November 1986 [RFC0990], and it was codified as a 108 requirement for all Internet hosts three years after that, in 109 [RFC1122]. The substantive interpretation of these addresses has 110 remained unchanged since RFC 990 indicated that the 112 | network number 127 is assigned the "loopback" function, that is, a 113 | datagram sent by a higher level protocol to a network 127 address 114 | should loop back inside the host. No datagram "sent" to a network 115 | 127 address should ever appear on any network anywhere. 117 Many decisions about IPv4 addressing contemporaneous with this one 118 underscore the lack of concern about address scarcity. It was common 119 in the early 1980s to allocate an entire /8 to an individual 120 university, company, government agency, or even a research project. 122 By contrast, IPv6, despite its vastly larger pool of available 123 address space, allocates only a single local loopback address (::1) 124 [RFC4291]. This appears to be an architectural vote of confidence in 125 the idea that Internet protocols ultimately do not require millions 126 of distinct loopback addresses. 128 Most applications use only the single loopback address 127.0.0.1 129 ("localhost") for IPv4 loopback purposes, although there are 130 exceptions. For example, the systemd-resolved service on Linux 131 provides a stub DNS resolver at 127.0.0.53. 133 In theory, having multiple local loopback addresses might be useful 134 for increasing the number of distinct IPv4 sockets that can be used 135 for inter-process communication within a host. The local loopback 136 /16 network retained by this document will still permit billions of 137 distinct concurrent loopback TCP connections within a single host, 138 even if both the IP address and port number of one endpoint of each 139 connection are fixed. 141 3. Change in Status of Addresses Within 127/8 143 The purpose of this document is to reduce the size of the special- 144 case reservation of 127/8, so that only 127.0/16 is reserved as the 145 local loopback network. 147 Other IPv4 addresses whose first octet is 127 (that is, the addresses 148 127.1.0.0 to 127.255.255.255) are no longer reserved and are now 149 available for general Internet unicast use, treated identically to 150 other IPv4 addresses, and subject to potential future allocation. 152 All host and router software SHOULD treat 127.1.0.0 to 153 127.255.255.255 as a global unicast address range. 155 Clients for autoconfiguration mechanisms such as DHCP [RFC2131] 156 SHOULD accept a lease or assignment of addresses within 127.1/16 to 157 127.255/16 whenever the underlying operating system is capable of 158 accepting it. Servers for these mechanisms SHOULD assign this 159 address when so configured. 161 4. Compatibility and Interoperability 163 Many deployed systems follow older Internet standards in rejecting 164 externally-originating packets from addresses in 127/8, and in not 165 generating packets addressed to them). RFC 3704 [RFC3704] (BCP 84) 166 cites RFC 2827 [RFC2827] (BCP 38) to this effect: 168 | RFC 2827 recommends that ISPs police their customers' traffic by 169 | dropping traffic entering their networks that is coming from a 170 | source address not legitimately in use by the customer network. 171 | The filtering includes but is in no way limited to the traffic 172 | whose source address is a so-called "Martian Address" - an address 173 | that is reserved, including any address within 0.0.0.0/8, 174 | 10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 175 | 224.0.0.0/4, or 240.0.0.0/4. 177 In this context, RFC 3704 specifies filtering of these addresses as 178 source (not destination) addresses at a network ingress point as a 179 countermeasure against forged source addresses, limiting forwarded 180 packets' source addresses to only the set which have been actually 181 assigned to the customer's network. The RFC's mention of these 182 "Martian Addresses" is based on the assumption that they could never 183 be legitimately in use by the customer network. 185 Because the 127/8 address space is no longer reserved as a whole, an 186 address within this space, other than those within 127/16, is no 187 longer inherently a "Martian" address. Both hosts and routers MUST 188 NOT hard-code a policy of always rejecting such addresses. Hosts and 189 routers SHOULD NOT be configured to apply Martian address filtering 190 to any packet solely on the basis of its reference to a source or 191 destination address in 127/8 (other than those in 127/16). 192 Maintainers of lists of "Martian addresses" MUST NOT designate 193 addresses from the 127/8 range (other than those within 127/16) as 194 "Martian". 196 The filtering recommended by RFC 3704 is designed for border routers, 197 not for hosts. To the extent that an ISP had validly allocated an 198 address range from within 127/8 to its customer, RFC 3704 would 199 already not require packets with those source addresses to be 200 filtered out by the ISP's border router. 202 Since deployed implementations' willingness to accept 127/8 addresses 203 as valid unicast addresses varies, a host to which an address from 204 this range has been assigned may also have a varying ability to 205 communicate with other hosts. 207 Such a host might be inaccessible by some devices either on its local 208 network segment or elsewhere on the Internet, due to a combination of 209 host software limitations or reachability limitations in the network. 210 IPv4 unicast interoperability with 127/8 can be expected to improve 211 over time following the publication of this document. Before or 212 after allocations are eventually made within this range, 213 "debogonization" efforts for allocated ranges can improve 214 reachability to the whole address block. Similar efforts have 215 already been done by Cloudflare on 1.1.1.1 [Cloudflare], and by RIPE 216 Labs on 1/8 [RIPElabs18], 2a10::/12 [RIPElabs2a1012], and 128.0/16 217 [RIPElabs128016]. The Internet community can use network probing 218 with any of several measurement-oriented platforms to investigate how 219 usable these addresses are at any particular point in time, as well 220 as to localize medium-to-large-scale routing problems. (Examples are 221 described in [Huston], [NLNOGRing], and [Atlas].) Any network 222 operator to whom such addresses are made available by a future 223 allocation will have to examine the situation in detail to determine 224 how well its interoperability requirements will be met. 226 5. IANA Considerations 228 This memo unreserves a portion of 127/8. It therefore requests IANA 229 to update the IPv4 Special-Purpose Address registry [IANA4SP] by 230 replacing the entry for 127.0.0.0/8 with 127.0.0.0/16, with authority 231 of this document. 233 IANA is also requested to update the IPv4 Address Space Registry 234 [IANA4] by changing the entry for 127/8 (IANA - Loopback) to read 235 127/16, and by adding a new entry 127.1/16-127.255/16 Unallocated 236 [Date of this document] [blank] [blank] UNALLOCATED 237 Finally, IANA is requested to prepare for this address space to be 238 addressed in in the reverse DNS space in in-addr.arpa. 240 This memo does not effect a registration, transfer, allocation, or 241 authorization for use of these addresses by any specific entity. 242 This memo's scope is to require IPv4 software implementations to 243 support the ordinary unicast use of addresses in the newly 244 unallocated range 127.1.0.0 through 127.255.255.255. During a 245 significant transition period, it would only be prudent for the 246 global Internet to use those addresses for experimental purposes such 247 as debogonization and testing. After that transition period, a 248 responsible entity such as IETF or IANA could later consider whether, 249 how and when to allocate those addresses to entities or to other 250 protocol functions. 252 6. Security Considerations 254 The behavior change specified by this document could produce security 255 concerns where two devices, or two different parts of the software on 256 a host, or a software application and a human user, follow divergent 257 interpretations of an address that was formerly a loopback address. 259 For example, this could lead to errors in the specification or 260 enforcement of rules about Internet hosts' connectivity to one 261 another, or their right to access resources. It could also lead to 262 an application connecting to the local host when it expected to 263 connect to a remote host, or vice versa. 265 One undesired case would arise where a local process on a host 266 accepts connections on what it believes is a loopback address, in 267 order to receive commands from other software on the same host, yet 268 the bound address is actually reachable from outside that host. The 269 traditional socket API present on most operating systems does not 270 make this especially likely, since a listening process typically 271 binds to either INADDR_ANY (which includes both loopback and 272 nonloopback interfaces) or INADDR_LOOPBACK (which includes only the 273 single address 127.0.0.1). The existence of an additional interface 274 with a remotely addressable unicast address like 127.8.9.10 would 275 not, in itself, change which hosts can communicate with either of 276 these sockets. Nonetheless, an operating system or software library 277 that provides some other interface with its own means of scoping the 278 receipt of incoming connections must take care not to leave an 279 ambiguity between host-only and non-host-only address scopes as a 280 result of the change specified by this document. 282 The importance of the distinction just mentioned is underscored by 283 practical examples of vulnerabilities when specific software relaxed 284 the distinction between loopback and non-loopback addresses in a 285 different way. A 2017 vulnerability [CVE-2016-1551] related to the 286 reference implementation of the Network Time Protocol v4 [RFC5905], 287 and an analogous 2020 vulnerability [CVE-2020-8558] in the Kubernetes 288 cluster management software, both involved the use of a Linux kernel 289 option that removed the prohibition on sending or receiving packets 290 over the wire with a 127/8 destination address. This, however, 291 allowed other devices to reach and communicate with server processes 292 that had deliberately listened on what they otherwise expected to be 293 loopback addresses. 295 The change requested by this document does not have the same effect, 296 because loopback addresses in the reduced 127.0/16 loopback range are 297 still not permitted to appear on the wire, and should still be 298 rejected by implementations. The ability to enforce the 299 inaccessibility of loopback addresses by other hosts remains 300 necessary for security. In particular, treating all of 127/8 as 301 globally routable address space is not a safe behavior. Operating 302 systems SHOULD continue to treat 127.0/16 as loopback-only and never 303 route packets between 127.0/16 loopback addresses and any other 304 interface. Addresses in 127.0/16 still SHOULD NOT appear on any 305 network link and SHOULD NOT be accepted or generated over a network 306 link. Applications MUST NOT use 127.1/16 to 127.255/16 for loopback 307 purposes or assume that connections from these addresses necessarily 308 originated from software on the local host. 310 Apart from that, firewall rules that assume that 127.1/16 through 311 127.255/16 are unroutable and/or local SHOULD be updated to take into 312 account that they may be routable and/or non-local. 314 Software that assumes that all of 127/8, either as a source or a 315 destination, refers to the local host SHOULD be updated to make that 316 inference only for 127/16. Communications to or from 127.1/16 317 through 127.255/16 SHOULD NOT be treated as inherently more trusted 318 than communications to or from the public Internet as a whole. 320 7. Acknowledgements 322 This document directly builds on prior work by Dave Täht and 323 John Gilmore as part of the IPv4 Unicast Extensions Project. 325 Members of the Internet History Mailing List helped us clarify the 326 early history of 127/8. 328 8. References 330 8.1. Normative References 332 [IANA4] Internet Assigned Numbers Authority, "IANA IPv4 Address 333 Space Registry", . 336 [IANA4SP] Internet Assigned Numbers Authority, "IANA IPv4 Special- 337 Purpose Address Registry", 338 . 341 [RFC0776] Postel, J., "Assigned numbers", RFC 776, 342 DOI 10.17487/RFC0776, January 1981, 343 . 345 [RFC0990] Reynolds, J. and J. Postel, "Assigned numbers", RFC 990, 346 DOI 10.17487/RFC0990, November 1986, 347 . 349 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 350 Communication Layers", STD 3, RFC 1122, 351 DOI 10.17487/RFC1122, October 1989, 352 . 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, 356 DOI 10.17487/RFC2119, March 1997, 357 . 359 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 360 RFC 2131, DOI 10.17487/RFC2131, March 1997, 361 . 363 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 364 Defeating Denial of Service Attacks which employ IP Source 365 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 366 May 2000, . 368 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 369 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 370 2004, . 372 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 373 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 374 2006, . 376 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 377 "Network Time Protocol Version 4: Protocol and Algorithms 378 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 379 . 381 8.2. Informative References 383 [Atlas] RIPE Network Coordination Centre, "RIPE Atlas", 384 . 386 [Cloudflare] 387 Strong, M., "Fixing reachability to 1.1.1.1, GLOBALLY!", 4 388 April 2018, . 391 [CVE-2016-1551] 392 NIST National Vulnerability Database, "CVE-2016-1551", 393 January 2017, 394 . 396 [CVE-2020-8558] 397 NIST National Vulnerability Database, "CVE-2020-8558", 398 July 2020, 399 . 401 [Huston] Huston, G., "Detecting IP Address Filters", 13 January 402 2012, . 405 [NLNOGRing] 406 NLNOG RING, "10 Years of NLNOG RING", 407 . 409 [RIPElabs128016] 410 Aben, E., "The Curious Case of 128.0/16", 6 December 2011, 411 . 414 [RIPElabs18] 415 Schwarzinger, F., "Pollution in 1/8", 3 February 2010, 416 . 418 [RIPElabs2a1012] 419 Aben, E., "The Debogonisation of 2a10::/12", 17 January 420 2020, . 423 Appendix A. Implementation Status 425 To our knowledge, the behavior specified by this document is not 426 currently the default in any TCP/IP implementation. We have prepared 427 and tested small patches to the Linux and FreeBSD kernels, and 428 achieved interoperability between patched versions of these systems 429 when numbered with 127/8 addresses. The patched systems were 430 otherwise usable normally. 432 The behavior of our patches contrasts with that of the existing 433 route_localnet option in Linux. The route_localnet option is a Linux 434 kernel feature which a user can enable in order to make all of 127/8 435 simultaneously addressable in both host and network address scopes, 436 which, as described in the Security Considerations section, has had 437 undesirable security consequences. Our patches instead retain 438 127.0/16 an exclusive loopback address range, continuing to forbid it 439 from appearing on the wire at all. 441 Authors' Addresses 443 Seth David Schoen 444 IPv4 Unicast Extensions Project 445 San Francisco, CA 446 United States of America 447 Email: schoen@loyalty.org 449 John Gilmore 450 IPv4 Unicast Extensions Project 451 PO Box 170640-rfc 452 San Francisco, CA 94117-0640 453 United States of America 454 Email: gnu@rfc.toad.com 456 David M. Täht 457 IPv4 Unicast Extensions Project 458 Half Moon Bay, CA 459 United States of America 460 Email: dave@taht.net