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
smime.p7s
Description: S/MIME Cryptographic Signature
