J. Hellenthal wrote:
FreeBSD operators have been using this space for quite a long time for many NAT'ing reasons including firewalls and other services behind them for jail routing and such.
https://dan.langille.org/2013/12/29/freebsd-jails-on-non-routable-ip-address...
That's just one example that I've seen repeated in multiple other ways. One of which a jail operator with about 250 addresses out of that range that enabled his jail routed services.
Thank you for letting us know! We would be happy to improve the draft so that it has less impact on such pre-existing users. When we surveyed publicly visible applications based on Linux, we only found them configured to use the lowest /16. It's true that any system operator could configure their system in any part of 127/8, but we focused on the default configurations of popular software (such as systemd and Kubernetes). Do you know of any FreeBSD software that comes with a default configuration in 127/8 but not in 127/16? (It looks like the web page you referenced is about specific manual configuration, not about the default behavior of supplied software.) I do not know the details of FreeBSD jail configuration, nor the precise behavior of its loopback interface. From my limited understanding, it looks like the jail configured in the web page you referenced, with address 127.1.0.128/32 on lo1, would provide loopback service regardless of whether the default address on lo0 was 127.0.0.1/8 or 127.0.0.1/16. That's because lo1 is a separate interface from lo0, and the "lo" interfaces always loop back any packets sent through them, no matter what addresses are configured on them. (Indeed the example configures it with a 10.80.0.128 address as well, which would not normally be considered a loopback address.) So, if I am right, then even if our current Internet-Draft became a standard and FreeBSD was modified to implement it, the recommended commands would continue to work. The only impact would be that such a FreeBSD machine would be unable to reach a potential global Internet service hosted out on the Internet at address 127.1.0.128 (because a local interface has been configured at that address, shadowing the globally reachable address). I anticipate that no such global services would be created before 2026 at the very earliest (other than for reachability testing), and likely much later in the 2020's or early 2030's. If it turns out that FreeBSD usage of 127.1/16 is widespread, and the above analysis is incorrect or unacceptable to the FreeBSD community, we would be happy to modify the draft to retain default loopback behavior on 127.0.0.1/17 rather than 127.0.0.1/16. That would include both 127.0.x.y and 127.1.x.y as default loopback addresses. This would completely resolve the issue presented on the "FreeBSD jails on non-routable IP addresses" web page, while still recovering more than 16 million addresses for global use. The worst case might be if FreeBSD sysadmins have become accustomed to picking "random" addresses manually from all over the 127/8 space. If so, it is not unreasonable to expect that when manually configuring a node to use "non-routable" addresses, that in the passage of time, some of them might become routable in the future. When upgrading any machine to a new OS release, various small things typically need adjusting to fit into the revised OS. Renumbering the in-system use of up to a few hundred non-routable addresses like 127.44.22.66 into addresses like 127.0.22.66 (in a smaller non-routable range that still would still contain 65,000 or 130,000 addresses) might be one of those things that could be easily adjusted during such an upgrade. John