Put all work into reorg, for what? Some numbers to change? Why when IPv4 works?
My company has just turned off all ip6 connectivity for its corporate laptops because it’s considered a security risk. I disagree, but I do agree that having 4 and 6 is a higher risk than 4 alone or 6 alone, and 6 alone sadly still doesn’t work reliably.
All the “promise” of ip6, direct connections etc, were lost when stateful firewalls became required and memory became cheaper than $20 a megabyte. Some bespoke old protocols don’t like ports changing, which can be a problem, but it’s a very small number and easier to work around with modern protocols than support a dual stack environment securely for the majority of places that struggle securing a single stack.
If your corporate laptops are running Windows, then you're going against the officially supported configuration of the vendor (Microsoft):
> Internet Protocol version 6 (IPv6) is a mandatory part of Windows Vista and Windows Server 2008 and newer versions.
> We don't recommend that you disable IPv6 or IPv6 components or unbind IPv6 from interfaces. If you do, some Windows components might not function.
* https://learn.microsoft.com/en-us/troubleshoot/windows-serve...
> Cg nat does everything that’s needed […]
Except for making it convenient for end-user to, say, play P2P video games, or host Mindcraft servers, etc.
> […] and 6 alone sadly still doesn’t work reliably.
It's so unreliable that half of all Internet traffic uses it. It's so unreliable that Microsoft has been going IPv6-only in their corporate networks (a decade ago):
* https://labs.ripe.net/author/mirjam/ipv6-only-at-microsoft/
It's so unreliable that Google is now 99% IPv6-only/mostly on their corporate networks:
With ipv4 you have a two tier internet. Computers talk to servers, servers talk to servers, computers can't talk to computers so every video call must be routed through a server.
That the server can figure out that two computers in the same house are different since your laptop and phone no longer share the same ipv4 address but instead have two ipv6 address?
Your phone and laptop can just have multiple ipv6 addresses and rotate through them regularly... as apple does by default https://support.apple.com/en-ca/guide/security/seccb625dcd9/...
Security? NAT is not a firewall, you need a firewall, and switching to IPv6 does not remove your firewall.
Before IPv6: The server gets "1.2.3.4:56789" for your device. After IPv6: the server gets "1:2:3:4::56" or whatever for your device. In either case, if the server makes a connection to 1.2.3.4:56789 or 1:2:3:4::56, your router sees the packet and firewalls the connection. Cool.
Want to give me a concrete example of where IPv6 is hurting my privacy or security, because I've been using it for over a decade with zero mishaps, zero privacy issues, zero security issues (to my knowledge at least)
Using a random address (Privacy Extensions) solves this problem though, but do we expect everyone to know what that is and check it's enabled? Mine wasn't enabled by default (on Linux) and I only noticed when a bittorrent site warned me.
* https://support.apple.com/en-ca/guide/security/seccb625dcd9/...
As does Windows (since Vista), and Android (8+).
So why are we still talking about this?
(All of that hinges on the key question that people seldom ask: what is being protected, and from who. The "two-tier" Internet is, in a way, pointing out a case where regular users are seen as threat actors.)
Some people will mention stateful firewalls. They're pretty easy to holepunch through because you just need each side to send a packet to the other, then each firewall sees it as an outgoing connection and allows it. It's nothing like IPv4 NAT.
I had a very concreteish security risk with IPv6 and openvpn. At least in Debian config openvpn tunneled only IPv4 by default. I only noticed this by being surprised I got results tailored to my origin country instead of the VPN out node country.
It's eternal (dual stack) paper cuts like this why just turning IPv6 off makes life a lot easier.
Ubiquity gateways also seem to not support it sadly. It would be awesome if they supported something like Hurricane Electric’s tunneling.
$ curl -v https://news.ycombinator.com
* Host news.ycombinator.com:443 was resolved.
* IPv6: 2606:7100:1:67::26
* IPv4: 209.216.230.207
* Trying [2606:7100:1:67::26]:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
HE tunnel IP space is now sufficiently penalized as non-residential/office that I’ve had to turn it off anyway. YouTube, for example, largely seems to block users in HE space unless they are logged in, and I frequently ran into neverending captchas.
But you can't use HE tunnels because every website you visit will block you. You also can't use them from CGNAT or if your home router doesn't have a DMZ.
But my TP-Link router blocks by default inbound IPv6 connections, without any option to configure it, still bad for pure IPv6 bidirectional streaming, gaming or services on home networks.
To your point, IPv6 sought to replace NAT with just having enough addresses but interestingly, that created a problem. If you used NAT and had a service on your computer request a port for incoming connections, that showed intent on behalf of the owner of that service. IPv6 doesn't have that intent, which forces home router makers do block addresses by default because you don't want most PCs on the Internet such that an external agent can scan your PC. You may end up with an unintended service on the open Internet.
So is the bigger address range better? Technically, maybe? But you have to consider defaults and intents of users. And that can take a good technical solution to a bad solution or at least create a whole bunch of problems.
Using NAT as a firewall might work but it brings it's own problems. I find the IPv6 way better.
Glad to hear that you don't have a problem with your router, but how does that relate to GPs problems with theirs?
The solution for them is "get a better router" because the problem is not the IPv6 protocol. Opening a port is not harder than creating a NAT forwarding and if your hardware can't do it then it's bad.
Every residential router already has PCP (RFC 6887) and UPnP IGD to deal with the NAT44 non-sense that is the status quo, and both protocols support IPv6 hole punching, so IPv6 default deny as a policy is hardly an issue in the residential space.
Nobody includes their MAC address in their public IPv6 addresses anymore, but every IPv6 setup that I've seen still gives every device a unique globally-routable IPv6 address, with no NAT at all.
> One of my favorite is the decision to default to /64 blocks.
The nice thing is that a /64 is big enough that clients can just randomly pick any address, and it will almost certainly be available, meaning that you don't need DHCP. This is actually widely implemented, and is known as SLAAC [0].
> Yet we're still stuck with the 128 bit addresses that came from that.
The extra address space only adds 16 bytes to every packet, and it ensures that we will never run out of addresses like we did with IPv4.
[0]: https://en.wikipedia.org/wiki/IPv6#Stateless_address_autocon...
Crucially though, if we change it, we just have to change how addresses are allocated, not change the protocol again.
Picking a random local address (which is very important for privacy, as you've mentioned) is much easier if you don't have to do an elaborate dance of listen, announce, listen for collisions etc. first (practically that still happens, but collisions are the absolute exception).
> So is the bigger address range better?
Yes, because consider the alternative of re-doing all of this again in a future in which IP usage for some reason jumps by a few orders of magnitude again.
Due to hardware getting better over time, the per-packet cost of a few extra bits is going down all the time, while the cost of rolling out a future IPv7 increases with every new deployed host.
Randomizing the local address doesn't mean it isn't useful. You can't scan a /64 so that's already a major improvement. The fact that randomly selecting a number is effectively never going to collide greatly simplifies automatic network configuration.
The major issue is that the /64 isn't mandatory from a technical perspective. Being merely a subset of the larger address it's nothing more than a convention. In the end not all providers make it available to you even though supposedly they ought to.
If we're going to complain about anything it should be the godawful notation that so easily breaks parsers. Or the fact that the width is massively excessive which creates a usability nightmare due to normal humans not being able to readily recall 128 bit numbers (let alone how long it takes to type them in).
[1] https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
LTE arch with the PGW handles IP allocation to devices
https://www.arcep.fr/fileadmin/reprise/observatoire/ipv6/Arc...
(2025, from 2024 data)
Reason that Google isn't seeing more is a) some BigCo v4 holdouts b) happy eyeballs sometimes landing on v4 because their v6 is shitty 6rd or something (e.g Free SAS)
At the moment pretty much every website is reachable via IPv4 but a lot not via IPv6. Will there be a day when this turns around?
That's already the case. IPv6 is often faster because most ISPs these days use cgnat for IPv4.
This becomes noticeable when pipelines on IPv6 connected servers suddenly have random request/post failures to public services. Then either the whole service is temporarily having issues or there are a few bad IPv6 endpoints while all the IPv4 endpoints are fine.
Seemingly this failure mode can go unnoticed for days while the same won't be true for IPv4 due IPv4-only still being the norm for corporate networks. And no, current form of happy eyeballs v2 won't account for this.
Besides bad endpoints it could also be a problem with bgp route advertisements where the IPv6 prefix takes a weird path and ends up being blocked by a CDN at the other side of the ocean. This happens more than you'd think. Obtaining pypi packages was quite a challenge last year for us for a couple of weeks due to this.
Not really a fault of IPv6 technology wise, and in general can be solved client side through retry functionality, but in practice it still can lead to a worse outcome due to lackluster IPv6 adoption.
I used to think ISPs, organisations, admins and users were just being lazy for not implementing IPv6 or turning it off as the first thing to do when network problems happen, but when this far in the rollout such basic things still lead to difficult troubleshooting sessions then perhaps time has come to say something has gone terribly wrong.
It saddens me to say that I totally understand that businesses do not want to pay the price for implementing IPv6 unless absolutely necessary, because until the majority of traffic is IPv6 or even IPv6-only it does not make a lot of sense.
The flipping point is nearer than ever, though I fear it will in the short term lead to even worse stability for both protocols until IPv6 truly becomes the norm, whenever that may be.
Do you have examples for this? I've never experienced this, and I've been using IPv6 for years.
Also, how can you be sure that the same request to IPv4 would have been fine? Did you actually see consistent failures on v6 and consistent success on v4? Otherwise, if a service has a reasonably low error rate, success on retry is the expected outcome, regardless of the path the retry takes.
This happened with pypi (IPv6 BGP routing problem caused by a bad route from one of our peers combined with their fastly CDN not reply to us on IPv6 from the other side of the ocean for some weird reason), but also with yum and apt mirrors (seemingly random problems with the IPv6 service or firewall of the remote endpoint), and various other web resources accessed from pipelines.
The solution always was to temporarily block the bad IPv6 endpoint(s) or temporarily completely disabling IPv6 on the server itself or on the squid proxy server for workloads without direct connectivity.
Obviously it also can be the other way around, but in practice it appears to happen less often with IPv4, and if it does things get addressed quickly instead of taking hours or days or weeks.
Infact the only isp I have seen do it is starlink and I have contacts with ISPs in 60 different counties.
Unless you want to host multiple minecraft servers on the same port on different servers at home?
Indeed hosting anything at home is such a rare workflow that someone wanting it can choose an isp which gives them the facilities they need.
Unless you don’t live in a competitive market based economy and just have the single government mandated isp aimed at the lowest common denominator, in which case you’ve got far worse problems.
If there's one thing market competition does well, is remove any kind of meaningful variety - because supporting a niche offering costs money, and is not worth it unless it nets positive, otherwise it's just a drag that makes you fall behind your competition.
https://radar.cloudflare.com/adoption-and-usage#ipv4-vs-ipv6
But we have to remember that this reflects the adoption on the client side. With many high profile services still IPv4-only, the fraction of IPv6 flowing on the public Internet might be much lower.
I wonder what incentives are needed to push this forward, because it's not the same incentives as years ago for sure. We've long since exhausted new IPv4 allocations.
From the user side IPv6 is great for me. My ISP is using CGNAT and would bill me ten pounds a month for a static IPv4 address but I automatically get a vast block of IPv6. I'm using that block to allow me to VPN back home when out and about, and if I wanted to I could also host services from devices on my home network without needing any NAT nonsense, I can just open access to the relevant device on the router. (Because this is a world where not everywhere supports IPv6 yet if I'm on an IPv4 only network the VPN endpoint is a dedicated server I rent which forwards the relevant port back to my home router over IPv6)
Chances are they also skimping on other areas including over subscription. Choose a better isp if you want a better service.
Your “just open traffic to internal host 1 on your firewall is the same no matter if it has nat or not, unless you are using a non stateful firewall? Or perhaps your configuration layer splits the two for reasons.
Mobile carriers use it almost exclusively, which is already a huge chunk of the internet, and newer ISPs are switching to it too.
> I'm supporting both because I heard it's good to support both, but I'm not sure what the actual benefit is.
The benefit is that you allow IPv4-only and IPv6-only clients to connect.
Some applications will still fail to work though unless you also have 46 nat on your device which still doesn’t work transparently on majority of types of device.
You also need all devices on your lan to support v6 natively, and v6 only. From your printer to your speaker.
You might be able to do something with mdns and nat64 to get them working on an IPv4 only subnet. But you’re talking layers and layers of complexity for things which just have to work.
I’m posting this from my phone on my IPv6 only subnet, not sure if it’s using a 64 gateway or 6 native to HN, but it’s possible.
Also you made the life better of people who have DS lite. They only get a public IPv6 and all their IPv4 traffic goes through a CGNAT.
https://cr.yp.to/djbdns/ipv6mess.html
Yes, it is old, many examples are outdated, but the main points still hold. Decades later his suggestions for making IPv6 succeed are still not implemented.
2. Most websites assume that 1 IPv4 address==1 household, so you'll often run into rate limits. Or even worse, you might be blocked entirely if your CGNAT neighbours are spammers or otherwise breaking website rules.
2) if cg nat is as popular as people claim then they won’t be doing that as it’s not an edge case
Yeah, I just mentioned that because P2P networking is used a lot more than most people think these days, since even things like Zoom that look like typical client–server web browsing actually use P2P networking internally.
> It was suggested that a website operator deploying IPv6 would somehow improve the end user experience by virtue of avoiding CGNAT and I was questioning that.
Reliability and latency will be marginally better with IPv6 than with CGNAT, but this is so minor that I doubt that most people will notice this. And many CGNATs will RST connections that last too long, but most protocols have some sort of automatic retry/reconnect built in, so this shouldn't cause issues very often either.
IPv6 addresses are quite a bit cheaper than IPv4 addresses in most clouds, but since most servers still need to support IPv4, this doesn't help you directly. Supporting IPv6 means that others using the cheaper IPv6-only cloud services will be able to connect to your server, but this doesn't matter for consumer-only services.
So yeah, you're probably right that enabling IPv6 server-side won't have (m)any benefits.
> I do of course appreciate that going via CGNAT to a clueless operator that eagerly adds IPv4 bans can be problematic but that's more a question of why you as a consumer might want IPv6 connectivity not why a service provider would want to deploy it.
Being able to ban IP addresses without worrying about collateral damage is a pretty big benefit to the service provider though, for certain applications at least.
I also have built cloud infrastructure for multiple SaaS providers with tens of thousands of customers over the past decade. Only one customer I’m aware of has ever even requested IPv6 support. And if customers aren’t asking for it, my employers have never been interested in the full network re-architecture required to truly support it internally.
There are still several basic services you can’t run IPv6-only in AWS, and a handful of AWS service features that don’t support it at all.
As a sysadmin for decades now, I’ve always found IPv6 to be overengineered and in many ways completely ridiculous. But I’d love to be supporting it in everything I do. Only I still can’t, even after 20+ years of being lectured about it; even after complete IPv4 exhaustion has been reached. I don’t think we’re ever going to turn IPv4 off. At best it will be progressively hidden, even from technical users. And folks like me will just have to keep building workarounds to patch the holes where IPv6 still doesn’t work.
Most software continues to have horrible IPv6 support and documentation making it look more complicated, but the actual protocol is considerably simpler than IPv4. For example:
1. An IPv4 packet header is variable-length, and the checksum must be recalculated by every router because the TTL is included in the checksum. Whereas an IPv6 packet header is fixed-length and has no checksum.
2. NAT is effectively required with IPv4, but it makes everything much more complicated, since it means that most computers don't even know their "real" IP address, it makes peer-to-peer networking very challenging, and it's tricky for routers to implement. Whereas with IPv6, no NAT is required.
3. Any router along the network path is allowed to fragment an IPv4 packet, and is in fact required to if its MTU is smaller than the packet's size. Whereas only the originating node is allowed to fragment an IPv6 packet.
4. To acquire an IPv4 address, both clients and routers must implement DHCP, which is a fairly complicated protocol, and both clients and routers must remember the list of assigned addresses. Whereas with IPv6, the client can just choose a random address (via SLAAC) and then start using it immediately.
5. IPv6 multicast is considerably simpler than IPv4 multicast, and NDP (v6) is considerably simpler than ARP (v4).
Despite all this, I agree with you that setting up IPv6 networking is harder than setting up IPv4 networking, but this is more of a software problem than a protocol problem.
3 well you can set the dont fragment bit at a client side or a router can drop the packet. These are choices. If a 1500 byte IPv6 packet arrives on a router with an 1100 byte next hop, does it just drop? Or send back a fragmentation needed icmp? How is that different from setting a “don’t fragment” option on a router.
4 isn’t created from a security or management point of view either. And v4 has the 169.254 range for this purpose. I guess the lack of router advertisement is the primary difference. And the operational expectations.
5a I’m not sure about. My main experience with multicast is pim-sm on v4. SSM v4 multicast however seems simple, and while I don’t use it as I have kit that’s too old for it is v6 really easier than v4/ssm/igmp3?
As for arp, I don’t see any real complexity with it as a network operator, but maybe that’s because I’m used to it. Perhaps it’s easier to implement nd rather than arp, but given almost every v6 deployment for the last 30 years is dual stack all it does is increase complexity.
ARP is a special protocol implemented on the data link layer, while NDP is just another type of ICMPv6 packet.
> which creates a recursive chicken and egg situation
I believe that NDP mostly uses the special ff02::/16 link-local multicast addresses [0], which don't require any configuration to use.
[0]: https://www.iana.org/assignments/ipv6-multicast-addresses/ip...
I personally found that the features I interacted with were useful (SLAAC, address size, router advertisements, ...) and the changes made it cleaner (removal of broadcast for multicast, removal of fragmentation fields, ...).
"But other than that, Ms. Lincoln, how was the play?"
I think the future is bright and most problems will be solved by 2040, and almost all by 2050.
> At this point it would be best to recognize the sunk cost and give up on the migration.
That's a pretty wild thing to say in the comment section of an article about v6 reaching 50% eyeballs-side deployment.
With AI companies using botnets ("residential proxies") for scraping, they're probably going to be in the 50% that doesn't use IPv6.
New regex: IP(any collection of numbers and dots).
Now we have infinite IP address possibilities and no one controls the space.
Done.
If so, that is incorrect. They use the binary values. The actual difference between IPv4 and IPv6 is that IPv6 uses 128-bit addresses, not 32. So you can devise whatever human-readable abstraction you like, it won't change how networking actually operates.
Sure Gmail has ipv6 enabled and routable ip6 MX. but sending to those addresses is often rejected and forced to retry over ipv4.
Don’t get me started on gh
I am still sometimes using Google Search. First results are now almost always videos on youtube, aka self-promo. These videos are in 99.9% of the search results I use, totally useless and worthless. Even searching on youtube has recently gotten worse. It is also crap now. I know that because I bookmark various videos, and I can not find older videos anymore either. I can eliminate some results I don't care via ublock origin hero-blocking this Google garbage, but I really think we should no longer allow this de-facto monopoly to worsen the global situation any longer. The USA is protecting these gangsters - it is time to have true legislation that gets rid of that mafia bloc that is Google.
They added those new addresses that can store more information.. but this requires a rewrite of old software to make it work.
If they used the old >bolting on top< method by extending ip4 from 4 octets to 8 (or more) octets, then old software could be extended much easier too / probably addresses could be simply mechanically translated too, so ancient software can work.
The problems, as I observe, are more in network infrastructure, routing, etc.
The IPv4 protocol has 4 octets each for source and destination address. Period. If you change that, your packets won't work on any IPv4 routers or software any more.
If you want to write IPv6 addresses as numbers separated by dots no one's stopping you but I don't see how it's better. They switched to hex because the old format was too long.
42.0.20.80.64.1.192.15.0.0.0.0.0.0.0.113
is easier to remember than
2a00:1450:4001:c0f::71 (or 2a00:1450:4001:0c0f:0000:0000:0000:0071)
It does not work like that. Put extra octets where exactly? Where would a hardware router put the extra bytes? Where would software with 32 bit buffers?
You would still need to replace all of the software and hardware and have the exact same problem.
It's a standard Asus router but it's given me a lot of ire. I hate to say it but it's never a problem when I install windows on the same machines
(I'm currently in the process of trying to completely remove windows from my life)
It's usually bad configuration done by the router vendors. It doesn't mean IPv6 is bad.
IIRC, a workaround was to prevent Linux from setting this field, or force-reset it on every outbound packet using netfilter.
Another such example is SELinux, which would have prevented so many vulnerabilities from being exploited, but whose poor UX also caused everyone to disable it at install time.
SELinux's UX was significantly improved many years later, but already too late to change ingrained opinions. There are a lot of ingrained opinions about IPv6 too.
in what way?
* https://havevirginmediaenabledipv6yet.co.uk/
A major ISP in the U.K., that said in a public statement on World IPv6 Day in 2011 that
> As well as our core and access networks being capable of supporting IPv6, we're rigorously testing our entire network to ensure that all customers have a smooth and simple transition when the time comes to flick the switch and turn IPv6 on. We're really pleased with how our tests are advancing and are happy to say that by the end of 2012, we'll be able to fully support customers looking to switch to IPv6.
has not managed to actually flick that switch in 15 years.
* https://ispreview.co.uk/story/2011/06/08/uk-isp-fluidata-hai...
That plus other ISPs v6 implementations breaking things randomly, I understand why they don't bother.