Ask HN: Why is HN not reachable through IPv6?
It's 2023 and it looks like news.ycombinator.com lacks an AAAA record. Why?
Does GitHub not support IPv6 for repo activity though? eg clone, pull, push.
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.
$ 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
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()).
$ ping 0010.000010.0000000010.000000000000000010
PING 0010.000010.0000000010.000000000000000010 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=2.48 ms
- 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.
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.
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.
[0]: Yes, you might say this is on them but I've seen public wifis without IPv4 a number of times now.
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.