HomeFreeBSD

Change lowest address on subnet (host 0) not to broadcast by default.

Description

Change lowest address on subnet (host 0) not to broadcast by default.

The address with a host part of all zeros was used as a broadcast long
ago, but the default has been all ones since 4.3BSD and RFC1122. Until
now, we would broadcast the host zero address as well as the configured
address. Change to not broadcasting that address by default, but add a
sysctl (net.inet.ip.broadcast_lowest) to re-enable it. Note that the
correct way to use the zero address for broadcast would be to configure
it as the broadcast address for the network.

See https:/datatracker.ietf.org/doc/draft-schoen-intarea-lowest-address/
and the discussion in https://reviews.freebsd.org/D19316. Note, Linux
now implements this.

Reviewed by: rgrimes, tuexen; melifaro (previous version)
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D31861

Details

Provenance
karelsAuthored on Sep 5 2021, 6:14 PM
Reviewer
rgrimes
Differential Revision
D31861: Change lowest address on subnet (host 0) not to broadcast by default.
Parents
R10:b43d7aa09b3c: EC2: Default to UEFI booting
Branches
Unknown
Tags
Unknown

Event Timeline

I applied this against a FreeBSD 13.0-RELEASE-p4 system and checked for interoperability successfully on a LAN with a machine running Linux kernel 5.14.1 (which includes our corresponding patch with this same functionality). ARP, ICMP, and TCP worked in both directions with either the FreeBSD or the Linux machine set to use the lowest address on their shared subnet.

I haven't yet tried routing in this configuration (i.e., confirming that both the Linux and FreeBSD machines will be willing to route packets in both directions in this condition), but I'll give that a try next.

I haven't yet tried routing in this configuration (i.e., confirming that both the Linux and FreeBSD machines will be willing to route packets in both directions in this condition), but I'll give that a try next.

Just to confirm, I tried all four of these combinations

FreeBSD .0, Linux .x, routing via Linux machine
FreeBSD .x, Linux .0, routing via Linux machine
FreeBSD .0, Linux .x, routing via FreeBSD machine
FreeBSD .x, Linux .0, routing via FreeBSD machine

to communicate with an unpatched machine on a different subnet, and all four worked properly.

e.g. the first of the four variants above looks like

patched patched unpatched
FreeBSD Linux Linux
\ / \ /
242.42.42.0 [wired eth] 242.42.42.1 250.250.250.1 [wifi] 250.250.250.250

and the unpatched Linux machine (right) is able to communicate correctly with the patched FreeBSD machine (left). All subnets are /24.

I didn't test to confirm that the unpatched machine *can't* communicate directly on the same subnet with the patched machine to which .0 was assigned, but I've noted that behavior in the past and it's almost certainly still the case.