The Lowest Address in an IPv4 Subnet

Introduction This document provides history and rationale to change the interpretation of the lowest address in each IPv4 subnet from an alternative broadcast address to an ordinary assignable host address, and updates requirements for hosts and routers accordingly. The decision taken in 1989 to reserve two forms instead of one for local IPv4 segment broadcasts is no longer necessary because of the obsolescence and disappearance of the software that motivated it. Unreserving the lowest address provides an optional extra IPv4 host address in every subnet, Internet-wide, alleviating some of the pressure of IPv4 address exhaustion.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Background and Current Standards IPv4 has long supported several mechanisms for broadcasting communications to every station on a network. One form of broadcast in IPv4 is "segment-directed broadcast" in which a broadcast is addressed to every station on a particular network (identified by its network number). Current standards reserve a huge number of addresses for this: not just one, but two, addresses per subnet, Internet-wide. The standard broadcast address on a subnet is the address whose "host part" consists of all ones in binary. For example, in a 24-bit subnet that starts at 192.168.3.0, the address 192.168.3.255 is the standard broadcast address. In addition to the standard broadcast address, RFC 1122 (October 1989) acknowledged a then-current non-standard implementation behavior in "4.2BSD Unix and its derivatives, but not 4.3BSD", whereby those operating systems "use non-standard broadcast address forms, substituting 0 for -1". According to RFC 1122 and its successors, Internet hosts are expected to "recognize and accept [...] these non-standard broadcast addresses as the destination address of an incoming datagram", and not otherwise use them to identify Internet hosts. RFCs 1812 (sections 4.2.3.1 and 5.3.5), and 3021 (sections 2.2, 3.1, and 3.3) reiterate and further expand on this requirement. This non-standard broadcast address is the address whose "host part" consists of all zeroes. (The quantity of zeroes depends, in present-day terminology, on the applicable subnet mask.) This address is the lowest expressible address within any particular numbered network. Following computer science tradition, it may also be referred to as the "zeroth address" of its respective subnet. The address triple syntax used in RFC 1122 looks unusual to modern eyes. These triples included the "{ network number, subnet number, host number }". The notation also used two's complement binary notation in referring to a host number "-1" as containing all binary 1-bits. After the widespread adoption of CIDR, network numbers no longer have an "address class" definition based on their high-order bits, and there is no distinction between a network number and a subnet number (except locally at the router where individual subnets are being routed). Instead, following RFC 4632, IPv4 network addresses are denoted with a dotted-decimal format containing one to four positive 8-bit integers, a slash, and a whole count of the bits in the network number portion, the so-called CIDR notation, reportedly devised by Phil Karn. So for example 192.1.2.0/28 has a 28-bit network number and a 4-bit host number (32 address bits total, minus those 28 bits). All of the bits of that particular host number are zero (because the whole fourth dotted number is 0), and thus the interpretation of this address would be affected by this document. We will use both notations as convenient. Where RFC 1122 and its successors use the terms "0 form" and "-1 form", we may refer respectively to "all-zeros" and "all-ones" host numbers, since every bit in the binary representation of these two host numbers has the value 0 or 1, respectively. 4.2BSD, the operating system to whose non-standard behavior RFC 1122 required deference, was the first BSD operating system full release to include TCP/IP support; it was released in 1983. Its successor, 4.3BSD, was released in 1986, which is why RFC 1122 could already confirm that the broadcast behavior had been fixed. See . RFC 1812 calls the old behavior "obsolete" in 1995, and RFC 3021 reiterates that it is "obsolete" in 2000, although both express the idea that the lowest address must continue to be reserved for historical reasons. All subsequent operating systems used on the Internet implement the standard all-ones form of the broadcast address and use it by default. Continuing to reserve the non-standard all-zeroes form wastes one IPv4 address per subnet. No known operating system generates IP broadcasts in this format today, and documentation consistently encourages network administrators and software developers to use the standard form. The IPv4 protocol does not benefit from having two different broadcast addresses with the same functionality in every subnet, and the non-standard form has always been reserved primarily for backwards compatibility with systems that have not existed for decades on the Internet. As IPv4 addresses were not perceived as particularly scarce through the 1980s, the prospect of wasting tens of millions of otherwise assignable addresses in order to achieve backwards compatibility with a particular operating system appeared reasonable. Today, those addresses are clearly valuable and could be put to good use as identifiers of Internet hosts in a time of IPv4 numbering resource exhaustion.

