WordPress.org API not accessible over IPv6

[deaky]

We run multiple WordPress instances on hosts which are IPv6 only. These websites are used internally where we recently transitioned to IPv6 completely and disabled IPv4 for simplicity.
Unfortunately your ​API at api.wordpress.org does not seem to support IPv6. At least it doesn't have any AAAA records set. Therefore we are not able to use WordPress features like auto updates or plugin installation which connect to your API.
You’d make maintaining our WP instances a lot easier if you added support for IPv6 to your API.

[dd32]

The WordPress.org Systems team is aware of the want for IPv6, unfortunately at present it's not supported by our upstream providers. When IPv6 is available in our hosting environment, it'll be enabled for all WordPress.org services.

If you wish to run in an IPv6-only world, I'd suggest you investigate enabling a DNS64/NAT64 service for your network to allow transparent forwarding to IPv4-only resources.

I'm marking this as maybelater purely based on that it'll happen, but having a ticket open isn't going to nudge us towards it.

[Paul Guijt]

OK, I regretfully respect that. But could you please take care that a ticket is opened to have Wordpress communicate with Wordpress.org and Wordpress.com (and any other site that is only IPv4) through IPv4 only?

Replying to dd32:

The WordPress.org Systems team is aware of the want for IPv6, unfortunately at present it's not supported by our upstream providers. When IPv6 is available in our hosting environment, it'll be enabled for all WordPress.org services.

If you wish to run in an IPv6-only world, I'd suggest you investigate enabling a DNS64/NAT64 service for your network to allow transparent forwarding to IPv4-only resources.

I'm marking this as maybelater purely based on that it'll happen, but having a ticket open isn't going to nudge us towards it.

[dd32]

Replying to Paul Guijt:

OK, I regretfully respect that. But could you please take care that a ticket is opened to have WordPress communicate with Wordpress.org and Wordpress.com (and any other site that is only IPv4) through IPv4 only?

This is a server configuration issue on the hosts end. As only IPv4 DNS records are returned, it's up to the hosts PHP configuration being configured correctly to connect over IPv4. If an IPv4 gateway isn't available and only IPv6 is enabled, then it would be expected that the HTTP requests would fail quite fast due to the underlying network not supporting it.

WordPress.org's API will be available over IPv6 some day when our hosting infrastructure supports it, so we're not going to lock it down to only occurring over IPv4.

There have been some bugs in PHP's CURL implementation in the past which causes IPv4 connections to fail on IPv6-only hosts even when a IPv4 gateway is present which can't be worked around reliably from within WordPress.

[deaky]

Is there any news here? The API is still only accessible through legacy networks. I have to say it's really frustrating to have to setup and maintain NAT64+DNS64 just for systems that run WordPress.

I suggest to reopen this ticket as this is clearly not resolved.

[dd32]

Replying to deaky:

Is there any news here?

No, the network infrastructure we're running still doesn't have any IPv6 addresses allocated, it's not as simple as requesting/assigning them as we have complex load balancing and DDOS implications to take into consideration. It's not as high priority right now due to the majority of connections having either dual-stack or NAT gateways for the other half of the internet that has no native IPv6 routes.

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.

The other option is to use ​WordPress's built in proxy support, which would replace having to handle a NAT64 instance with a potentially simpler non-caching proxy.

I'm going to continue to leave this ticket closed, as there's no action the meta team can do here ourselves, this is up to the systems team to enable when they feel comfortable doing so. I do know it's on a long term roadmap though.

[ocean90]

#5785 was marked as a duplicate.

[ott]

api.wordpress.org does not have an AAAA RR in the DNS. Therefore, it is not reachable over IPv6. This is a problem for hosts that are IPv6-only. As a result, the admin dashboard contains multiple errors message and (automatic) updates seem to be broken. This decreases the confidence in WordPress and can lead to security problems.

IPv6-only hosts are becoming more important as IPv4 address depletion continues and the cost of IPv4 addresses increases. Example of scenarios where IPv6-only hosts are deployed today are public web hosting, in particular with load balancers or other address translators that connect IPv6-only networks to the IPv4 Internet, and internal networks that already IPv6-only. IPv6-only networks lower the operational costs and complexity for networks that do not need IPv4 and some larger organizations have even run out of RFC 1918 address space.

It's a larger topic but I hope this explanation suffices to justify the need for IPv6 connectivity for api.wordpress.org. If the justification does not suffice, please contact me via email and I can mention concrete example of IPv6-only networks and use-cases in private correspondence. The topic has also been discussed in public conferences and it is possible to find recordings of presentations that discuss this topic in far more detail and also mention concrete use-cases and deployments.

[maltris]

Yea, would be great to get IPv6 support here, throws a bad light on the WP tech if they didnt manage in 24 years. If you need help, feel free to inquire with me.

[johnjonestaggle]

since the hosting provider has for some time provided IPv6 transit +
the load balancing and DDOS implications are null(if they are not present do tell which vendor)

this is 2023 most mobile providers are IPv6 native and there is at least 15% degradation not using IPv6

since this is happening across the industry

​https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/

since singlehop and internap are both ipv6 enabled I dont see any reason...

who is going to stand up and do the hard work ?

[dd32]

This is not something the Meta team has any control over at this point in time. I'm re-closing this, purely as there's nothing actionable for the Meta team at present.

The WordPress.org systems team DO have IPv6 plans, but at present there are higher priority tasks and there's no widespread requirement for IPv6 connectivity.

Due to the size of traffic that WordPress.org see's (especially APIs) I expect there'd also be concerns around rate limiting (as IPv6 would be 4x the memory requirement, so 5x IPv4 for a dual-stack 4+6 limits).

If a host/DC is IPv6-only, they need to offer a NAT64 or DNS64 service, ​such as what Amazon suggests for AWS.
This is for more than just WordPress.org, this is also needed for a variety of other web services which are either unavailable over IPv6 or simply have bad IPv6 routes.
There's a reason why desktops retry over IPv4/connect over both 4+6 and use the first successful connection.

[bviktor]

Replying to 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

So yeah, thanks to GitHub, I can't even download wp-cli, only upload it via SFTP. But 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)... 198.143.164.252
Connecting to wordpress.org (wordpress.org)|198.143.164.252|: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, let alone update them later on.

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.

[bviktor]

Some more comments on the performance "penalty":

"There has been a growing trend of IPv6 usage on the internet. If we look at the last month of connections made worldwide by Apple devices, we see that IPv6 now accounts for 26% of all connections made," Mehta added. "20% of the time, the connection could have used IPv6, but the server didn't have it enabled.

"And when IPv6 is in use, the median connection setup is 1.4 times faster than IPv4. This is primarily due to reduced NAT usage and improved routing."

And this report is from 3.5 years ago.

So yeah, you can keep resisting and make life more complicated and slower both for yourselves and your users - I just don't see the point.