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