If you do have AAAA records, Let's Encrypt (not unlike other software and services!) will prefer the AAAA records when doing domain validation for your domain. So if you have a correct A record and an incorrect AAAA record, your domain validation process will fail. You can then "fix" this by deleting the AAAA record, but it isn't a fix in the larger scheme of things, but indeed it makes plenty of users happy right away.
In addition, rate limiting with IPv6 is much harder (because IPs aren't scarce), so you risk DoS or other kind of abuse.
Users aren't getting single IPv6 addresses though. Most assign a /48 which is at least a bit better.
And rate limiting is very uncertain. If I limit per /56, users that have an entire /48 can outright bypass the rate limit. If I limit per /48, maybe I'll erroneously limit thousands of users whose ISP has all of them on the same /48.
If you wanted to block me, you'd have to block the whole /48. If you blocked a /48, you could be blocking 64,000 people.
Looks like crote brought the issue up in a sibling thread.
It's a shame that you're getting downvoted. I'm sure a lot of those people are shouting at their screen "well just learn it" but even if you're familiar enough with all the stuff it changes (RA, NDP, heck the lack of NAT), it's still a ton of work to get it properly set up and worse yet to maintain.
Large companies (and even ISPs) seem to be going for "IPv6-mostly" rollouts. Basically, everything is done primarily using IPv6, with fallbacks to IPv4 only when strictly necessary. This means IPv4 traffic gets converted to IPv6 at the client, forwarded over an IPv6-only network, and turned into "native" IPv4 for the internet at an edge NAT64 gateway. Legacy IPv4-only devices (printers and such) get an isolated vlan with its own gateway, and will of course be replaced with IPv6-capable alternatives as soon as it's appropriate.
I agree that for smaller companies it's relatively little benefit for the amount of work required, but if you're overhauling your network for other reasons anyways it makes little sense not to do it.
Hell, if you run a modern Microsoft domain (think newer than Windows Server 2008), you're hamstringing yourself if your network is IPv4 only, because since NT6 Windows is IPv6 first system, and there are indeed some corporate features that do not work if services aren't available over v6.
Sorry, but that's a load of manure. It's not just about memorizing.
People break their DNS so often that it's a meme.
Not everything automatically does a reverse lookup on every address it sees, and when it does rDNS could quite easily be broken.
So when you need to figure out if a device is in the same building as you, is it easier to say "1.2.3. - oh, that's my building" or "1234:5678:90ab:cdef:1234:5678:90ab:: - oh, that's my building"?
> Hell, if you run a modern Microsoft domain (think newer than Windows Server 2008), you're hamstringing yourself if your network is IPv4 only, because since NT6 Windows is IPv6 first system, and there are indeed some corporate features that do not work if services aren't available over v6.
Like? I mean I avoid using MS where possible so I probably just haven't seen it but I'm quite curious what's dependent on it.
Ok, not just memorising. It's also the culture of cargo culted broken network designs, of excel spreadsheets from hell, of thinking everyone can memorise or put few post-its with IP addresses important to them so you don't need to care for DHCP and DNS or actually setting up routing instead of throwing a ton of NATed 10.0.0.0/8 or 192.168.0.0/24 then crying when there's a need to setup 5 layers of translation to connect two services (been there, done that, kept the scars).
As others pointed out, you should have anycast addresses for core network services (DNS at least).
IPv6 arguably even makes it easier because link-local automatic configuration actually works unlike v4 APIPA, well enough to discover and talk to other nodes on given L2. I still remember my happy surprise when HP ILOs used that to let me configure them over network by just connecting to same vlan, something I can't do on v4 without messing with DHCP rules.
The fact that link local actually works, combined with multicast and predefined multicast addresses like ff02::1 or the addresses for mDNS, DNS-SD, LLMNR etc mean that you can actually get somewhere without configuring IP on the link.
Do you need to learn new things, and possibly rearchitect the network? Sure. But it's because v4 was deficient.
Also, more often than not, the "it was DNS" involves "resolver not configured" or "put BS in DNS got BS back now crying".
> Like? I mean I avoid using MS where possible so I probably just haven't seen it but I'm quite curious what's dependent on it.
Essentially entire promise of DirectAccess, the transparent VPN system added in Vista, depends on the office network being IPv6-clean (as in, no user-used services that require v4 connectivity). Originally it required IPv6+IPsec connectivity at client side, due to lack of wide availability various fallbacks were added in Windows 7.
It's also why Vista and later had such a push to autoconfigure Teredo and similar V6 transition technologies.
> when it's broken it's broken cuz you broke it
No duh, but that doesn't make it any less broken.
Forcing the change seems to be the only way to fix some networks and some software, in fact.
> No duh, but that doesn't make it any less broken.
Nor does it make ones inability to ship minimal HOSTS file any less bad.
This is a very poor straw man.
In IPv6 world you wouldn’t use all the significant digits randomly and because you have so many you could actually use one of the octets to perfectly encode the building information:
Building 1: 2001:1:: Building 2: 2001:2::
(You can go further with this concept and encode region/country/state/etc into the addressing as required)
In IPv6 world you wouldn't get 2001::/112, you'd get 2001:1234:5678:90ab::/48. So your building might actually be at best something like 2001:1234:5678:90ab:1::.
For equivalent of 10./8 space, you'd have ULA, which can be subdivided this way just fine (and arguably since fc00::/8 is left in limbo, you can use that. Or just decide to fit whatever addressing scheme you decide into 80 bits left after typical fd00::<48bit random>/48.
So sorry, your v4 strawman isn't too good either.
I mentally swap the labels[1] when reading their marketing or release notes. If it says things like "No longer crashes when using IPv6", then I flip that and read it as "No longer crashes when using IPv4". That latter statement is absolutely insane and would have you abandoning that vendor as fast as you can tear up the contract. Nobody bats an eye with the first statement! Why not!?
Azure literally had this scenario, where merely enabling IPv6 on one network would crash their managed PostegreSQL service on another peered network with no recourse other than rebuilding everything form scratch without IPv6 to roll the change back!
[1] Or a generic placeholder than encompasses both. E.g.: "Fix: Enabling the internet protocol no longer causes irreversible outages with your database service."
Even Google, one of the champions of IPv6 adoption on the Internet, only started adding IPv6 support to GCP in the 2020s. In all public clouds, there are still numerous services that don't support it at all. And I can 100% guarantee that the next public cloud that anyone creates will start off with IPv4 support; maybe it will have IPv6 as well on day one, maybe not.
On the contrary, essentially all of the IPv4 public ranges have now been allocated. The incumbents have bought up what they can, leaving essentially nothing for new clouds to use. It's one type of moat, and the three biggest providers are happy to keep everyone on the far side of it.
A new cloud starting in 2025 onwards would likely be based on an IPv6 native design with IPv4 as the "add on" for public endpoints only, such as load balancers and proxies.
IPv4 is far too ingrained to start with IPv6 only.
We’re closer than most people assume.
If ipv6 had been designed form the start to allow seemless transparent access to ipv4 from an ipv6 only client that would be fine. But dual stack means twice the work and very little benefit (what services are ipv6 only, even today)
It does. It's called NAT64, and it works/breaks as well as regular NAT44.
A good majority chunk of cell carriers today have gone IPv6-only for phones. They rely on NAT64 gateways (rather than CGNAT) to access IPv4-only resources. A lot of consumer internet is slowly following that lead as a better alternative to CGNAT. At least if your customers are consumers we are really close to "You might only need to serve IPv6."
(It's the "Enterprise-grade internet" that is interestingly lagging and falling behind in IPv6 adoption, and maybe doesn't see enough reason to support IPv6-only well; especially if the cost of IPv4 plateaus again, as some suggest it might. Recent AWS cost increases for IPv4 have been something of a call to action to some Corporations, but in general if you are B2B you probably need IPv4 support for a while longer as the economic incentives games play out on a long, slow horizon.)
I thought it was possible to make a pure v6 network and use NAT64 as needed? I mean, we can argue if that counts, but I argue yes:)
On the client side there are apparently some subtleties about the DNS interaction if you want to literally have IPv6-only on the clients (as opposed to IPv4 CGN). If the clients do anything to not trust their ISP's view of DNS (like DNSSEC enforcement, or using DoH and an outside resolver), the ISP can't fool them into thinking that they should connect to an IPv6 address for a service that, from the point of view of the Internet as a whole, is actually IPv4-only.
Can I do "ssh 1.2.3.4" on a pure ipv6 stack yet? Last time I looked at ipv6 I couldn't even ping an ipv6 host by doing "ping 1234::5678", I had to run a separate tool (ping6)
The nat64 and vice versa should have been the play from the start. Want to host a sevice? Put in ipv6 only network, host it on 1234:5678::1, have your firewall with a public ipv4 address do the port forwarding, taking your public 12.34.56.78:1234 and natting it to 1234:5678::1.
Just the same as hosting your service on 192.168.0.1 and port forwarding.
But 20 years of dual stack and horrible cludges around changing public IPs later and many people still prefer ipv4.
IIRC, it's been over a decade since the "ping" command became able to understand both IPv4 and IPv6 addresses; it was only during the early adoption of IPv6 by userspace that we had separate commands for the new IPv6 stuff. Quoting https://www.man7.org/linux/man-pages/man8/ping.8.html "As of version s20150815, the ping6 binary doesn't exist anymore. It has been merged into ping. Creating a symlink named ping6 pointing to ping will result in the same functionality as before." So it seems it has been a long time since you last looked at IPv6.
I ran IPv6 on xfinity. It works. My devices don’t. I like my devices. Easier to just not use it.
I think Let's Encrypt's behavior is correct, and I don't think anyone inside Let's Encrypt or CA/B Forum would like to inflict "pain [...] on host and network operators" beyond the current practice. Let's Encrypt's current behavior could be described as cooperating with IPv6 adoption rather than compelling IPv6 adoption, which seems like a reasonable place for a certificate authority to be.
There are cases where Let's Encrypt has made choices that potentially slightly reduce compatibility in order to encourage what it considers technically correct behavior. The first one that comes to mind is
https://community.letsencrypt.org/t/adding-random-entries-to...
but I know there are others. On the other hand, all of those decisions can be justified in terms of improving the correctness of PKI software (like not hard-coding things that should not be hard-coded). I can't think of any example that's like "we wish this other technical thing would happen outside of the PKI, so we'll try to force it along", and I don't foresee the broader community getting comfortable with that.
There was a comment below that in the LE forums instead of asking people to fix their AAAA records, they ask them to remove it. That's exactly the behavior you don't want to reward, so you must cause pain.
https://www.verizon.com/support/residential/internet/getting...
There is a great level of IPv6 awareness and enthusiasm in sort of technically elite spaces. Like at Ben's talk at RIPE that we're talking about, the audience was kind of laughing together at the non-IPv6 outgroup.
Meanwhile, I keep helping people use Let's Encrypt over on the Let's Encrypt forum. One of the most common reasons that people are failing to get their certificates is ... misconfigured IPv6 on their servers or in their DNS! And people in that situation often (1) didn't think of that as a possibility, (2) didn't notice (!!), (3) didn't necessarily care about it. Even worse, when people are told something like "your certificate issuance isn't working because your AAAA record is pointing at your old hosting provider rather than your current hosting provider" their usual response is to delete the AAAA record rather than updating it.
Other forum members may also advocate this as a solution. "Oh, just delete your AAAA record, you don't need it."
I'm not making this up, I've seen these things happen about 100 times on the Let's Encrypt forum.
Now, these are primarily sites in the long tail of Internet popularity, the proverbial Joe's Lamp Store rather than Gmail or Facebook or something. But the level of IPv6 awareness and interest among small-scale site operators and people doing small-scale IT stuff is very weak. And I've also seen that a surprisingly high fraction of web sites are IPv4-only rather than dual-stack.
I'm working on 240/4 usability, but I certainly don't want people to delete their AAAA records. I want them to know what an AAAA record is, and want to have their AAAA records be correct.
But there's quite a gap, in a way, between the elite and the non-elite tech spaces on this.