>I am so surprised by the hate for IPv6 in this thread.
I find that HN views IPv6 noticeably more harshly than many other communities I have been a part of (e.g. networking subreddits and gaming communities). I am curious of the reason behind this.
Networking communities understand the way it works and the improvements it's making.
Gamers understand the consequences of not having it when they want to play with their friend but both are behind CGNAT and they can only play games with a server run by someone else and not any that use P2P multiplayer.
HN users can afford the $2/month/server that AWS or whoever charges today and besides your standard SPA + REST API doesn't really care how many layers of NAT and proxies it's behind.
Developers who don’t care to learn how/why things work, have gone by without it, and are upset that they gotta learn more now because it works differently.
I just hope that people won't repeat the same "I wish IPv6 were just IPv4 with extra octets" viewpoint again...
The use of hex is very helpful when you're calculating subnets. You want a /48 prefix? Just take the first 3 hextets. /56? First 3 and a half hextets. /64? First 4 hextets.
The thread posted yesterday about Czech Republic's IPv4 deprecation plans had at least a comment about IPv4 with extras octets. I am pretty sure that even once IPv4 will be fully dead and replaced by v6, people will still rant about that.
This is an excellent point because entire tools exist with ipv4 to calculate subnets and unless you do base math all the time you’re usually using them to figure out stuff like CIDR overlaps
I think it’s a bit more nuanced than that. The UX of IPv6 is still decidedly inferior. Typing a curl command etc or in general manually typing and remembering IPs is decidedly more difficult with IPv6 vs IPv4. I think IPv6 needs either a killer command line tool or aliasing scheme to overcome that stigma.
If "IPv6 addresses are harder to type or remember" is the worst thing that happens during the transition to IPv6 then I'd call the whole thing an unquestionable success, given that there were numerous far more important things that could have gone wrong or ended up worse but didn't.
DNS exists to solve the problem of people not having to remember or type IP addresses. This is true regardless of whether you are talking about IPv4 or IPv6.
What problem is not solved by various DNS and local-addressing options, but is solvable by some other aliasing scheme that isn't DNS under another name, and can you outline how a better aliasing scheme would work?
Background and current options, as I'm aware of them:
"IPv6 addresses are too difficult" objectors don't seem to want a solution to the ease-of-use problem that leverages aliases, because DNS is that. They want the ease of typing in IPv4 addresses without any overhead of setting up alias mappings or trusting local hosts' ideas of their own names. That's not possible, in general, with an addressing scheme that's 4x as big. The standard representation has tried to improve things with hex instead of decimal and collapsing the longest run of 0-fields. It could have used a higher base than 16 [1], but that would slow visual spot-recognition of an address. It could have dispensed with all the ':' chars, but that would prevent collapsing addresses and make chunking more difficult.
DNS as an aliasing scheme has many administrative forms. It can be configured per-machine with /etc/hosts (copied around manually, or with scripted or configuration management tools); on a trusted local network with mdns and ip autoassignment, if the network is trustworthy enough; or manually with a full-fledged DNS server, either private or public. More complex network environments leverage tooling to make DNS as painless as possible. The mappings still have to be configured and managed somewhere, even if that's separately per host via what hostname they each think they have.
It's also possible to assign stable, short local addresses that can be remembered and typed easily roughly on par with v4 addresses (10.0.x.1 vs fc00::x:1, which becomes shorter than IPv4 for x==0).
[1] See RFC 1924. Who wouldn't love to use addresses in the form of "4)+k&C#VzJ4br>0wv%Yp" ?
Solved you say? So how do I set up DNS for LAN hosts that under IPv4 would have static private addresses?
Under IPv6, you run into problems long before DNS - trying to assign static addresses as DHCPv6 is an afterthought, also whole setup has to be robust somehow when the whole network prefix changes.
Sounds like adding yet another potentially exploitable service listening on every host? Swell!
Seriously, I have yet to see a good tutorial how to herd IPv6 LAN with reliable local DNS, as is usual with IPv4. Everything is just handwaved away "nah, zero configuration". The reluctance to adopt it could stem from that.
Dude, it actually is zero configuration lol. My devices assign themselves an IPv6 via SLAAC, and they are reachable from other devices via devicename.local.
Macs and iPhones have relied on mDNS for years. Windows supports it. Android supports it since 2022. Linux has avahi.
If people could look a little further than the tip of their nose, they’d realize how much easier it’ll be to explain to people to just type in alices-iphone.local instead of trying to find the IPv4 address first.
..until another Alice joins the network with her iphone. There are plenty of valid reasons to manage names centrally and configure addresses explicitly, but no I'm supposedly a dinosaur that is supposed to get extinct finally :(
Not sure what you mean you can't use the Internet without IPv4. Yes some sites won't work but some sites don't work with https but that doesn't mean you can't use https on the internet
All those sites you mention work with IPv4 just fine. When you shut off IPv4 in favour of IPv6 you shut off access to probably 70% of the Internet. Let's see what happens when you don't enable IPv6? Oh nothing... that's right, the Internet will remain working just fine. There's very little incentive to support IPv6 when all that is required to connect to the Internet is IPv4. Which comes to the fundamental issue with the deployment and transition with IPv6, it will always remain a second class citizen until we no longer need to rely on IPv4.
>it will always remain a second class citizen until we no longer need to rely on IPv4
At $DAYJOB we are already running some services on IPv6 only to save costs, and if our IPv6 connectivity drops people notice it immediately. Is IPv6 still considered a second class citizen when this is the case?
Here's a reminder that "the Internet" is not just Google, Facebook, and Amazon.
Literally the one job it had, to prevent address depletion on the Internet. Just to be clear, we're talking about the Internet here, and not some IPv6 island.
I don't get you. We are running dual stack for the time being, and indeed we cannot solve address depletion this way, but that doesn't mean we are doing it forever.
At some point -- maybe when 60%, 70%, or 80%, or 90% of the Internet is running on IPv6 -- Internet services at a large scale will begin to deem IPv4 as a liability, and drop IPv4 support along with the addresses they are holding.
I am not talking about a distant future either. We already have IPv6-only servers up and running, mine included, and we haven't even reached the 50% milestone. In a way, the existence of IPv6-only servers meant that IPv6 is _already_ preventing IPv4 address depletion, because those servers would otherwise have to compete for IPv4 addresses with the other servers too.
Furthermore, I find "I hate IPv6 because it hasn't eliminated IPv4" a really weird opinion (it's not exactly what you said, but it is how I interpret your first few comments combined) because it's sort of recursive: hate IPv6 -> continues to use IPv4 -> IPv6 is unable to eliminate IPv4 -> hate IPv6??? Perhaps you can elaborate on it further, but I don't think it will be agreeable either way.
IPng was meant to avert the IPv4 address exhaustion crisis. IPv6 was chosen as the way forward. A transition group (ngtrans) was formed and instead of taking the time to consider how to integrate IPv6 into the existing landscape it decided to create a separate island. We now have a hodgepodge of transition plans and umpteen different transition mechanisms of which none make IPv6 first class.
What do I mean by making IPv6 first class? Basically a transition plan/mechanism where IPv6 is interoperable with IPv4. This was one of the primary considerations at the time when IPng were still deciding, where other contenders at the time had a better transition plan story. Instead the IPng group chose the technology that didn't have any transition plan because they liked the shiny new features that were irrelevant to averting the address exhaustion situation. Their failure to address the transition back then is why we're in this IPv6 adoption bottleneck.
Can you tell us what the better transition story was? As far as I can tell, v6 is already approximately as interoperable with v4 as it's possible to be.
I don't get your claim that it's a separate island at all. It's not. This machine is v6-only and isn't on an island, it has full access to the entire Internet.
TUBA had a sane transition story [1] although I do not know of the mailing lists these were discussed (probably done in in-person IETF meetings).
For IPv6 transition mechanism you can look into the ngtrans mailing list regarding AutoIPv6 which is basically an extension of 6to4 but instead of connecting IPv6 networks over IPv4 it would extend to IPv4 hosts. There's also an archive link in my post history which you can lookup (on phone).
As for current v6 being interoperable with v4, that is patently false.
I think you are having a very romanticized view of 6to4 and its derivatives.
By the late 2000s it was clear as day that 6to4 wasn't working out (the design rationales of contemporary IPv4<->IPv6 transition technologies will tell you why [0]). By extension, AutoIPv6 which was building on 6to4 was also unlikely to work out. Even worse, AutoIPv6 relies at least partially on anycast 6to4 which was later deprecated due to operational problems [1].
The only surviving 6to4 derivative is 6rd and even that is mostly phased out.
>As for current v6 being interoperable with v4, that is patently false.
You need to define your scope. Are you talking about programming? Or ability for IPv6 clients to talk to IPv4 servers? Or...?
IPv6 is interoperable with IPv4 from a programmer's perspective, once you upgrade your sockets from accepting sockaddr_in to accepting sockaddr_in6, your program automatically receives both IPv4 and IPv6 packets with IPv4 addresses represented as ::ffff:x.y.z.w.
And from a client's perspective, IPv6 clients absolutely can connect to IPv4 servers through a border relay of some sort, typically NAT64. But you can do SIIT as well if you are feeling fancy. Note that this is not much different from 6to4 and its derivatives.
As for the perspective of a server, indeed this is unsolved but again AutoIPv6 doesn't solve the issue as well since the server still needs a public IPv4 address.
Hm... according to that draft, TUBA's transition story is dual stack, which is the same as the main transition approach for v6. How come it's sane for TUBA but not sane when v6 does it?
> As for current v6 being interoperable with v4, that is patently false.
This machine is v6-only and can reach the entire Internet, including v4-only hosts. It clearly has more interoperability than you're claiming or this wouldn't be possible.
Interoperability would be the ability to use either IPv4 or IPv6 and talk to each other seamlessly. This is clearly not the case for IPv4 clients talking to IPv6 servers. This is clearly not the case for IPv6 servers accepting IPv4 connections.
As for TUBA, the transition plan incorporated tunneling, with a bit more thought put into this we could've had something similar to AutoIPv6. That document was just a starting point and outlined some important aspects of the criteria such as low administrative overhead for transitioning IPv4 networks to IPng, something which IPv6 falls completely flat on.
I've talked from v4 clients to v6 servers before, and I've accepted v4 connections to v6 servers. How can it be so clear that it's not possible when I've done it before?
> As for TUBA, the transition plan incorporated tunneling
The transition plan for v6 also incorporates tunneling (6in4 is the same thing as the EON tunneling described in the draft you linked), so again I ask why TUBA counts as having a sane transition plan when doing the same things in v6 doesn't.
There's not much administrative overhead involving in transitioning a network to v6. For most people it involves doing exactly no extra work beyond what they already do to deploy v4. Of course, you do need to reconfigure anything that's been configured such that it can only work with v4 (and this might be quite a lot of stuff), but that was always going to be necessary no matter what you're transitioning to.
I find that HN views IPv6 noticeably more harshly than many other communities I have been a part of (e.g. networking subreddits and gaming communities). I am curious of the reason behind this.