Hi!
I'm working on a project with John Gilmore to make it possible for
people to make better use of historically reserved IPv4 address space.
In many cases address types were reserved in the 1980s for purposes
that made sense at the time but that are no longer relevant today.
There are several changes that we've been targeting in different systems.
We were gratified to see that OpenBSD was the first system to adopt one
of those, considerably before the start of our project, by removing the
duplicate broadcast address. This change landed twelve years ago:
> revision 1.59
> date: 2010/01/13 10:30:31; author: henning; state: Exp; lines: +2 -12;
> 4.2BSD had the host parts bit of the address all zero as broadcast address.
> 4.3BSD (anno 1986) supported the host part bits all one for broadcast as
> well, since that's what everybody agreed on and RFC919 (anno 1984) proposed.
> now, roughly a quarter decade later, we can really stop supporting the all
> zero variant. sorry to you guys still running 4.2BSD. ok theo ryan
We have independently been promoting this elsewhere, so we were very
pleasantly surprised to see that it's already long-standing default
behavior in OpenBSD. We recently also got the same behavior adopted
as a default in Linux and FreeBSD (although you may not immediately see
it in Linux distributions as they often use older kernels). I'm happy
to say that our Linux patch interoperated properly with a stock OpenBSD
system. A particularly convenient thing about the all-zeros broadcast
address change is that the existing Internet standards don't allow
distant hosts to make assumptions about netmasks of networks to which
they aren't directly attached. So using the all-zeros form as a host
address already works everywhere outside the LAN environment.
Anyway, one thing we would like to propose that OpenBSD update is the
in_canforward treatment of 240/4 (former class E) addresses. Apparently
mainly as a result of proposals in 2008 to make these addresses more
usable, most OSes now no longer treat these specially (although they
can't yet be allocated as public address space). They have been seeing
some considerable use as unofficial private address space. OpenBSD is
one of the numerous systems that already permits these addresses to be
assigned to an interface and used by a socket, but there's one remaining
discrepancy in the in_canforward definition.
This has some odd consequences. For instance, if an OpenBSD system
has an interface numbered with an address in 240/4, it can initiate
and receive TCP connections using that address, and it can ping other
hosts using that address, but it won't respond to pings from other
hosts. This patch cleans this up:
Index: in.c
===================================================================
RCS file: /cvs/src/sys/netinet/in.c,v
retrieving revision 1.173
diff -u -p -r1.173 in.c
--- in.c 28 Mar 2022 16:31:26 -0000 1.173
+++ in.c 5 May 2022 01:05:04 -0000
@@ -103,7 +103,7 @@ in_canforward(struct in_addr in)
{
u_int32_t net;
- if (IN_EXPERIMENTAL(in.s_addr) || IN_MULTICAST(in.s_addr))
+ if (IN_MULTICAST(in.s_addr))
return (0);
if (IN_CLASSA(in.s_addr)) {
net = in.s_addr & IN_CLASSA_NET;