Assumptions About the Lowest Host Address by Remote Systems In general, under CIDR, only hosts and routers on a network segment know that segment's netmask with certainty. Remote parts of the Internet are already expected to not make assumptions about whether or not a particular address is a broadcast address, since that determination is already only meaningful for devices connected to the segment containing that address. This document does not change any of these things. Thus, if the behavior of devices on a particular network segment has been updated in accordance with this memo, the lowest address on that segment can already be addressed by hosts elsewhere on the Internet without any changes to their own software. To the extent that software continues to make assumptions about IP network classes today, it is out of compliance with RFC 4632. Ever since the adoption of CIDR, it has been unknowable whether or to what extent the remote network would internally aggregate or deaggregate routes that were visible elsewhere on the Internet. Therefore, Internet hosts and routers MUST NOT assume that an IPv4 address on a remote network, other than 0.0.0.0, is invalid, unroutable, or unaddressable merely because it ends with a particular number of zeroes. In keeping with the Internet's end-to-end principle, decisions about possible invalidity of otherwise routable addresses belong as close to the endpoints as possible.

Multicast Addresses; Point-to-Point Links Multicast addresses, as defined by RFC 1112, do not have a network part and host part, nor do they have a netmask or CIDR prefix length. IPv4 multicast addresses, except 224.0.0.0 (which is "guaranteed not to be assigned to any group" by RFC 1112), could always end with any number of zeroes, and have never had any form of directed broadcast address. , section 2.1, standardized that, in a point-to-point link using a 31-bit netmask, the all-zero and all-one forms of the host-part of the address MUST both be treated as unicast ("host") addresses. The present document does not change the interpretation of multicast addresses or 31-bit subnet addresses in any way.

Current Limitations on Subnet-Directed Broadcast Addresses Sending packets to a subnet-directed broadcast address is still generally useful in today's Internet, but only for nodes attached directly to that subnet. discouraged routers from forwarding such packets, to reduce their use in amplifying denial-of-service attacks, so they often cannot be received when sent from distant hosts. Many hosts today ignore ICMP packets sent as broadcasts, so a directed broadcast ping is no longer a reliable means of enumerating all hosts attached to a network. As Informational notes, "broadcast can only be relied on within a link".

Comparison to IPv6 Behavior In IPv6 there are no reserved per-segment broadcast addresses (or, indeed, any broadcast addresses whatsoever). Instead, IPv6 hosts can address all hosts on a network segment by using the link-local multicast group address ff02::1, which, for example, produces a multicast Ethernet frame when transmitted over an Ethernet-like link. The lowest address on a subnet is, however, reserved in IPv6 by Section 2.6.1 of RFC 4291 for the Subnet-Router address (a means of addressing "any router" on an indicated subnet).

Change to Interpretation of the Lowest Address The purpose of this document is to designate the all-zeros address in each subnet as a unicast address. All such addresses are now available for general non-broadcast use, treated identically to all host addresses in the subnet besides the "all-ones" broadcast address. This document therefore eliminates an element of the IPv4 protocol's historical adaptation to 4.2BSD's non-standard behavior. All hosts SHOULD continue to recognize and accept only the all-ones form of the IPv4 subnet broadcast address. Host software that intends to transmit a segment-directed broadcast packet in an IPv4 network MUST use only the all-ones form as the destination address of the packet. An IPv4 datagram containing a source or destination that is equal to the all-zeroes form of the local broadcast address SHOULD be treated, by both hosts and routers, as a normal unicast datagram; it SHOULD NOT be treated as a local broadcast datagram. Host software SHOULD allow a network interface to be configured with the lowest address on a subnet. A host with such an address configured MUST use this assigned address as a source address for datagrams just as it would with any other assigned interface address, and MUST recognize a datagram sent to that address as addressed to itself. Host software SHOULD be capable of generating unicast packets to the lowest address on a subnet when so requested by an application, and MUST encapsulate such packets into link-layer unicast frames when transmitted on a link layer that distinguishes unicast and broadcast. Clients for autoconfiguration mechanisms such as DHCP SHOULD accept a lease or assignment of the lowest address whenever the underlying operating system is capable of accepting it. Servers for these mechanisms SHOULD assign this address when so configured. The network operator of each subnet retains the discretion to number hosts on that subnet with, or without, the use of the lowest address, based on local conditions.

