idnits 2.17.1 draft-schoen-intarea-lowest-address-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 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 (17 September 2021) is 950 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: 21 March 2022 M. Karels 7 17 September 2021 9 The Lowest Address in an IPv4 Subnet 10 draft-schoen-intarea-lowest-address-01 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 21 March 2022. 40 Copyright Notice 42 Copyright (c) 2021 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 Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 This document provides history and rationale to change the 84 interpretation of the lowest address in each IPv4 subnet from an 85 alternative broadcast address to an ordinary assignable host address, 86 and updates requirements for hosts and routers accordingly. The 87 decision taken in 1989 to reserve two forms instead of one for local 88 IPv4 segment broadcasts is no longer necessary because of the 89 obsolescence and disappearance of the software that motivated it. 90 Unreserving the lowest address provides an optional extra IPv4 host 91 address in every subnet, Internet-wide, alleviating some of the 92 pressure of IPv4 address exhaustion. 94 1.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 2. Background and Current Standards 102 IPv4 has long supported several mechanisms for broadcasting 103 communications to every station on a network. One form of broadcast 104 in IPv4 is "segment-directed broadcast" in which a broadcast is 105 addressed to every station on a particular network (identified by its 106 network number). Current standards reserve a huge number of 107 addresses for this: not just one, but two, addresses per subnet, 108 Internet-wide. 110 The standard broadcast address on a subnet is the address whose "host 111 part" consists of all ones in binary. For example, in a 24-bit 112 subnet that starts at 192.168.3.0, the address 192.168.3.255 is the 113 standard broadcast address. [RFC1122][RFC0894] 115 In addition to the standard broadcast address, RFC 1122 (October 116 1989) acknowledged a then-current implementation behavior in "4.2BSD 117 Unix and its derivatives, but not 4.3BSD", whereby those operating 118 systems "use non-standard broadcast address forms, substituting 0 for 119 -1". (Note that there was no standard for IP broadcast when 4.2BSD 120 was released in August 1983, more than a year prior to [RFC0919]. 121 The -1 form was first proposed in [IEN212] in 1982 but was not yet a 122 standard.) According to RFC 1122 and its successors, Internet hosts 123 are expected to "recognize and accept [...] these non-standard 124 broadcast addresses as the destination address of an incoming 125 datagram", and not otherwise use them to identify Internet hosts. 126 RFCs 1812 [RFC1812] (sections 4.2.3.1 and 5.3.5), and 3021 [RFC3021] 127 (sections 2.2, 3.1, and 3.3) reiterate and further expand on this 128 requirement. 130 This non-standard broadcast address is the address whose "host part" 131 consists of all zeroes. (The quantity of zeroes depends, in present- 132 day terminology, on the applicable subnet mask.) This address is the 133 lowest expressible address within any particular numbered network. 134 Following computer science tradition, it may also be referred to as 135 the "zeroth address" of its respective subnet. 137 The address triple syntax used in RFC 1122 looks unusual to modern 138 eyes. These triples included the "{ network number, subnet number, 139 host number }". The notation also used two's complement binary 140 notation in referring to a host number "-1" as containing all binary 141 1-bits. After the widespread adoption of CIDR [RFC4632], network 142 numbers no longer have an "address class" definition based on their 143 high-order bits, and there is no distinction between a network number 144 and a subnet number (except locally at the router where individual 145 subnets are being routed). Instead, following RFC 4632, IPv4 network 146 addresses are denoted with a dotted-decimal format containing one to 147 four positive 8-bit integers, a slash, and a whole count of the bits 148 in the network number portion, the so-called CIDR notation, 149 reportedly devised by Phil Karn. So for example 192.1.2.0/28 has a 150 28-bit network number and a 4-bit host number (32 address bits total, 151 minus those 28 bits). All of the bits of that particular host number 152 are zero (because the whole fourth dotted number is 0), and thus the 153 interpretation of this address would be affected by this document. 154 We will use both notations as convenient. Where RFC 1122 and its 155 successors use the terms "0 form" and "-1 form", we may refer 156 respectively to "all-zeros" and "all-ones" host numbers, since every 157 bit in the binary representation of these two host numbers has the 158 value 0 or 1, respectively. 160 4.2BSD, the operating system to whose behavior RFC 1122 required 161 deference, was the first BSD operating system full release to include 162 TCP/IP support; it was released in 1983. Its successor, 4.3BSD, was 163 released in 1986, which is why RFC 1122 could already confirm that 164 the broadcast behavior had been changed. See [BSDHIST]. RFC 1812 165 calls the old behavior "obsolete" in 1995, and RFC 3021 reiterates 166 that it is "obsolete" in 2000, although both express the idea that 167 the lowest address must continue to be reserved for historical 168 reasons. 170 All subsequent operating systems used on the Internet implement the 171 standard all-ones form of the broadcast address and use it by 172 default. Continuing to reserve the non-standard all-zeroes form 173 wastes one IPv4 address per subnet. No known operating system 174 generates IP broadcasts in this format today, and documentation 175 consistently encourages network administrators and software 176 developers to use the standard form. The IPv4 protocol does not 177 benefit from having two different broadcast addresses with the same 178 functionality in every subnet, and the non-standard form has always 179 been reserved primarily for backwards compatibility with systems that 180 have not existed for decades on the Internet. 182 As IPv4 addresses were not perceived as particularly scarce through 183 the 1980s, the prospect of wasting tens of millions of otherwise 184 assignable addresses in order to achieve backwards compatibility with 185 a particular operating system appeared reasonable. Today, those 186 addresses are clearly valuable and could be put to good use as 187 identifiers of Internet hosts in a time of IPv4 numbering resource 188 exhaustion. 190 2.1. Assumptions About the Lowest Host Address by Remote Systems 192 In general, under CIDR [RFC4632], only hosts and routers on a network 193 segment know that segment's netmask with certainty. Remote parts of 194 the Internet are already expected to not make assumptions about 195 whether or not a particular address is a broadcast address, since 196 that determination is already only meaningful for devices connected 197 to the segment containing that address. This document does not 198 change any of these things. Thus, if the behavior of devices on a 199 particular network segment has been updated in accordance with this 200 memo, the lowest address on that segment can already be addressed by 201 hosts elsewhere on the Internet without any changes to their own 202 software. 204 [RFC1812] noted in section 4.2.3.1 that whether a reserved address is 205 treated specially at all depends on one's vantage point on the 206 network: 208 | [a] router obviously cannot recognize addresses of the form { 209 | , 0 } if the router has no interface to that 210 | network prefix. In that case, the rules of the second bullet 211 | [requiring a packet to be discarded] do not apply because, from 212 | the point of view of the router, the packet is not an IP broadcast 213 | packet. 215 It also noted in section 5.3.5.2 that 217 | in view of CIDR, such [packets addressed to broadcast addresses of 218 | distant networks] appear to be host addresses within the network 219 | prefix; we preclude inspection of the host part of such network 220 | prefixes. 222 To the extent that software continues to make assumptions about IP 223 network classes today, it is out of compliance with RFC 4632. Ever 224 since the adoption of CIDR in RFC 1519, it has been unknowable 225 whether or to what extent the remote network would internally 226 aggregate or deaggregate routes that were visible elsewhere on the 227 Internet. Therefore, Internet hosts and routers MUST NOT assume that 228 an IPv4 address on a remote network, other than 0.0.0.0, is invalid, 229 unroutable, or unaddressable merely because it ends with a particular 230 number of zeroes. In keeping with the Internet's end-to-end 231 principle, decisions about possible invalidity of otherwise routable 232 addresses belong as close to the endpoints as possible. 234 2.2. Multicast Addresses; Point-to-Point Links 236 Multicast addresses, as defined by RFC 1112 [RFC1112], do not have a 237 network part and host part, nor do they have a netmask or CIDR prefix 238 length. IPv4 multicast addresses, except 224.0.0.0 (which is 239 "guaranteed not to be assigned to any group" by RFC 1112), could 240 always end with any number of zeroes, and have never had any form of 241 directed broadcast address. 243 [RFC3021], section 2.1, standardized that, in a point-to-point link 244 using a 31-bit netmask, the all-zero and all-one forms of the host- 245 part of the address MUST both be treated as unicast ("host") 246 addresses. 248 The present document does not change the interpretation of multicast 249 addresses or 31-bit subnet addresses in any way. 251 2.3. Current Limitations on Subnet-Directed Broadcast Addresses 253 Sending packets to a subnet-directed broadcast address is still 254 generally useful in today's Internet, but only for nodes attached 255 directly to that subnet. [RFC2644] discouraged routers from 256 forwarding such packets, to reduce their use in amplifying denial-of- 257 service attacks, so they often cannot be received when sent from 258 distant hosts. Many hosts today ignore ICMP packets sent as 259 broadcasts, so a directed broadcast ping is no longer a reliable 260 means of enumerating all hosts attached to a network. As 261 Informational [RFC6250] notes, "broadcast can only be relied on 262 within a link". 264 2.4. Comparison to IPv6 Behavior 266 In IPv6 there are no reserved per-segment broadcast addresses (or, 267 indeed, any broadcast addresses whatsoever). Instead, IPv6 hosts can 268 address all hosts on a network segment by using the link-local 269 multicast group address ff02::1 [RFC4291], which, for example, 270 produces a multicast Ethernet frame when transmitted over an 271 Ethernet-like link [RFC2464]. The lowest address on a subnet is, 272 however, reserved in IPv6 by Section 2.6.1 of RFC 4291 [RFC4291] for 273 the Subnet-Router address (a means of addressing "any router" on an 274 indicated subnet). 276 3. Change to Interpretation of the Lowest Address 278 The purpose of this document is to designate the all-zeros address in 279 each subnet as a unicast address. All such addresses are now 280 available for general non-broadcast use, treated identically to all 281 host addresses in the subnet besides the "all-ones" broadcast 282 address. This document therefore eliminates an element of the IPv4 283 protocol's historical adaptation to 4.2BSD's behavior. All hosts 284 SHOULD continue to recognize and accept only the all-ones form of the 285 IPv4 subnet broadcast address. 287 Host software that intends to transmit a segment-directed broadcast 288 packet in an IPv4 network MUST use only the all-ones form as the 289 destination address of the packet. 291 An IPv4 datagram containing a source or destination that is equal to 292 the all-zeroes form of the local broadcast address SHOULD be treated, 293 by both hosts and routers, as a normal unicast datagram; it SHOULD 294 NOT be treated as a local broadcast datagram. 296 Host software SHOULD allow a network interface to be configured with 297 the lowest address on a subnet. A host with such an address 298 configured MUST use this assigned address as a source address for 299 datagrams just as it would with any other assigned interface address, 300 and MUST recognize a datagram sent to that address as addressed to 301 itself. Host software SHOULD be capable of generating unicast 302 packets to the lowest address on a subnet when so requested by an 303 application, and MUST encapsulate such packets into link-layer 304 unicast frames when transmitted on a link layer that distinguishes 305 unicast and broadcast. 307 Clients for autoconfiguration mechanisms such as DHCP [RFC2131] 308 SHOULD accept a lease or assignment of the lowest address whenever 309 the underlying operating system is capable of accepting it. Servers 310 for these mechanisms SHOULD assign this address when so configured. 311 The network operator of each subnet retains the discretion to number 312 hosts on that subnet with, or without, the use of the lowest address, 313 based on local conditions. 315 3.1. Link-Layer Interaction 317 The link layer always indicates to the IP layer whether or not a 318 datagram was transmitted as a broadcast at the link layer. Hosts 319 MUST continue to follow the RFC 1122 rule about link-layer broadcast 320 indications: 322 | A host SHOULD silently discard a datagram that is received via a 323 | link-layer broadcast [...] but does not specify an IP multicast or 324 | broadcast destination address. 326 This rule is, among other things, intended to avoid broadcast storms. 327 This document now defines the lowest address as a non-broadcast 328 address. Therefore, a host SHOULD silently discard a datagram 329 received via a link-layer broadcast whose destination address is the 330 lowest IPv4 address in a subnet. This is true even if the interface 331 on which the host received that datagram uses the lowest address as a 332 unicast IPv4 address. 334 3.2. Recommendations 336 The considerations presented in this document affect other published 337 work. This section details the updates made to other documents. 339 3.2.1. "Requirements for Internet Hosts -- Communication Layers" 340 [RFC1122] 342 The new section numbered 3.2.1.3 (h) which was added by RFC 3021 is 343 replaced with: 345 | (h) { , , 0 } 346 | 347 | An ordinary unicast ("host") address in the subnet. May be used 348 | as either a source or destination address. If a link-level 349 | broadcast packet is received with this address (or any other 350 | unicast address) as its destination, it MUST be silently 351 | discarded. Such a packet may be sent by long-obsolete hosts on 352 | the local network. 353 | 354 | In applications using CIDR notation [RFC4632], this address, or 355 | any other address in the subnet, may also be used together with a 356 | prefix length to refer to the entire subnet. 358 3.2.2. "Requirements for IP Version 4 Routers" [RFC1812] 360 The new section (numbered 4.2.2.11 (f)) added by RFC 3021 is replaced 361 by: 363 | (f) { , 0 } 364 | 365 | An ordinary unicast ("host") address in the subnet. May be used 366 | as either a source or destination address. If a link-layer 367 | broadcast packet is received with this address (or any other 368 | unicast address) as its destination, it MUST be silently 369 | discarded. Such a packet may be sent by long-obsolete hosts on 370 | the local network. 371 | 372 | In applications using CIDR notation [RFC4632], this address, or 373 | any other address in the subnet, may also be used together with a 374 | prefix length to refer to the entire subnet. 376 The first paragraph on page 49 (which appears after section 4.2.2.11 377 (e) in the original RFC 1812, or after section 4.2.2.11 (f) in RFC 378 1812 as modified by RFC 3021) is changed from this original text 380 | IP addresses are not permitted to have the value 0 or -1 for the 381 | or fields except in the special 382 | cases listed above. This implies that each of these fields will 383 | be at least two bits long. 384 | 385 | DISCUSSION 386 | 387 | Previous versions of this document also noted that subnet numbers 388 | must be neither 0 nor -1, and must be at least two bits in length. 389 | In a CIDR world, the subnet number is clearly an extension of the 390 | network prefix and cannot be interpreted without the remainder of 391 | the prefix. This restriction of subnet numbers is therefore 392 | meaningless in view of CIDR and may be safely ignored. 394 to this new text 396 | Unicast IP addresses are permitted to have the value 0 for the 397 | field, and may have the value -1 in the special 398 | cases listed above. There is no requirement that the field be any particular length. In some cases using CIDR 400 | notation, a host may be designated with a /32 suffix (e.g. 401 | 192.0.2.34/32), indicating that the specific host rather than its 402 | subnet is being described. 403 | 404 | DISCUSSION 405 | 406 | Previous versions of this document also noted that subnet numbers 407 | must be neither 0 nor -1, and must be at least two bits in length. 408 | Other versions required that fields must be 409 | neither 0 nor -1, and must be at least two bits long. 410 | 411 | Now that the Internet has fully transitioned to CIDR routing, 412 | there are no original classful s to be 413 | distinguished from . Each address only has a 414 | based on its network mask (or equivalently, the 415 | CIDR suffix specifying how many bits are in the ). 416 | The former restrictions on subnet numbers and their sizes are 417 | meaningless in view of CIDR and are hereby repealed. For example, 418 | a route to 0.0.0.0/6 or even 0.0.0.0/1 is a viable CIDR route (for 419 | the aggregation of the blocks 0/8, 1/8, 2/8, and 3/8; or for the 420 | entire lower half of the IPv4 address space) and should not be 421 | considered invalid. 0.0.0.0/0 is standardized to mean "all unicast 422 | IPv4 addresses", e.g. in a default route, by section 5.1 of 423 | [RFC4632], which MUST also continue to work. 425 Sections 4.2.3.1 (2) and (4) are replaced with: 427 | (2) SHOULD silently discard on receipt (i.e., do not even deliver 428 | to applications in the router) any packet addressed to 0.0.0.0. 429 | If these packets are not silently discarded, they MUST be treated 430 | as IP broadcasts (see Section [5.3.5]). There MAY be a 431 | configuration option to allow receipt of these packets. This 432 | option SHOULD default to discarding them. 433 | 434 | A packet addressed to { , 0 } is an ordinary 435 | unicast packet, and MUST be treated as such. 436 | 437 | (4) SHOULD NOT originate datagrams addressed to 0.0.0.0. SHOULD 438 | allow for the generation of datagrams addressed to {, 0 } since that is now defined as an ordinary unicast 440 | adddress. 442 3.3. Example 444 The only IPv4 broadcast address for 192.168.42.0/24 is 192.168.42.255 445 (the all-ones or "-1" host number). 192.168.42.0 (the all-zeroes or 446 "0" host number) was formerly a second broadcast address on that 447 subnet, but is now a unicast address. 449 The fact that the address identifier 192.168.42.0 can refer to both a 450 network and a specific host 192.168.42.0 is not unusual. Similarly, 451 referring to a subnet as 192.168.42.0/24 and configuring a particular 452 interface on that subnet as 192.168.42.0/24 is also not unusual. 453 Computer scientists normally count all sorts of things starting at 454 the zeroth (lowest) element in a sequence.[EWD831] For example, the 455 initial element in an array is likely to be stored at a memory 456 address equal to the memory address of the array itself.[ARRAY] 457 Similarly, IPv4 hosts in a subnet MAY be enumerated starting with an 458 address that matches the address of the subnet itself. 460 Similarly, the only IPv4 broadcast address for the subnet 461 192.168.42.96/28 is 192.168.42.111. The address 192.168.42.96 MAY be 462 assigned to an individual host on this network. 464 3.4. Compatibility and Interoperability 466 Many deployed systems follow older Internet standards in not allowing 467 the lowest address in a network to be assigned or used as a source or 468 destination address. Assigning this address to a host may thus make 469 it unaddressable by some devices on its local network segment. 470 Network operators considering assigning this address to a host should 471 investigate their own network environments to determine whether their 472 interoperability requirements will be met. Interoperability with 473 these addresses is likely to improve over time, following the 474 publication of this document. 476 Prior standards required hosts and gateways to ignore, and to refrain 477 from generating, non-broadcast datagrams from or to the lowest 478 address. So when a single network contains a device that has been 479 assigned the lowest address as specified by this document, along with 480 one or more devices that follow the traditional behavior, the 481 traditional devices will not be able to communicate with the lowest- 482 address device at all. Other sorts of malfunctions are unlikely, 483 because the former standards (RFC 1122) required traditional hosts to 484 drop any unicast packet addressed to the secondary broadcast address 485 that they implemented at the lowest address. 487 4. IANA Considerations 489 This memo includes no request to IANA. 491 5. Security Considerations 493 The behavior change specified by this document could produce security 494 concerns where two devices, or two different pieces of software on a 495 single host, or a software application and a human user, follow 496 divergent interpretations of the lowest address on a network. For 497 example, this could lead to errors in the specification or 498 enforcement of rules about Internet hosts' connectivity to one 499 another, or their right to access resources. 501 Firewall rules that assume that the lowest address on a subnet cannot 502 be addressed SHOULD be updated to take into account that it can be 503 addressed, so as to avoid either unintentionally allowing or 504 unintentionally forbidding connections involving it. Other security, 505 monitoring, or logging systems that treat the lowest address as an 506 unaddressable bogon address SHOULD likewise be updated. 508 Host software SHOULD make the distinction between lowest-address 509 (considered individually) and subnet (considered as a group) clear to 510 users, where this distinction is relevant and could be a subject of 511 confusion. 513 6. Acknowledgements 515 This document directly builds on prior work by Dave Täht and 516 John Gilmore as part of the IPv4 Unicast Extensions Project. 518 7. References 520 7.1. Normative References 522 [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, 523 RFC 919, DOI 10.17487/RFC0919, October 1984, 524 . 526 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 527 Communication Layers", STD 3, RFC 1122, 528 DOI 10.17487/RFC1122, October 1989, 529 . 531 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 532 RFC 1812, DOI 10.17487/RFC1812, June 1995, 533 . 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, 537 DOI 10.17487/RFC2119, March 1997, 538 . 540 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 541 (CIDR): The Internet Address Assignment and Aggregation 542 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 543 2006, . 545 7.2. Informative References 547 [ARRAY] Wikipedia, "C Programming Language: Array-pointer 548 interchangeability", . 552 [BSDHIST] Wikipedia, "History of the Berkeley Software 553 Distribution", . 556 [EWD831] Dijkstra, E.W., "Why Numbering Should Start at Zero", 557 August 1982, 558 . 561 [IEN212] Gurwitz, R. and R. Hinden, "IP - Local Area Network 562 Addressing Issues", IEN 212, September 1982, 563 . 565 [RFC0894] Hornig, C., "A Standard for the Transmission of IP 566 Datagrams over Ethernet Networks", STD 41, RFC 894, 567 DOI 10.17487/RFC0894, April 1984, 568 . 570 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 571 RFC 1112, DOI 10.17487/RFC1112, August 1989, 572 . 574 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 575 RFC 2131, DOI 10.17487/RFC2131, March 1997, 576 . 578 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 579 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 580 . 582 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 583 in Routers", BCP 34, RFC 2644, DOI 10.17487/RFC2644, 584 August 1999, . 586 [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, 587 "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", 588 RFC 3021, DOI 10.17487/RFC3021, December 2000, 589 . 591 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 592 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 593 2006, . 595 [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, 596 DOI 10.17487/RFC6250, May 2011, 597 . 599 Authors' Addresses 600 Seth David Schoen 601 IPv4 Unicast Extensions Project 602 San Francisco, CA 603 United States of America 605 Email: schoen@loyalty.org 607 John Gilmore 608 IPv4 Unicast Extensions Project 609 PO Box 170640-rfc 610 San Francisco, CA 94117-0640 611 United States of America 613 Email: gnu@rfc.toad.com 615 David M. Täht 616 IPv4 Unicast Extensions Project 617 Half Moon Bay, CA 618 United States of America 620 Email: dave@taht.net 622 Michael J. Karels 623 Eden Prairie, MN 624 United States of America 626 Email: rfc@karels.net