On Thu, May 05, 2022 at 12:58:06PM +1000, Damien Miller wrote:
> 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"
>
Agreed, there is also IN_BADCLASS() which is used by the routing daemons.
IN_EXPERIMENTAL and IN_BADCLASS are the same definition.
Looking at debian code search IN_EXPERIMENTAL() is still referenced in a
bunch of packages. So I wonder if your alternative to just make
IN_EXPERIMENTAL never match is the right approach.
OK on the in.c diff
--
:wq Claudio
