"This patch makes the default to build IPv6 into the kernel. IPv6
now has significant traction and any remaining vestiges of IPv6
not being provided parity with IPv4 should be swept away. IPv6 is now
core to the Internet and kernel.

Points on IPv6 adoption:
- Per Google statistics, IPv6 usage has reached 7% on the Internet
and continues to exhibit an exponential growth rate
https://www.google.com/intl/en/ipv6/statistics.html
- Just a few days ago ARIN officially depleted its IPv4 pool
- IPv6 only data centers are being successfully built
(e.g. at Facebook)"

So it’s strange a new project would choose to neglect IPv6 support when supporting it from the start should require basically no effort these days.

So it’s strange a new project would choose to neglect IPv6 support when supporting it from the start should require basically no effort these days.

Both the Boulder CA software and the Let’s Encrypt client fully support IPv6, and the majority (53%!) of traffic to the Let’s Encrypt APIs is IPv6.

The problem is the validation piece due not to software development but rather datacenter connectivity. I’ve heard that it’s been helpful to point the datacenter folks to all the discussion as a demonstration that IPv6 really is in demand.

(As a note, the selection criteria on the datacenter was driven far more by security requirements than IPv6 support. We figured we could encourage IPv6 adoption, as long as the security was top-notch.)

Another motivation is that a few VPS hosting providers have started to offer lower prices for instances with IPv6-only connectivity (ie, no IPv4 connectivity). When HTTP DCV, these servers won’t have options to get validated other than via IPv6.

Is there anything the community can do in the interim to help? If 53% of traffic is IPv6 then I’d say getting IPv6 working for validation should be pretty high up, so some of us may be willing to help bridge the gap (accounting for security concerns etc) until the DC supports it.

We’re pushing on the appropriate organizations. Being high security environments, no one wants to be specific about how much of the delay is process control versus reconfiguring or replacing old hardware.

We’re looking at other options. One thing that has come up is to do an analysis of the security properties of doing validation through a 6to4 tunnel, or similar. I haven’t had time to do such a review personally, and I know the ops team has their hands full as well. Certainly we don’t want to add more opportunities for a MITM, but since DNS wouldn’t be through 6to4, in theory this may work, but someone has to write the analysis and get it peer reviewed before we can trust the Internet to it.

FWIW, IPv6 support is more than 7% now; it’s at 9% and growing exponentially. In certain countries, it’s over 35% (US has a bit over 20%). I wouldn’t recommend 6to4; you’re at the mercy of the return relay (and your own relay, but that’s easier to control), and due to the anycasted nature, a MITM is much, much easier than regular IPv4 or IPv6. It’s also pretty much dead these days, so connectivity is going to be spotty.

My DNS server will happily spit out an AAAA record for xyz789.blah to an IPv4 client. For validation, if the fact that the request is coming from the same IP as the authoritative and DNSSEC-signed NS for xyz789.blah is not sufficient, I’d love to be able to have LE run a simple SQL query (where I can easily give the executing user very specific permissions at the database level) to update a SRV or TXT record in the DNS instead of giving it root access to run an httpd just to verify a little string.

As @gary pointed out, Boulder has some to-dos for IPv6 validation, but those are low priority since we’re still waiting on resolution from our datacenter folks for them to do their required changes and give us IPs.

Speaking from experience, we’re likely not going to get any status updates, just a sudden “here are your IP blocks” email.

I spoke to a few people at IETF 94 about IPv6 tunnel protocols (including @sds!) and got some mixed gut feelings about whether it would invalidate trust in validation or be (only) a risk increase. I think, without doing the legwork on an analysis, it’s too early to say. Based on that, and everyone being super-busy with the public launch, I believe the right answer is native IPv6 connectivity. Which means it won’t be there for GA, I’m afraid.