The article's right that IPv6 isn't going to happen.
I'm not sure it makes any points besides that.
(1) It's hard to fear our NAT-ed future when we're all living in the NAT-ed present to little ill effect. A typical large company today has more than a /19 allocated to it; if we're really talking about exhausting the TCP endpoint space, that /19 offers 536,000,000 concurrent connections. ISP distribution layers might not do that many packets per second.
(1a) If multiplexing is the problem, we can solve that in a subtransport-layer protocol without a worldwide ISP flag day that renumbers the whole world. There are already transports that are more multiplexing-friendly than TCP --- for instance, SCTP, a well-researched telco protocol.
(2) IPv6 exacerbates routing problems; it doesn't solve them. Routing table explosion and address space size are orthogonal.
(3) If we're embracing our NAT'd future anyways, I'm not sure I care how routable IPv4 are traded, or who has to go ask Halliburton to start paying for their obscene legacy allocation. You decided to work for the ISP, not me. Have fun!
> The key problem has been in the delayed roll out of IPv6 to end customers, or for xDSL modems to be able to support IPv6 (most of which only support IPv4).
The real key problem has always been that there's almost nothing to do in IPv6 space. I've got IPv6 connectivity (via 6to4 and HE tunnel broker) for more than two years. All I remember is watching that dancing turtle, visiting Google search over IPv6 (once or twice, maybe, because typing "ipv6.google.com" is inconvenient and pointless), read Python docs and updated various GNU/Linux distros from IPv6-capable mirrors. Oh, the only really useful thing is the ability to directly ssh/scp into any computer at my home without constructing additional tunnels to overcome limitation of having a single globally-routable IPv4 address per 6 devices.
It's not like most ISPs can provide IPv6 support easily, but even those who can see no point in doing so. NAT64+DNS64 is resourcewise worse than classic IPv4 NAT. Some (lots?) of clients will experience all sorts of strange client-side bugs with IPv6-only connectivity. And, more important, there're almost nothing to do in IPv6 Internet today.
I believe when hosting providers will start giving IPv6 blocks to every and each customer, ISPs will follow. Not the other way.
> IPv6 is a big deal though. Everyone's going to have to touch their long-running servers sometime before the end of this year. With IPv6 Day closing in this June and the eventual migration of residential broadband to IPv6, this is one of those inevitable things that isn't going to magically go away.
I think you're confused about the implications of the IPv6 transition -- IPv4 is a subset of that address space, so existing servers will "just work" via Carrier-Grade NAT that ISPs are providing.
Some tiny percentage of the Internet is IPv6 reachable today, and it ain't all gonna change this year. The IPv4 space can't turn into a parallel ghetto Internet after all...
> IPv6 once widely implemented might solve the problem, since new fixed IPv4 addresses are unobtanium for non corporate networks; I'm not holding my breath though.
I have this strange feeling that we (the general public) are, in some manner, being segregated away from full implementation if IPv6 for precisely this reason.
That the limitations of IPv4 have benefitted the centralization of our internet access; IPv6, due to its sheer size of address space, turns that space into a commodity that is easily shared. ISPs would (or should) cease to be "gateways" and instead become mere infrastructure.
Assuming efficient network bandwidth allocation, it would allow for easy p2p or "peering"-like arrangements, which isn't easy or as scalable with IPv4 today.
But of course, that isn't in their business interest.
I can't think of any reason why IPv6 isn't "fully deployed" today; I'm sure there's a lot of legacy hardware out there that doesn't support it, but I would think it would be a minority amount in the whole "grand scheme" of the internet. Certainly the "end points" - our workstations and phones and such - are all IPv6 capable today. There's no real good reason for the rest of it not to be - except for control over access.
I feel like a lot of the issues raised in that article aren't as relevant anymore. The issue of IPv6 only clients communicating over IPv4 can be solved via tunneling in both directions. Reading over that article again, it really does seem like he's complaining about the transition not the protocol. The solution to what he's complaining about is being solved by a slow and gradual approach that's taken place for well over a decade. The details have been worked out as time has gone on.
The biggest issue will not be getting everybody onto IPv6. That will happen at some point, however distant. The bigger issue is that clients slow to transition to IPv6, for whatever reason, will experience IPv4 service degradation as more and more of the internet switches to an IPv6 only stack.
> IPv6 is in widespread use. IPv6 is not "the future". It's the present. I have services in production where >30% of users access the service over v6. Use is growing. IPv6-only mobile operators are also now a thing.
That's... great, and I'm glad there's progress being made somewhere, but I don't think it's fair to say it's "the present". It's on its way.
My ISP has rolled out FttH across a wide area but still only offers IPv6 on business buildouts. Even if they offered IPv6 to general customers, they still have a ton of home gateway devices out there that don't support any IPv6 at all. The other ISPs don't offer it or have any external roadmap either. I don't think this situation is all that unusual or unique - it's just not something that the people paying the bills are clamouring for and it's a long road from where we are to significant penetration.
Oh, and EC2 still doesn't support IPv6 on anything but their load balancers. What portion of the market and traffic do you think they make up?
> In none of these situations would an ISP connect its customers via IPv6 only or would anyone provide any service that requires IPv6.
It's so much cheaper and faster already today that it makes sense to do v6-only internally and deliver IPv6 to the large fraction of customers who can have IPv6 and deploy a transform layer for the (gradually shrinking) class of have-nots.
Your IPv4-only competitors are spending more money to deliver a worse service. Maybe they'll wake up and realise, but the story of the past couple of decades suggests most such outfits are not too bright and when offered IPv6 on new links they'll smugly decline. Meanwhile you get to keep the difference. Your competitor thinks this service costs 86¢ per dollar revenue and you're only spending 84¢ per dollar revenue that's a lot of extra profitability.
Fighting this is a losing battle, and I imagine that decades from now somebody is going to write a book about how it was cognitively possible for "leaders" to champion an idea that couldn't possibly work, that they intellectually knew couldn't work, and all the actual evidence said wasn't working, and yet they believed in it anyway. Or that book might be about climate change denial, either way.
Eventually by the way - and 90% global is close to and even perhaps at the threshold where that's plausible for some of them - many general ISPs won't bother providing actual IPv4 networking. If you want IPv4 you're a niche customer, go find a bespoke IPv4 Internet Service Provider. If you're IPv6 capable but you want to reach an IPv4 host you'll go via a translation box automatically. As the interest in global IPv4 shrinks, the transit companies will lose interest in that service too, and eventually - decades from now - the IPv4 Internet literally goes away, the RIRs stop "managing" the now largely unused space and the residual pockets of IPv4 cease to interoperate.
I mean there's several existing solutions, NAT, ipv4 rationing, ip leasing, coexisting with ipv6.
Things look fine to me, the reality is dual stack, a full ipv6 transition is idyllic and pointless.
I'm certainly not the first ipv6 critic, and you may notice the nuance that I didn't advocate for not using it, I just don't advocate dropping ipv4. Furthermore it doesn't matter if I advocate it or not, like a train ipv4 keeps going, it's only ipv6 that is advocated.
> The major reason why we aren't seeing adoption is that
> there is no commercial need - that's the real driver.
Not entirely true. All big networks using private IP addresses and NAT (recent ISPs, and most cellular networks for example) have to implement carrier grade NAT (CGN), and it's getting painful and costly.
Also, a lot of web applications require low latency. The way to do this is often to create a lot of parallel connections to fetch content. For example, a google map can easily span 40+ TCP connection to fetch all the tiles making the MAP. During peak time this can put a very high load on CGN gateways. And when they overload, some sessions lags or time out (missing or delayed tiles => bad user experience).
This is why all big players on the web now support IPv6 and use it when possible. IPv6 avoid CGN and does not have such issues. Even if that still makes a small percentage of all traffic, it's steadily rising now. IPv6 is finally happening, because the alternative (CGN) is too painful to scale.
Now old large ISP with little growth don't care: they have plenty of public IPv4 addresses, with enough in stock to absorb their limited growth for a while. So they don't need CGN and don't care about IPv6. I don't expect this to change.
But with mobile and cellular getting a bigger and bigger share and mostly on NAT with IPv4 there is enough of a pressure to move to IPv6 to make sure it'll be mainstream by the end of the decade.
An odd article. He seems to think there ought to be a Grand Plan forcing the transition.
Servers can have both IPv4 and IPv6 addresses, there's no need for everyone to just switch over at once.
I strongly suspect that the big providers will start rolling it out over the next couple of years, and that this will filter down to local users after that.
My main problem is that very few home routers support IPv6, so they'll need to be replaced. But this can happen over time, with people on IPv4 being behind NAT, and thus having less accessibility to soem applications, they can make their own choices about when to upgrade.
As anyone who knows what you just condescendingly explained knows, anything short of 100% doesn't alleviate the problem that motivated IPv6 in the first place. Until absolutely everything is accessible via v6, we must continue to allocate v4 (or, worse, NAT it all), so we aren't really anywhere.
It was a side point. I'm on dual stack Comcast, so I already knew what you're telling me, and I made the point nonetheless.
Not many firewalls support NPT. OpenBSD PF doesn't, where IPv6 NAT works much the same as IPv4 NAT.
I wouldn't put much stock into that article. Many of their points are IPv6 pros (and the sections seem to make that clear), and many of the cons simply boil down to IPv6 being different, often necessarily so--for example, PTR records for a 128-bit address space were always going to be long even if the delegation prefix chunks were larger (e.g. 8 or 16 bits instead of 4). And I don't see how any of those problems constitute a nightmare.
The only real pain point for IPv6 deployment IME is DHCP.[1] DHCPv6 was never even supposed to be a thing; the very fact that it exists shows that the alternatives can be replaced or supplemented. But either way this problem really comes down to tooling and operating system support. IPv6 deployment and the standards and software for deploying it will mature together, and complexity will ebb and flow as alternatives enter and leave the fray. It could never have been any other way. IPv4 was hardly without its hiccups. Heck, the switch to classless IPv4 addressing was somewhat bumpy and confusing even as late as the early 2000s simply because a lot of software, including standard tools like ifconfig(1), didn't make it ergonomic or even possible. Frankly the latent complexity is still annoying.
I think it pays to remember that a lot of these articles are written by people with an eye toward job recruiting, interviewing, and generally grooming their credentials. The conclusions don't matter, they're just an excuse to exhibit familiarity with the technical details. They're a sales pitch for the author, and that essay is a particularly good one--the author demonstrates a comprehensive familiarity with the issues, notwithstanding their framing and conclusions.
[1] The biggest pain point in earlier years was the need for BSD Sockets API support in application software. But it seems we're mostly over that hump, notwithstanding the regressions caused during the shift to cloud computing, where IPv6 support was and remains much more immature than in the wider ecosystem.
> […] while providing IPv6 routing where necessary.
This is the key point. Right now, and on the short term, IPv6 is not necessary at all. Or at least it isn't perceived to be. Reason: everyone is still compatible with IPv4. I know it's as stupid as racing towards a concrete wall, telling yourself that you can always slam the breaks later, but we seem to race towards that wall anyway.
> People are basically in denial. […] they have seemingly no accountability […]
I completely agree. But I can't think of a way to solve this.
In order for IPv6 to ever become reality, a massive upgrade of infrastructure is required. So far ISPs have been reluctant to make the move. Whether or not ipv6 will ever see the light of day is arguable. We think not.
> The only real solution is widespread IPv6 adoption, which seems depressingly unlikely right now
Slow maybe, but unlikely? No, not really. IPv6 internet has grown fairly steadily (and afaik at a growing pace) since its inception and I don't see any reason why that trend would slow down or stop. There hasn't been any real opposition or alternatives for IPv6, mostly just indifference and ignorance. More and more new gear supporting IPv6 natively out of the box is being deployed on the field, reasons for not enabling it are dwindling. XP just got deprecated, most end-user stuff probably already supports IPv6. Old network engineers retire someday, and new generation is well aware of the issue at hand.
> The big "win" here is that existing IPv4 routers in the Internet's core infrastructure do not need to be upgraded all at once.
As I understand it, that is not the limiting factor in IPv6. Actually, I believe it was the second piece of the Internet's infrastructure to support IPv6 (the first part being OS networking support). Instead, the limiting factor is network management and middleware, in other words the edges and not the core of the Internet, that are holding back IPv6 adoption.
Bernstein's rant shows its age. It kind of proves the reverse of what you are trying to state.
The text starts with a question that undermines the whole text: "does every node need direct Internet connection?". Today, with P2P traffic on the uprise, the answer is a striking Yes. If, even with the hurdles of poor performing NATs, there is market pressure for P2P protocols, it's absurdly obvious the Internet must be symmetrical, not server-client.
The text then goes on about the impossible transition plan for IPv6. It's now obvious that moving servers to dual-stack, then clients progressively onto IPv6 (through provider address-space exhaustion) is a sound plan. It's happening, and it's approaching the critical point. 2016 starts at 10% IPv6 traffic, will end at 25% IPv6 traffic. No sound company today will launch its services in IPv4 only and eschew 10%-25% of potential traffic.
"Many people I talk with don't believe that IPv6 is the future and I commonly hear that they have forcibly disabled it on their computers due to this or that random problem."
It is their choice to make not anyone else's. They could be right. It might not be the future. I am one of those non-believers. I would love an improved protocol but I do not see IPv6 as the right fit. I think it is no coincidence that the providers are having problems with offering it to customers. Networking is complex and error-prone enough without IPv6. It is less so with IPv6? We know what the IPv6 zealots will say. Beware of "analyses" that focus solely on benefits without considering costs.
I'm not sure it makes any points besides that.
(1) It's hard to fear our NAT-ed future when we're all living in the NAT-ed present to little ill effect. A typical large company today has more than a /19 allocated to it; if we're really talking about exhausting the TCP endpoint space, that /19 offers 536,000,000 concurrent connections. ISP distribution layers might not do that many packets per second.
(1a) If multiplexing is the problem, we can solve that in a subtransport-layer protocol without a worldwide ISP flag day that renumbers the whole world. There are already transports that are more multiplexing-friendly than TCP --- for instance, SCTP, a well-researched telco protocol.
(2) IPv6 exacerbates routing problems; it doesn't solve them. Routing table explosion and address space size are orthogonal.
(3) If we're embracing our NAT'd future anyways, I'm not sure I care how routable IPv4 are traded, or who has to go ask Halliburton to start paying for their obscene legacy allocation. You decided to work for the ISP, not me. Have fun!
reply