Bumping this task.

We could use IPv6 connectivity for the account-creation-assistance project. Since IPv6 addresses are starting to show up on Wikipedia now, it becomes rather problematic for us if we see a different IP address for users requesting Wikipedia accounts than what Wikipedia will see, especially since we perform sockpuppetry checks and such before fulfilling account requests.

In T37947#399351, @scfc wrote:

http://permalink.gmane.org/gmane.org.wikimedia.labs/2651:

> Of particular interest would be to hear if there are plans to IPv6

> enable the labs web proxy server and start publishing AAAA records for

> the dns aliases one can register in wikitech?

Our current networking stack in Labs currently makes this overcomplicated.

But there is good news: as we roll out to our new datacenter in Dallas,

we plan on having Openstack there use Neutron, which should allow us to

deploy IPv6 as well, so at the very least Dallas instances should be

IPv6 capable.

After that, upgrading Ashburn to use the same networking setup as Dallas

becomes something that can be planned for.

Note this was deprioritised, see T85609

In T37947#2449718, @FastLizard4 wrote:

Bumping this task.

I hate to bump this again, but is there any plan for this to happen in the near/mid/distant future? Is there any help that volunteers can give to expedite, or is this entirely dependent on operations staff time?

We could use IPv6 connectivity for the account-creation-assistance project. Since IPv6 addresses are starting to show up on Wikipedia now, it becomes rather problematic for us if we see a different IP address for users requesting Wikipedia accounts than what Wikipedia will see, especially since we perform sockpuppetry checks and such before fulfilling account requests.

I'm aware that IPv6 adoption is growing, as are IPv6 blocks/rangeblocks, so the above reason given by @FastLizard4 is getting more and more relevant.

+1.

A lot of granted ACC requests may be slipping through because we only see the user's IPv4 when they are actually suffering from an IPv6 block. For all we know, we could be creating sockpuppets without even knowing.

FWIW, UTRS could benefit from being able to handle the growing number of IPv6 blocks for similar reasons to ACC.

UTRS github tracking issue: https://github.com/UTRS/utrs/issues/139

It should probably be noted on this task that work to move to neutron has resumed at T167293: Nova-network to Neutron migration, after which it is hoped that IPv6 should be doable without too much trouble.

Note for myself: https://docs.openstack.org/mitaka/networking-guide/config-ipv6.html

Before we can move forward with this, there are several things to sort out:

• what is our ideal IPv6 model for CloudVPS
• to which extent we can implement our ideal model with our current Openstack version (mitaka)
• describe use cases, new workflows, etc we will have with IPv6 support in CloudVPS (specially, floating IPs, proxies, etc)

Persisting here some notes from @chasemp for future reference:

• This comes from around Kilo time when IPv6 was first being introduced and it was described as planning to be ready for general deploy in Newton. This is just a note I have from that time.

• BGP for Neutron routers and an upstream is seemingly only a serious option starting in Mitaka and I believe we talked about not wanting to plan on implementing both at once so probably that doubled down on the Newton narrative.

• At the time we started kicking this around it was unclear what the relationship was going to be between VXLAN (or other overlays) and IPv6. AFAICT overlays still require the host to use IPv4 even if the tenants are on IPv6, which is OK. It seems like ironically IPv6 within the Cloud is tested much better than IPv6 for control plane components.

• I have a note that indicates Router HA is not viable for IPv6 in Mitka with prefix designation https://docs.openstack.org/mitaka/networking-guide/config-ipv6.html. Whether this seriously matters probably depends on what the ideal model is here but in some dusty corner of my brain the idea that each tenant has globally unique IPv6 space via some overlay mechanism with HA software routers wouldn't work out it seems.

TLDR pre-Neutron things were very unclear what would even be possible

CloudVPS now uses a version of openstack that fully supports IPv6. Research/PoC work on IPv6 can be seen at T245495: CloudVPS: IPv6 in codfw1dev

Obviously, no one has come up with this idea since 2012, and it's still the same after 11 years, which is sad.

Change 975826 had a related patch set uploaded (by Cathal Mooney; author: Cathal Mooney):

[operations/software/netbox-extras@master] Remove cloud hosts except clouddb from the "no IPv6 hostname" list

https://gerrit.wikimedia.org/r/975826

Change 975826 merged by jenkins-bot:

[operations/software/netbox-extras@master] Remove cloud hosts except clouddb from the "no IPv6 hostname" list

https://gerrit.wikimedia.org/r/975826

What is the status on this? The lack of IPv6 support of the webservice seems to be one of the reasons for slow connections from some internet providers. T362822

Just wanted to add this is still a source of trouble for us when trying to use cloud VPS to have test machines. We keep having to work around it a lot in different contexts just like many years ago.

It has been suggested by @cmooney that we introduce support for IPv6 while on the migration for T364725: Migrate Cloud VPS instances to VXLAN based networks, which I agree, and I'll try to do.

additional tracking of the project happening in https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS/Admin/IPv6/initial_deploy

We are targeting to announce/start the user-facing migration on 2025-01-06, see also https://wikitech.wikimedia.org/wiki/News/Cloud_VPS_VXLAN_IPv6_migration