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

[Maria Matejka]

Hello!

I needa repeat myself.

>> (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.

This point is first on purpose. Extending the life of legacy IP will 
just harm more people in long-term. Everybody with legacy-only 
connection can and should use an IPv6 tunnel or other techniques.

>> (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.

Until 240/4 is officially marked as Internet and available for 
assignment, there is not only no reason to mark it as Internet in BIRD. 
You can use it now, BIRD doesn't do any difference between site-local 
and Internet routes.

We should at least reject site-locals in eBGP sessions by default to 
remedy the fact that we gave way for the previous 240/4-enabling patch 
without proper assessment of its security implications.

And as I'm thinking about it once again, we should probably just revert 
the 240/4 classification to invalid as it is of better performance than 
filtering it in filters. BIRD is open-source and everybody involved in 
the 240/4 technological backwardness may simply build their own binary 
with the patch applied on their own risk, or stick with 2.0.10-11.

>> (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.

And instead of trying to make 240/4 public, IANA should start retracting 
any legacy IP block as it gets free, while publishing an official list 
of deprecated prefixes which should be never seen on the Internet again.

(Credits for this idea: 
https://twitter.com/becomethewaifu/status/1605754063320059904)

> 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.

It makes literally no sense to upstream changes which go against 
Internet security. If we do it, it is a bug, not a good thing.

> 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.

Until there is a reasonably complete autotest suite for BIRD, checking 
that 0/8 does break literally nothing, there is no reason to believe it.

BTW there is a SNMP AgentX implementation in progress inside BIRD so 
thank you for pointing out that we really shouldn't debogonize 0/8 at all.

> 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.

Argumentum ad populum.

> 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's a good measure of how much the Internet is incapable of filtering 
bogons, not a compatibility test at all.
> 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.

Argumentum ad populum again.

Maria
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2839 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20221222/84b00064/attachment.p7s>