
Allow 0.0.0.0/8 as a valid address range - cesarb
https://git.kernel.org/linus/96125bf9985a
======
digitalsushi
I could actually see us successfully inventing, and implementing, a multiverse
concept for ipv4 to make these 32 bit addresses last another 40 years, as
opposed to throwing these non-upgradable, hardcoded v4 devices out. And this
is from a pure v6 evangelist. I'm complaining, not being optimistic.

~~~
justinsaccount
sure, just prepend every address with some more bits to indicate which
multiverse it's from. while you are at it you might as well add a lot of bits,
say, 96 of them.

~~~
electronstudio
If they had done just that and only that - taken IPv4 and added more bits - we
might all be using IPv6 now. Instead they used the opportunity to cram every
feature but the kitchen sink in there, so none of the hardware vendors were
interested in implementing it and the backbones were slow to adopt it. So we
got mass adoption of NAT instead of mass adoption of IPv6.

~~~
wbl
They removed, not added features. The hardware problems had more to do with
other things.

~~~
yardstick
Yeah it’s the feature changes that made it problematic.

They removed NAT, which made laymen deployment difficult. I can’t just plug an
IPv6 router behind another router (or 3-4 levels of routers) and expect it to
just work. In IPv4, DHCP+NAT handles that just fine. In IPv6 I need to worry
about address assignment. I don’t care about P2P connectivity issues- the NAT
trade-off of using STUN/TURN techniques works for me.

They replaced ARP, and replaced DHCP with SLAAC then realised that people like
DHCP so added a version of DHCP back. Except it’s still not the same so has
it’s own quirks.

Then there’s the difficulty of supporting multiple IPv6 WANs in one router in
a useful fashion. SLAAC takes too long for a PC to detect a dead WAN and use
the other WAN range. And there’s no ability to do policy based routing (eg
prefer YouTube via dsl, prefer VoIP via fibre) without using NAT+ULA.

Don’t get me wrong, there’s a lot of great things about not using NAT, but
there’s a lot of real world scenarios where using NAT is the preferred trade-
off.

IPv6 originally decided they didn’t want NAT, and tried to force people into
their one way of doing things. They just needed to support both, and then IPv6
deployments wouldn’t be so complicated. They added NAT and DHCPv6 far too late
in the game. Even Android doesn’t support DHCPv6 yet and it’s 2019!

~~~
avian
> They removed NAT, which made laymen deployment difficult. I can’t just plug
> an IPv6 router behind another router (or 3-4 levels of routers) and expect
> it to just work.

Is this common, plugging consumer routers with NAT several layers deep? I
haven’t seen that in the wild. The only time I myself tried it didn’t work for
some unknown reason.

My only real gripe with IPv6 is the fact that Duplicate Address Detection
seems broken on many Wi-Fi networks (clients for some reason see their own
traffic as traffic from another node and trigger DAD, which shuts down IPv6
access). I’ve seen this on routers from multiple vendors and I believe it’s
some bug in their broadcast/multicast implementations.

~~~
yardstick
Re consumers, I can’t comment on how common they are, but people will have the
ISP router, and then their router. They should ideally bridge but that doesn’t
always happen, either due to just not knowing you should do that, or the ISP
router/modem is a piece of junk that doesn’t support bridging or has quirks.

In the commercial/business space it’s more common to see 3 deep. I see it
every day. Petroleum in particular often has ISP Router -> Site
Firewall/Router -> ServiceProvider Router, because the fuel tank monitoring
equipment is behind its own router so the vendor can get remote access/send
data back over VPNs they manage.

In retail environments, especially malls and concession stands within
department stores, it’s common to be plugged into their network, which you’ll
want your own firewall protecting your PCs etc. I’ve also seen businesses at
the same office building pool resources and share the one internet connection,
with each having their own firewall/router behind the primary site
firewall/router.

There’s also hotspots, where the business both puts that infrastructure on a
separate network from their back office, and the hotspots themselves are doing
NAT too.

Also some payment processors these days are pushing for organisations to
install their own router behind the customers network and route all payments
via that (Rather than customer managed IPsec VPNs or straight TLS over the
Internet).

Yeah it’s definitely common.

------
maltalex
I imagine this could break some existing code. Especially if IANA starts to
actually allocate addresses from the 0.0.0.0/8 range.

Luckily, this doesn't change the fact that 0.0.0.0/8 is still reserved by
RFC8190[0]

