Talk:Wikimedia Cloud Services team/EnhancementProposals/Network refresh

IPv6 allocation scheme

Regarding the assignment of addresses - Reserving a certain part of the ipv6 address scheme to encode a hash or crc of the project name might be a reasonable idea. DSquirrelGM (talk) 15:42, 13 February 2020 (UTC)

We plan to allocate a IPv6 range per project. So each IPv6 address can be mapped directly to a given CloudVPS project, which is what I think you are thinking of? --Arturo Borrero Gonzalez (talk) 16:42, 13 February 2020 (UTC)

Essentially, yes, but have it a little more deterministic in individual address assignments than startup order or some other method that may give unpredictable results between service restarts. DSquirrelGM (talk) 00:13, 14 February 2020 (UTC)

I haven't thought about this deeply, but it seems like the simplest IPv6 allocation scheme for Cloud VPS would be to use SLAAC to allocate addresses based on EUI-64 (OpenStack Rocky docs on slaac). The IPv6 subnet that the SLAAC allocations are taken from would be set by the Neutron network that the instance's port is attached to. Today we use a single Neutron network for all projects in the eqiad region, but that may change before or after we roll out IPv6 generally. I do not see a special need to encode the Cloud VPS project the instance belongs to in the IPv6 address. We should be able to have AAAA and PTR DNS records for forward/reverse lookups. OpenStack's IPv6 support does not include support for RFC:4941 privacy extensions , so there should not be any non-deterministic address issues to deal with. --BryanDavis (talk) 05:19, 14 February 2020 (UTC)