14:00:16 #startmeeting neutron_ipv6 14:00:16 Meeting started Tue Apr 29 14:00:16 2014 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:20 The meeting name has been set to 'neutron_ipv6' 14:00:42 #topic blueprints 14:01:23 Hi 14:01:28 baoli: hey 14:02:47 Do we have any new blueprints in review? 14:03:28 #link https://review.openstack.org/#/c/88043/ ipv6-provider-slaac 14:04:08 sc68cal, I'm planning to start neutron specs for the radvd bp and the prefix delegation bp for the next couple of weeks. 14:04:35 great! 14:04:47 do we have functioning units for dhcpv6 yet? 14:05:04 I haven't seen anything that actually turns on stateful and sets up a scope in dnsmasq 14:05:13 that might be a pre-req for PD to work 14:06:27 I believe we need to get the neutron-specs in, then we can break up the code that shixiong wrote into smaller, manageable chunks 14:06:35 ok 14:07:12 #topic code reviews 14:07:35 Honestly I've dropped the ball on updating any of my ipv6 patch submissions 14:08:20 but I think we have a lot of stuff to hammer out at the summit 14:09:44 Anyone have any code reviews to discuss, or we can move to bugs then open discussion 14:11:15 #topic bugs 14:12:05 #link https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6 bugs tagged ipv6 14:13:01 shouldn't bumping the min version be a quick fix? 14:13:21 aveiga: yes - but I don't know how that interacts with the distros 14:14:00 but I think we do need to bump it - I think we had a couple lines in meetings previously discussing it 14:14:08 I'll have to do some grepping 14:16:03 #topic open discussion 14:16:12 I have a question. In an IPV6 environment when OpenStack dnsmasq is acting as a stateful DHCPV6 server, how does it identify the client uniquely? 14:16:18 As DHCPV6 Clients identify themselves using the DUID instead of MAC address and since clients can use UUID generated in three different ways (Link Layer Address with time, Vendor Assigned Unique ID and Link Layer Address), hence the question. 14:16:56 s/UUID/DUID 14:17:34 I suppose that depends on the guest? 14:17:53 thats true, it depends on the DHCP V6 client running inside the VM. 14:18:37 But since the dnsmasq is going to serve the IP address in a static manner. The mapping should be pre-determined using the DUID field. 14:18:59 So I was wondering how we will be supporting the DHCPV6 Statefull mode. 14:19:58 Do you think we can enforce the requirement that DHCPV6 clients in the VMs should always use the Link Local Address as the DUID field? 14:20:08 I'll freely admit that you're probably a bit further ahead than I am about this problem - so I'd be happy to delegate to you to figure out how to solve it 14:20:29 and start discussing it on the ML to see if anyone else has some good ideas 14:20:43 no problem sc68cal. I'll have a look at it closely. 14:20:50 Sure, I'll send out an email on the mailing list. 14:21:55 The more I think about it, the more I realize that addressing in Neutron had a lot of ipv4 isms in it where addressing can be centrally defined 14:22:22 as opposed to ipv6 where the client has more influence in the transaction 14:22:44 We are kind of lucky since we also determine the MAC for the guest 14:23:23 yeah that is true. 14:23:44 But supporting privacy extensions could be very tricky.. 14:24:03 We will not be supporting the display of PE addrs 14:24:15 guests are free to use them, but they won't show up in API calls 14:24:24 since they're ... private ;) 14:24:44 would they be forwarded and supported by the Neutron router? 14:25:20 there are a few hacks in flight for dnsmasq here 14:25:23 not sure what you mean 14:25:38 like being able to determine from a dual-stacked host that the DUID and MAC match 14:26:01 or being able to strip the timestamp from an LLA+TS DUID 14:26:08 interesting 14:26:15 but in general it's going to come down to the same setup we have with SLAAC 14:26:23 SridharGaddam: when you say supported by a neutron router, can you explain? 14:26:39 we're telling people that privacy extensions are invalid in our environment, so why not also restrict to LLA DUID? 14:27:07 I meant to say that will the VMs with privacy extensions enabled be able to communicate to external world? Sorry if it was not clear. 14:27:39 aveiga: that is one possible solution. 14:28:23 SridharGaddam: with PE, the prefix won't be chnaged but the ID part of the address, right? 14:28:59 yes, AFAIK the id part would no longer be constructed using EUI64 method. 14:29:21 and since that's a client-generated method with no way for us to calculate it, it's invalid for Neutron 14:29:31 since Neutron needs a predictable address to provide to advances services 14:29:46 things like FWaaS, VPNaaS and LBaaS will fail with PE 14:30:05 yes aveiga, I agree. 14:30:34 When a guest uses PE, it still keeps the assigned address - like if it's a slaac network 14:30:59 so I assume that in this env they'd be using that address for accessing it, then perhaps just PE for sending traffic? 14:31:11 the PE addr becomes the default 14:31:44 which means FWaaS rules may fail, return NAT will fail from an LBaaS, etc 14:31:52 hmm... since each ipaddress has a valid lifetime and preferred lifetime. The SLAAC generated address could eventually timeout and the one generated using PE could be used for all the communication. 14:32:12 if the SLAAC addr times out, routing will fail 14:32:14 because that means the RA has timed out 14:32:20 and your default route is no longer valid 14:35:50 yes aveiga. Supporting privacy extensions could be very tricky for the above reasons. 14:36:05 as long as the prefix won't change, the routing wouldn't change. The concern with PE is the anti-ip spoofing filter. It's installed with ipv4 by default. 14:36:26 the concern with PE is the instability and unpredictability of the address 14:36:47 tyou can't provide PE to other systems, so it should be officially unsupported 14:37:38 I suppose our easiest solution is to wait until someone files a bug about it, the only thing that could make things difficult is if a distro enables PE by default 14:38:29 (which may already be the case - not sure to be honest) 14:38:46 Ubuntu does by default 14:38:54 that's true 14:39:05 there are bugs filed there, as well 14:39:47 #link https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1068756 Ubuntu IPv6 PE bug 14:39:48 Launchpad bug 1068756 in procps "IPv6 Privacy Extensions enabled on Ubuntu Server by default" [Undecided,Confirmed] 14:40:15 basically ignored for 2 years 14:40:52 nice find 14:40:58 some thread on PE. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622845 14:41:00 Debian bug 622845 in linux-2.6 "please enable IPv6 privacy extension in default configuration" [Wishlist,Open] 14:41:17 it's actually a valid concern for clients 14:41:20 but bad for servers 14:42:05 if the address is generated by dhcpv6, would the guest still use PEs? In other words, would PE only works with SLAAC address? 14:42:10 agree. They should be disabling it for server images 14:42:23 RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 14:42:28 baoli: nope, it's SLAC only 14:42:50 so for servers, they dont' have to use slaac 14:42:50 dhcpv6-assigned prefixes will not have this, unless the A bit is set 14:43:10 it's possible if you had A, M and O all set to true you'd have both PE and dhcpv6 addrs 14:43:24 but we don't allow that on Neutron-issued RAs 14:43:43 there's no API option for SLAAC+Stateful 14:43:49 But the dhcpv6 addr will not expire 14:44:01 sure it will, it should have a valid lifetime 14:44:09 the client will need to renew 14:44:15 but the client will renew it, right 14:44:20 yes 14:44:26 just like today with v4 14:45:01 I think we can safely say that just as we don't support PE, we should only support LLA DUID 14:45:05 for now, at least 14:45:29 if any of you wants to write some really ugly hacks to dnsmasq to do otherwise, you're welcome to submit them upstream 14:45:29 ok 14:46:30 anyone disagree? 14:46:44 I'm not a dictator here :) 14:47:44 I think we should keep an eye on those bugs that people highlighted 14:47:54 +1 14:48:47 we've got some work to do in the layer of neutron that runs dnsmasq - so we'll get to the PE thing when we get to it :) 14:49:04 let it not be known that the ipv6 team lacks things to be worked on :) 14:49:05 ah, decouple the issue 14:49:12 the dnsmasq bit is for DUID 14:49:23 PE is SLAAC/Neutron management, not dnsmasq 14:49:51 true- but we need to get some code into neutron to drive subnets that have stateless set as the attrs 14:50:00 yep 14:50:02 err stateful 14:50:06 etc. etc. 14:50:07 also true 14:50:21 so we can focus for now on getting LLA DUIDs supported 14:50:27 so we at least have a basic functional target 14:51:23 To be honest, I'm lost here. How dhcpv6 duid is related to PE? 14:51:23 ok - should we start something on the ML about it or is there enough info to put something into neutron-specs and LP? 14:51:40 baoli: they aren't 14:51:43 that's waht I was getting at 14:51:53 there is one BP and I asked this question in the BP earlier. 14:51:58 sc68cal: blueprint it as the basic miulestone 14:52:05 https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful 14:52:36 ok - I see your comment. 14:52:48 We need to move that into neutron-specs and hash that out 14:53:04 doing it on LP's whiteboard is a pain - I know I'm sort of waving my hand and hiding behind process 14:53:57 Honestly stuff in LP just gets neglected, most neutron devs are in gerrit 14:54:11 either that or the ML 14:54:39 so feel free to start up convos on the ML 14:54:47 +1 14:55:01 or if you're a bit farther long in an idea, do a spec in neutron-specs 14:55:01 Each DHCP client and server has a DUID. DHCP servers use DUIDs to 14:55:01 identify clients for the selection of configuration parameters and in 14:55:01 the association of IAs with clients. DHCP clients use DUIDs to 14:55:03 identify a server in messages where a server needs to be identified. 14:55:05 See sections 22.2 and 22.3 for the representation of a DUID in a DHCP 14:55:07 message. 14:55:09 Clients and servers MUST treat DUIDs as opaque values and MUST only 14:55:11 compare DUIDs for equality. Clients and servers MUST NOT in any 14:55:13 other way interpret DUIDs. Clients and servers MUST NOT restrict 14:55:15 DUIDs to the types defined in this document, as additional DUID types 14:55:17 may be defined in the future. 14:55:49 baoli: This fails for static allocations when the DUID is not pre-defined 14:55:59 the only DUID that can be pre-determined by Neutron is LLA 14:56:07 or by mangling an LLA+Time 14:57:08 aveiga, I think that I have some homework to do 14:57:23 hit me up if you need help, I worked with the team that wrote this RFC 14:57:31 and was sort of mentored by the WG chair 14:57:45 aveiga: I did not explore much, but some of the DHCPV6 clients which I used seem to use LLA+time as DUID(i.e, default conf). 14:57:48 aveiga, sure. thanks 14:58:15 there's a chance that some distros ship with LLA+time as the default 14:58:23 I know OpenWRT did for a while 14:58:23 ok 14:58:43 ok 14:59:34 Alright everyone 14:59:44 till next week - thanks everyone for attending 14:59:51 #endmeeting