[0]:
[https://tools.ietf.org/html/rfc8190](https://tools.ietf.org/html/rfc8190)

~~~
gruez
>Especially if IANA starts to actually allocate addresses from the 0.0.0.0/8
range.

Who's going to want to use that block? Given how many legacy devices are there
on the web, it's probably not going to be reachable for a sizeable chunk of
the internet.

~~~
kabwj
That’s the same thing they said about addresses in bogons ranges and
eventually we succeeded in using them.

------
OJFord
This is a fantastic commit, contents aside, it's a great demo: the diff's
tiny; the message is so much longer, and explains why the diff's there with
even (very) historical context.

~~~
edwintorok
Unfortunately IANA disagrees, it says it is still reserved:
[https://www.iana.org/assignments/iana-ipv4-special-
registry/...](https://www.iana.org/assignments/iana-ipv4-special-
registry/iana-ipv4-special-registry.xhtml) "0.0.0.0/8 "This host on this
network" [RFC1122], Section 3.2.1.3 1981-09 N/A True False False False True"

The referenced RFC is the same one as in the commit message but different
section 3.2.1.3 vs 3.2.2.7. Shouldn't IANA have lifted (or indicated its
intention to lift) the reservation before the kernel change?

~~~
azernik
Given the seniority of the author and committer in the networking world, I
assume that they're operating under the knowledge that IANA's reservation is
being reconsidered.

~~~
dtaht
We have had many talks at many levels over the years. This is an attempt to
break the logjam of finger pointing that ensued. We expect wide adoption of
this and other ipv4 related patches over the next few years across the open
source stacks... and then a standards dialog can take place.

John Gilmore (creator of the unicast extensions project) was the co-inventor
of bootp in 85, which is what made using 0.0.0.0/8 feasible, then. The fact
that it's been feasible since and no movement in the standards orgs to fix it,
has kind of been a record long wait from bug fix to deployment in both our
cases.

------
p1mrx
This will break code that uses (e.g.) 0.0.0.1 as a "fail address":

    
    
        $ telnet 0.0.0.1 22
        Trying 0.0.0.1...
        telnet: Unable to connect to remote host: Invalid argument
    

It's nice because the connect() syscall fails immediately, instead of sending
packets and waiting for a timeout. 0.0.0.0 is not a suitable replacement,
because it's interpreted as 127.0.0.1:

    
    
        $ telnet 0.0.0.0 22
        Trying 0.0.0.0...
        Connected to 0.0.0.0.
        Escape character is '^]'.
        SSH-2.0-OpenSSH_7.9p1 Debian-10
    

Doesn't the kernel have a policy of not breaking userspace, even if the
behavior is undocumented?

~~~
herpderperator
If you ask me, 0.0.0.0 should not be interpreted as 127.0.0.1. Yes, I know
programs like ping interpret it this way as well. I just think it's
ridiculous.

~~~
unilynx
It makes sense if you compare it to how listening sockets work - if I listen
on 127.0.0.1:80, I can connect to 127.0.0.1:80. if I listen to 0.0.0.0:80 (all
ipv4 addresses), I can connect to 0.0.0.0:80

And as a bonus, I can just 'telnet 0 80' instead of having to type out
127.0.0.1

------
ggm
Makes sense. Also 240.0.0.0/4\. small focussed change in code. getting the
IANA process worked out with the IAB is going to take a bit more work. (from
the experience with 240/4 where I tried with some others to author a draft)

~~~
rixrax
While at it, I feel like we could also squeeze the 224.0.0.0–239.255.255.255
multicast range to maybe 224.0.0.0/8 if not tighter.

For reference here is a list of reserved ipv4 addresses[0].

