On Wed, 4 May 2022, Seth David Schoen wrote:
[snip]
> 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))
This seems reasonanble. It looks like this is the only use of
IN_EXPERIMENTAL() in base, so maybe we should remove the definition too?
There is the posibility that it might affect some ports, but I'd argue
that unless they similarly adapt then they would already be broken (at
least wrt 240/4 addresses).
Alternetely, we could retain it as "#define IN_EXPERIMENTAL() 0"
-d
