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.

[johnjonestaggle]

with all vendors such as singlehop and internap are both ipv6 enabled this should be just a case of adding a IP address

IPv6 IP address is no different from adding a IPv4 at this time what would be a blocker here ?

[dd32]

IPv6 IP address is no different from adding a IPv4 at this time what would be a blocker here ?

While that is true to enable IPv6 connectivity, there's a lot of other network-level requirements in Switches, Routers, network upstreams, and within the WordPress.org software stack as well, in order to allow IPv6 traffic to be stable and reliable.

Notably, DDOS mitigation for IPv6 requires a higher level of memory usage and attack protection, / per-IP rate limits also become harder to handle with end-connections receiving anything from a /64 (18,446,744,073,709,551,616 individual IPs) or /48 for some business connections, all the way down to a single /128 per connection. You can treat every /64 as one "person" but in doing so you might be treating an entire country or ISP as one "person". This is already becoming an issue with CGNAT / NAT64 too, with entire IPv6-only networks connecting to us as a singular IPv4 (or usually, a /24~/21 IPv4 range representing 20x the people), which can result in the same issue in reverse.

I'm personally aware of some VPS providers which only provide IPv6 connectivity and provide no outgoing IPv4 connectivity, and others that provide a NAT service for that.

So it's not just a case of turning it on, it's a complicated chain of events that doesn't necessarily benefit the majority of end-users right now. I know it's still on the systems roadmap, but that's not a high priority nor will it likely roll out as you may expect (ie. it'll appear on s.w.org CDN first, and possibly api/downloads before other user-facing areas)

[nikize]

Why is this closed? It is a major issue!

Just for info, a ISP customer should never have less than /64
Most of the time you should even be assigned one /64 + /56.

Some countries does change IP every 24h

So filtering on /64 will never hit worse than a legacy IPv4 /32

[ballerburg9005]

It is important to note that you can access the entire IPv4 network on an IPv6-only connection, for most intents and purposes the same way as if using IPv4. But this functionality of IPv6 might have been deliberately left disabled by server providers, who want to charge you extra for having it run in a normal manner.

Many people do not understand that an IPv6-only connection is simply misconfigured, if it cannot access the IPv4 network via NAT64. There is no technological limitation that would prevent IPv6-only hosts to talk to IPv4 addresses. It is basically the same as if using dual stack, just without the IPv4 protocol. Your gateway is responsible for facilitating the necessary address translation, and you need to use the DNS server from your network that has DNS64 enabled.

[ari-el]

Just migrated my blog's AWS EC2 instance to IPv6-only connectivity, only to find that WordPress doesn't fully support v6. In 2024!! OMG.
These days most mobiles (android/ios) do v6-only browsing most of the time while on cellular connectivity, and so do most users at home at least in north america. Looks like wordpress didn't get the news, pun intended.

IMHO the ticket needs to stay open until fixed.

[dd32]

I've escalated this to a Systems request; ​https://make.wordpress.org/systems/2024/03/04/ipv6-support/ for tracking and feedback from the network/systems administrators.

While I understand your interest, and frustration caused by providers who provide limited services not designed for hosting popular applications, the same reason why those providers don't provide IPv6-to-4 gateways and why WordPress.org hasn't deployed IPv6 is very similar.

Keeping this ticket open isn't helpful to us, as we (The Meta team of WordPress.org) are unable to influence this, and those who run the systems/network side of WordPress.org don't follow tickets here actively. IPv6 support will be made available at some stage; but it's my opinion that it'll likely only happen with a significant infrastructure redesign, which is unlikely to have any priority to it.

---

Similar to the above comments on this ticket;

AWS EC2 instance to IPv6-only connectivity

DNS64 is available for the purpose of providing IPv4 connectivity for outgoing requests on AWS services; I've not used it, but it appears to exist.

​https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html#nat-gateway-nat64-dns64-walkthrough-internet

most mobiles do v6-only .. while on cellular connectivity

All IPv6 deployments that I've heard of in the mobile scene will be using a NAT64 approach; while to the client it may seem like IPv6 only, it still has IPv4 connectivity ability. IPv6 in the mobile industry was heavily encouraged by VoLTE And their historic use of CGNAT/NAT44 (IPv4 NAT) devices, which is a very different scale than hosting deployments.

[deanhills]

I've been spending literally HOURS and HOURS trying to figure out why my IPV6 VPS cannot connect with WordPress.org. I created WordPress with Debian 10 and all of my permissions are set up correct. I was able to successfully create WordPress on Debian 10 but only from FileZilla SFTP. Debian 10 could not reach WordPress.org to fetch the software. Then when I Googled the issue no one responded with the real issue, which is WordPress.org is not really interested (or ready yet) to deal with IPv6 as IPv6. It wants those with IPv6 to translate the IP back to IPv4. If everyone else is working with IPv6 as IPv6, why is WordPress going against the current?

If WordPress cannot support IPv6, can you at least add this as one of the possible reasons to the WP Dashboard when you say - Your site cannot reach WordPress.org at 198.143.164.251 and Curl Error? You cover all options of why wordpress.org cannot be reached, except the most important one. As yet, WP doesn't support IPv6 as IPv6.