[PATCH] bird: treat former classe addresses as valid addresses

[Dave Taht]

replying via gmail as taht.net's server mandates starttls and someone
doesn't have that enabled for outgoing mail.

>On Tue, Dec 11, 2018 at 03:26:08PM -0800, Dave Taht wrote:
>> There is no reason to disallow the former class e address
>> space, except in a bogon file.

>Hi

>>  static inline int ip4_is_unicast(ip4_addr a)
>> -{ return _I(a) < 0xe0000000; }
>> +{ return _I(a) < 0xe0000000 || (_I(a) >= 0xf0000000 && _I(a) != 0xffffffff); }

>Well, this summarises the reason why to disallow former class E address
>space. If these addresses are not defined / reserved for future use, how
>can we say that they are unicast and not multicast or for some complete
>different but not yet defined purpose?

As best as we can tell they have been treated as unicast by linux,
freebsd, and OSX since at least about 2010, perhaps longer.

>IMHO first should IETF redefine it as a regular unicast range, then
>routing software should change its behavior. Please correct me if
>that already happened.

The deployment is all unicast in the 240/4 range. Try it - in linux:

ip addr add 255.255.255.254/24 dev whatever

Over the last few months we've tested apple IOS, OSX, Freebsd, most
modern linux linuxes use the iproute suite per above, and just work,
and
those few that don't, like openwrt, use an ifconfig ioctl that we also
have a few line patch awaiting approval to the linux kernel.

The original patch in this series goes back to 2008
(https://lkml.org/lkml/2008/1/7/370 ). Multiple switches, APs, and
devices "just work".
Only windows, currently cannot route to or accept a 240/4 address, and
we're hoping to address that. document in progress on that...

So even if the IETF wanted to change the unicast interpretation, it
would be unwise.

as for how these addresses could be used, well, that's a subject for a
new RFC (pending)
but the technical feasibility appears bright at the moment.

We (john gilmore, rob landley, others) behind this are trying to gain
approval for a worldwide test
opening up a few of these ranges, especially the "hard" one, 255/8,
for analysis.

>OTOH, perhaps we could allow all possible routes regardless of address
>classification (even for prefixes from multicast range) in routing table.

That's what the babeld patch does, currently. Under test. Many bogon
files also filter out this range.
one line changed, and voila!

>OSes allow that and sometimes even uses that (e.g. route for multicast
range in regular unicast table is used for selection of default multcast
interface on clients).

Thank you for pointing this out. We have been using things like
searchcode for all the public sources in the world, and thus far...
all but the IN_MULTICAST macros are essentially unused in userspace.
I'll go look harder for other potential multicast/unicast conflicts
like that,
but the linux kernel, at least, looked clean.

... only the main routing daemons had issues.

http://www.taht.net/classe/ has the tiny patch sets for everything so far

We're in the FRR process over here:

https://github.com/FRRouting/frr/pull/3462

does anyone still use xorp?



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740