Link-Layer Interaction The link layer always indicates to the IP layer whether or not a datagram was transmitted as a broadcast at the link layer. Hosts MUST continue to follow the RFC 1122 rule about link-layer broadcast indications:

A host SHOULD silently discard a datagram that is received via a link-layer broadcast [...] but does not specify an IP multicast or broadcast destination address.

This rule is, among other things, intended to avoid broadcast storms. This document now defines the lowest address as a non-broadcast address. Therefore, a host SHOULD silently discard a datagram received via a link-layer broadcast whose destination address is the lowest IPv4 address in a subnet. This is true even if the interface on which the host received that datagram uses the lowest address as a unicast IPv4 address.

Recommendations The considerations presented in this document affect other published work. This section details the updates made to other documents.

"Requirements for Internet Hosts -- Communication Layers" [RFC1122] The new section numbered 3.2.1.3 (h) which was added by RFC 3021 is replaced with:

(h) { <Network-number>, <Subnet-number>, 0 } An ordinary unicast ("host") address in the subnet. May be used as either a source or destination address. If a link-level broadcast packet is received with this address (or any other unicast address) as its destination, it MUST be silently discarded. Such a packet may be sent by long-obsolete hosts on the local network. In applications using CIDR notation, this address, or any other address in the subnet, may also be used together with a prefix length to refer to the entire subnet.

"Requirements for IP Version 4 Routers" [RFC1812] The new section (numbered 4.2.2.11 (f)) added by RFC 3021 is replaced by:

(f) { <Network-prefix>, 0 } An ordinary unicast ("host") address in the subnet. May be used as either a source or destination address. If a link-layer broadcast packet is received with this address (or any other unicast address) as its destination, it MUST be silently discarded. Such a packet may be sent by long-obsolete hosts on the local network. In applications using CIDR notation, this address, or any other address in the subnet, may also be used together with a prefix length to refer to the entire subnet.

The first paragraph on page 49 (which appears after section 4.2.2.11 (e) in the original RFC 1812, or after section 4.2.2.11 (f) in RFC 1812 as modified by RFC 3021) is changed from this original text

IP addresses are not permitted to have the value 0 or -1 for the <Host-number> or <Network-prefix> fields except in the special cases listed above. This implies that each of these fields will be at least two bits long. DISCUSSION Previous versions of this document also noted that subnet numbers must be neither 0 nor -1, and must be at least two bits in length. In a CIDR world, the subnet number is clearly an extension of the network prefix and cannot be interpreted without the remainder of the prefix. This restriction of subnet numbers is therefore meaningless in view of CIDR and may be safely ignored.

to this new text

Unicast IP addresses are permitted to have the value 0 for the <Host-number> field, and may have the value -1 in the special cases listed above. There is no requirement that the <Host-number> field be any particular length. In some cases using CIDR notation, a host may be designated with a /32 suffix (e.g. 192.0.2.34/32), indicating that the specific host rather than its subnet is being described. DISCUSSION Previous versions of this document also noted that subnet numbers must be neither 0 nor -1, and must be at least two bits in length. Other versions required that <Network-prefix> fields must be neither 0 nor -1, and must be at least two bits long. Now that the Internet has fully transitioned to CIDR routing, there are no original classful <Network-number>s to be distinguished from <Subnet-numbers>. Each address only has a <Network-prefix> based on its network mask (or equivalently, the CIDR suffix specifying how many bits are in the <Network-prefix>). The former restrictions on subnet numbers and their sizes are meaningless in view of CIDR and are hereby repealed. For example, a route to 0.0.0.0/6 or even 0.0.0.0/1 is a viable CIDR route (for the aggregation of the blocks 0/8, 1/8, 2/8, and 3/8; or for the entire lower half of the IPv4 address space) and should not be considered invalid. 0.0.0.0/0 is standardized to mean "all unicast IPv4 addresses", e.g. in a default route, by section 5.1 of , which MUST also continue to work.

