Yes, it denies simple P2P connectivity. World doesn't need it. Consumers are behind firewalls either way. We need a way for consumers to connect to a server. That's all.
With IPv4 + NAT, you have a public IP address. That public address goes to your router. Your router can forward any port to any machine on your LAN. I used to run Minecraft servers from a residential connection on IPv4, it was fine. Never had to call the ISP.
In many countries they don't have enough, so you have CGNAT.
Still, I do think that the solution of, "one IPv4 address per household + NAT" is a perfectly good system. I view the IPv6 mentality of giving each computer in the world a globally unique IPv6 address as a non-goal.
For one, businesses and other entities also need Internet access. Cloud companies in particular needs a ton of addresses. That's gonna eat up a fair chunk of the remaining 50%.
Two, humanity is still growing, governments across the world are building new housing. That's gonna eat up another chunk.
Three, routing is hierarchical, and infrastructure organisations and ISPs are assigned blocks of addresses, not individual addresses. We can't just have a pool of free IP addresses and assign any address to any house in the world as needed. So even having 50% of IP addresses free wouldn't really be enough.
So in my mind, an IP addresses to household ratio of 0.5 means residential CGNAT is inevitable, even if we ignore legacy issues like individual universities and other institutions owning gigantic /8 or /16 ranges.
If you are giving out public IPs then you aren't really NAT'ing.
I mean, I understand that this feels normal today, that 10-20-50 devices need internet and that the way to manage that is to nat the connections, but your ISP isn't doing nat, it is you.
I also deployed it as a pilot on an internal network. Other than getting direct IPv6 connectivity to some services, which sometimes gave us better performance, it conferred no advantage to us.
IPv6 is great for phones where you don't expect any inbound traffic. Even then, every US carrier is using Carrier NAT to route and proxy traffic for their own purposes.
Either way, mea culpa.
I don't want our communications infrastructures to be just for consumers.
Worth pointing out that this article was written by the now-CEO of Tailscale. I don't know if "The world doesn't need P2P connectivity" is a compelling take.
I do wish ISPs would refrain from intentionally breaking things though. It ought to be illegal for them to block specific ports or filter specific sorts of traffic absent a pressing and active security concern.
Unfortunately, the internet is used for a lot more than using one of the six gigantic centralized websites.
Speaking of that, why don't we just keep ipv4 for ourselves and let them eat ipv6?
Roughly, it's my belief that an IPv6 world makes it easier for centralizing forces and harder for local p2p or p2p-esque ones; e.g. an IPv6 world would have likely made it easier to do bad things like "charge for individual internet user in a home."
The decentralization of "routing power" is more a good thing than bad, what you pay for in complexity you get back in "power to the people."
This idea comes up in every HN conversation about IPv6, and so I suppose this time it's my turn to point out RFC 8981[0]. tl;dr: typically, machines which receive IPv6 address assignment via SLAAC (functional equivalent of DHCP) periodically cycle their addresses. Supposed to offer pretty effective protection against host-counting.
Yes! They need an alternate encoding form that distills to the same addresses.
My machines Link-local IPV6 address is "fe90::6329:c59:ad67:4b52%8"
If I try to paste that into the address bar in Edge or Chrome (with the https://) it does an internet search on that string! No way around it.
I have to do workarounds like: "http://fe90::6329:c59:ad67:4b52%8.ipv6-literal.net:8081/
All to test the IPv6 interface on a web server I'm running on my local machine.
https://[fe80::5ad6:9567:26b7:763b%18]:8081/
Even Hacker News doesn't think it's a link
If it's on the same machine then just use http://[::1]:8081/. Dropping the interface specifier (http://[fe90::6329:c59:ad67:4b52]:8081/) works if the OS picks a default, which some will. curl seems to be happy to work. Or just use one of the non-link-local addresses on the machine, if you have any.
The other frustrating part of this is that it makes it impossible to come up with your own address syntax. An NSS plugin on Linux could implement a custom address format, and it's kind of obvious that the intention behind the URL syntax is that "[" and "]" enter and exit a raw address mode where other URI metacharacters have no special meaning. In general you can't syntax validate the address anyway because you don't know what formats it could be in (including future formats or ones local to a specific machine), so the only sane thing to do is pass the contents verbatim to getaddrinfo() and see if you get an error.
But no, they wrote the spec to only allow a subset of v6 addresses and nothing else.
I very much didn't test it, but this patch might do the job on Firefox (provided there's no code in the UI doing extra validation on top):
--- a/netwerk/base/nsURLHelper.cpp
+++ b/netwerk/base/nsURLHelper.cpp
@@ -928,3 +928,3 @@ bool net_IsValidIPv4Addr(const nsACString& aAddr) {
bool net_IsValidIPv6Addr(const nsACString& aAddr) {
- return mozilla::net::rust_net_is_valid_ipv6_addr(&aAddr);
+ return true;
}True future-proofing would require representing address length as an arbitrary-precision nonzero unsigned integer.
Since allowing a zero-length network address format would serve no purpose other than to pointlessly complicate standards definitions, you could trivially and without loss of generality interpret zero to denote some extended-length address length representation to be defined in a future version of the standard.
It still would have been a ton of work, but we could have just had what IPv6 claimed to be: IPv4 with bigger addresses. Except after the upgrade, there'd be no parallel system. And all of DJB's points apply: https://cr.yp.to/djbdns/ipv6mess.html
The people involved in core Internet protocol design were used to the net being a largely walled garden of governments, corporations, universities, and a small number of BBSes and niche ISPs.
Major protocol upgrades had happened before, not just for the core protocol but all kinds of other then-core services.
It had been a while but not that long, I think less than 20 years, and last time it was pretty easy. They assumed they could design something better and phase it in and all the members of the Internet community would just do the right thing.
That’s probably what made them feel they could push a more radical upgrade.
Unfortunately they started this right as the massive tsunami of Internet commercialization hit. Since V6 was too new, everyone went with V4. Now all the sudden you had thousands of times more nodes, sites, and personnel, and all of them were steeped in IPv4 and rushing to ship on top of it. You also lost the small town atmosphere of the early net where admins were a club and could coordinate things.
Had V6 launched five years earlier V4 would probably be dead.
V6 usage will probably keep creeping up, but as it stands we will likely be dual stack forever. Once the installed user base and sunk cost is this high the design is fixed and can never be changed without a hard core heavy handed measure like a government mandate.
Most things use DNS, so they keep working. Only things that rely on connecting to an exact IPv4 address break, which is very similar to the way that NAT broke things that relied on accepting connections to an exact IPv4 address.
Not a chance. IPv6 ate way more memory than IPv4 and memory was expensive back in 1995. Even IPv4 proliferation was chewing up memory and that was why the IETF introduced Classless Inter-Domain Routing (CIDR) in 1993 which gave us subnet masking.
Memory cost was a problem in routing tables until after both the DotBomb and the TeleBomb.
v4 extension headers are well known to get your packets dropped on the Internet, so they're a non-starter, but there's another extension mechanism you can use: you can set the "next protocol" field to a special value, then put the extended address at the start of the payload, followed by the original payload. This is functionally identical to using extension headers, but using a mechanism that doesn't get your packets dropped.
Far from not being seriously considered, this approach was adopted in v6 as RFC 3056.
> Except after the upgrade, there'd be no parallel system.
No. You get a parallel system because v6 addresses are too big to work with v4. Even if you used extension headers, v6 addresses would still be too big to work with v4. Whatever you do, v6 addresses are too big to work with v4. You WILL get a parallel system, and there's no way around this other than not making the addresses bigger.
A decade later, when IPv6 had real-world deployments was far to late for 6to4 to save the day: entirely because a swath of non-6to4 addresses existed and needed to be reachable. Given no strategic gain apparent for upgrading the commercial core, aligning financial interests by upgrading past the edge instead would absolutely have made sense. Unfortunately the hard parts the engineers anticipated in the early 90s were not the ones that held IPv6 back.
In summary, I agree: 6to4 could have been great!
> even the idea of starting a new protocol with 64-bit addresses with an upgrade path was considered far too scary at the time
No it wasn't? Every proposal had an upgrade path. Having one was a mandatory requirement.
You can read the requirements document yourself: https://datatracker.ietf.org/doc/html/rfc1726. To me, it looks like these requirements were decided by the community rather than being imposed from above, but either way you can see that having a simple transition from v4 is listed right there.
> A decade later, when IPv6 had real-world deployments was far to late for 6to4 to save the day: entirely because a swath of non-6to4 addresses existed and needed to be reachable
What I'm hearing is that the compatibility with v4 that 6to4 provides wasn't considered important, and not by people in any position of authority but rather by the actual people choosing what to deploy on their own networks. Even though there were more 6to4 hosts than non-6to4 ones, and even though 6to4 doesn't prevent you from reaching those non-6to4 hosts, people still didn't want it.
If you add *any* address bits you've already broken protocol compatibility and you need to upgrade the entire world. While you're already upgrading the entire world, you should add so many address bits that we'll never need more, because it costs the same, and you may as well fix those other niggling problems as well, right?
All the complaints I hear are pretty much all ignorance except one: long addresses. That is a genuine inconvenience and the encoding is kind of crap. Fixing the human readable address encoding would help.