ipv4: allow use of 240/4 by default

[emaste]

Summary

RFC1112 refers to 240.0.0.0/4 as "Class E" addresses and reserved them for future addressing modes. At this point it is clear that they will not be used for a future addressing mode, and there is a goal of adding them as unicast addresses[1]. Most other operating systems have enabled this use by default already[2].

[1] https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240
[2] https://blog.benjojo.co.uk/post/class-e-addresses-in-the-real-world

[emaste]

Oops, not sure how I accepted (and did not mean to).

[rscheff]

Seems you inadvertedly removed all reviewers; I added a bunch who probably want to chime in from the transport/ip side. I myself welcome this change - and maybe we should be backporting this to stable/14 and the upcoming release even.... I suspect most public deployments have that tunable toggled already?

[bz]

Please don't flip the switch before it's in the IANA list.
That draft (if not updated--and IETF just happened-were there any news?) will expire end of this year.
Even source [2] after all says towards the end "Should you use Class E space? The short version is, Typically no."
Arista and Juniper also treat it as an "supported but opt-in" according to the draft.

What's the reason to flip the switch now rather than when the sysctl was introduced?

[emaste]

Even source [2] after all says towards the end "Should you use Class E space? The short version is, Typically no."

Should you use it? Probably not. Should you be prevented from using it? IMO also probably not.

What's the reason to flip the switch now rather than when the sysctl was introduced?

The passage of around 2.5 years. When Mike introduced the sysctl I would have agreed that enabling it by default was premature.

OpenBSD enabled it in 2022:

commit ef8f8f938aa6d1ea1347e941d416f4a2c0029c60
Author: claudio <[e-mail]>
Date:   Fri May 6 15:51:09 2022 +0000

    Relax the limitation of what is an acceptable unicast IP.
    
    Remove the IN_BADCLASS() check which filters out the experimental IPv4
    address space. Now there are no more experiments in IPv4 and so there
    is less reason for these network daemons to deny such an IP.
    Everything still disallows multicast IPs (224/4) and loopback (127/8)
    a few also disallow 0/8 but this is not consistent.
    
    In any case using 240/4 in production is a really bad idea but it is
    not up to this software to prevent you from being a fool.
    
    OK deraadt@ tb@

Linux in 2008:

commit 1e637c74b0f84eaca02b914c0b8c6f67276e9697
Author: Jan Engelhardt <[e-mail]>
Date:   Mon Jan 21 03:18:08 2008 -0800

    [IPV4]: Enable use of 240/4 address space.
    
    This short patch modifies the IPv4 networking to enable use of the
    240.0.0.0/4 (aka "class-E") address space as propsed in the internet
    draft draft-fuller-240space-00.txt.
    
    Signed-off-by: Jan Engelhardt <[e-mail]>
    Acked-by: YOSHIFUJI Hideaki <[e-mail]>
    Signed-off-by: David S. Miller <[e-mail]>

[emaste]

In particular, the current state as described in draft-schoen-intarea-unicast-240 seems undesirable:

All known TCP/IP implementations either interoperate properly with
packets with sources or destinations in the 240/4 range, or ignore
these packets entirely, except FreeBSD and NetBSD, which have support
for 240/4 for some purposes while blocking it for others.

[bz]

In D47512#1083767, @emaste wrote:

In particular, the current state as described in draft-schoen-intarea-unicast-240 seems undesirable:

All known TCP/IP implementations either interoperate properly with
packets with sources or destinations in the 240/4 range, or ignore
these packets entirely, except FreeBSD and NetBSD, which have support
for 240/4 for some purposes while blocking it for others.

I agree. We should have never allowed local configuration by default either.
And in that regard inet.4 and the implementation seem to differ.

allow_net240        Boolean: allow experimental use of addresses in
                    240.0.0.0/4 as endpoints, and allow forwarding of
                    packets with these addresses.

We do allow 'as endpoints' independent of the boolean it seems. I just (partially) tried.

If we were consistent we would probably read the same way as Juniper "can be enabled by a simple sysctl switch".

The draft is done as an individual submission (as others were before).
Please wait if it expires at least before doing anything.
If they'll update it we can always ask them to clarify the text (and/or flip the switch or actually fix the "configuration" problem to match the documentation and avoid the split view on FreeBSD).

In the past other attempts also went nowhere (and that may clarify where the early attempts of other OSes came from):

• https://www.ietf.org/archive/id/draft-wilson-class-e-02.txt expired
• https://datatracker.ietf.org/doc/html/draft-fuller-240space-02 expired

I agreed on the original implementation if the status quo did not change -- people who wanted to play with it could enable it.

I also wonder why you would want to change the status quot for 240/4 but not for the other two netblocks that also came along in D35741?

[emaste]

And in that regard inet.4 and the implementation seem to differ.

That's rather unfortunate, and I didn't realize that until a few hours ago when I spotted the text in in draft-schoen-intarea-unicast-240.

The sysctl description doesn't make a distinction - it is currently net.inet.ip.allow_net240: Allow use of Experimental addresses, aka Class E (240/4).

Perhaps allowing 240/4 as an endpoint address should have been controlled by the sysctl when it was introduced, but I don't like the idea of "fixing" that now and potentially breaking a working configuration. I'd suggest we choose one of:

1. update the description and man page to reference forwarding 240/4, leaving the code as is
2. update the code to match the description and switch to enabling the sysctl by default

I prefer #1. Avoiding use of 240/4 as an endpoint can easily be achieved by the admin, by simply not using 240/4 as an endpoint. We don't really need a sysctl to control whether or not the admin can do so. Giving control for forwarding makes sense.

I also wonder why you would want to change the status quot for 240/4 but not for the other two netblocks that also came along in D35741?

240/4 seems to be the least controversial / problematic range. 0/8 probably deserves the same treatment. 127 seems more problematic.

[bz]

In D47512#1083788, @emaste wrote:

And in that regard inet.4 and the implementation seem to differ.

That's rather unfortunate, and I didn't realize that until a few hours ago when I spotted the text in in draft-schoen-intarea-unicast-240.

Agreed. I hadn't realised back then either. I am too tired to quickly throw up a history 11.3 release or o and try if that had always worked anyway for us too. But it in the end it won't matter much.

The sysctl description doesn't make a distinction - it is currently net.inet.ip.allow_net240: Allow use of Experimental addresses, aka Class E (240/4).

I cannot remember if that's because there was one (or two) sysctl initially named experimental_something and then got renamed to the allow_netX (I maay misremember but I might be to blame for that).

Perhaps allowing 240/4 as an endpoint address should have been controlled by the sysctl when it was introduced, but I don't like the idea of "fixing" that now and potentially breaking a working configuration. I'd suggest we choose one of:

ACK

1. update the description and man page to reference forwarding 240/4, leaving the code as is
2. update the code to match the description and switch to enabling the sysctl by default

I prefer #1.

ACK +1 for #1

Avoiding use of 240/4 as an endpoint can easily be achieved by the admin, by simply not using 240/4 as an endpoint. We don't really need a sysctl to control whether or not the admin can do so. Giving control for forwarding makes sense.

+ icmp_reflect() as the draft hints to (should probably mention).

I also wonder why you would want to change the status quot for 240/4 but not for the other two netblocks that also came along in D35741?

240/4 seems to be the least controversial / problematic range. 0/8 probably deserves the same treatment. 127 seems more problematic.

Okay. Are you in a rush for a good reason (14.2?)?

Otherwise, we'll know by the end of the year. If it goes anywhere we'll likely want to remove the sysctls for each one and not just flip them; if it goes nowhere (more likely?) I am not sure I would want to enable it by default just because Linux has done so 2 different drafts ago and a draft description sounds like "FreeBSD/NetBSD are complicatedly different".

In the end I may be biased because most of my machines don't even support INET anymore I have to admit given we've done IPv6-only-jails more than 1.5 decades ago and no-INET FreeBSD almost 1.5 decades ago. But I do understand other people see the world differently and hence not objecting to Mike having done this with the current sysctl state.

I have a TODO item myself to yank some "EXPERIMENTAL" code out of FreeBSD again before 15.0.

[emaste]

Okay. Are you in a rush for a good reason (14.2?)?

Nope, no rush for 14.2.

In the end I may be biased because most of my machines don't even support INET anymore

Yeah - and all of this might be a moot point as it's going to take a long time before 240/4 will actually be (fully) usable anyway.

[schoen_loyalty.org]

Hi!

We (authors of draft-schoen-intarea-unicast-240) continue to advocate this proposal and are planning to continue publishing updates to the draft, including before the current draft expires at the end of 2024.

I'm not sure of what considerations most influence everyone's views about what the default of net.inet.allow_net240 should be. I have several observations that I think suggest that enabling by default would be beneficial.

(1) We don't know of any case in which allowing 240/4 ever causes harm in the sense of making systems unreliable or unstable.

(2) Defaulting to enabling it helps make it more convenient for people to number networks with 240/4 addresses in the future because there are fewer individual systems that need to be reconfigured.

(3) Although it isn't our most preferred use of 240/4, there's also a noticeable trend toward cloud hosting companies using, or actively advocating use of, 240/4 ranges as private address space because some of the infrastructure in question has run out of RFC 1918 space. For example, Google started recommending that for Google Cloud customers a couple of years ago and has actually documented it publicly this year. (We would rather see IETF work on coordinating these uses in order to maximize the overall value of the addresses to the Internet.) Google cites the example of Snap Inc. (the creator of SnapChat) using 240/4 for private IPv4 addressing in its Google-hosted cloud infrastructure, but also warns that some OSes don't allow it by default. Allowing it by default in FreeBSD would be more convenient in this regard, although I admit I don't know of a particular prospective user who's asking for that—I guess the Snap example was overwhelmingly Linux servers. You can read about this at https://cloud.google.com/blog/products/containers-kubernetes/how-class-e-addresses-solve-for-ip-address-exhaustion-in-gke/

(4) As also noted in our Internet-Draft and above, FreeBSD's existing behavior here is somewhat inconsistent (240/4 works for some purposes in the FreeBSD kernel but not for others) and defaulting net.inet.allow_net240 to true would make the behavior much more consistent overall.

I understand that some people actively disagree with us about at least (1) and (2) here because of seeing reduced RFC 1122 compliance as a harm in its own right, or because of preferring to *discourage* rather than *encourage* future uses of 240/4 addresses.