Sections 4.2.3.1 (2) and (4) are replaced with:

(2) SHOULD silently discard on receipt (i.e., do not even deliver to applications in the router) any packet addressed to 0.0.0.0. If these packets are not silently discarded, they MUST be treated as IP broadcasts (see Section [5.3.5]). There MAY be a configuration option to allow receipt of these packets. This option SHOULD default to discarding them. A packet addressed to { <Network-prefix>, 0 } is an ordinary unicast packet, and MUST be treated as such. (4) SHOULD NOT originate datagrams addressed to 0.0.0.0. SHOULD allow for the generation of datagrams addressed to {<Network-prefix>, 0 } since that is now defined as an ordinary unicast adddress.

Example The only IPv4 broadcast address for 192.168.42.0/24 is 192.168.42.255 (the all-ones or "-1" host number). 192.168.42.0 (the all-zeroes or "0" host number) was formerly a second broadcast address on that subnet, but is now a unicast address. The fact that the address identifier 192.168.42.0 can refer to both a network and a specific host 192.168.42.0 is not unusual. Similarly, referring to a subnet as 192.168.42.0/24 and configuring a particular interface on that subnet as 192.168.42.0/24 is also not unusual. Computer scientists normally count all sorts of things starting at the zeroth (lowest) element in a sequence. For example, the initial element in an array is likely to be stored at a memory address equal to the memory address of the array itself. Similarly, IPv4 hosts in a subnet MAY be enumerated starting with an address that matches the address of the subnet itself. Similarly, the only IPv4 broadcast address for the subnet 192.168.42.96/28 is 192.168.42.111. The address 192.168.42.96 MAY be assigned to an individual host on this network.

Compatibility and Interoperability Many deployed systems follow older Internet standards in not allowing the lowest address in a network to be assigned or used as a source or destination address. Assigning this address to a host may thus make it unaddressable by some devices on its local network segment. Network operators considering assigning this address to a host should investigate their own network environments to determine whether their interoperability requirements will be met. Interoperability with these addresses is likely to improve over time, following the publication of this document. Prior standards required hosts and gateways to ignore, and to refrain from generating, non-broadcast datagrams from or to the lowest address. So when a single network contains a device that has been assigned the lowest address as specified by this document, along with one or more devices that follow the traditional behavior, the traditional devices will not be able to communicate with the lowest-address device at all. Other sorts of malfunctions are unlikely, because the former standards (RFC 1122) required traditional hosts to drop any unicast packet addressed to the secondary broadcast address that they implemented at the lowest address.

IANA Considerations This memo includes no request to IANA.

Security Considerations The behavior change specified by this document could produce security concerns where two devices, or two different pieces of software on a single host, or a software application and a human user, follow divergent interpretations of the lowest address on a network. For example, this could lead to errors in the specification or enforcement of rules about Internet hosts' connectivity to one another, or their right to access resources. Firewall rules that assume that the lowest address on a subnet cannot be addressed SHOULD be updated to take into account that it can be addressed, so as to avoid either unintentionally allowing or unintentionally forbidding connections involving it. Other security, monitoring, or logging systems that treat the lowest address as an unaddressable bogon address SHOULD likewise be updated. Host software SHOULD make the distinction between lowest-address (considered individually) and subnet (considered as a group) clear to users, where this distinction is relevant and could be a subject of confusion.

Acknowledgements This document directly builds on prior work by Dave Täht and John Gilmore as part of the IPv4 Unicast Extensions Project.