The IPv6 mess (2002)
cr.yp.to
cr.yp.to
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
BTW I found it via a discussion about this post:
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.
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.
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'.
Also who are you explaining entering v6 addresses to? Serious question. And how is that effectively longer than a dns name?
People aren't used to v6 addresses, I get that. But they aren't meaningfully harder than myts3server.cgnatsucksdns.com.
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.
> URL's don't have a fixed length, so I'm not sure variable length is significant barrier to adoption by itself?
URLs tend to be a word or phrase that can be communicated. You tend to have to just say google dot com not gee oh oh gee el ee dot cee oh em.
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?
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.
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.
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.
It's reflective of work-in-office patterns--IPv6 penetration is much lower in business settings than in residential (or mobile) settings.
(At least as I've heard it explained before. But it could be a large country with high adoption like India swaying the statistics.)
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.
Worldwide. For the US specifically it's 52%:
* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
- 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 wrote a lengthy comment a month ago regarding the ARCEP IPv6 report: https://news.ycombinator.com/item?id=36788130
Kidding, but also kinda not. We should make ipv7 which is just ipv6 but the extra bytes go in an expanded header, like the author suggests.
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.
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)".
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.
Apple has a vested interest in IPv6 working on mobile, but benefits nothing from disabling IPv4.
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.
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.
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.
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
- [ ] ...
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.NAT
- [ ] is not a firewall
- [ ] does not provide any additional privacy over IPV6 privacy extensionsIt 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.
"Nobody will join your IPv6 network if it can't talk to Google, CNN, etc."
IPv6 networks can now talk to Google and CNN, for instance.
So why are we still dredging up this article when the problems have been solved?
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
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.
It's not surprising to me, it's worrisome.
Buying v4 addresses isn’t sustainable and drives the prices up long term.
CGNAT v4 at scale requires hefty and expensive translation boxes that have to keep growing with traffic volume.
Native v6 immediately takes the majority of your traffic - most of the big CDNs & content providers like Netflix support v6 already.
I wonder why they're not then. Clearly it's not a very big incentive.
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.
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.
For anyone interested in this it's called dhcpv6 prefix delegation: https://wiki.archlinux.org/title/IPv6#Prefix_delegation_(DHC...
Grumble grumble.
The world in which IPv6 was a good design (2017) - https://news.ycombinator.com/item?id=37116487 - Aug 2023 (134 comments)
Fusion was the energy of the future. Fusion is the energy of the future. Fusion will always be the energy of the future!
IPv6 was the protocol of the future. IPv6 is the protocol of the future. IPv6 will always be the protocol of the future!
How viable is it these days to flip this around, and run IPv6-only on the clients with NAT64 for external IPv4 access?
Obviously this precludes the use of IPv4-only devices, lets say I'd be fine with that.
Both have IPv6 addresses.
Or even make it 256^16. Then set the system that it changes to 256^32 in year 2100.
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.
I don't understand what does that mean
Why couldnt do the old IP address space just be extended to have more octets? 16 octets instead of 4?
Obviously the old stuff wouldnt work but translation (when needed - similar to NAT) would be relatively easy.
Sinct you dont seem to grasp it:
Old adress 1.2.3.4
New: 1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16
IP6 is unreadable for humans. Having 8 or 16 or whatever amount of octets would be easier to read or explain on the phone.
Hardware had to be changed for IP6 as well so why do you even talk about hardware?
And one could do some magic by trunctuating new address to old to make old software work.
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:
38.7.248.176.64.4.12.8.0.0.0.0.0.0.0.113
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.
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…
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.
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.
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.
You could say: at this point we are at only 50% of traffic, so why not rollback?
In the end, IPv4 is still working fine. Maybe IPv6 was just a huge error while the status quo was already good enough.
IPv4 address space is just too small. Full stop.
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.
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.
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. :(
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.
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.
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.
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).
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.
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.
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.
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).
It's not an address per person any more, but an address per IoT device or connected sensor, which might continue to grow even if population doesn't.