Re: Reserved address behavior (alternate broadcast and 240/4)
On 2022/05/05 08:36, Claudio Jeker wrote: > > 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. It looks all or nearly all guarded with ifdefs in some way or other. I don't know what the best approach is but I will do a ports bulk with this removed completely to collect data about how many things fail (I think it will be at the most single-digit numbers, and quite possibly 0).
Re: Reserved address behavior (alternate broadcast and 240/4)
On Wed, May 04, 2022 at 06:48:14PM -0700, Seth David Schoen wrote:
> 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:
As forwarding and icmp reflect is the only place where IN_EXPERIMENTAL()
is used, I cannot see a downside of this patch.
OK bluhm@
> 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 - 1.173
> +++ in.c 5 May 2022 01:05:04 -
> @@ -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;
Re: Reserved address behavior (alternate broadcast and 240/4)
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.c28 Mar 2022 16:31:26 - 1.173
> > +++ in.c5 May 2022 01:05:04 -
> > @@ -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
Re: Reserved address behavior (alternate broadcast and 240/4)
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 - 1.173
> +++ in.c 5 May 2022 01:05:04 -
> @@ -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
Reserved address behavior (alternate broadcast and 240/4)
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.c28 Mar 2022 16:31:26 - 1.173
+++ in.c5 May 2022 01:05:04 -
@@ -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;
