Allow 0.0.0.0/8 as a valid address range
git.kernel.org
git.kernel.org
The thing here is cross universe communication and legacy hardware/software stacks.
This sounds like a great mental exercise.
Prepending bits wasn't a solution for the problem he discussed.
but then everyone would complain that its harder to write the numbers and try and come up with excuses for implementing it
IPv6 isn’t just a few extra bytes in an IP address.
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!
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.
But IPv6 in home networks replaces the unreachability-because-of-NAT by unreachability-because-of-filtering. The usual home router protects your clients, and if it's not your box, you're out of luck.
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.
Linux/Iptables support wasn’t until Linux 3.7 & iptables 1.4.18 [1]. So that’s only from 2013, when IPv4 NAT has been possible for well over a decade before that.
Also to do NAT66 you really need a ULA address space, that wasn’t defined until 2005 [2]. RFC1918 addresses for IPv4 were set in 1996.
The tooling, support code, supporting RFCs, and UIs for doing IPv6 NAT has been neglected. It’s a halfway house.
1. http://tldp.org/HOWTO/Linux+IPv6-HOWTO/ch18s04.html 2. https://tools.ietf.org/html/rfc4193
It's been a decade and IPv6 has barely entered the zeitgeist of the common internet user.
besides, https://www.google.com/intl/en/ipv6/statistics.html
It has not been a decade! I remember printing out the draft spec in the late 1990s thinking that I have to get ahead of this curve. Twenty years in the making.
I recall at the time thinking initially that the obscure nomenclature for addressing would be annoying, but that it clearly would be fine. What do I know.
In 2010 hackernews luminaries predicted the ipv6 momentum singlularity here: https://news.ycombinator.com/item?id=1236048
The fact of the matter is very very large private corporate networks do not need more addressing space. ISPs use CGnats. Most home broadband routers|modems are junk. It is just a mess
But since VLANs are a layer 2 concept it means you can in theory use them with IPv6 as well (albeit I’ve never personally tested that theory)
When I said invent, I was supposing we do invent one little extra bit to IPv4, wherein we default to this IPv4 Internet, but we could somehow specify another "universe" and simply have another entire IPv4 network, ad nauseum. Some proprietary routing topography would presumably exist as an inner layer, providing decades of new complexities, masking the implementation for naive ipv4 stacks that couldn't be updated. Those, could continue to exist unawares and perhaps very disjoint between "universes".
Anyways, I am not an Internet architect, and this idea is entirely foolhardy since we have a perfectly good IPv6 universe to move into, one that barely has unpacked the moving boxes from the previous. I suppose all I meant, is that we might invest some more energy in IPv4 before we're really done with it.
They should be actively blocked or redirected to a site that offers quality hardware (Cisco need not apply)
Hell the equipment probably has hardcoded creds that are part of critical infrastructure too.
My argument is to trash crappy equipment.
You didn’t seem to take into consideration all the places where 30-year old equipment is still good, the reasons for why stuff is not uogradeable, nor people who cannot afford spending $100 for the new stuff.
Luckily, this doesn't change the fact that 0.0.0.0/8 is still reserved by RFC8190[0]
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.
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?
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.
I’m not saying that this is true as written, but I’m saying that this is a plausible example in support of why I think it’s “interesting”.
$ telnet 0.0.0.1 22
Trying 0.0.0.1...
telnet: Unable to connect to remote host: Invalid argument
$ 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
This explains so many broken tutorials..
And as a bonus, I can just 'telnet 0 80' instead of having to type out 127.0.0.1
It is a trivial number of patches to enable all the open source code in the world to work.
For reference here is a list of reserved ipv4 addresses[0].
128m addresses....
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.
Still, the addresses need to become routable, and from there (aside from politics and depoloyment delay), globally routable is the dream for most of these new addresses, in 5-10 years.
Would you want to host your website on port 15988? Think how many school/office users are going to complain that Google and Facebook work fine, but your site does not...
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.
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.)
https://www.iana.org/assignments/iana-ipv4-special-registry/...
https://www.iana.org/assignments/iana-ipv6-special-registry/...
It’s part of the reason hand-wringing over some of the “wasteful” /8s that were handed out to organizations in the early days is largely pointless. Even if you could get those orgs to consolidate and give back large useable ranges in those blocks, there’s simply not enough there to meaningfully change the long term mismatch between demand and supply.
>0.0.0.0/32 is still prohibited, of course.
> 0.0.0.0/32 is still prohibited, of course.
Some additional info from RIPE: https://labs.ripe.net/Members/stephane_bortzmeyer/all-ip-add...
https://www.internetgovernance.org/2019/02/20/report-on-ipv6...
"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.
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.
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
> There's a very small argument for privacy
You can't say it has the "same security", while also saying there is a "small" difference. Privacy is an integral part of security, especially for natural persons.
> we have privacy addresses
AFAIK "privacy extensions" merely pick a random host address rather than naively using the ethernet MAC (!!). This still allows identifying discrete hosts.
The NAT scheme I described is strictly better than this. So yes, I can envision an IPv6 future where we have convenient global addresses for incoming traffic, but outgoing traffic gets NATted to a single address (single probability distribution, really). It's just not going to be a return to the trustful 1970's air-out-your-genitals simplicity that is widely envisioned.
> 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
Those other ways are also security vulnerabilities. We shouldn't excuse vulnerabilities because other vulnerabilities exist, especially in the direction of the foundation. While it is appropriate for a higher protocol to simply accept a weakness of a lower layer that it is built on, going the other way is unjustifiably throwing in the towel.
> pwnat, pronounced "poe-nat", is a tool that allows any number of clients behind NATs to communicate with a server behind a separate NAT with no port forwarding no DMZ setup, and no 3rd party involvement. The server does not need to know anything about the clients trying to connect.
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
I've seen at another of these discussions an argument that an inbound firewall is actually stronger. Suppose you have a NAT router with 192.168.1.0/24 as its "inside" network, and 203.0.113.0/24 as its "outside" network, doing NAT between them. Now suppose another host at the 203.0.113.0/24 network sends a packet to this router, with a destination address within the 192.168.1.0/24 network. A router which only does NAT would accept and deliver this packet, while a router with a correctly configured firewall would reject it.
That only gets harder as address space limits[1] squeeze more and more people onto Carrier Grade NAT and similar workarounds.
> NAT is actually a security feature.
No, it's not. All supposed security features are actually from some other source, because NAT is only ever about changing addresses (or port) fields in the IP header.
> it hides specific client host addresses from servers.
NAT usually makes your local addresses very predictable. Is yours 192.168.[01].[1-4]? Often guessing isn't needed; the other IP fields that NAT does not touch can be used to differentiate[2] between hosts behind a NAT.
> The last thing anybody should want is to leak even more information to the surveillance companies.
That's why it's so important that we move to IPv6 asap. The theoretical problem of a few bits of identifiable entropy (differentiating between a few hosts on a private LAN) is trivial in comparison to the centralization that NAT has forced us into. NAT forces network software development into the client/increasingly-centralized-server model[3].
> The point is that a flat address space isn't the RPC-panacea
A flat address space is the most important feature of the original internet, because it makes all hosts equal in the eyes of the protocol. You don't need an imprimatur[4] - an authority's permission to publish - to publish from your own IP. You don't need a centralized server's permission to develop new network software that uses new network protocols.
Of course we don't want to leak information to a serer, especially those owned by surveillance companies. The way to do that is to write software that doesn't involve that server, which is only possible with a flat address space. Arguing otherwise is arguing we should keep using party lines[3].
[1] http://www.potaroo.net/tools/ipv4/index.html
[2] (section 0x03-2) http://phrack.org/issues/63/3.html#article
Warning: we're awfully close to violent agreement here. I'm saying that the demand for more IPs is primarily for end users needing their first public IP, compared to end users needing public subnets for their devices.
> NAT is only ever about changing addresses (or port) fields in the IP header
Ya, the changing of which has the security benefit of a remote server not receiving it! I suspect you've become too used to responding to "I like NAT because it blocks connections to my network" to read what I've actually written.
> NAT usually makes your local addresses very predictable. Is yours 192.168.[01].[1-4]
Sure, for MACs (and guests) that are listed to receive 192.168 addresses because their treacherous software (eg Android, WebRTC, etc) is likely to turn around and leak it... That is the concern I am talking about here, not my local network being actively probed from outside.
But most substantively I do not agree with the point in your [3], based on relative significance. I believe the overriding dynamic is that serverless software is much harder to fund. Implementing UPnP and NAT punching is trivial compared to developing, polishing, and marketing software for mass adoption. Meanwhile centralized surveillance is lucrative, attracting massive investment.
And don't be confused by the brief popularity blip of end-user hosted websites using DNS, because DNS is a terrible user-facing namespace. It essentially mandates a high availability server standing ready to answer requests for every specific entity. There is no ability to retrieve the latest version of a given object from an untrusted peer.
It's possible if and only if you have control of the router. Good luck doing that when it's your ISP doing CGNAT. This is already impossible in some areas (e.g. parts of China) that are behind multiple (5+) layers of NAT. This isn't a theoretical concern; there are already many places on the IPv4 network that cannot get any kind of port forwarding (including UPnP).
Also, NAT hole punching is not[5] "trivial". It only seems trivial if you only consider the easiest case. It also requires a centralized server to initiate.
edit: re: the supposed privacy benefits of NAT - even if you have globally routable addresses, you can still proxy your HTTP requests through your router if you want to. You do not need NAT to have webservers see a single IP address from your LAN.
> harder to fund
100% offtopic; I'm not talking about software funding. The point is that NAT has held back software development. There are entire categories of network software that haven't even been invented yet, because they require being able to receive calls (incoming TCP SYN packets). We don't know what is even possible, because true network software has receive4d very little development effort.
> end-user hosted websites
That is useful. I know several people that use local hosting for various useful activities. Bandwidth isn't that important if you're just sharing with friends. However, this is yet again an example of the client/server model. You seem to be proving my point that being stuck behind NAT can limit your thinking to the one model that works.
For a simple example of non-client/server network software, how about chat software that makes direct connections without the need for a server? (discovery can still use a server; that doesn't mean the chat protocol itself has to be centralized). In ~1996 I did that with very early PGP-encrypted VOIP software that let you simply dial whomever you wanted by their IP address. Just like we dial people on the telephone network by their telephone number. Yes, there are more convenient methods, most of which require trusting a centralized source. To even have a chance at developing something better, we need the ability to develop software freely at the network endpoints, which is incompatible with NAT.
> DNS
I didn't say anything about DNS. As I said above, you seem to be assuming a very limited range of network software. Of course DNS has serious problems; it's not the only way we can discover IP addresses. I want a future where we are free to invent these new methods, instead of a highly-centralized future where the surveillance capitalists have the power to decide which network connections you are allowed to make.
> I did that with very early PGP-encrypted VOIP software that let you simply dial whomever you wanted by their IP address
This is a cute demo but ultimately a red herring. I think the crux of our disagreement comes down to whether we see IP addresses as sufficient user-facing/user-identity addresses. I do not believe them to be so.
By "DNS" above, I really meant DNS+IP - a namespace that assumes the ability to contact an authoritative server, talking directly to it to accomplish a task. As I said, there is no ability to retrieve the latest version of a given object from an untrusted peer - talking to the authoritative server is the only way to obtain updates!
A real communication service needs things like presence information, roaming, multiple endpoints, asynchronous notifications, etc. Which in your example (phone number == IP address) ultimately requires having a bona fide server sitting there to answer for those requests. You called this "discovery", but it's much heavier than that. This is the technical burden that is straightforwardly solved by the software-as-surveillance companies - set up a well-known server, and simply pay a bunch of people to make sure it is always up.
A thought experiment: Say I have a neighbor who is also DIY-technical. What can we actually gain by running a network link between us? I can give him an NFS export (or the like) to access my collection, but he's got to explicitly use of it (ie incorporate my hierarchy into his own mental hierarchy). For wider use with HTTP(s), the best I can do is give him transit to contact the server himself, but that is just becoming his ISP.
However if we're on the same torrent, and the torrent client knows how to discover his client, we can both cooperate without explicit coordination. Because Bittorrent addresses chunks by the hash of their content, I can verify whatever I receive from him without needing to contact the original publisher! Contrast when an object identity relies on an IP or DNS name, the only way to verify it is to contact its server yourself.
> even if you have globally routable addresses, you can still proxy your HTTP requests through your router if you want to
So, L4 address translation instead of L3... And I agree, to scrub fingerprints it makes sense to proxy at the highest protocol layer possible. So sure, maybe the future will be a nice flat v6 namespace for incoming connections, and a household HTML proxy to scrub access to legacy HTTP(s).
Don't get me wrong - I'm certainly not arguing against adopting v6. I just don't think it is wise to wait for it to usher in the peer paradise that people were imagining 20 years ago. AJAX and surveillance as a service didn't get adopted simply due to a shortage of v4 addresses.
> This is already impossible in some areas (e.g. parts of China) that are behind multiple (5+) layers of NAT
At a basic level, I do agree this development path is worrying. But IMO the real way to push back against this is to create a demand for something else. Unless the net result looks immediately different to a significant number of end users, the demand isn't there. And right now, even in the US/EU there isn't a widely-compelling advantage to having a routable v4 address.
Just to clarify, I wasn't trying to pigeonhole you to raw numeric IP addresses. I meant IPs and names that effectively translate to IPs - hostnames, DNS names, etc. Even with dynamic DNS.
IMHO, it is too late for these hacks. We need to embrace IPv6. I've been running it for almost 10 years now...
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.
https://github.com/WordPress/WordPress/blob/abcbee954f4d8baa...
If allocations in 0.0.0.0/8 happen someday, users will probably see similar misfeatures in many applications.
240/4 already works in many idea also. 127 and 225/8-232/8 can be reallocated as unicast also.
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.