I have been deploying IPv6 for more than ten years and it really improve many situations (beside larger addresses).
I have to admit, there is a learning curve. But I want to encourage everybody involved in configuring computers to learn.
Also I want to rent about Cisco not using /64 for link local by default, thus being incompatible with BSD systems. Link local must be /64.
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.
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 new Godwin's Law, any discussion about IPv6 will inevitably lead to someone suggesting IPv4 with extra octets.
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.
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" ?
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.
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.
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.
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.
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.
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.
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.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-tuba-transi...
> 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.
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.
> 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.
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.
[0]: https://en.wikipedia.org/wiki/IPv6_rapid_deployment#Comparis...
[1]: https://datatracker.ietf.org/doc/html/rfc6343#section-3
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
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.
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.
IPv6 will, finally, enabled the real internet: all p2p protocols will start to work seamlessly. I am thinking a super simple no-dns IP (audio|video) phone protocol listening only on tcp 1 port, new bittorrent like protocol for live streaming, etc.
Since IPv6 has been almost everywhere in my country for years: enjoying ssh session everywhere (ipv6 mobile internet), without any domestic NAT to configure.
But, still... steam... github... and some "rogue" (:P) smtp servers.
That said for HN, where is the champagne?
I get an ipv6 for my phone through Wireguard that way.
Yes. You also have to get an ASN though, and an ISP which which will advertise both over BGP.
(If you qualify for one, there's little downside to requesting it at the same time as your IPs, though)
If we want that, global orgs in charge of the global phone number mapping must coordinate around some slice of the IPv6 address space (what they already do with international roaming of phone numbers). This will be very hard to operate safely, very probably.
I don't know if it's actually being used. IIRC since then everything has moved to a higher layer.
A good idea? No.
IP addresses are used for routing. Every provider-independent block of addresses needs its own entry in the global routing tables, which are stored on basically every BGP router in the world. There's a limit to the size of these tables, as they need to be stored in special TCAM memory.
Note that IPv4 currently has many more routes than IPv6 not only due to higher adoption, but also due to higher fragmentation: some providers are obtaining many small non-consecutive blocks from different sources (buying addresses wherever they are cheapest), which results in a large number of routing entries. The increase in the overall table size means all other ISPs have to buy new hardware sooner than they would have without the increase caused by fragmentation. Everyone having their own personal address block would cause even worse fragmentation issues.
The processes involved wouldn't really scale if normal people were going to do it either, but if it's something you care deeply about and are willing to spend the time on, it is possible.
As another poster said, you can get a tunnel from Hurricane Electric, or some other tunnel brokers, and that works too, although it's not as flexible --- HE tunnels are not geographically flexible, you pick where your tunnel is assigned, and those addresses will always be routed through that location. If you move far away, you'll likely want to setup a new tunnel in a new location for performance reasons.
But won't that also have disadvantages? NAT obscures which natural person is responsible for any given household traffic, which makes user tracking and surveillance harder.
IPv6 has roughly the same level of privacy; your client device's IPv6 address changes every few hours. Yes there's a minor loss since an association can be made during those hours, but arguably with the generally low number of people sharing a household internet connection I don't think it's a huge difference.
Actually, this should be a base service of mobile internet. The various carrier peerings will define how "efficiently" your traffic is routed (realtime audio/video...).
The blocker is the billing scheme I guess (as usual...).
I have… concerns about removing NAT from everyone’s house now that IOT is a thing. Could it be done safely? Yes. Will it? Signs point to no.
Even without a firewall, a /64 is an extremely large amount of space. It's nearly impossible to find active hosts by port scanning, compared to v4 where it's trivial to scan the entire address space. We won't end up in the same situation we were in on v4 back when nobody used firewalls, and that's not just because our networks mostly have firewalls these days.
This is probably most of it.
My gripe is that there is essentially no realistic end to ipv4 in sight. So we as an industry carry the debt of securing, managing and troubleshooting parallel v4 and v6 networks for decades.
If ipv4 had an EOL it'd make the transition so much better
IPv4 will never go away, but will be smaller part of the Internet.
It will absolutely hang around in small private networks for 50 years (there's still some token ring networks out there)
I run my desktop with no v4, so it's clearly possible to push handling for v4 out of your network. You could outsource it to somebody else even, for example by using one of the DNS servers listed on https://nat64.net/.
The migration strategy for ipv4->ipv6 was just so horribly conceived that we'll be running both in parallel for decades.
TBH I think it would have been better if ipv6 was named something else entirely. Running TCP and UDP in parallel doesn't raise any flags, but running two versions of the same protocol in parallel is strange.
I don't think it was horribly conceived. I think it's close to the best we can do given the constraints we're working under. These constraints include the fact that there are millions of networks being run by millions of people and nobody is in a position to force all of these people to stop using v4.
That will drop the quality of the v4 internet, things will break and be slow to be fixed because who cares about the <10% v4 only traffic?
My T-Mobile connection issues an IPv6 address but fails online “is my IPv6 working?” tests.
I enjoy it on my private networks but simply can’t rely on it on the Internet yet.
There's nothing I do that IPv6 makes better, and switching to it is a very large and painful task, so delaying that switch until it's required doesn't seem unreasonable.
In any case, considerations like that are part of why I'm putting off any serious effort or decisions until it's required.
You've spent longer talking about not deploying v6 than you would have done deploying it. I said this before, but I suggest you sit down and turn v6 on for your network -- and *just* that, don't start gaming out how to disable v4 or deal with devices that don't support v6 or anything else, *just* do the basic enabling v6 on the network part. That way you'll see that you're seriously overthinking it.
But you won't listen to me, because http://habitatchronicles.com/2004/04/you-cant-tell-people-an...
I guarantee that I haven't.
> I suggest you sit down and turn v6 on for your network
I did this a long while ago. I apologize for giving the impression that I haven't. But actually using IPv6 in any serious way takes more than just turning it on. It requires reconfiguring a nontrivial number of machines/devices, figuring out how to accommodate the many machines/devices that aren't able to use IPv6, and so forth.
Now, I will admit that I'm still learning IPv6 stuff and as a result there are likely things that I'm overthinking. But responses like yours don't move that ball forward any. You're just scolding people for not being experts.
for most people, it is transparent and doesn't improve anything... ipv6 could be disabled on their router and everything would be the same (I actually used to disable ipv6 at router level to avoid inadvertently leaking data on ipv6)
Don't twist that effort into a reason to not deploy v6.