[wp-meta] [Making WordPress.org] #3090: WordPress.org API not accessible over IPv6

Making WordPress.org noreply at wordpress.org
Wed Nov 22 01:14:37 UTC 2023

#3090: WordPress.org API not accessible over IPv6
 Reporter:  deaky        |       Owner:  (none)
     Type:  enhancement  |      Status:  closed
 Priority:  high         |   Milestone:
Component:  API          |  Resolution:  maybelater
 Keywords:               |

Comment (by bviktor):

 Replying to [comment:6 dd32]:
 > I'm curious what environments you're running WordPress under that only
 have IPv6 connectivity though, as most instances of IPv6-only servers I've
 come across still have outbound IPv4 connectivity via a NAT interface.

 Pretty much any IPv6 VPS, e.g. Vultr, DigitalOcean. I'm trying to set up
 my VPS to use Cloudflare Tunnel via IPv6, and there's only two things that
 don't work:

 - GitHub (no, please don't pull the "others do that too" card, it won't
 make it any less ridiculous)
 - WordPress

 Not only does this omission break auto-updates, it breaks manual updates
 as well.

 Error: RuntimeException: Failed to get url 'https://api.wordpress.org/core
 /version-check/1.7/?locale=en_US': cURL error 7: Failed to connect to
 api.wordpress.org port 443 after 2 ms: Couldn't connect to server.

 That's all that `wp` can come up with. I can't even download the WP
 tarball, since, obviously,

 --2023-11-22 00:43:26--  https://wordpress.org/wordpress-6.4.1.tar.gz
 Resolving wordpress.org (wordpress.org)...
 Connecting to wordpress.org (wordpress.org)||:443...
 failed: Network is unreachable.

 So at this point the only thing I could do is upload the tarballs manually
 via SFTP. And I'm guessing I wouldn't be able to install, or even browse
 any themes or extensions either.

 I'd like to note that the complaint about memory requirements for DDoS
 protection seems rather weak, as a relevant paper that investigates this
 mentions something like 140 MB per user, when you let that user send 870k
 (!) requests per minute. I'm fairly certain your limits are at least 2
 orders of magnitude smaller.

 I'd also like to mention the fact that Cloudflare has a **free** version,
 even for enterprises. So yeah, I don't want to offend anyone, but I don't
 know how else to put it: if you can't figure out IPv6 or DDoS, let others
 do it for you. Setting up Cloudflare couldn't be simpler, it's literally
 just a click on "enable", so at this point, there's really no excuse other
 than "we don't care".

 The mentioned NAT64 guide is about setting up a separate host just to
 proxy all IPv4 traffic for the IPv6-only host. Which isn't really a
 solution, rather an ugly workaround, and doesn't really address the issue
 here. It doesn't seem really sensible for everyone to set up their own
 individual IPv4 proxy for wordpress.org to work, does it?

 The fact that "the meta team can't do anything about it" doesn't seem
 terribly relevant either. The meta team is the one we can talk to, so
 obviously, we submit the issue to the meta team. If we could submit issues
 to the system team, we would. But since we can't, it seems your
 responsibility to relay between the involved parties - in this case, us
 users, and your system team. And I want them to know that they should get
 their act together.

Ticket URL: <https://meta.trac.wordpress.org/ticket/3090#comment:13>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org

More information about the wp-meta mailing list