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.