I thought this too, until I tried to add IPV6 support for a fairly simple web application.
The single biggest problem is the quality and consistency of IPV6 implementations is frequently very poor. I ran into many bugs, strange inconsistencies and poor handling of edge cases by middleware, clients, routers and firewalls that any advantage from IPV6 was simply not worth it for our needs.
Mobile telcos and cloud providers are currently the only parties where the benefits of V6 outweighs the pain, and as such their software and services tend to support it quite well.
While the cost of V4 is going up, for almost everyone it’s still far less than dealing with V6, and there’s nothing relevant (unless you have telco/cloud provider needs) V6
can provide you that V4 can’t.
But unfortunately nodays with the prices of IPv4s it's like it's broken. The best price you can lease is probably in the ballpark of around 0.5 USD / IP.
There are certain auction platforms, I sold my IPs through https://auctions.ipv4.global/ which went smoothly. The registries have waiting lists for resources that get handed back to them (very rare). You need to be a member to buy IP space though.
I love the idea of v6, but the reality is still not worth it for most situations even at that price. IP v6 implementations are still all too commonly buggy and inconstant, and that’s on top of all the work required to bring v6 online.
Well, it was broken for me: Yesterday I used some hotel wifi and realized they didn't have an IPv4 address[0], so I could only access the IPv6 internet. Guess which site I tried to open first…
[0]: Yes, you might say this is on them but I've seen public wifis without IPv4 a number of times now.
There's a lot more work for IPv6 support than just throwing a AAAA record on a domain. A few of them:
- IPv6 Peerage.
- An IPv4 or IPv6 broker.
- First party software configuration.
- Support from upstream and downstream from infrastructure/partners and configuration.
It is a significant project. People think you just assign an IPv6 IP, throw in a AAAA record, and then it magically just works. More than likely you'd just create a block-hole where IPv6 traffic goes to die.
hn has two servers at m5hosting which according to their FAQ [0] "IPv6 support is currently available for Dedicated Servers or Colocation." so you ask support, they assign you a prefix and you add a few IPs from that prefix. done. My guess is their anti spam or something else in the software expects an IPv4.
IPv6 is work, but it's not that much work if your networking or hosting provider already supports it (as is claimed in this case).
Address classification changes are real work. I haven't done heavy benchmarks, but bigger addresses and everything else probably does add up to a measurable server performance drop, but that's balanced by real world networking performance improvements for users with nasty network stuff on IPv4 and less for IPv6. Otoh, I'd guess HN isn't bottlenecked by networking anyway.
I think that if you are in a position where you are hosting your own infrastructure in a data center these wouldn't be difficult issues to address and are the bare minimum in running that type of operation. You can front any website with a load balancer that proxies the connection to a IPv4 only back end and the major web server software such as Apache and Nginx supports v6 natively.
If you aren't hosting the infrastructure yourself then you are limited in what you can support but you wouldn't be worried about peering, brokers, or up/downstream providers since thats what you would be paying the hosting provider for.
It hasn't exactly failed. Depending on where you look, it's in the neighborhood of 40% of traffic, although variability is very high.
40% market share isn't really failing, although it sure does feel like it could have been better. IPv4 is still a must, and IPv6 is optional in most circumstances.
Yeah I wouldn't say it failed its just that there wasn't a financial motive to move towards IPv6. As more networked devices and the device data itself becomes important moving to IPv6 will follow. Residential ISP's and some cloud providers are the biggest hold-up as most mobile carriers already dual stack and Tier 1 transit providers have had IPv6 for at least a decade or more.
I wonder if part of the incentive problem was that the companies with the most traffic would have already invested heavily in securing sufficient IPv4 address space for their usage. If so, the ones with the most ability to influence everyone to swap over would be the ones with the least need to do so, and then the smaller players who might need IPv6 most for future growth wouldn't have enough users yet to incentivize the infrastructure changes needed.
Yes this is a good observation. They would also be the first to be on the lookout for good deals on IPv4 space, furthering their acquisitions early on before the IP address market took off. Most notably though they would also be the companies working or providing suggestions on needs based policies for their respective RIR.
That article is obsolete. There are newer standards that fix the problems with IPv6 and make it usable. Slow standard development big reason for slow adoption of IPv6. But IPv6 is now usable; Hacker News and Reddit are the only IPv4 tabs I have open, the rest are IPv6.
A good example is NAT64/DNS64 which allows IPv6-only hosts to access IPv4 internet. The result is that makes sense to use IPv6-only or IPv6-first for new networks.
Do you have a reference for when the Internet as a whole was supposed to cut over to IPv6 only?
There are plenty of organizations that have transition mandates but those are self imposed and would easily be delayed for other monetary business objectives. The Internet as we know it was only created/available in 1993[1] and while some RIR's have exhausted their available IPv4 space it doesn't mean IPv4 addresses are not available.
Did you miss where I mentioned the protocol that let's IPv6-only hosts access the IPv4 Internet?
NAT64/DNS64 are at least a decade old. And being used successfully. Facebook is moving their datacenters to IPv6-only. I can't find articles but they may be moving whole internal network.
It is impossible for IPv4 talk to IPv6. Just like it is impossible to talk to server behind NAT.
But there are a lot fewer public servers than there are hosts and private servers. It makes sense to give the load balancers IPv4 and then have all the internal servers and hosts IPv6. IPv6 leads to much simpler internal network. Still have to do NAT64 to talk to IPv4, but have to do NAT for IPv4.
Tunneling doesn't help. IPv4 host only knows about 32-bit addresses. It would be possible to have some proxy service but that would only work for subset and IPv6 is too big for that. What works is having IPv4 proxy for services.
There is no need for IPv4 hosts to talk to IPv6 hosts. For one thing, many hosts are dual-homed. IPv4 can keep doing its thing while everybody switches to IPv6.
Tunneling v6 packets to a known anycast that’d bridge the networks would mean that there’d be interoperability.
With interoperability it would mean that hosting a service on a v6 only network means you wouldn’t need a v4 address (which today is a must have and expensive unlike v6 which is optional).
The IPv4 host can't tunnel IPv6 packets, it has no concept that IPv6 exists. It can only talk to IPv4. You could have some dynamic IPv4 to IPv6 service, which needs IPv4 addresses. But it is much simpler for each service to have one IPv4 address on the load balancer.
Also, the real shortage with IPv4 is with devices where ISPs are using CGNAT. Server addresses are less important when can run an entire company with a handful.
It's not useless. v6 provides a vastly bigger address space.
You're making the same mistake djb made: you've identified a problem, but rather than provide a solution, all you're doing is insinuating that somebody else should have solved it -- while failing to realize that the problem is unsolvable.
If you have a solution, please share it with us. Otherwise, stop criticizing v6 for not having one. As far as I can see, nobody can do it because it's impossible, but you could easily prove me wrong by just telling us how it's done.
I actually asked you this before, and you refused to answer. It's time you either put up or shut up.
> Tunneling v6 packets to a known anycast that’d bridge the networks would mean that there’d be interoperability.
Just to be clear, v6 already has this (it's 192.88.99.1). If this is your solution then v6 can already do it.
I think the failure isn't IPv6 itself, but the dreadful prospect of having to step from the boat to the dock: simultaneous production implementations of ipv4 and IPv6 in the same organization.
Mostly this is a DNS headache, especially if you're already segmented into a bunch of different split horizons due to organizational boundaries or vpns or what have you, and unlike software networking is almost necessarily done direct to production as staging is extraordinarily complex and expensive, and again unlike software development is not part of the daily iteration cycle but instead of once or twice in a decade type of thing.
anyone managing or responsible for managing that infrastructure is going to need an extremely compelling reason to pursue a switch thanks to the two systems obstacle.
Chicken and egg problem. In many countries the legacy of telecom access oligopoly led to an ISP oligopoly. If your ISP doesn't support it then you won't bother deploying since there's no IPv6 route. The ISPs won't deploy it until "there's customer demand" (even though there can be no customer demand until they turn it on - hardware and infrastructure have to come first before layers on top can be deployed). Switching to an ISP with IPv6 is usually not an option.
Eyeball networks were waiting for the content networks to deploy and vice versa. Now that eyeball networks generally moved first the content networks say their anti-spam and anti-attack solutions don't have IPv6.
Many IT pros have become used to and even attached to Network Address Translation and specific IPv4 addresses. Some have beliefs like reducing security attack surface requires disabling IPv6, NAT is a firewall, or they reflexively blame any network issue on IPv6.
If the cryptocurrency bubble hadn't popped maybe there could have been a IPv6 coin that rewarded mining addresses. Mine the one correct address out of 2^128 that block and earn a IPv6coin (joke).
The biggest problem with ipv6 right now is that the DNS record system needs to be updated to support both simultaneously. Right now, it is necessary to perform the AAAA lookup alongside the A lookup which doubles the workload on the DNS. Also, ipv6 coverage is still spotty enough that it is sometimes more efficient to open both ipv4 and ipv6 in parallel in order to pick the one which performs better.
The problem is that websites will, for the foreseeable future, have to be accessible via ipv4 else suffer a significant reduction in traffic. The issues that I've mentioned above are the reasons why nobody is currently rushing to implement ipv6. Depending on what websites you use, as little as 20% might be accessible via ipv6. This will hold true, I think, for 5 to 10 years.
I don't believe that ipv4 will go away. One reason is because ipv6 is unwieldly in comparison. For one thing, the format is imprecise because it does not enforce consistency. There are dozens of different ways to write an ipv6 address because leading zeroes are allowed while leading zeroes are illegal under ipv4. Personally, I have a real beef with the use of the colon as a separator.
My prediction is that, as ipv6 becomes more endemic on the Internet back-end and the pressure on the ipv4 address space eases, then ipv4 addressing will become MORE attractive on the Internet front-end (meaning the consumer).
That's really not the biggest issue. DNS servers can handle this level of load just fine. People throwing out excuse after excuse (frequently wrong or ill-informed) for not doing v6 is a bigger issue.
> For one thing, the format is imprecise because it does not enforce consistency. There are dozens of different ways to write an ipv6 address because leading zeroes are allowed while leading zeroes are illegal under ipv4
You'd be amazed how much worse v4 is on this front. Leading zeros are actually legal, but they turn the field into octal. Hex is an option, and so is combining fields. You can write HN's IP as 0321.216.230.240, or 0321.216.0xe6.240. Or 0xd1.216.0163360. There's about 40 different combinations like this.
v6 clearly defines a canonical form, and doesn't have as much possible variation outside of it.
> Personally, I have a real beef with the use of the colon as a separator.
It had to be changed from . to avoid ambiguity with DNS. It also allows writing the right-hand 32 bits as a v4 literal (e.g. 64:ff9b::209.216.230.240 -- fortunately only in this form and not all of the other forms v4 has) which is convenient sometimes. Given their existing use in other networking protocols and things like MAC addresses, colons seem like the obvious alternative.
>You'd be amazed how much worse v4 is on this front. Leading zeros are actually legal, but they turn the field into octal.
That depends on the platform (and, no, leading zeroes are not legal). I work with Node.js and leading zeroes in an ipv4 address will be correctly rejected. There is no chance of mistaking 127.00.0.01 for 127.0.0.1 (the former will fail the net.isIP test). With ipv6, Node is quite forgiving and this annoys me. Without deconstructing and reconstructing the address in proper canonical form, it is difficult to tell the difference between identical addresses due to the presence of extra zeroes (they will pass the net.isIP test). Unfortunately, Node does not include a method for normalizing an address.
$ ping 0000000000321.216.230.240
PING 0000000000321.216.230.240 (209.216.230.240) 56(84) bytes of data.
64 bytes from 209.216.230.240: icmp_seq=1 ttl=46 time=142 ms
Platform-specific syntax, excellent. That sure makes it sound more consistent.
You're right that you need to canonicalize addresses as part of comparing their textual forms. It's well-documented -- at least in v6 -- that you need to do that.
> Unfortunately, Node does not include a method for normalizing an address.
That sounds like a Node problem. In C you can do it via getnameinfo(getaddrinfo()) or inet_ntop(inet_pton()).
53 comments
[ 5.5 ms ] story [ 98.2 ms ] threadI thought this too, until I tried to add IPV6 support for a fairly simple web application.
The single biggest problem is the quality and consistency of IPV6 implementations is frequently very poor. I ran into many bugs, strange inconsistencies and poor handling of edge cases by middleware, clients, routers and firewalls that any advantage from IPV6 was simply not worth it for our needs.
Mobile telcos and cloud providers are currently the only parties where the benefits of V6 outweighs the pain, and as such their software and services tend to support it quite well.
While the cost of V4 is going up, for almost everyone it’s still far less than dealing with V6, and there’s nothing relevant (unless you have telco/cloud provider needs) V6 can provide you that V4 can’t.
[0]: Yes, you might say this is on them but I've seen public wifis without IPv4 a number of times now.
Does GitHub not support IPv6 for repo activity though? eg clone, pull, push.
- IPv6 Peerage.
- An IPv4 or IPv6 broker.
- First party software configuration.
- Support from upstream and downstream from infrastructure/partners and configuration.
It is a significant project. People think you just assign an IPv6 IP, throw in a AAAA record, and then it magically just works. More than likely you'd just create a block-hole where IPv6 traffic goes to die.
[0] https://www.m5hosting.com/support/cloud-faq/
Address classification changes are real work. I haven't done heavy benchmarks, but bigger addresses and everything else probably does add up to a measurable server performance drop, but that's balanced by real world networking performance improvements for users with nasty network stuff on IPv4 and less for IPv6. Otoh, I'd guess HN isn't bottlenecked by networking anyway.
But something like HN probably has various moderation/spam preventing tools that assume IPV4.
I believe people have made IPv6 gateways to the ipv4 content.
It's still called a black hole.
https://en.wikipedia.org/wiki/Black_hole_(networking)
If you aren't hosting the infrastructure yourself then you are limited in what you can support but you wouldn't be worried about peering, brokers, or up/downstream providers since thats what you would be paying the hosting provider for.
40% market share isn't really failing, although it sure does feel like it could have been better. IPv4 is still a must, and IPv6 is optional in most circumstances.
Also, many don't seem eager to adopt it. If that is due to the protocol or just the lack of tooling, I don't know.
(and that was written in 2002)
A good example is NAT64/DNS64 which allows IPv6-only hosts to access IPv4 internet. The result is that makes sense to use IPv6-only or IPv6-first for new networks.
There are plenty of organizations that have transition mandates but those are self imposed and would easily be delayed for other monetary business objectives. The Internet as we know it was only created/available in 1993[1] and while some RIR's have exhausted their available IPv4 space it doesn't mean IPv4 addresses are not available.
[1] https://www.npr.org/2023/04/30/1172276538/world-wide-web-int...
[1] https://datatracker.ietf.org/wg/opsec/documents/ [2] https://datatracker.ietf.org/wg/v6ops/documents/
NAT64/DNS64 are at least a decade old. And being used successfully. Facebook is moving their datacenters to IPv6-only. I can't find articles but they may be moving whole internal network.
But there are a lot fewer public servers than there are hosts and private servers. It makes sense to give the load balancers IPv4 and then have all the internal servers and hosts IPv6. IPv6 leads to much simpler internal network. Still have to do NAT64 to talk to IPv4, but have to do NAT for IPv4.
Not being able to have v4 talk to v6 is why v6 will never be a first class citizen.
There is no need for IPv4 hosts to talk to IPv6 hosts. For one thing, many hosts are dual-homed. IPv4 can keep doing its thing while everybody switches to IPv6.
With interoperability it would mean that hosting a service on a v6 only network means you wouldn’t need a v4 address (which today is a must have and expensive unlike v6 which is optional).
Also, the real shortage with IPv4 is with devices where ISPs are using CGNAT. Server addresses are less important when can run an entire company with a handful.
You're making the same mistake djb made: you've identified a problem, but rather than provide a solution, all you're doing is insinuating that somebody else should have solved it -- while failing to realize that the problem is unsolvable.
If you have a solution, please share it with us. Otherwise, stop criticizing v6 for not having one. As far as I can see, nobody can do it because it's impossible, but you could easily prove me wrong by just telling us how it's done.
I actually asked you this before, and you refused to answer. It's time you either put up or shut up.
> Tunneling v6 packets to a known anycast that’d bridge the networks would mean that there’d be interoperability.
Just to be clear, v6 already has this (it's 192.88.99.1). If this is your solution then v6 can already do it.
Mostly this is a DNS headache, especially if you're already segmented into a bunch of different split horizons due to organizational boundaries or vpns or what have you, and unlike software networking is almost necessarily done direct to production as staging is extraordinarily complex and expensive, and again unlike software development is not part of the daily iteration cycle but instead of once or twice in a decade type of thing.
anyone managing or responsible for managing that infrastructure is going to need an extremely compelling reason to pursue a switch thanks to the two systems obstacle.
Eyeball networks were waiting for the content networks to deploy and vice versa. Now that eyeball networks generally moved first the content networks say their anti-spam and anti-attack solutions don't have IPv6.
Many IT pros have become used to and even attached to Network Address Translation and specific IPv4 addresses. Some have beliefs like reducing security attack surface requires disabling IPv6, NAT is a firewall, or they reflexively blame any network issue on IPv6.
If the cryptocurrency bubble hadn't popped maybe there could have been a IPv6 coin that rewarded mining addresses. Mine the one correct address out of 2^128 that block and earn a IPv6coin (joke).
The problem is that websites will, for the foreseeable future, have to be accessible via ipv4 else suffer a significant reduction in traffic. The issues that I've mentioned above are the reasons why nobody is currently rushing to implement ipv6. Depending on what websites you use, as little as 20% might be accessible via ipv6. This will hold true, I think, for 5 to 10 years.
I don't believe that ipv4 will go away. One reason is because ipv6 is unwieldly in comparison. For one thing, the format is imprecise because it does not enforce consistency. There are dozens of different ways to write an ipv6 address because leading zeroes are allowed while leading zeroes are illegal under ipv4. Personally, I have a real beef with the use of the colon as a separator.
My prediction is that, as ipv6 becomes more endemic on the Internet back-end and the pressure on the ipv4 address space eases, then ipv4 addressing will become MORE attractive on the Internet front-end (meaning the consumer).
> For one thing, the format is imprecise because it does not enforce consistency. There are dozens of different ways to write an ipv6 address because leading zeroes are allowed while leading zeroes are illegal under ipv4
You'd be amazed how much worse v4 is on this front. Leading zeros are actually legal, but they turn the field into octal. Hex is an option, and so is combining fields. You can write HN's IP as 0321.216.230.240, or 0321.216.0xe6.240. Or 0xd1.216.0163360. There's about 40 different combinations like this.
v6 clearly defines a canonical form, and doesn't have as much possible variation outside of it.
> Personally, I have a real beef with the use of the colon as a separator.
It had to be changed from . to avoid ambiguity with DNS. It also allows writing the right-hand 32 bits as a v4 literal (e.g. 64:ff9b::209.216.230.240 -- fortunately only in this form and not all of the other forms v4 has) which is convenient sometimes. Given their existing use in other networking protocols and things like MAC addresses, colons seem like the obvious alternative.
That depends on the platform (and, no, leading zeroes are not legal). I work with Node.js and leading zeroes in an ipv4 address will be correctly rejected. There is no chance of mistaking 127.00.0.01 for 127.0.0.1 (the former will fail the net.isIP test). With ipv6, Node is quite forgiving and this annoys me. Without deconstructing and reconstructing the address in proper canonical form, it is difficult to tell the difference between identical addresses due to the presence of extra zeroes (they will pass the net.isIP test). Unfortunately, Node does not include a method for normalizing an address.
You're right that you need to canonicalize addresses as part of comparing their textual forms. It's well-documented -- at least in v6 -- that you need to do that.
> Unfortunately, Node does not include a method for normalizing an address.
That sounds like a Node problem. In C you can do it via getnameinfo(getaddrinfo()) or inet_ntop(inet_pton()).