You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

Difference between revisions of "Talk:Wikimedia Cloud Services team/EnhancementProposals/Network refresh"

From Wikitech
Jump to navigation Jump to search
imported>DSquirrelGM
 
imported>Quiddity
(fix magiclink)
 
Line 1: Line 1:
 +
== 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. [[User:DSquirrelGM|DSquirrelGM]] ([[User talk:DSquirrelGM|talk]]) 15:42, 13 February 2020 (UTC)
 
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. [[User:DSquirrelGM|DSquirrelGM]] ([[User talk: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? --[[User:Arturo Borrero Gonzalez|Arturo Borrero Gonzalez]] ([[User talk:Arturo Borrero Gonzalez|talk]]) 16: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?
+
:: 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. [[User:DSquirrelGM|DSquirrelGM]] ([[User talk:DSquirrelGM|talk]]) 00:13, 14 February 2020 (UTC)
--[[User:Arturo Borrero Gonzalez|Arturo Borrero Gonzalez]] ([[User talk:Arturo Borrero Gonzalez|talk]]) 16:42, 13 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 [[w:SLAAC|SLAAC]] to allocate addresses based on [[w:IPv6_address#Modified_EUI-64|EUI-64]] ([https://docs.openstack.org/neutron/rocky/admin/config-ipv6.html#using-slaac-for-addressing 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 [https://docs.openstack.org/neutron/rocky/admin/config-ipv6.html#configuring-interfaces-of-the-guest], so there should not be any non-deterministic address issues to deal with. --[[User:BryanDavis|BryanDavis]] ([[User talk:BryanDavis|talk]]) 05:19, 14 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. [[User:DSquirrelGM|DSquirrelGM]] ([[User talk:DSquirrelGM|talk]]) 00:13, 14 February 2020 (UTC)
 

Latest revision as of 05:45, 14 February 2020

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 [1], so there should not be any non-deterministic address issues to deal with. --BryanDavis (talk) 05:19, 14 February 2020 (UTC)