We could have done a lot of good by adopting proposals to extend v4 like 0/8 and class D, but instead the decision was made to collectively drown the babies in the bathwater and insist on v6 at all costs.
People like to complain a lot about the new features in v6, but they don't make it any worse as a v4 replacement.
https://web.archive.org/web/20210122043401/https://blogs.aka...
The only thing that will make corporate environments change is if something they need starts requiring it, and not a second before.
Cloud is slowly getting it. Slowly. GitHub still doesn’t have it though, which makes pure v6 nodes annoying for a lot of use cases.
I'd love to be at a point where everyone just dual stacked everything so that one day we can flip off the IPv4 switch.
Kubernetes didn't get IPv6 support until later, and it sounds like it isn't reliable yet.
Heh. Kubernetes as a whole was a failed project at Google that got open sourced.
So in the end you are looking both at capex, increased opex and for what? You have ipv6? Congratulation, now you go to your C-level bosses and explain to them why it was worth it. Good luck.
There are entire ISPs (in the US) that are IPv6-only for CPE because IPv4 is unavailable and they have to use expensive CG-NAT boxes to deal with IPv4:
* https://community.roku.com/t5/Features-settings-updates/It-s...
*https://news.ycombinator.com/item?id=35047624
Meanwhile India was 80% IPv6 as of a few months ago:
* https://news.ycombinator.com/item?id=32798003
The fact that the US and EU just happened to get a bunch of addresses first doesn't mean the rest of the world has the same options available.
More addresses are needed if everyone on the planet is to be able to connect.
As I said before IPv6 will never happen fully because it solves a non-problem very expensively - by assuming the whole world is 64-bit workstations!
I'm worried that the time when we can start removing v4 and therefore see the actual advantage of v6 won't be here for at least a hundred years, optimistically.
- $55/mo. 3 Mbps DSL
- $80/mo. 300 Mbps cable (or even more expensive, faster cable)
- $120/mo. 100+ Mbps (if you're lucky) Starlink
- A few other heavily restricted, very expensive satellite options (e.g. HughesNet), to which the aforementioned fleet of ill-trained carrier pigeons might be preferable
Only one of those is practical and (mostly) reliable for anything remotely approaching something like remote work.
Back home it's such a luxury to be able to choose DSL, cable, or fiber. I can only dream that all markets will have an actual choice between Internet service providers someday.
That was the work of a few people on the YouTube team, not the company itself taking a stand:
(Which we could have had with a minor tweak of IPv4 instead.)
This kinda a problem for motivating people to move to v6 because as implementations of v6 grow there's going to be less and less pressure on the v4 address space.
In fact v6 mostly _is_ a minor tweak to v4; most parts of it are lifted directly from v4 but with a longer address.
v6 advantages:
* If you're an ISP, you need more complex hardware for CGNAT-v4 if your traffic is huge. If you do support v6, netflix, youtube and majority of your traffic is already on v6, you can get by without upgrading your CGNAT Infra.
* I suspect v6 should have faster initial connection - time to first byte, because of no NAT. I assume NAT is implied in v4 because if you're an ISP say in India where you have 1.2B mobile devices, you cannot buy 1/4th of all IPv4 addresses.
* Because of more IP addresses you can run VMs with public v6 addresses. It's not common to have ISPs give multiple IPv4 to a single customer, but with v6 that's always the case.
* I really don't think NAT could possibly make a noticeable difference in the time to first byte. My guess about what's "barely noticeable" would be a few hundred added milliseconds, my guess at what NAT would add would be a few milliseconds. Happy to be proven wrong though if there are any studies or experiments on the topic.
* I'm not sure what benefits there are to giving your VMs public v6 IPs when you still need to support incoming v4 connections.
(Also, doing things like loading a webpage requires many round trips, so even a small RTT difference multiplies to a bigger delay for total load time.)
You don't need to remove v4 to get benefits from v6. For example, you can handle inbound v4 on your load balancers to avoid needing to mess around with it on your entire VM fleet.
For services at home, where I do need IPv4 support, access over IPv6 is simpler and more robust. We can expect more of that in the future. Increasing prices of IPv4 addresses, certainly if for routing purposes you need a /24, may result in worse traffic engineering for IPv4.
End user facing apps also use it in gradual way when available, eg with WebRTC it lowers service ops costs and gives better latency.
Kubernetes is comically bad at IPv6. Docker is comically bad at IPv6.
GitHub is comically bad at IPv6.
Like I said, pricing IPv4 at all, is at least a start, a baby step in the right direction. Even if it is a drop in the bucket compared to the rest of the cloud invoice, it is still at least a line item that corporate accountants are going to notice. It is now an obvious cost to cut. Maybe that will put pressure on fixing how comically bad the above offenders (and more) are actually supporting IPv6, because corporate accountants may start asking hard questions.
Corporate networks were the last to drop XP, the last to drop IE, and will be the last to adopt IPv6.
IPv6 has issues but it hasn’t failed.
One question I have about this statistic (and also about Google's IPv6 statistic) is, does traffic mean raw bytes? And in that case, is this just a reflection that like 75% of all internet traffic is just YouTube and Netflix due to video being a bandwidth hog?
(I'm a huge proponent of IPv6 - I just wish we had more useful statistics!)
I guess you're thinking that the number of v4-only websites is much higher than the traffic numbers represent -- which is true but that's actually fine because v6-only clients can still reach those sites easily via NAT64, so having a lot of v4-only websites isn't blocking deployment of v6 or undeployment of v4. The only real problem it causes is that people use it as an excuse to not do v6...
As for Google's stats, they're probably percentage of either connections or users as measured by their frontend load balancers.
I think the only way that we will move to IPv6 is a law (probably from the EU) that imposes to every provider to give its consumers an IPv6 address.
I still don't understand why IPv6 is a thing. End users can use NAT just fine. Servers can use CDNs and reverse proxies, sharing single IPv4 address among any number of hostnames. But it is a thing, so it's hard to imagine any other protocol to take over.
So you want all computers to be behind at least a single layer of NAT. And you also want people to not only have to purchase a domain but also have to pay their NAT operator to add their domain to the reverse proxy
They're very different precisely because of hacky nonsense like NAT.
Now, CGNAT is a different beast and more worrisome from that point of view.
ICE/TURN/STUN: the address that your software sees on your laptop, desktop, home NAS is not the address that clients can connect to.
In both NAT and non-NAT you have to use UPnP/PCP to do hole punching, but with NAT you have to do a bunch of address-y stuff as well.
There’s plenty of numbers out there. Ipv6 lets my house have a whole subnet of them. It’s good.
being behind their NAT caused all sorts of issues that i didnt realise they were causing... stuff like UPnP didnt work right, opening ports wasnt working right... everything was all over the place.
Running servers at home is a good thing to have, but I doubt that ISP cares much about users running servers at home. Users watch youtube and netflix. That's what they optimize for.
NAT requires stateful tracking of stateless protocols. It's a hack much larger than anything related to ipv6.
IPv6 would have worked better if they had made minimal changes to the support protocols. But it was have had slow adoption because there was no incentive to switch until addresses ran out.
You are confusing hoarding demand for legitimate need. The Amazon's and Cloudflare's of the world were playing games to get large allocations, speculators were spinning up hundreds of legal entities to get allocations, tons of backroom deals to look the other way.
Pretty much every use case today for IPv6 is environments where CGN would have worked just as well.
While one can say that there's no way that IPv4 demand can ever be "satisfied" (which seems right to me), one can also imagine a different quantity demanded at $0.50/address than at $0.00/address, and also different levels of effort to make sure that almost all addresses that are allocated get put into use on the Internet. (I know $0.00/address isn't exactly the right way to describe what RIR allocations cost, but economically they've been more similar to the "beauty contest" than the "auction" allocation method.)
In the final direct initial allocation phase, people learned that something (with substantial economic value that can likely be sold in the future, no less!) was very scarce, and was being given out nearly at no cost for almost the last time. It's not surprising that they would have jumped at the opportunity to get as much of it as they could qualify for, somewhat independent of what use they expected to make of it in the short term. Maybe especially when they were hearing how other people were jumping at that opportunity.
- changed arp. Ok, new design is better but that didn’t need to happen. Shouldn’t be a problem for anyone?
- prefixes are an addition but there are really good arguments for them and not much downside. This can be argued I think
- fusing the end system identifier in the public address was a mistake, and I thought so at the time, and I guess it’s been mostly rectified.
So what is so tragic here? ISPs just didn’t care for 20 years because the crunch was delayed. Now they do. So where did Steve screw up?
IMHO the biggest problem is that IPv6 address autoconfiguration was half-baked. There is no mechanism to inform anybody about which address you have configured for yourself, unlike IPv4's DHCP where a central server knows everyone's address and can do things like update DNS entries and configure security devices. Autoconfiguration also didn't include critical details like "Who provides DNS for the local network?" and "What's the NTP server?". There isn't even any way to authenticate that the Router Advertisement your machine receives is valid, although this problem is shared with DHCP. The committee seems to have put a lot of faith in anycast routing, which has never been a good idea outside of toy networks.
Indeed. I thought I was being an idiot and just not understanding how this was supposed to work, until I learned that it just doesn't do a lot of important things. So when the day comes that I have to move my network to IPv6, I plan on continuing to use DHCP because I want the omitted functionality.
Of course, I still might be being an idiot and not understanding. Getting a solid picture of how IPv6 is supposed to work is genuinely hard to do with any confidence.
The more I learn about IPv6, the more I dread it.
The one thing that mattered was more address space. 4 billion addresses are not enough for the world. Anything else in ip6 is nice to have but falls off a cliff of importance and naval gazing that, if really of even nearly comparable significance, would be better directed to ipX or whatever's next.
IP6 is already facilitating connectivity for billions. Globally. That's a pretty major thing, more so than renditions of doing it my way.