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.
