idnits 2.17.1 draft-schoen-intarea-unicast-lowest-address-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 3 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 8 instances 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 document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- 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 RFC3021, 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. 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 (16 May 2022) is 704 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 6 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, 3021 (if approved) D. Täht 5 Intended status: Standards Track IPv4 Unicast Extensions Project 6 Expires: 17 November 2022 M. Karels 7 16 May 2022 9 Unicast Use of the Lowest Address in an IPv4 Subnet 10 draft-schoen-intarea-unicast-lowest-address-02 12 Abstract 14 With ever-increasing pressure to conserve IP address space on the 15 Internet, it makes sense to consider where relatively minor changes 16 can be made to fielded practice to improve numbering efficiency. One 17 such change, proposed by this document, is to increase the number of 18 unicast addresses in each existing subnet, by redefining the use of 19 the lowest-numbered (zeroth) host address in each IPv4 subnet as an 20 ordinary unicast host identifier, instead of as a duplicate segment- 21 directed broadcast address. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 17 November 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Background and Current Standards . . . . . . . . . . . . . . 3 59 2.1. Assumptions About the Lowest Host Address by Remote 60 Systems . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Multicast Addresses; Point-to-Point Links . . . . . . . . 6 62 2.3. Current Limitations on Subnet-Directed Broadcast 63 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.4. Comparison to IPv6 Behavior . . . . . . . . . . . . . . . 6 65 3. Change to Interpretation of the Lowest Address . . . . . . . 7 66 3.1. Link-Layer Interaction . . . . . . . . . . . . . . . . . 7 67 3.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 8 68 3.2.1. "Requirements for Internet Hosts -- Communication 69 Layers" [RFC1122] . . . . . . . . . . . . . . . . . . 8 70 3.2.2. "Requirements for IP Version 4 Routers" [RFC1812] . . 8 71 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 3.4. Compatibility and Interoperability . . . . . . . . . . . 11 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 7.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Appendix A. Implementation Status . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 This document provides history and rationale to change the 85 interpretation of the lowest address in each IPv4 subnet from an 86 alternative broadcast address to an ordinary assignable host address, 87 and updates requirements for hosts and routers accordingly. The 88 decision taken in 1989 to reserve two forms instead of one for local 89 IPv4 segment broadcasts is no longer necessary because of the 90 obsolescence and disappearance of the software that motivated it. 91 Unreserving the lowest address provides an optional extra IPv4 host 92 address in every subnet, Internet-wide, alleviating some of the 93 pressure of IPv4 address exhaustion. 95 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. Background and Current Standards 103 IPv4 has long supported several mechanisms for broadcasting 104 communications to every station on a network. One form of broadcast 105 in IPv4 is "segment-directed broadcast" in which a broadcast is 106 addressed to every station on a particular network (identified by its 107 network number). Current standards reserve a huge number of 108 addresses for this: not just one, but two, addresses per subnet, 109 Internet-wide. 111 The standard broadcast address on a subnet is the address whose "host 112 part" consists of all ones in binary. For example, in a 24-bit 113 subnet that starts at 192.168.3.0, the address 192.168.3.255 is the 114 standard broadcast address. [RFC1122][RFC0894] 116 In addition to the standard broadcast address, RFC 1122 (October 117 1989) acknowledged a then-current implementation behavior in "4.2BSD 118 Unix and its derivatives, but not 4.3BSD", whereby those operating 119 systems "use non-standard broadcast address forms, substituting 0 for 120 -1". (Note that there was no standard for IP broadcast when 4.2BSD 121 was released in August 1983, more than a year prior to [RFC0919]. 122 The -1 form was first proposed in [IEN212] in 1982 but was not yet a 123 standard.) According to RFC 1122 and its successors, Internet hosts 124 are expected to "recognize and accept [...] these non-standard 125 broadcast addresses as the destination address of an incoming 126 datagram", and not otherwise use them to identify Internet hosts. 127 RFCs 1812 [RFC1812] (sections 4.2.3.1 and 5.3.5), and 3021 [RFC3021] 128 (sections 2.2, 3.1, and 3.3) reiterate and further expand on this 129 requirement. 131 This non-standard broadcast address is the address whose "host part" 132 consists of all zeroes. (The quantity of zeroes depends, in present- 133 day terminology, on the applicable subnet mask.) This address is the 134 lowest expressible address within any particular numbered network. 135 Following computer science tradition, it may also be referred to as 136 the "zeroth address" of its respective subnet. 138 The address triple syntax used in RFC 1122 looks unusual to modern 139 eyes. These triples included the "{ network number, subnet number, 140 host number }". The notation also used two's complement binary 141 notation in referring to a host number "-1" as containing all binary 142 1-bits. After the widespread adoption of CIDR [RFC4632], network 143 numbers no longer have an "address class" definition based on their 144 high-order bits, and there is no distinction between a network number 145 and a subnet number (except locally at the router where individual 146 subnets are being routed). Instead, following RFC 4632, IPv4 network 147 addresses are denoted with a dotted-decimal format containing one to 148 four positive 8-bit integers, a slash, and a whole count of the bits 149 in the network number portion, the so-called CIDR notation, 150 reportedly devised by Phil Karn. So for example 192.1.2.0/28 has a 151 28-bit network number and a 4-bit host number (32 address bits total, 152 minus those 28 bits). All of the bits of that particular host number 153 are zero (because the whole fourth dotted number is 0), and thus the 154 interpretation of this address would be affected by this document. 155 We will use both notations as convenient. Where RFC 1122 and its 156 successors use the terms "0 form" and "-1 form", we may refer 157 respectively to "all-zeros" and "all-ones" host numbers, since every 158 bit in the binary representation of these two host numbers has the 159 value 0 or 1, respectively. 161 4.2BSD, the operating system to whose behavior RFC 1122 required 162 deference, was the first BSD operating system full release to include 163 TCP/IP support; it was released in 1983. Its successor, 4.3BSD, was 164 released in 1986, which is why RFC 1122 could already confirm that 165 the broadcast behavior had been changed. See [BSDHIST]. RFC 1812 166 calls the old behavior "obsolete" in 1995, and RFC 3021 reiterates 167 that it is "obsolete" in 2000, although both express the idea that 168 the lowest address must continue to be reserved for historical 169 reasons. 171 All subsequent operating systems used on the Internet implement the 172 standard all-ones form of the broadcast address and use it by 173 default. Continuing to reserve the non-standard all-zeroes form 174 wastes one IPv4 address per subnet. No known operating system 175 generates IP broadcasts in this format today, and documentation 176 consistently encourages network administrators and software 177 developers to use the standard form. The IPv4 protocol does not 178 benefit from having two different broadcast addresses with the same 179 functionality in every subnet, and the non-standard form has always 180 been reserved primarily for backwards compatibility with systems that 181 have not existed for decades on the Internet. 183 As IPv4 addresses were not perceived as particularly scarce through 184 the 1980s, the prospect of wasting tens of millions of otherwise 185 assignable addresses in order to achieve backwards compatibility with 186 a particular operating system appeared reasonable. Today, those 187 addresses are clearly valuable and could be put to good use as 188 identifiers of Internet hosts in a time of IPv4 numbering resource 189 exhaustion. 191 2.1. Assumptions About the Lowest Host Address by Remote Systems 193 In general, under CIDR [RFC4632], only hosts and routers on a network 194 segment know that segment's netmask with certainty. Remote parts of 195 the Internet are already expected to not make assumptions about 196 whether or not a particular address is a broadcast address, since 197 that determination is already only meaningful for devices connected 198 to the segment containing that address. This document does not 199 change any of these things. Thus, if the behavior of devices on a 200 particular network segment has been updated in accordance with this 201 memo, the lowest address on that segment can already be addressed by 202 hosts elsewhere on the Internet without any changes to their own 203 software. 205 [RFC1812] noted in section 4.2.3.1 that whether a reserved address is 206 treated specially at all depends on one's vantage point on the 207 network: 209 | [a] router obviously cannot recognize addresses of the form { 210 | , 0 } if the router has no interface to that 211 | network prefix. In that case, the rules of the second bullet 212 | [requiring a packet to be discarded] do not apply because, from 213 | the point of view of the router, the packet is not an IP broadcast 214 | packet. 216 It also noted in section 5.3.5.2 that 218 | in view of CIDR, such [packets addressed to broadcast addresses of 219 | distant networks] appear to be host addresses within the network 220 | prefix; we preclude inspection of the host part of such network 221 | prefixes. 223 To the extent that software continues to make assumptions about IP 224 network classes today, it is out of compliance with RFC 4632. Ever 225 since the adoption of CIDR in RFC 1519, it has been unknowable 226 whether or to what extent the remote network would internally 227 aggregate or deaggregate routes that were visible elsewhere on the 228 Internet. Therefore, Internet hosts and routers MUST NOT assume that 229 an IPv4 address on a remote network, other than 0.0.0.0, is invalid, 230 unroutable, or inaccessible merely because it ends with a particular 231 number of zeroes. In keeping with the Internet's end-to-end 232 principle, decisions about possible invalidity of otherwise routable 233 addresses belong as close to the endpoints as possible. 235 2.2. Multicast Addresses; Point-to-Point Links 237 Multicast addresses, as defined by RFC 1112 [RFC1112], do not have a 238 network part and host part, nor do they have a netmask or CIDR prefix 239 length. IPv4 multicast addresses, except 224.0.0.0 (which is 240 "guaranteed not to be assigned to any group" by RFC 1112), could 241 always end with any number of zeroes, and have never had any form of 242 directed broadcast address. 244 [RFC3021], section 2.1, standardized that, in a point-to-point link 245 using a 31-bit netmask, the all-zero and all-one forms of the host- 246 part of the address MUST both be treated as unicast ("host") 247 addresses. 249 The present document does not change the interpretation of multicast 250 addresses or 31-bit subnet addresses in any way. 252 2.3. Current Limitations on Subnet-Directed Broadcast Addresses 254 Sending packets to a subnet-directed broadcast address is still 255 generally useful in today's Internet, but only for nodes attached 256 directly to that subnet. [RFC2644] discouraged routers from 257 forwarding such packets, to reduce their use in amplifying denial-of- 258 service attacks, so they often cannot be received when sent from 259 distant hosts. Many hosts today ignore ICMP packets sent as 260 broadcasts, so a directed broadcast ping is no longer a reliable 261 means of enumerating all hosts attached to a network. As 262 Informational [RFC6250] notes, "broadcast can only be relied on 263 within a link". 265 2.4. Comparison to IPv6 Behavior 267 In IPv6 there are no reserved per-segment broadcast addresses (or, 268 indeed, any broadcast addresses whatsoever). Instead, IPv6 hosts can 269 address all hosts on a network segment by using the link-local 270 multicast group address ff02::1 [RFC4291], which, for example, 271 produces a multicast Ethernet frame when transmitted over an 272 Ethernet-like link [RFC2464]. The lowest address on a subnet is, 273 however, reserved in IPv6 by Section 2.6.1 of RFC 4291 [RFC4291] for 274 the Subnet-Router address (a means of addressing "any router" on an 275 indicated subnet). 277 3. Change to Interpretation of the Lowest Address 279 The purpose of this document is to designate the all-zeros address in 280 each subnet as a unicast address. All such addresses are now 281 available for general non-broadcast use, treated identically to all 282 host addresses in the subnet besides the "all-ones" broadcast 283 address. This document therefore eliminates an element of the IPv4 284 protocol's historical adaptation to 4.2BSD's behavior. All hosts 285 SHOULD continue to recognize and accept only the all-ones form of the 286 IPv4 subnet broadcast address. 288 Host software that intends to transmit a segment-directed broadcast 289 packet in an IPv4 network MUST use only the all-ones form as the 290 destination address of the packet. 292 An IPv4 datagram containing a source or destination that is equal to 293 the all-zeroes form of the local broadcast address SHOULD be treated, 294 by both hosts and routers, as a normal unicast datagram; it SHOULD 295 NOT be treated as a local broadcast datagram. 297 Host software SHOULD allow a network interface to be configured with 298 the lowest address on a subnet. A host with such an address 299 configured MUST use this assigned address as a source address for 300 datagrams just as it would with any other assigned interface address, 301 and MUST recognize a datagram sent to that address as addressed to 302 itself. Host software SHOULD be capable of generating unicast 303 packets to the lowest address on a subnet when so requested by an 304 application, and MUST encapsulate such packets into link-layer 305 unicast frames when transmitted on a link layer that distinguishes 306 unicast and broadcast. 308 Clients for autoconfiguration mechanisms such as DHCP [RFC2131] 309 SHOULD accept a lease or assignment of the lowest address whenever 310 the underlying operating system is capable of accepting it. Servers 311 for these mechanisms SHOULD assign this address when so configured. 312 The network operator of each subnet retains the discretion to number 313 hosts on that subnet with, or without, the use of the lowest address, 314 based on local conditions. 316 3.1. Link-Layer Interaction 318 The link layer always indicates to the IP layer whether or not a 319 datagram was transmitted as a broadcast at the link layer. Hosts 320 MUST continue to follow the RFC 1122 rule about link-layer broadcast 321 indications: 323 | A host SHOULD silently discard a datagram that is received via a 324 | link-layer broadcast [...] but does not specify an IP multicast or 325 | broadcast destination address. 327 This rule is, among other things, intended to avoid broadcast storms. 328 This document now defines the lowest address as a non-broadcast 329 address. Therefore, a host SHOULD silently discard a datagram 330 received via a link-layer broadcast whose destination address is the 331 lowest IPv4 address in a subnet. This is true even if the interface 332 on which the host received that datagram uses the lowest address as a 333 unicast IPv4 address. 335 3.2. Recommendations 337 The considerations presented in this document affect other published 338 work. This section details the updates made to other documents. 340 3.2.1. "Requirements for Internet Hosts -- Communication Layers" 341 [RFC1122] 343 The new section numbered 3.2.1.3 (h) which was added by RFC 3021 is 344 replaced with: 346 | (h) { , , 0 } 347 | 348 | An ordinary unicast ("host") address in the subnet. May be used 349 | as either a source or destination address. If a link-level 350 | broadcast packet is received with this address (or any other 351 | unicast address) as its destination, it MUST be silently 352 | discarded. Such a packet may be sent by long-obsolete hosts on 353 | the local network. 354 | 355 | In applications using CIDR notation [RFC4632], this address, or 356 | any other address in the subnet, may also be used together with a 357 | prefix length to refer to the entire subnet. 359 3.2.2. "Requirements for IP Version 4 Routers" [RFC1812] 361 The new section (numbered 4.2.2.11 (f)) added by RFC 3021 is replaced 362 by: 364 | (f) { , 0 } 365 | 366 | An ordinary unicast ("host") address in the subnet. May be used 367 | as either a source or destination address. If a link-layer 368 | broadcast packet is received with this address (or any other 369 | unicast address) as its destination, it MUST be silently 370 | discarded. Such a packet may be sent by long-obsolete hosts on 371 | the local network. 372 | 373 | In applications using CIDR notation [RFC4632], this address, or 374 | any other address in the subnet, may also be used together with a 375 | prefix length to refer to the entire subnet. 377 The first paragraph on page 49 (which appears after section 4.2.2.11 378 (e) in the original RFC 1812, or after section 4.2.2.11 (f) in RFC 379 1812 as modified by RFC 3021) is changed from this original text 381 | IP addresses are not permitted to have the value 0 or -1 for the 382 | or fields except in the special 383 | cases listed above. This implies that each of these fields will 384 | be at least two bits long. 385 | 386 | DISCUSSION 387 | 388 | Previous versions of this document also noted that subnet numbers 389 | must be neither 0 nor -1, and must be at least two bits in length. 390 | In a CIDR world, the subnet number is clearly an extension of the 391 | network prefix and cannot be interpreted without the remainder of 392 | the prefix. This restriction of subnet numbers is therefore 393 | meaningless in view of CIDR and may be safely ignored. 395 to this new text 397 | Unicast IP addresses are permitted to have the value 0 for the 398 | field, and may have the value -1 in the special 399 | cases listed above. There is no requirement that the field be any particular length. In some cases using CIDR 401 | notation, a host may be designated with a /32 suffix (e.g. 402 | 192.0.2.34/32), indicating that the specific host rather than its 403 | subnet is being described. 404 | 405 | DISCUSSION 406 | 407 | Previous versions of this document also noted that subnet numbers 408 | must be neither 0 nor -1, and must be at least two bits in length. 409 | Other versions required that fields must be 410 | neither 0 nor -1, and must be at least two bits long. 411 | 412 | Now that the Internet has fully transitioned to CIDR routing, 413 | there are no original classful s to be 414 | distinguished from . Each address only has a 415 | based on its network mask (or equivalently, the 416 | CIDR suffix specifying how many bits are in the ). 417 | The former restrictions on subnet numbers and their sizes are 418 | meaningless in view of CIDR and are hereby repealed. For example, 419 | a route to 0.0.0.0/6 or even 0.0.0.0/1 is a viable CIDR route (for 420 | the aggregation of the blocks 0/8, 1/8, 2/8, and 3/8; or for the 421 | entire lower half of the IPv4 address space) and should not be 422 | considered invalid. 0.0.0.0/0 is standardized to mean "all unicast 423 | IPv4 addresses", e.g. in a default route, by section 5.1 of 424 | [RFC4632], which MUST also continue to work. 426 Sections 4.2.3.1 (2) and (4) are replaced with: 428 | (2) SHOULD silently discard on receipt (i.e., do not even deliver 429 | to applications in the router) any packet addressed to 0.0.0.0. 430 | If these packets are not silently discarded, they MUST be treated 431 | as IP broadcasts (see Section [5.3.5]). There MAY be a 432 | configuration option to allow receipt of these packets. This 433 | option SHOULD default to discarding them. 434 | 435 | A packet addressed to { , 0 } is an ordinary 436 | unicast packet, and MUST be treated as such. 437 | 438 | (4) SHOULD NOT originate datagrams addressed to 0.0.0.0. SHOULD 439 | allow for the generation of datagrams addressed to {, 0 } since that is now defined as an ordinary unicast 441 | adddress. 443 3.3. Example 445 The only IPv4 broadcast address for 192.168.42.0/24 is 192.168.42.255 446 (the all-ones or "-1" host number). 192.168.42.0 (the all-zeroes or 447 "0" host number) was formerly a second broadcast address on that 448 subnet, but is now a unicast address. 450 The fact that the address identifier 192.168.42.0 can refer to both a 451 network and a specific host 192.168.42.0 is not unusual. Similarly, 452 referring to a subnet as 192.168.42.0/24 and configuring a particular 453 interface on that subnet as 192.168.42.0/24 is also not unusual. 454 Computer scientists normally count all sorts of things starting at 455 the zeroth (lowest) element in a sequence.[EWD831] For example, the 456 initial element in an array is likely to be stored at a memory 457 address equal to the memory address of the array itself.[ARRAY] 458 Similarly, IPv4 hosts in a subnet MAY be enumerated starting with an 459 address that matches the address of the subnet itself. 461 Similarly, the only IPv4 broadcast address for the subnet 462 192.168.42.96/28 is 192.168.42.111. The address 192.168.42.96 MAY be 463 assigned to an individual host on this network. 465 3.4. Compatibility and Interoperability 467 Many deployed systems follow older Internet standards in not allowing 468 the lowest address in a network to be assigned or used as a source or 469 destination address. Assigning this address to a host may thus make 470 it inaccessible by some devices on its local network segment. 471 Network operators considering assigning this address to a host should 472 investigate their own network environments to determine whether their 473 interoperability requirements will be met. Interoperability with 474 these addresses is likely to improve over time, following the 475 publication of this document. 477 Prior standards required hosts and routers to ignore, and to refrain 478 from generating, non-broadcast datagrams from or to the lowest 479 address. So when a single network contains a device that has been 480 assigned the lowest address as specified by this document, along with 481 one or more devices that follow the traditional behavior, the 482 traditional devices will not be able to communicate with the lowest- 483 address device at all. Other sorts of malfunctions are unlikely, 484 because the former standards (RFC 1122) required traditional hosts to 485 drop any unicast packet addressed to the secondary broadcast address 486 that they implemented at the lowest address. 488 4. IANA Considerations 490 This memo includes no request to IANA. 492 5. Security Considerations 494 The behavior change specified by this document could produce security 495 concerns where two devices, or two different pieces of software on a 496 single host, or a software application and a human user, follow 497 divergent interpretations of the lowest address on a network. For 498 example, this could lead to errors in the specification or 499 enforcement of rules about Internet hosts' connectivity to one 500 another, or their right to access resources. 502 Firewall rules that assume that the lowest address on a subnet cannot 503 be addressed SHOULD be updated to take into account that it can be 504 addressed, so as to avoid either unintentionally allowing or 505 unintentionally forbidding connections involving it. Other security, 506 monitoring, or logging systems that treat the lowest address as an 507 inaccessible bogon address SHOULD likewise be updated. 509 Host software SHOULD make the distinction between lowest-address 510 (considered individually) and subnet (considered as a group) clear to 511 users, where this distinction is relevant and could be a subject of 512 confusion. 514 6. Acknowledgements 516 This document directly builds on prior work by Dave Täht and 517 John Gilmore as part of the IPv4 Unicast Extensions Project. 519 7. References 521 7.1. Normative References 523 [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, 524 RFC 919, DOI 10.17487/RFC0919, October 1984, 525 . 527 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 528 Communication Layers", STD 3, RFC 1122, 529 DOI 10.17487/RFC1122, October 1989, 530 . 532 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 533 RFC 1812, DOI 10.17487/RFC1812, June 1995, 534 . 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, 538 DOI 10.17487/RFC2119, March 1997, 539 . 541 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 542 (CIDR): The Internet Address Assignment and Aggregation 543 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 544 2006, . 546 7.2. Informative References 548 [ARRAY] Wikipedia, "C Programming Language: Array-pointer 549 interchangeability", . 553 [BSDHIST] Wikipedia, "History of the Berkeley Software 554 Distribution", . 557 [EWD831] Dijkstra, E.W., "Why Numbering Should Start at Zero", 558 August 1982, 559 . 562 [IEN212] Gurwitz, R. and R. Hinden, "IP - Local Area Network 563 Addressing Issues", IEN 212, September 1982, 564 . 566 [RFC0894] Hornig, C., "A Standard for the Transmission of IP 567 Datagrams over Ethernet Networks", STD 41, RFC 894, 568 DOI 10.17487/RFC0894, April 1984, 569 . 571 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 572 RFC 1112, DOI 10.17487/RFC1112, August 1989, 573 . 575 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 576 RFC 2131, DOI 10.17487/RFC2131, March 1997, 577 . 579 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 580 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 581 . 583 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 584 in Routers", BCP 34, RFC 2644, DOI 10.17487/RFC2644, 585 August 1999, . 587 [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, 588 "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", 589 RFC 3021, DOI 10.17487/RFC3021, December 2000, 590 . 592 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 593 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 594 2006, . 596 [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, 597 DOI 10.17487/RFC6250, May 2011, 598 . 600 Appendix A. Implementation Status 602 The behavior specified in this document has been implemented by 603 OpenBSD since version 4.7, released in May 2010. 605 The behavior specified in this document has been implemented by the 606 Linux kernel since version 5.14, released in August 2021. 608 The lowest address per subnet is treated as unicast in the OS 609 releases Fedora 35 (released in November 2021) and Ubuntu 22.04 610 (released in April 2022). In addition, nodes that run Fedora 34 and 611 install the standard online updates also implement this feature. 613 This behavior has not yet been implemented in a standard Android 614 release, as of 2022-03-29. 616 This behavior has also been implemented in FreeBSD since 13.1-beta1, 617 released in March 2022. The FreeBSD and Linux implementations 618 interoperate successfully. 620 To our knowledge, the behavior specified by this document is not 621 currently the default in any other TCP/IP implementation. 623 Authors' Addresses 625 Seth David Schoen 626 IPv4 Unicast Extensions Project 627 San Francisco, CA 628 United States of America 629 Email: schoen@loyalty.org 631 John Gilmore 632 IPv4 Unicast Extensions Project 633 PO Box 170640-rfc 634 San Francisco, CA 94117-0640 635 United States of America 636 Email: gnu@rfc.toad.com 638 David M. Täht 639 IPv4 Unicast Extensions Project 640 Half Moon Bay, CA 641 United States of America 642 Email: dave@taht.net 644 Michael J. Karels 645 Eden Prairie, MN 646 United States of America 647 Email: rfc@karels.net