I believe a lot of this traffic is from mobile devices on networks where cellular carriers do have a good incentive to roll out IPv6 and mobile phones have good support for it. I would like to see google break this down by desktop / mobile traffic to see how much penetration traditional ISPs have. My ISP has IPv6 support and address space but refuses to roll it out to customers, I suspect due to the support issues it will create.
V6 addresses are not friendly. Four numbers is east to communicate, easy to enter, and easy to spot even for a non technical person. V6 is more difficult and variable length which is harder to explain to your grandparents. I also think there is something to be said about people with dyslexia and how the numbers are perceived by them.
And there will be lots of support needed to roll this out to home routers with various levels of support and bugs, needing to enable firewalls at the device level instead of at the router, all of the IoT devices with just enough processing power to send an up address on a half baked networking stack. It’s still a massive uphill battle. And yes, I know there are solutions to all of these issues, it’s just getting them out there.
If you're using V6 addresses by hand often enough to consider them unfriendly, you're doing something wrong.
Also basically every home router in the last 10 years is V6 dual stack because they're all more or less just running variations on Linux or FreeBSD with user land stripped out for Busybox.
Ipv6 has been fine for years. It is purely institutional laziness at this point.
> If you're using V6 addresses by hand often enough to consider them unfriendly, you're doing something wrong.
I more or less agree that it should be hands off. However explaining to someone over a voice channel how to enter an IPv6 address who isn't familiar even once is unfriendly. Not impossible, more difficult than IPv4.
> Also basically every home router in the last 10 years is V6 dual stack because they're all more or less just running variations on Linux or FreeBSD with user land stripped out for Busybox.
Yes, however they all have various levels of support for managing IPv6. Many early routers didn't have friendly interfaces to set this up, or did so automatically if the ISP provided addresses. Firewall support is still a mixed bag IMO, especially when you start to consider the crap router/gateways that ISPs provide to the lowest bidder. Good hardware with good support isn't something a non-technical person with a single tablet in the house is going to pick up next to the 40-Dollar option on a shelf. You are right, it's getting better.
> Ipv6 has been fine for years. It is purely institutional laziness at this point.
You could also argue that despite the dire warnings about the impending doom of the internet, IPv4 has largely been 'fine' for years as well, and will likely continue to hamper IPv6 adoption until v4 is no longer 'fine'.
> V6 addresses are not friendly. Four numbers is east to communicate, easy to enter, and easy to spot even for a non technical person. V6 is more difficult and variable length which is harder to explain to your grandparents. I also think there is something to be said about people with dyslexia and how the numbers are perceived by them.
URL's don't have a fixed length, so I'm not sure variable length is significant barrier to adoption by itself? Phone numbers also have variable lengths.
> Yes in many parts of the world you are correct. In North America, phone numbers are all 10 digits prefixed with a 1 for long distance.
911, and other special and vanity numbers don't count? People have never heard of international numbers, either? Or that long distance vs local changes the length?
For me it's mostly been IoT type devices where you need to join the network of the device, and if I am lucky, it will have a captive portal to setup the device. This could still be V4 for the foreseeable future, however I see this as a problem in any level of communication. Just time yourself saying a full IPv4 address vs an IPv6 one, without a block of zeros, it's significantly longer and more error prone.
Your example of 8.8.8.8 is itself designed to be easy to communicate and enter, same with 1.1.1.1 and 9.9.9.9, etc. They exist because communicating an ISPs DNS server or a standard IPv4 address can be hard sometimes.
Isn't it time to stop using "grandparents" as a stand-in for "naive user"? I know a lot of grandparents who are more tech-savvy than their grandchildren.
One situation a grandparent can find themselves in: they connect to a free wi-fi network that should show you a welcome screen, where you agree to something, before actually turning on the internet. Quite often this welcome screen fails to appear on at least some devices. A very useful workaround is to open a browser and go to 10.0.0.1; the agree-and-join page is quite likely to appear then.
> V6 is more difficult and variable length which is harder to explain to your grandparents.
IPv6 addresses are still fixed size. They aren't variable length. The :: shortcut is just "fill with zeroes here" and your grandparents probably had lots of bank account numbers and credit card numbers they memorized as prefix, suffix and some number of zeroes in the middle. (Like the :: shortcut they might not even bother to remember how many zeroes and just fill out the boxes until it looked right.) That's still common among some banks to use account/card numbering schemes like that, even in the computer age where you probably shouldn't memorize your account number and it is better for security if the account number had something a lot more pseudo-random than a long series of zeroes in the middle.
> I also think there is something to be said about people with dyslexia and how the numbers are perceived by them.
I can't speak for anyone else with dyscalculia (like dyslexia but only for the ordering of numbers) but hexadecimal is a lot kinder to me than decimal. I often remember the right digits but not their order, but I rarely have such problems with "words" and IPv6's use of hex 4-digit groups looks to my brain a lot more like words than numbers, especially when a through f show up. I hate trying to remember IPv4 addresses in dotted quad format because it is sometimes a million ways to get the orders wrong even knowing the format, but I've personally had fewer problems visually/memorably with IPv6 addresses, especially when you get a nice chunky :: in there somewhere. (It's so great sometimes to just handwave away all the less meaningful zeroes.)
Again, that's just my experience with my own (undiagnosed from a professional standpoint, undebilitating) dyscalculia.
If you zoom in on the graph, you can see oscillatory behaviour / noise. Would anyone know where this is coming from? It is almost like they are measuring an analogue signal and have a 50/60Hz hum on it...
Edit: I just remembered seeing something similar related to rounding a floating point signal once. Maybe that is the reason behind it.
Edit 2: Peaks seem to fall on Saturdays, so maybe this corresponds to people turning on their computers/routers at home more often on the weekend.
If you really zoom in, you can see the general pattern: it is highest on a Saturday, and low on Monday-Thursday, with Friday and Sunday in intermediate positions. Furthermore, the troughs get noticeably higher between November and December. Finally, the troughs got a big, sudden boost in March 2020 that takes several months to slowly "recover". What other behavior follows that pattern?
It's reflective of work-in-office patterns--IPv6 penetration is much lower in business settings than in residential (or mobile) settings.
Zooming right in the peaks in IPv6 are on Saturdays. So it's probably people at home or on their mobiles more at the weekend, more at work the rest of the week.
I'm surprised that it falls back pretty equally on Fridays and Sundays, though. Maybe this is an artefact of the timezone they are operating in - some of the Friday traffic is actually Saturday, some of the Sunday traffic has gone to Saturday.
Other comments are pointing out it's much much easier to migrate mobile to ipv6 than it is to migrate desktop, so I'm thinking it's more likely this than the other possibilities.
France has recent reports of IPv6 deployment. There's been a huge political push for modernising the country infrastructure to stay competitive in the global tech space, which included:
- FTTH everywhere (even in remote areas) with provisions to ensure competition and eliminate ISP lock in (which happened in the cable days, lessons were learned)
- tracking IPv6 deployment, publishing detailed yearly reports of status and plans, and pressuring ISPs
- mandating IPv6 if a mobile operator wanted a 5G license
Net result is you can basically assume that IPv6 is there except in increasingly rare cases (90-99% except one laggard). IPv6 just works, and is a freaking breath of fresh air in a world of double NAT and CGNAT. I've been on IPv6 for over a decade with both simple and complex scenarios, and every bit of IPv6 is just flat out better than IPv4 in my experience.
I've noticed too would have expected that some not as developed countries would dominate ipv6 since Germany and France have about five times more v4 addresses then India.
In order to predict how bad the long tail will be though we should ideally look at the graphs broken down by network type. Does the increase just represent a switch from people using their residential ISP connection for everything to people using their cell connection more, or does it actually reflect residential connections moving from v4 to v6?
The only way to break the long tail is regulation or forced updates. If you're at 95% rollout, it's fairly likely the last 5% of holdouts won't do it willingly, so they need the stick.
I would definitely support regulation here, especially regulation forcing ISPs to provide v6. That would at least take care of one large part of the problem.
I despise pointless recency trolling on articles on this site, but I will note, somewhat sheepishly, this seems to have been written in or shortly after 2002, a solid twenty years ago... and how has the situation improved since then?
Half of the big four ISPs in the UK provide IPv6 now (eg BT, Sky).
Full dual stack or something like v4 CGNAT + native v6 is practical and works well where available.
Big CDNs and content providers typically support v6 - eg Apple does, Netflix does, Google does, the big CDNs like Cloudfront, Fastly, Cloudflare do.
Apple requires app store apps to function on IPv6 only networks since 2016.
The holdbacks are smaller ISPs, ISPs with big legacy v4 allocations, and businesses.
I see more pushback from MSPs etc on IPv6 (and practices like disabling it completely) than any other sector.
edit: for an ISP that enables IPv6, the majority of their traffic will pretty much immediately be over it, as a result of the big CDNs and content providers supporting it. This reduces load on compatibility mechanisms like CGNAT, which is nice too.
> Apple requires app store apps to function on IPv6 only networks since 2016.
Oooh, I think that's really big. That basically forces every app company to make sure their main domain at least has an AAAA record that goes somewhere.
I think Apple could force IPv6 adoption alone by extending this policy... An iPhone update could change the behaviour to only connect to a new wifi network if there is working ipv6 connectivity. "new" would be defined as any network whose mac address is not currently in Apples geolocation database.
That would mean anyone getting a new broadband connection or router would see it as not working unless it had IPv6.
Perhaps you can have an override - eg. "Use this legacy network anyway this time (some apps may not work properly)".
> That basically forces every app company to make sure their main domain at least has an AAAA record that goes somewhere
They don't require that. They just require that it works on an IPv6-only network with some kind of NAT64/DNS64-type gateway.
I.e. they require that apps aren't manually using IPv4 addresses internally but either are using the OS APIs that protocol-agnostic, or doing the right thing manually.
If they can ensure most Apple devices have IPv6 connectivity, there are a bunch of device-to-device connectivity benefits. For example, they can do video calling without having to host expensive proxy/STUN/TURN servers. Peer-to-peer data distribution and storage starts to make sense. Peer to peer gaming stops requiring server infrastructure.
It also means that typically all the other devices in a users home will be able to get IPv6 - so they can for example continue to remote control your Apple TV even if you walk a little out of wifi range.
Sure - for any IPv6 feature they build, they will need IPv4/proxied fallback. But if they can make sure 90% of users use IPv6 and direct connections, then the money and user experience costs of having to run the fallback servers becomes manageable.
I do not think any of those things would even remotely make up for the brand damage and bad will Apple would garner from breaking their customers’ Internet connectivity.
Maybe not, but remember it will mostly be the ISP taking the brand damage. "Hi tech support: The router you sent me isn't working properly! My iPhone won't connect to it, but the iPhone worked fine with the old router!"
No ISP would hesitate for a second to call out Apple on this kind of BS.
Every pundit on the planet would make hay of the matter and everybody and their dog would know to not purchased Apple products since it breaks their Wi-Fi.
All Apple would get out of this is a huge black eye and no upside.
Mobile operators want to deploy something like NAT64/DNS64 and they're the ones pressuring Apple.
You app can require access to IPv4-only servers, as long as if your app looks up the DNS and finds a 64: AAAA record it will connect to that. That is fine by Apple.
There used to be a form response people would post in discussions about ending spam or similar. Something like
Your proposed anti-spam measure wouldn't work because
- [ ] it assumes mail administrators operate in good faith
- [X] it assumes all systems can be upgraded in a timely manner
- [ ] ...
We could probably have the same for IPv6.
The proposed method
- [ ] for an alternative to IPv6
- [X] to avoid the transition to IPv6
- [ ] to allow us to keep using IPv4 indefinitely
would not work because
- [X] it would require replacing all the hardware and updating operating systems anyway
- [ ] it does not expand the address space to the extent required
- [ ] etc.
It is gradually becoming acceptable to dismiss IPv6 and suggest searching for a modern, practically minded alternative. Important first step in untangling the mess.
Naturally opinions vary as to what exactly would constitute modern. Common complaint is the significant mixing of OSI layers, in particular application level concerns like significant baggage of encryption & authentication. And then there's my pet peeve of BSD Sockets API incompatibility which was introduced accidentally.
It is interesting or ironic that the article's not actually dated (afaict), given the insistence on/fairly unusual and specific style of dating everything that's referenced within. 'As of 2002.11' within the text is the only hint I noticed, which doesn't actually mean it was written in November 2002, but in practice probably does (at least that sentence).
Old devices failed, new devices "just work" with IPv6, corporate environments are slow to change, until they're forced to. The "internet companies" have moved on to IPv6, but the "non-internet companies" are still stuck on ipv4 only (so google and cnn work, but your local steelworks is stuck on ipv4)
It's bewildering to me the number of large American ISP's that just don't (or won't?) support IPv6 for one reason or another. I dumped CenturyLink about a year ago over it (among other things with their wretched fiber service)
Of course those clowns proudly boasted about participating in "world IPv6 day" *12 years ago* but all their services and websites are still IPv4 only
For all of Comcast's innumerable faults and absolutely parasitic rent-seeking, at least they offer IPv6. Even if it's "only" a /64
Is it really that surprising? Here in Sweden many ISPs have begun charging for being assigned a public IPv4 address. I'm sure since it's happening here now it's probably been happening in the US for a long time.
If IPv6 actually became ubiquitous enough to rely on then people wouldn't have a use for IPv4 addresses, and they don't have a leg to stand on charging people money for an IPv6 block.
What even is the advantage for an ISP to offer v6? Consumers aren't demanding it. Everything works on v4. And even if consumers were demanding it, most of those consumers don't have a choice in ISP company.
Regardless of if an ISP offers IPv6 or not, they still need IPv4. Thus if you are small and/or have enough IPv4 address space, IPv6 is just an additional cost and burden.
The support burden of IPv6 isn’t trivial when you do not control the end user devices.
IPv6 bandwidth isn’t cheaper nor more performant. From a business perspective, the only thing you get from IPv6 is a larger address space and a smaller need for (CG)NAT.
There is an incentive to deploy IPv6 if your (CG)NAT costs and/or the costs to acquire more IPv4 addresses is larger than the costs to deploy and support IPv6.
The tipping point is different for each ISP.
It also depends on the regulator environment whether you are forced to deploy IPv6 or not.
At small ISP scales, the cost of CGNAT isn't too high.
Larger ISPs tend to be longer lived and often have large pools of v4 allocations that they didn't pay market rates for, so are happy to sweat long term.
> I never understood why they couldnt just double it from a.b.c.d to a.b.c.d.e.f.g.h.
What do you mean "just"? There's no "just" anything in this regard.
IP is a binary protocol. Its meaning is deeply burned into millions of pieces of networking hardware.
The source address in IPv4 is 4 octets starting at octet 12. The destination ddress is 4 octets starting at octet 16. You can't extend anything without forcing an adjustment in everything that follows, and literally redesigning hardware because there's physical parts of chips that are 32 bits wide.
So "just doubling" doesn't really help anything, you still need to readjust everything in existence.
> Or even make it 256^16. Then set the system that it changes to 256^32 in year 2100.
> Why couldnt do the old IP address space just be extended to have more octets? 16 octets instead of 4?
That's exactly what they did. IPv6 is precisely 16 octets.
I think you're getting hung up on the hex representation, but that's all it is, a representation. Nothing stops you from writing an IPv6 address as 16 sets of numbers from 0 to 255.
In fact, IPv6 has the :: shortcut, which stands for "fill in all zeroes here".
So, one of Google's addresses is 2607:f8b0:4004:c08::71. This is short for 2607:f8b0:4004:0c08:0000:0000:0000:0071. Which you could also write as:
To repeat the other comment in this thread. Just increasing the address space is such a headache that you might as well take advantage of the suffering to fix the other problems with v4.
If they’d simply added two or four bytes (IPs of 48 or 64 bits) by finding space in the V4 header we would have been done by the mid 2000s.
But at this point we are at almost 50% of traffic, so why stop.
I wonder if the disaster is partly due to the various standards boards of the time (late 90s) still acting like they had the kind of ability to do things in a coordinated manner they had when the net was just government and research institutions. The fact that it was now a giant unmanaged market hadn’t sunk in.
The fact that lots of packet processing hardware relied (and still relies) on the IP header having the structure it did means you’d have exactly the problem IPv6 had. So you’d have to roll out brand new hardware that simultaneously supports both types, just like with IPv6.
As for endpoints, it’s similar - no IPv4 endpoint could talk to an IPv4+ (or whatever you want to call it) endpoint without additional code to handle it (just like IPv6 needed software modifications), and if you wanted backwards compatibility you’d have to still have a regular IPv4 address on every endpoint (or NAT) as well as an IPv4+ or whatever address - just like what’s needed with IPv6!
So ‘just’ doing that causes literally all the exact same problems as what we had with IPv6…
It's actually a lot worse. Unmodified routers route IPv4+ packets to whichever IPv4 endpoint happens to have the "same" address. So depending on which path your packet takes, you suddenly end up in nondeterministic routing loops.
Right, that could also end up the case that the IPv4 endpoints become NAT landlords charging extra for all the "4+" traffic that they have to see. We already see blocks of IPv4 addresses changing hand for lots of money, imagine if they could also monetize "downstream" traffic. Doesn't that give added economic incentive to never "fix" those bottlenecks? They could encourage more people to support "4+" directly on their devices or they could keep collecting easy rent from being NAT gateways. I have a hard time imagining that profit motives wouldn't make deployment of any "IPv4+" worse than IPv6 deployment.
> So ‘just’ doing that causes literally all the exact same problems as what we had with IPv6…
To be fair, there’s a lot of other changes with IPv6 that could have been simplified or approached in a more IPv4 familiar way:
- ARP instead of NDP
- DHCP instead of SLAAC, DHCPv6, DHCPv6-PD, etc
- IP syntax (periods vs colons and square brackets)
- IP header design (extension headers/non fixed size approach for the header)
- NAT support from the get-go (you can debate the evils of NAT all you want- not including it from the start was a net negative against IPv6 adoption)
- Private IP RFC1918 style space instead of the ULA addressing
Probably missed a few others. It’s the whole ecosystem you need to take into account. Too many changes were attempted at the same time.
There is no such space in the IPv4 header. And even if it were possible and you could specify an IPv4+, you’d run into the exact same problem: people would still insist on an IPv4 address to talk to whoever still is in the IPv4 world.
Extend the address space to the right. All V4 addresses become /32 prefixes in a /48 space. 48-bit addresses ending in .0.0 are semantically identical to 32-bit addresses and may in fact be sent as classical 32-bit addressed packets or converted to such in flight to support old devices.
Use the IP options facility for additional address bits, or alternately use the identification field and deprecate fragmentation at the IP level which is often broken anyway and is obviated by path MTU discovery.
Routers would still have to be updated, but only close to or at the edge for quite some time.
Could have been done that way but water under the bridge.
If you'd got that standardised before CIDR then it might've worked, but there's no way to make it happen now; the IPv4 routing table is hopelessly fragmented and getting worse every day. New ISPs would be doomed to be forever second- or third-class citizens - there are no new class A or B blocks to hand out.
We already have v6 addresses that are semantically equivalent to v4 ones: ::ffff:a.b.c.d.
You could put extra address bits into option headers instead of expanding the address fields, but... what do you do then? How do you make things work? No existing OS, software or hardware device knows how to use them, and you have to go around and update those in exactly the same way you have to on v6.
None of what you've suggested here would have allowed us to finish in the mid 2000s.
There is the Options field, it could have been theoretically used. But that would have made the whole routing and decoding even more inefficient and messy...
IPv4 isn't working fine unless the only use case for the Internet is pure client-server access to centralized cloud. Even there it's not working fine because cloud is running out of IP space.
That doesn't mean the problems have gone away. It means we spend time and effort working around them, and many things just don't work at all.
It remains true that v4 is too small and that it isn't working fine. That's been the case for so long that a lot of people grew up with the problems and can't even see them because they're so used to them, but the problems are still there.
I did not realize at first sight that this is an old article. It was standardized in the 90s and supported by most interfaces since the early 2000s but does not seem to be working properly as of today in terms of adoption. A big problem today regarding Ipv6 is the still missing auto configuration on most devices and router sided problems like don't sending out router advertisements with the prefix. Then there are other problems like no default gateway set. Technical skilled people are able to get Ipv6 running on their pc, but not the average guy.
Problems get much bigger on mobile which represents most of the worlds population digital presence. If everything properly configured Ipv6 works over ones own network normally as on a pc. But good luck with mobile data. Changing APN settings on android to Ipv6 does often not work / not supported by the ISP.
Almost half the world is using IPv6, according to Google's traffic statistics. In some countries it's 60%, 70%+ and I'm sure includes plenty of average guys.
This is mobile phones dominating that number. Almost every 4G / 5G phone right now uses a dual stack IPv4/6 connection. This is not necessarily problematic but home broadband is still lagging by a lot. I sometimes never get a prefix assigned. I have to redial PPPoE as IPv6 link uses IPv4 session. It's not plug and play for home broadband unless you use their modem router combo which has other issues.
Good point but there is still half of the worlds population missing which is due to missing auto configuration / proper support by the ISP. And I would guess that these numbers represent connections from home networks and not from people on the go using mobile data.
In my experience with consumer internet service and cellular service, ipv6 (when available) just works out of the box and you don't even have to notice.
>A big problem today regarding Ipv6 is the still missing auto configuration on most devices and router sided problems like don't sending out router advertisements with the prefix.
Huh, I haven't seen that issue with RAs. So far, my SLAAC deployment is playing nicely with my endpoints. About 40k devices, all BYOD. SLAAC seems like the only way to make this go. Because Android still has no intention of implementing DHCPv6. :(
Assign 2^96 addresses to each IPv4 address. The original address is now a.b.c.d.0 and there are lots more a.b.c.d.x. When sending a packet over an IPv4 link, translate packets with .0 destinations to v4 packets and embed others in a special v4 protocol. When receiving a packet do the reverse. Now you need a v4/.0 address only if you are directly connected to a v4 peer, and an upgrade is useful even for a single computer behind a NAT.
I came up with this idea in like 5 minutes so I'm sure it is flawed. But i think that if we had a realistic design we could have been done with the transition in early 00s.
It's actually not that flawed, you've more or less invented 6to4. Every v4 address has an associated v6 network (basically 32.2.a.b.c.d.*), and you can send packets to that network by crafting packets that use protocol 41 ("6in4"). It only gives 2^80 addresses per v4 address but that should be enough for anybody.
But uh... it doesn't seem to have helped as much as you're thinking.
Also, you didn't address how v4-only devices or software would talk these bigger addresses (how can you fit >32 bits into a sockaddr_in struct?). That's one of the big difficulties of v6 deployment and it won't go away no matter how you design v6.
The key point is that all v6 addresses are owned by v4 addresses and therefore tunnelable, and that tunneling support is mandatory. There is no external prereq to having an individual device be able to open connections to v6 addresses, and only support at the router (with a public address) is needed to receive connections from any v6 address.
There is no way around upgrading end devices. But the problem with v6 adoption isn't the number of end devices from before 1995.
Basically the adoption plan could have been:
1. Get end OSs to have v6 support. They gain the ability to make outgoing connections to v6 addresses right away. There's no reason, from the beginning, for this not to be enabled by default with zero configuration from the beginning.
2. Get NAT routers at the edge to have v6 support. Gains the ability to publish services from inside without awkward port forwarding etc (and increases the benefit of 1)
3. Slowly make v4 addresses expensive so that consumers make do with less than a /32. They need v6 capable endpoints but can communicate as clients with anyone, and as servers with anyone who has adopted v6
4. Eventually v4 addresses are so expensive, and the number of machines running browsers that don't support v6 so small, that small time web sites stop taking a /32
etc. it doesn't really matter when the network backbones upgrade, it just saves a few bytes on the wire and they internalize the cost of that
This just doesn't seem like what happened in our timeline.
Tunnels cost money to run. In Step 3 the companies that own IPv4 addresses have even more reason to pass those costs directly on to their downstream consumers, plus a little extra to earn a bit of profit.
IPv4 address owners get to be landlords collecting rent on anyone downstream. It benefits those with massive early IPv4 allocations and few other people.
In that case there seems like less reason to upgrade major network interconnects from v4 because that would "ruin" some IPv4 landlord's "rent" (and profit).
It only takes a few v4 addresses to make enough v6 addresses for everyone, so there is no long term rent once all edge devices are v6. v4 addresses being temporarily "rentable" helps push the system towards that end goal (because the key is to fix the edges, and the edges are the ones getting screwed paying for v4 addresses if they want them). It doesn't matter if major interconnects upgrade - if they want to shuffle v4 packets tunneling v6 packets, and have enough addresses to do it, it's their problem.
I still think there are technical flaws in my proposal - for example, probably the tunnel should use udp so that it can traverse totally clueless NAT - but I think the basic idea of trying to upgrade the edges while fully interoperating is incentive compatible in a way that the idealistic v6 approach just isn't.
We have CGNAT and NAT46 and NAT64 and all sorts of tunnels today. It doesn't take a lot of current experience to imagine how much a v6 dependent on v4 and tunneled through v4 solution feels bad for the edges.
The problem with IPv6 deployment has never had anything to do with lack of tunnels, "temporary" or otherwise, we've had that technology all along.
It does matter if the major interconnects upgrade. We've got decades of data now if you want to science it.
In your scheme if you aren't mandating every v4 address be a NAT "forever", then you've at best got huge sections of "dark" addresses that can't properly be used without some traffic accidentally blackholed. If you do mandate it you run the risk of bad actors taking advantage of it and toll bridging the chokepoints at the tunnels. (Which is also in theory a massive man-in-middle security risk.) Either way you are locked into the whims of IPv4 address owners and the mistakes of past IPv4 allocations (including all the early /8s that went to big companies just because they asked the right year and the fact that the large continent of Africa has never had anywhere near enough address space, and a fraction in comparison to Europe and the Americas).
I really don't see the economic incentives that would have made that addressing system better than the IPv6 we got, but I certainly see a lot of them that would have made things much worse.
> The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.
That is THE problem. Those designers failed to see the huge chicken-and-egg issue.
They chose to make it impossible to establish IPv6 without the active participation of people, and they did expect people to actively change their setup to join the IPv6 club before IPv6 being fully established... just for the sake of the cause... which is laughable if we want to be kind and the definition of sheer idiocy if we want to be honest.
People will move towards a target when the reward is ready to pick; otherwise, apart from a few enthusiasts, inertia will prevail.
I wish this debacle would be used as an example of how (not to try) to motivate people for serious stuff, like global warming.
I do wonder if things would have been fine if had just added another octet. We would still have had enough addresses to not need more for the forseeable future. Some may disagree, but a trillion addresses are fine for human population which is going plateau soon. I am not a network engineer, but I believe it would have been far easier to make the two versions interoperable. The number of addresses possible with IPv6 are too much for its own good. The ranges are absurdly long and far apart. Add to the difficulty to communicate and understand an address filled with hex-codes. I think IPv6 solved more problems than that were actually needed.
> I am not a network engineer, but I believe it would have been far easier to make the two versions interoperable.
And what do you base this belief on?
Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6).
Even with IPv6 we are not abandoning NAT. There are good reasons to have a single point of access / control. Do we really see billions of devices connected independently to the internet?
NAT still exists for IPv6. There is NAT66 and there is NPTv6. While no doubt there is less need for it than with IPv4, there are valid use cases for both.
Previous comments:
- 2010: "The IPv6 Mess" (37 comments): https://news.ycombinator.com/item?id=1236048
- 2022: "The IPv6 Mess (2002)" (68 comments): https://news.ycombinator.com/item?id=29757361