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

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

karels

Authored 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

rGb43d7aa09b3c: EC2: Default to UEFI booting

Branches

Unknown

Tags

Unknown

Event Timeline

karels committed rGfd0765933c3c: Change lowest address on subnet (host 0) not to broadcast by default. (authored by karels).Sep 17 2021, 12:42 AM

karels added an edge: D31861: Change lowest address on subnet (host 0) not to broadcast by default..

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.

karels mentioned this in rG3ee882bf21af: Change lowest address on subnet (host 0) not to broadcast by default..Oct 19 2021, 1:19 PM

Changes (1)

Path

Size

sys/

netinet/

in.c

rGfd0765933c3c

View Options