[schoen]

It's not correct that the modern Linux kernel refuses to forward packets with a source address in 0.0.0.0/8. The only address that it refuses to forward this way is 0.0.0.0/32.

I just got a patch into the ip(7) man page that describes this

https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/...

although there hasn't been a man-pages release since then, so you probably can't see this on your own system yet.

The original change (included in Linux 5.3) is

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

(I'm working on a project that aims to make these addresses potentially useful for numbering Internet hosts in the future, as part of which Dave Taht's patch linked above was written, so I follow this very closely!)

Separately, you need to be able to process a 0.0.0.0/32 source address on external interfaces (though not to forward it) in order to be able to implement a DHCP server, as that's the source address used by DHCP clients. (edit: another commenter pointed out that this commonly uses raw sockets so it doesn't necessarily require any explicit kernel support)

[usovalx]

May dhcp client/servers are using raw sockets and will thus bypass incorrect firewall config/martian packet filtering.

[schoen]

Yes, I forgot about that but you're right that that's the typical implementation method.

So the DHCP case does not necessarily need any special kernel support (other than not prefiltering before the raw socket).

Thanks for the correction.

[bombcar]

Is there any similar work to change 127/8 to be something more reasonable like 127/16 or 24?

[schoen]

We have proposed it!

https://www.ietf.org/archive/id/draft-schoen-intarea-unicast...

The big prize is 240/4.

https://www.ietf.org/archive/id/draft-schoen-intarea-unicast...

Our proposals have not been warmly received in the intarea WG so far.

[jacquesm]

I think it is pretty reasonable to be reluctant to make such changes because it may well break stuff.

[schoen]

Well, for 240/4 in particular we (in a very expansive sense of "we"¹) started making the change back in 2008 in response to

https://datatracker.ietf.org/doc/pdf/draft-fuller-240space-0...

If we (for an expansive sense of "we") had kept it up more actively, we would already have had 15 years of progress on updating implementations and evolving people's expectations. That wouldn't have been a super-fast change, necessarily.

We (for a narrow sense of "we") think it's pretty likely that people will still be interested in having more IPv4 space in 15 years from now, so it's too bad that progress is (somewhat) stalled on this (with most Unix-like systems allowing it, and Windows not allowing it, and dedicated routers from before about 2013-2016 often not allowing it).

¹ the specific project I'm working on, started by John Gilmore, didn't exist yet at that time, but is trying to revive/continue this idea

[jacquesm]

Fair enough, but that more or less emphasizes my point: if it wasn't done by 2010 or so that means that a ton of IoT hardware has now shipped that may never see updates and that would possibly end up failing when presented with such a departure from what the expected behavior was at the time the hardware was shipped. You change old established standards at your peril, especially how IPV4 is routed and which ranges are reserved. There are quite a few things that retrospectively could have been handled better and a large number of huge ranges got handed out like candy back in the day. Some of those have been reclaimed and some still remain. It may be easier and with less chance of breaking stuff if those ranges were reclaimed more aggressively.

[bombcar]

It would be amusing if a moderately breaking change to IPv4 is what finally causes all the old equipment to be finally dumpstered and IPv6 to reign supreme.

[GoblinSlayer]

I use 127/8 for local services, because ports are a very scarce resource. In this respect ip6 is a complete no go.

[bombcar]

What would use 1.04e+12 ports? Each IP has about 65k ports IIRC and 127/8 is 16m addresses.

[GoblinSlayer]

I select one 127/16 network for all my addresses - a vendor namespace. Each service can have worker processes, they get 127/24 networks.

[GoblinSlayer]

SELinux reserves them for unknown reasons. For all addresses.