[0]
[https://en.m.wikipedia.org/wiki/Reserved_IP_addresses](https://en.m.wikipedia.org/wiki/Reserved_IP_addresses)

~~~
simcop2387
This can't be done, there's a number of devices out there that do multicast on
fixed multicast IPs and so doing this would break them. In particular I've got
a series of HDMI<=>IP devices that forcefully go to 239.255.42.[42..141]
depending on their settings.

~~~
dtaht
225/8-231/8 were reserved for future multicast use and never allocated by
iana. As near as we can tell by grepping the entire world's source they are
entirely unused.

128m addresses....

~~~
simcop2387
yea that'd probably be reasonable to try to reclaim then. probably only useful
for private use unfortunately though, i bet there's a lot of stuff that'll
improperly route them given the range.

~~~
dtaht
We've had 225/8-231/8 up and running for 6+ months, with patches for various
routing daemons. Running a gauntlet with 240/4 and 0/8 now working seemed
best.

In our exploration of converting these 120m addresses from a multicast
definition to unicast, we only had to change the kernel with two tiny patches,
and recompile 89 fedora packages. Openwrt was less. The patches for frr and
bird, straightforward.

------
exabrial
I still am under the opinion of srv records were widely used the ipv4 shortage
could be delayed a very long time.

~~~
inopinatus
I agree, and I and many others raised it repeatedly with the HTTP2
editors/mailing list in particular, who sadly murdered that proposal because
they believe in their god-given right to squat the A record for their
protocol. I believe the failure to address DNS considerations in the HTTP
standard has driven a large part of ongoing IPv4 exhaustion.

~~~
zonidjan
While I agree that HTTP (and everything else) should support SRV records, they
wouldn't do anything for IPv4 exhaustion.

~~~
inopinatus
I beg to differ. Having run LIRs and with friends at RIRs I know for certain
that many large IPv4 allocation requests were justified on the basis of
needing separate addresses for websites. Policy may be tighter now than it’s
ever been, but the lack of aggregation due to well-known-port fixation drove
and continues to drive unnecessary assignments.

~~~
swinglock
Shouldn't the HTTP 1.1 Host header invalidate that argument?

~~~
inopinatus
Many people expected as much, but in practice not nearly to the extent that
was desired, partly because SSL was a problem until SNI came along (and that
far too late) and also because it comes after the TCP handshake, which
precludes a whole class of traffic routing and service options. Fine for low-
end shared hosting, not fine for many other applications.

------
unethical_ban
Unrelated to code, but related to IP space - there are at least two "reserved
IP spaces" that look like they are completely usable by private networks, not
included in RFC1918.

198.18.0.0/15, reserved for benchmarking devices across subnetworks.

100.64.0.0/10, reserved for carrier-grade NAT. This one might have the higher
chance of a collision depending on your use case or if it's part of a VPN
pool.

Several ISPs I have tested all drop them when you traceroute.

So if your organization can't switch to IPv6 internally and has performed
horrible IPAM on RFC1918, here is a last chance... don't screw it up.

~~~
zonidjan
You could also (ab)use the TEST-NET ranges as private address space.

~~~
jlgaddis
I've been (ab)using 198.18/15 (also reserved, cf. RFC2544) at home for years.

It works just as any other network would and is a perfect solution for me.

(Previously, I abused TEST-NET-2 and TEST-NET-3 and both of those worked fine
as well.)

------
Avamander
I see those bits being used in production happen but I seriously do not like
the idea of giving IPv4 even more time.

~~~
eeeeeeeeeeeee
This /8 won’t make a dent in that problem. Until every single device is
capable of IPv6, IPv4 will continue to persist.

~~~
ATsch
I mean, all of the devices already support v6. The problem is providers and
services not deploying it and software ignoring it's existence.

------
vesche
This would be really neat. However, it might confuse or complicate some tools
output (like netstat) that use the standard 0.0.0.0:80 style listening
notation. That is if 0.0.0.0 becomes a valid address.

~~~
emersion
No, 0.0.0.0 will still be reserved.

>0.0.0.0/32 is still prohibited, of course.

~~~
vesche
Gotcha! I skimmed too fast. I'm all for it then.

------
dtaht
This work is a fallout of the conclusion of this report:

[https://www.internetgovernance.org/2019/02/20/report-on-
ipv6...](https://www.internetgovernance.org/2019/02/20/report-on-ipv6-get-
ready-for-a-mixed-internet-world/)

"legacy IPv4 will coexist with IPv6 indefinitely"

which was referenced in the original talk, and I wish more "just deploy ipv6"
advocates would read. I have worked very hard on making ipv6 deployable
(notably in the cerowrt project) and came to the conclusion after reading that
that if we wanted sustained internet innovation we needed to expand and
improve ipv4, also. Thus 240/4, 0/8, 225/8-231/8 (pending) and yes, even a
large portion of 127 and a push to clean up other problems in ipv4 in general.

------
tobis87
Proposed draft: [https://raw.githubusercontent.com/dtaht/unicast-
extensions/m...](https://raw.githubusercontent.com/dtaht/unicast-
extensions/master/rfcs/draft-gilmore-taht-v4uniext.txt)

~~~
tobis87
This even proposes the use of the zero node address in each network or subnet
(6.1)

------
mindslight
IMO, device addresses are irrelevant - the real pressure is whether end users
can get at least one public IP.

NAT is actually a security feature. _Not_ because it necessitates a stateful
firewall (as is often believed), but rather because it hides specific client
host addresses from servers. The last thing anybody should want is to leak
even more information to the surveillance companies.

The problems of IPv6's larger address space can be mitigated similarly to v4
while retaining some advantage - for example NAT onto random "host" address
for 16+64 bits of saddr+sport rather than just 16 of sport. The point is that
a flat address space isn't the RPC-panacea it was when protocols like "active
FTP" were invented. In the modern world, blithely taking one's supposed L2
address and stuffing it into a higher level PDU is basically a layering
violation.

~~~
lathiat
An inbound firewall for all traffic has exactly the same security level as
NAT.

There's a very small argument for privacy but (a) we have privacy addresses
and (b) even behind NAT many of your devices are probably already identifiable
in many other fingerprinted ways that obscuring the address for this sake
would be pointless

~~~
gruez
>(a) we have privacy addresses and

AFAIK those get rotated every day or so. While this is better than fixed
addresses, it's still worse than NAT, especially if you use some sort of tool
obscure your sessions (eg. container tabs or private browsing).

>(b) even behind NAT many of your devices are probably already identifiable in
many other fingerprinted ways that obscuring the address for this sake would
be pointless

That sounds exactly like Google's excuse not to implement fingerprinting
hardening on Chrome[1].

[1]
[https://bugs.chromium.org/p/chromium/issues/detail?id=49075](https://bugs.chromium.org/p/chromium/issues/detail?id=49075)

------
icedchai
This gives us only another 16.7 million more IPs and will have tons of
compatibility issues with older systems. Re-purposing the old "class E" space
(240.0.0.0/4) would have similar problems.

IMHO, it is too late for these hacks. We need to embrace IPv6. I've been
running it for almost 10 years now...

~~~
guenthert
And I've been disabling it on every system I get superuser privileges on for
as long ...

I can't be bothered maintaining two sets of routes, two sets of firewall
tables and for the life of me can't remember IPv6 addresses.

My toaster doesn't need to talk to your fridge.

~~~
icedchai
People were saying the same thing during the multi-protocol days (x.25,
DECNet, AppleTalk, Novell IPX...) They couldn't be bothered to learn this
crazy Internet thing. IPv6 is the future.

------
tobis87
Talk from the author: [https://www.netdevconf.org/0x13/session.html?talk-
ipv4-unica...](https://www.netdevconf.org/0x13/session.html?talk-ipv4-unicast-
expansions)

~~~
dtaht
Thx for the pointers to the work and talks!

------
rurcliped
WordPress doesn't allow 0.0.0.0/8 in some contexts, as an attempt to block
some types of SSRF:

[https://github.com/WordPress/WordPress/blob/abcbee954f4d8baa...](https://github.com/WordPress/WordPress/blob/abcbee954f4d8baa5aff2df566a942c1b48ca2d7/wp-
includes/http.php#L563)

If allocations in 0.0.0.0/8 happen someday, users will probably see similar
misfeatures in many applications.

~~~
pledess
rejecting all of 0.0.0.0/8 was their CVE-2016-2222 fix

------
dtaht
I am pleased to see no one coming at us with pitchforks and torches ablaze.

240/4 already works in many idea also. 127 and 225/8-232/8 can be reallocated
as unicast also.

------
rphlx
AFAICT the risk/reward for this change (and others along the same line) is
poor, because like it or not, as a factual matter, there are many tens or
hundreds of millions of notionally "open source" devices that will never get
an updated Linux/BSD/... kernel. Most of them are probably Android phones but
there is also a giant tail of consumer routers, EOL'd network equipment, etc.
A lot of this stuff will stay in use until total HW failure, which may be a
decade, two decades or more.

There are of course also many closed-source products that will never get a
TCP/IP stack update. I haven't tested it but I doubt Win7 will ever be able to
reach 0.1.2.3 over the public internet. Even if that's a bogus example, you
get the idea: millions of dollars worth of old closed source gear out there
where it's impossible for the owner to patch the TCP/IP stack.

As a result, to prevent strange connectivity problems on 0.X% of their
connections, almost everyone will pay (and, if needed, significantly bid up)
the ~$20/yr "normal" IPv4 address cost to get an existing "non-reclaimed" IPv4
address instead of taking a gamble on one of these new ones that will
definitely have problems with many other hosts. In short I don't see a
voluntary rational buyer or user until the IPv4 market rises 10X+ and probably
more like 100X+; until then they seem like more of a liability than an asset
given how annoyingly long it will take to retire (or somehow otherwise ensure
that you'll never need to talk with) non-updatable IPv4 hosts.

Not that I like this, or am trying to defend or justify it, but I think it is
an accurate assessment.

TLDR: pretty much everyone will actively avoid these addrs given that millions
of hosts will never be able to reach them.

------
buzzert
I wonder if there are any secret computers on zeronet!

