how is it possible that on some projects it works? is it enabled or not

It doesn't. It's a MediaWiki hack that is acting like it's enabled.

OK, anyway, production is going to use ipv6 soon, why we can't have that on labs... do we still run old version of sw?

We don't have it enabled in openstack yet, and enabling it isn't straightforward because we created our networks before ipv6 support was available in openstack.

This is on our roadmap.

The Roadmap used to contain something for Q2 like adding a second zone in Eqiad, which Ryan told me (on IRC) would be the deployment.

See bug 39781 comment 2?

Adding 58791. Toolserver is dual stack, labs still lives in the 1990's.

We'll be enabling ipv6 during the move to eqiad, but depending on OpenStack support may keep it firewalled. Last time I checked the support for this in neutron is poor.

Hi folks!
Could you explain for which tools it's a blocker not to have ipv6?

(In reply to comment #15)

Hi folks!
Could you explain for which tools it's a blocker not to have ipv6?

I don't think anyone claimed any such tools existed...

Ok, then I propose not to insist on ipv6 for Labs for the moment. We don't need features just because toolserver has them - we need features that tools depend on.
Giving lower priority. Please give reasons if you insist/change it back.

(In reply to comment #17)

Ok, then I propose not to insist on ipv6 for Labs for the moment.

I suggest you read the overview in the page linked by Jasper in comment 4 above.

Allen, I have to precise what I meant. I am trying to prioritize what is crucial *just* for Tool Labs to replace the toolserver. Features that are absolutely needed for toolserver tools to migrate. As Maarten brought in that the toolserver has ipv6, I was wondering if there are tools that can't migrate without ipv6. If this is not the case, ipv6 is no blocker for toolserver migration.

I wasn't meaning that ipv6 is unimportant for the whole of Labs, sorry!

(removing as blocker to "missing feature" tracking bug; this does not block any tool migration)

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

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 early PoC

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