[PATCH] Don't treat 0/8 and 240/4 specially in IPv4 classification

[Seth David Schoen]

Maria Matejka writes:

> Hello!

Hi Maria!

> I have several reasons why to reject this patch:
> 
> (1) Everybody who is in need of bigger address space should have already migrated to IPv6. I see no good reason to continue the legacy IP agony with proposals like this. This point is first on purpose. 
> 
> (2) BIRD already treats 240/4 the same way as 10/8. We can't simply enable 0/8 as it may be used or checked internally in some protocols and its use is not safe without thorough assessment and testing.
> 
> (3) Even if you managed to make 240/4 public and assigned, it would postpone the legacy IP address crisis just by months. Migration to IPv6 is inevitable.
> 
> There are good technical reasons to keep legacy IP classifications, and even reclassifying 240/4 as site-local was essentially a bad compromise itself. I regret changing the default behavior in such a way that less vigilant operators may let unassigned 240/4 through BGP on the public internet. It's just a security hole itself.
> 
> If there is any problem or missing feature in BIRD in IPv6 routing, fixing or reporting that is the way to go.
> 
> Thank you for your understanding.

My own TL;DR: We don't have evidence of any harm from uses of 0/8, and it
makes sense in general to have bogons/Martians be configurable rather than
hard-coded, so different users have as much flexibility as possible to use
routing daemons for their own purposes.


First, with regard to the 0/8 vs. 240/4 distinction: it's true that there
may be systems or protocols that have a special meaning for 0/8 addresses.
We looked at a lot of RFC text and found that typically only 0.0.0.0
has a special meaning in standards, with very few exceptions (for
instance in certain SNMP MIBs); the rest of 0/8 doesn't.  Of course,
there could very well be some software that does assign a special meaning
to 0/8 in a way that's not specified or documented by an RFC.  If so,
we'd very much like to identify and document those, and potentially to
try to change those behaviors or our proposals, or both.

Both 0/8 and 240/4 (except 0.0.0.0/32 and 255.255.255.255/32) are now
treated as ordinary unicast addresses by a very large number of hosts
and routers' TCP/IP implementations, typically permitting them to take
global address scope.  When giving talks about this, I told people that
the device they were using to listen to me probably already supported
240/4 as global-scope unicast.  (Almost certainly, if it's not running
Windows.)  Here, similarly, most devices on which people are reading
this very message will also accept 240/4, and many will accept 0/8.

Of course, these addresses will currently only be assigned as part of an
organization's unofficial private use.  It might be that the consequences
of making this change in routing protocols are different from making the
change in hosts.  If so, I would also like to understand why.  Currently
there are things like the https://www.cidr-report.org/as2.0/#Bogons
report that identify ASNs that are making announcements for unallocated
address space, and I think one concern you're pointing to is that, if
more routing protocol implementations are happy to share routes for
reserved address space, we might see more bogon routes leaking into
routing tables outside of organizations that use those internally.

Still, I'd expect that could be handled well now and in the future by
having configurable tables of bogon/Martian spaces in devices, which can
readily be updated over time, rather than hard-coding them in the software
logic.  And also by continued coordination within the Internet community
(as things like the CIDR Report encourage).  Right now I see no route
announcements leaking for 240/4 or 0/8 space in the CIDR Report, though
maybe they do leak between some ASes and are stopped from propagating
further by filters, and maybe some operators have headaches from that.

I'm not sure that it's worth having an IPv6-vs.-IPv4 debate here on
the list.  I strongly encourage everyone to support and deploy IPv6.
Going IPv6-only is a challenge for those hosting public Internet sites
and services that are trying to address a global audience; without IPv4
addresses, they'd still be unreachable to most Internet users.  It may
be different in particular countries or regions where IPv6 deployment
is already more universal.  But globally, most Internet users still lack
native IPv6 connectivity, and it would be a huge sacrifice for services to
say that they won't serve those users at all.  So it's unsurprising that
there are still extremely few public Internet services, large or small,
old or new, that choose to operate IPv6-only without IPv4 addresses.

We anticipate that strong demand for IPv4 addresses will continue for
many years, and that it's worth maximizing the available addressing
resources from many different angles, even as a long-term project.

In the coming year, we hope to be able to do practical testing of reserved
addresses over the public Internet in order to better understand the
current compatibility situation.  For the benefit of flexibility for BIRD
users during these tests or in the future, it would be helpful to have
fewer hard-coded assumptions about what addresses are or will be valid.

It wasn't controversial for the Linux kernel to support unicast use of
240/4 (back in 2010) or of of 0/8 (in 2019).  OpenBSD and FreeBSD have
supported both of these in 2022.  Gobgp release 3.0.0 also supports them.
The Internet didn't break; in fact, enabling these ranges went virtually
unnoticed.  But together they make it likelier that the Internet community
will have broader options for IPv4 addressing resources in the future.