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-addresses/
>
> 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
> 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-addresses/
>
> 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
