14:00:16 <sc68cal> #startmeeting neutron_ipv6
14:00:16 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:20 <openstack> The meeting name has been set to 'neutron_ipv6'
14:00:42 <sc68cal> #topic blueprints
14:01:23 <baoli> Hi
14:01:28 <sc68cal> baoli: hey
14:02:47 <sc68cal> Do we have any new blueprints in review?
14:03:28 <sc68cal> #link https://review.openstack.org/#/c/88043/ ipv6-provider-slaac
14:04:08 <baoli> 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 <sc68cal> great!
14:04:47 <aveiga> do we have functioning units for dhcpv6 yet?
14:05:04 <aveiga> I haven't seen anything that actually turns on stateful and sets up a scope in dnsmasq
14:05:13 <aveiga> that might be a pre-req for PD to work
14:06:27 <sc68cal> 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 <aveiga> ok
14:07:12 <sc68cal> #topic code reviews
14:07:35 <sc68cal> Honestly I've dropped the ball on updating any of my ipv6 patch submissions
14:08:20 <sc68cal> but I think we have a lot of stuff to hammer out at the summit
14:09:44 <sc68cal> Anyone have any code reviews to discuss, or we can move to bugs then open discussion
14:11:15 <sc68cal> #topic bugs
14:12:05 <sc68cal> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6 bugs tagged ipv6
14:13:01 <aveiga> shouldn't bumping the min version be a quick fix?
14:13:21 <sc68cal> aveiga: yes - but I don't know how that interacts with the distros
14:14:00 <sc68cal> but I think we do need to bump it - I think we had a couple lines in meetings previously discussing it
14:14:08 <sc68cal> I'll have to do some grepping
14:16:03 <sc68cal> #topic open discussion
14:16:12 <SridharGaddam> 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 <SridharGaddam> 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 <SridharGaddam> s/UUID/DUID
14:17:34 <sc68cal> I suppose that depends on the guest?
14:17:53 <SridharGaddam> thats true, it depends on the DHCP V6 client running inside the VM.
14:18:37 <SridharGaddam> 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 <SridharGaddam> So I was wondering how we will be supporting the DHCPV6 Statefull mode.
14:19:58 <SridharGaddam> 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 <sc68cal> 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 <sc68cal> and start discussing it on the ML to see if anyone else has some good ideas
14:20:43 <SridharGaddam> no problem sc68cal. I'll have a look at it closely.
14:20:50 <SridharGaddam> Sure, I'll send out an email on the mailing list.
14:21:55 <sc68cal> 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 <sc68cal> as opposed to ipv6 where the client has more influence in the transaction
14:22:44 <sc68cal> We are kind of lucky since we also determine the MAC for the guest
14:23:23 <SridharGaddam> yeah that is true.
14:23:44 <SridharGaddam> But supporting privacy extensions could be very tricky..
14:24:03 <sc68cal> We will not be supporting the display of PE addrs
14:24:15 <sc68cal> guests are free to use them, but they won't show up in API calls
14:24:24 <sc68cal> since they're ... private ;)
14:24:44 <SridharGaddam> would they be forwarded and supported by the Neutron router?
14:25:20 <aveiga> there are a few hacks in flight for dnsmasq here
14:25:23 <sc68cal> not sure what you mean
14:25:38 <aveiga> like being able to determine from a dual-stacked host that the DUID and MAC match
14:26:01 <aveiga> or being able to strip the timestamp from an LLA+TS DUID
14:26:08 <sc68cal> interesting
14:26:15 <aveiga> but in general it's going to come down to the same setup we have with SLAAC
14:26:23 <sc68cal> SridharGaddam: when you say supported by a neutron router, can you explain?
14:26:39 <aveiga> we're telling people that privacy extensions are invalid in our environment, so why not also restrict to LLA DUID?
14:27:07 <SridharGaddam> 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 <SridharGaddam> aveiga: that is one possible solution.
14:28:23 <baoli> SridharGaddam: with PE, the prefix won't be chnaged but the ID part of the address, right?
14:28:59 <SridharGaddam> yes, AFAIK the id part would no longer be constructed using EUI64 method.
14:29:21 <aveiga> and since that's a client-generated method with no way for us to calculate it, it's invalid for Neutron
14:29:31 <aveiga> since Neutron needs a predictable address to provide to advances services
14:29:46 <aveiga> things like FWaaS, VPNaaS and LBaaS will fail with PE
14:30:05 <SridharGaddam> yes aveiga, I agree.
14:30:34 <sc68cal> When a guest uses PE, it still keeps the assigned address - like if it's a slaac network
14:30:59 <sc68cal> 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 <aveiga> the PE addr becomes the default
14:31:44 <aveiga> which means FWaaS rules may fail, return NAT will fail from an LBaaS, etc
14:31:52 <SridharGaddam> 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 <aveiga> if the SLAAC addr times out, routing will fail
14:32:14 <aveiga> because that means the RA has timed out
14:32:20 <aveiga> and your default route is no longer valid
14:35:50 <SridharGaddam> yes aveiga. Supporting privacy extensions could be very tricky for the above reasons.
14:36:05 <baoli> 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 <aveiga> the concern with PE is the instability and unpredictability of the address
14:36:47 <aveiga> tyou can't provide PE to other systems, so it should be officially unsupported
14:37:38 <sc68cal> 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 <sc68cal> (which may already be the case - not sure to be honest)
14:38:46 <aveiga> Ubuntu does by default
14:38:54 <baoli> that's true
14:39:05 <aveiga> there are bugs filed there, as well
14:39:47 <aveiga> #link https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1068756 Ubuntu IPv6 PE bug
14:39:48 <uvirtbot> Launchpad bug 1068756 in procps "IPv6 Privacy Extensions enabled on Ubuntu Server by default" [Undecided,Confirmed]
14:40:15 <aveiga> basically ignored for 2 years
14:40:52 <sc68cal> nice find
14:40:58 <SridharGaddam> some thread on PE. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622845
14:41:00 <uvirtbot> Debian bug 622845 in linux-2.6 "please enable IPv6 privacy extension in default configuration" [Wishlist,Open]
14:41:17 <aveiga> it's actually a valid concern for clients
14:41:20 <aveiga> but bad for servers
14:42:05 <baoli> 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 <sc68cal> agree. They should be disabling it for server images
14:42:23 <baoli> RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6
14:42:28 <aveiga> baoli: nope, it's SLAC only
14:42:50 <baoli> so for servers, they dont' have to use slaac
14:42:50 <aveiga> dhcpv6-assigned prefixes will not have this, unless the A bit is set
14:43:10 <aveiga> 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 <aveiga> but we don't allow that on Neutron-issued RAs
14:43:43 <aveiga> there's no API option for SLAAC+Stateful
14:43:49 <baoli> But the dhcpv6 addr will not expire
14:44:01 <aveiga> sure it will, it should have a valid lifetime
14:44:09 <aveiga> the client will need to renew
14:44:15 <baoli> but the client will renew it, right
14:44:20 <aveiga> yes
14:44:26 <aveiga> just like today with v4
14:45:01 <aveiga> I think we can safely say that just as we don't support PE, we should only support LLA DUID
14:45:05 <aveiga> for now, at least
14:45:29 <aveiga> 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 <SridharGaddam> ok
14:46:30 <aveiga> anyone disagree?
14:46:44 <aveiga> I'm not a dictator here :)
14:47:44 <sc68cal> I think we should keep an eye on those bugs that people highlighted
14:47:54 <aveiga> +1
14:48:47 <sc68cal> 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 <sc68cal> let it not be known that the ipv6 team lacks things to be worked on :)
14:49:05 <aveiga> ah, decouple the issue
14:49:12 <aveiga> the dnsmasq bit is for DUID
14:49:23 <aveiga> PE is SLAAC/Neutron management, not dnsmasq
14:49:51 <sc68cal> true- but we need to get some code into neutron to drive subnets that have stateless set as the attrs
14:50:00 <aveiga> yep
14:50:02 <sc68cal> err stateful
14:50:06 <sc68cal> etc. etc.
14:50:07 <aveiga> also true
14:50:21 <aveiga> so we can focus for now on getting LLA DUIDs supported
14:50:27 <aveiga> so we at least have a basic functional target
14:51:23 <baoli> To be honest, I'm lost here. How dhcpv6 duid is related to PE?
14:51:23 <sc68cal> 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 <aveiga> baoli: they aren't
14:51:43 <aveiga> that's waht I was getting at
14:51:53 <SridharGaddam> there is one BP and I asked this question in the BP earlier.
14:51:58 <aveiga> sc68cal: blueprint it as the basic miulestone
14:52:05 <SridharGaddam> https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful
14:52:36 <sc68cal> ok - I see your comment.
14:52:48 <sc68cal> We need to move that into neutron-specs and hash that out
14:53:04 <sc68cal> 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 <sc68cal> Honestly stuff in LP just gets neglected, most neutron devs are in gerrit
14:54:11 <sc68cal> either that or the ML
14:54:39 <sc68cal> so feel free to start up convos on the ML
14:54:47 <aveiga> +1
14:55:01 <sc68cal> or if you're a bit farther long in an idea, do a spec in neutron-specs
14:55:01 <baoli> Each DHCP client and server has a DUID.  DHCP servers use DUIDs to
14:55:01 <baoli> identify clients for the selection of configuration parameters and in
14:55:01 <baoli> the association of IAs with clients.  DHCP clients use DUIDs to
14:55:03 <baoli> identify a server in messages where a server needs to be identified.
14:55:05 <baoli> See sections 22.2 and 22.3 for the representation of a DUID in a DHCP
14:55:07 <baoli> message.
14:55:09 <baoli> Clients and servers MUST treat DUIDs as opaque values and MUST only
14:55:11 <baoli> compare DUIDs for equality.  Clients and servers MUST NOT in any
14:55:13 <baoli> other way interpret DUIDs.  Clients and servers MUST NOT restrict
14:55:15 <baoli> DUIDs to the types defined in this document, as additional DUID types
14:55:17 <baoli> may be defined in the future.
14:55:49 <aveiga> baoli: This fails for static allocations when the DUID is not pre-defined
14:55:59 <aveiga> the only DUID that can be pre-determined by Neutron is LLA
14:56:07 <aveiga> or by mangling an LLA+Time
14:57:08 <baoli> aveiga, I think that I have some homework to do
14:57:23 <aveiga> hit me up if you need help, I worked with the team that wrote this RFC
14:57:31 <aveiga> and was sort of mentored by the WG chair
14:57:45 <SridharGaddam> 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 <baoli> aveiga, sure. thanks
14:58:15 <aveiga> there's a chance that some distros ship with LLA+time as the default
14:58:23 <aveiga> I know OpenWRT did for a while
14:58:23 <SridharGaddam> ok
14:58:43 <SridharGaddam> ok
14:59:34 <sc68cal> Alright everyone
14:59:44 <sc68cal> till next week - thanks everyone for attending
14:59:51 <sc68cal> #endmeeting