21:02:07 <sc68cal> #startmeeting neutron_ipv6
21:02:08 <openstack> Meeting started Thu Dec 12 21:02:07 2013 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:12 <openstack> The meeting name has been set to 'neutron_ipv6'
21:02:42 <sc68cal> Agenda for today is a bit light - so I'd like to get through it quick and then do a big open discussion
21:02:56 <sc68cal> #topic recap previous meeting
21:03:27 <sc68cal> So we're still working through what we want to do with the subnet_mode review
21:04:15 <sc68cal> aveiga: IJW made a good point during a convo about some of the provider networking w/ ipv6 we want to do
21:04:38 <sc68cal> we should be setting enable_dhcp to false when we create a v6 subnet that is announced upstream
21:04:44 <aveiga> is this wrt disabling instead of setting SLAAC mode? I agree
21:04:52 <ijw> Yeah, there's two things.  Firstly, I don't really mind if we want slaac and dhcpv6 both working, that's fine, but I don't think we should tie ourselves forever to dnsmasq
21:05:21 <ijw> Second, I wanted to understand why people like slaac (other than on provider networks where it's an external router's problem, which totally makes sense)
21:06:10 <aveiga> ijw: I think there's issues on both modes.  SLAAC has RA problems with a lot of distributions (see RHEL bugs on RA priorities)
21:06:18 <ijw> Yup
21:06:22 <aveiga> DHCP has problems with client implementations
21:06:34 <aveiga> it also has RA issues, too
21:06:47 <sc68cal> aveiga: but that's if there are multiple RA packets flying around, right?
21:06:53 <ijw> I'm thinking mainly about comes up on non-provider (i.e. totally internal) networks
21:07:04 <aveiga> basically if you do DHCPv6, you either have to make the DHCP server a router, or have the RA come from an l3 gateway separately
21:07:12 <aveiga> and coordinate
21:07:28 <ijw> Yup, I don't think co-ordination is a problem particularly but we have to deal with networks with no routers
21:07:50 <aveiga> right, tenant private networks are irksome when it comes to this
21:07:53 <ijw> I also have no problem with being in the router namespace, but there's nothing in Neutron that forces you to have a single Neutron router either
21:08:05 <ijw> It's just a nightmare, that's the problem
21:08:07 <aveiga> and that's the real kicker
21:08:16 <aveiga> if there are multiple rotuers, where does the RA come from?
21:08:16 <sc68cal> is Randy Tuttle on?
21:08:20 <sc68cal> or Shixiong Shang
21:08:32 <ijw> So, first things first.  In ipv4 you get to choose your network's subnet and your port's address.  Do we still want to do either of those things?
21:08:32 <sc68cal> I think their design addressed some of this in depth
21:09:05 <aveiga> ijw: are you referring to neutron network creation on the subnet side?
21:09:16 <aveiga> or do you mean selecting potential networks at instance creation?
21:09:58 <ijw> I mean that in v4 you get (as tenant) to choose your subnet and you get to choose your address if you create a port manually (rather than letting the system do it on nova boot) if you keep it in that subnet
21:10:36 <aveiga> I'm not fully familiar, but doesn't choosing your subnet mean the same thing as selecting a neutron network?
21:11:00 <ijw> No, subnet is the address range rather than the network (which is l2)
21:11:02 <aveiga> oh, I think I know what you mean
21:11:30 <ijw> Reason I raise it is that I can imagine you'd want to stick with routeable addresses, or at least have routeable addresses chosen for your network automatically, in v6
21:11:43 <aveiga> yes
21:11:50 <ijw> In v4, the world is your oyster, cos v4 is evil and must die
21:12:00 <aveiga> the problem is going to be having dhcpv6 and slaac in the same l2
21:12:12 <aveiga> they would be separate subnets
21:12:17 <aveiga> but same l2 domain
21:12:22 <aveiga> so the RAs would be wonky
21:12:38 <ijw> We get to choose, we don't have to allow just everything
21:12:49 <aveiga> we could make them mutually exclusive
21:12:59 <sc68cal> should we make an action item to review how neutron behaves when you have a network with multiple subnets?
21:13:12 <sc68cal> on v4 side, and compare what would happen on v6 side with multiple subnets?
21:13:14 <aveiga> or force DHCOPv6 allocation to not use EUI-64 collision space
21:13:17 <ijw> My choice there would be that we allow precisely one v6 subnet per network (the v4 multiple subnet thing is a solution to address sparsity which isn't a problem we have) and use DHCPv6 so that we assign specific addrs to machine
21:14:00 <ijw> sc68cal: I think how it works is you get an address from one of the subnets, at least in v4.  Good chance no-one has tried it in v6, though certainly you can set it up, I tried
21:14:08 <sc68cal> ijw: So you'd force DHCPv6 as the only option on v6 side?
21:14:19 <sc68cal> meaning no slaac
21:14:36 <ijw> For internal networks, and if we could get away with it, that's my preference.  Tenant networks: DHCPv6 or off
21:14:49 <ijw> To be fair, even in v4 you can turn off DHCP if you like.
21:15:05 <aveiga> I actually don't see why non-routing tenant networks need addressing
21:15:09 <aveiga> you get LLA for free
21:15:12 <ijw> yup
21:15:28 <ijw> Tenant networks don't have to be non-routing, mind
21:15:41 <aveiga> yeah, but then I don't think I'd want to force DHCPO on them either
21:15:45 <ijw> (Sorry, I  have an evil mind and at the moment it sees problems and not answers)
21:16:06 <sc68cal> ijw: do you want to write up a blueprint for what you're thinking?
21:16:08 <aveiga> ijw: someone has to play devil's advocatel; nodding heads don't make good solutions
21:16:28 <aveiga> sc68cal: ijw: blueprint sounds liek a good idea
21:16:36 <ijw> Yeah, let me do that.  Problem is that (like a lot of other blueprints in this space) it excludes options whatever we implement, but I can do that
21:16:57 <aveiga> at least we can all discuss it with a model in front of us
21:17:11 <sc68cal> #action ijw write up blueprint discussing his preferred model for tenant networking
21:17:17 <aveiga> I'm just finidng it difficult to understand why we'd exclude slaac or static?
21:17:31 <aveiga> because keep in mind, some folks want config-drive or metadata static injection as well
21:17:39 <aveiga> and I can think of good use cases for it
21:17:45 <ijw> What do you mean by static?  Remember DHCP here is 1 MAC, 1 IP
21:17:59 <sc68cal> OK - let's go ahead and move on from this - keep to the agenda
21:18:06 <aveiga> I mean that the IP is injected into the guest config
21:18:08 <sc68cal> let's hold this until open discussion
21:18:09 <ijw> yup
21:18:10 <aveiga> ok
21:18:26 <sc68cal> #topic Nova IPv6 hairpin bug
21:18:38 <sc68cal> Promise if we get through these quick we can let you guys go at it
21:19:00 <sc68cal> So - we're getting some pushback on the hairpin issue
21:19:04 <ijw> I like the proposed solution for hairpinning and I don't think any Neutron module needs it but should we have a quick code review?
21:19:20 <ijw> (the solution being the one where VIF plugging requests it if required)(
21:19:32 <sc68cal> #link https://review.openstack.org/#/c/56381/ nova ipv6 hairpin bug review
21:19:45 <sc68cal> ijw: agreed
21:19:58 <aveiga> was there an issue with that from anyone else?
21:20:14 <sc68cal> aveiga: one of the core devs from nova wants it to be a per VIF attribute
21:20:24 <sc68cal> I think we agree - provided the default is off
21:20:37 <sc68cal> and if someone wants it, just pass in an attribute to turn it on, from Neutron
21:20:40 <ijw> Daniel is being cautious, though I think a bit too cautious.  Still.
21:20:55 <aveiga> I don't fully grasp the consequences here
21:21:02 <aveiga> what is lost by defaulting to off?
21:21:06 <baoli> Question, why hairpin has to be turned off with neutron?
21:21:17 <aveiga> baoli: DAD failure
21:21:28 <ijw> nova-network's usually on because the floating IP rewrite rules live between the switch and the port in nova-network
21:21:33 <ijw> Neutron doesn't put them there.
21:21:34 <aveiga> you see your own Neighbor Solicit, and eimmediately detect a duplicate address
21:21:54 <sc68cal> The problem is nova is adding patches to their firewall drivers to block traffic from coming back and breaking ipv6
21:21:58 <baoli> where does neutron put it?
21:22:02 <aveiga> ah, so unless it hairpinned NAT wouldn't apply?
21:22:03 <ijw> In the router
21:22:18 <ijw> Yup, you can't ping your own public address iirc
21:22:29 <aveiga> right
21:22:52 <sc68cal> There's a big chunk of code that Nachi has been working on, to have Neutron pass in VIF attributes for firewalling
21:22:53 <aveiga> so we should push this back on nova-network to have them set the hairpin option
21:23:18 <ijw> We also need to check all the other drivers - libvirt is not the world.
21:23:22 <sc68cal> So it wouldn't be too hard to add another attribute to the VIF stuff to make it turn on hairpinning
21:23:28 <aveiga> unless you think it's better to make it a negative case? Assume it's on, request it to be disabled per VIF?
21:23:42 <sc68cal> aveiga: I'd assume the inverse - always off, unless requested
21:23:55 <ijw> There's an argument for either but it's so slight let's just pick one.
21:24:01 <aveiga> ok, but expect an argument from the embedded parties there
21:24:23 <sc68cal> I'm picking off by default
21:24:30 <sc68cal> and vif attribute turns it on when requested
21:24:34 <aveiga> ok, propose it on the ML then
21:24:44 <sc68cal> aveiga: I did - I asked if anyone needed it
21:24:49 <sc68cal> no responses
21:25:03 <ijw> OK, so we have to check all the virt drivers for this and we also need to check the plugins
21:25:09 <ijw> Neutron plugins
21:25:19 <aveiga> is than AI for another code review?
21:25:36 <ijw> The virt drivers need changes, the neutron plugins only review
21:26:02 <sc68cal> I hope that it's only libvirt that enables hairpinning
21:26:12 <aveiga> how should we approach that? Setup the new VIF definition, then file bugs against the virt drivers?
21:26:41 <ijw> guess so
21:26:45 <sc68cal> aveiga: I think so, if we start sending the attribute, drivers should honor it and enable hairpin
21:27:03 <ijw> More to the point, have to honour its absence and not enable hairpin.
21:27:34 <sc68cal> ijw: agreed - which the review currently makes libvirt do
21:27:36 <aveiga> which is where the default on or off argument comes in
21:28:14 <sc68cal> OK - if nobody else objects I'll file a blueprint in nova to make hairpin a configurable setting
21:28:21 <aveiga> +1
21:28:24 <sc68cal> then people can make sub blueprints to link to specific drivers
21:28:24 <ijw> yup
21:28:44 <sc68cal> #action sc68cal create blueprint in nova for hairpinning via VIF attributes
21:29:14 <sc68cal> OK we're through
21:29:18 <sc68cal> #topic open discussion
21:29:29 <ijw> aviega: the point I wa ma
21:29:48 <ijw> was making earlier was that 'static' is not exclusive with the others
21:29:56 <ijw> You get that regardless of if DHCP is on or off
21:30:10 <aveiga> sorta
21:30:14 <ijw> so really we're only talking about flags that change the network address handing-out service
21:30:29 <aveiga> I can think of a scenario where having DHCP on would be detrimental to a static config
21:30:39 <ijw> Yep, that's fine, so you turn it off
21:30:43 <aveiga> ah, that's where I agree with you
21:30:46 <ijw> on/off is already available
21:31:05 <aveiga> so are we leaving it to the operator then?
21:31:15 <ijw> DHCP on/off should remain an option
21:31:17 <ijw> *but*
21:31:20 <aveiga> they have to know enough to disable DHCP
21:31:53 <ijw> Yeah, but I'm assuming if you know you need static config you can work that one out
21:31:59 <aveiga> ok
21:32:09 <aveiga> so in the case where we have SLAAC and DHCP
21:32:14 <ijw> DHCP / SLAAC is more of an issue.  SLAAC will come up with an address which isn't the one you have put on the port, for instance
21:32:17 <aveiga> I'm worried about collisions
21:32:40 <aveiga> so this is why I think the port needs to take a huint from the network
21:33:19 <ijw> What happens if we just don't let SLAAC addressed traffic through the port firewall?
21:33:50 <aveiga> you potentially break distruibutions
21:33:53 <ijw> Obviously a SLAAC chosen address wouldn't work, but we can require that VMs using v6 take the address they've been given and don't just make it up
21:34:31 <aveiga> if it's a mixed mode network and you block the SLAAC addr at the port, then some distros that get the SLAAC addr up first will be forever dead in the water
21:34:40 <aveiga> unless you manually alter routing tables
21:35:00 <aveiga> I think we need to make DHCP and SLAAC mutually exclusive
21:35:25 <ijw> Again, can we exclude mixed mode?
21:35:37 <ijw> I'm out of my depth here, so I'm honestly asking
21:35:44 <aveiga> yes
21:36:04 <aveiga> you can safely make the assumption that EUI-64 SLAAC is the least common denominator
21:36:10 <aveiga> since it existed for years before anything else
21:36:30 <ijw> Yeah, but the issue is that it's damned nice to be able to force an address on a VM rather than have one given
21:36:32 <aveiga> and assume that an operator choosing DHCP should know that their guest images must be able to use it
21:36:41 <aveiga> then you use DHCP
21:37:06 <aveiga> you can theoretically force an address
21:37:12 <aveiga> you have control of the MAC
21:37:13 <ijw> Well, you can predict it
21:37:39 <aveiga> my turn for devil's advocate
21:37:49 <aveiga> what if you want to put multiple addresses on the same interface?
21:38:01 <aveiga> i.e. bind apache to one and ssh to the other?
21:38:06 <aveiga> DHCP won't do that
21:38:10 <aveiga> SLAAC wont'
21:38:18 <aveiga> but if you filter the port on non-assigned addresses
21:38:19 <aveiga> that breaks
21:38:22 <ijw> static config, probably, at that point
21:38:37 <ijw> And there's an extension for that that arosen did, so we're not screwed
21:38:57 <aveiga> does it support injecting rotues?
21:38:59 <aveiga> routes*
21:39:22 <ijw> Don't think so, but you can see that coming, I agree
21:39:25 <aveiga> because (due to the RA bug in some distros) one of the main points for static is addressing with out RA so that you can do HSRP in v6
21:40:06 <ijw> Well, I'm still going to write a BP recommending against SLAAC (also, SLAAC only works on a /64 aiui)
21:40:08 <aveiga> that way RA juggling isn't necessary for multi-homed switches
21:40:16 <aveiga> that's correct
21:40:32 <ijw> and /64 is a big tenant net
21:41:04 <ijw> But anyway, initially let's assume we're going to want to make that extension either core or more widely implemented.  I'll go and find the one in question.
21:41:44 <aveiga> so what do you intend to do with clients that don't have a working DHCPv6 stack?
21:41:48 <aveiga> fore static injection?
21:41:49 <ijw> There's also magic to turn off antispoof entirely for a whole net.  It was much more important in nova-net than it is in Neutron (where you can have total control of all your VIFs on the network)
21:42:07 <ijw> configdrive?
21:43:06 <ijw> cloud-init happily supports config drives and they work without a functional network to get a network up.
21:43:12 <aveiga> I'm wary of saying that we support IPv6 if we don't support SLAAC
21:43:20 <aveiga> since SLAAC is part of the IPv6 RFC
21:43:23 <sc68cal> +1
21:43:27 <ijw> Better say that it's not core, I would say
21:43:41 <sc68cal> and we have a BP registered for how we deploy openstack at Comcast
21:43:52 <sc68cal> which involves SLAAC
21:44:02 <ijw> It's not that you can't do it, but I think we should aim for v4 parity in this, which is basically that you get to choose an address from the subnet and have it assigned via a handful of recognised methods
21:44:11 <ijw> SLAAC on internal networks?
21:44:17 <aveiga> both
21:44:24 <ijw> OK, point me at that offline
21:44:45 <ijw> We're going around on this, so let's cover something else while we have the time
21:44:47 <sc68cal> #link https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac Provider networking with slaac
21:44:59 <ijw> .. that's provider nets, not internal, though
21:45:02 <aveiga> what did you have in mind?
21:45:18 <ijw> floating IPs
21:45:24 <aveiga> ah, the killer
21:45:27 <ijw> Absolutely
21:45:41 <ijw> Now, no-one is allowed to say the N word without putting a quid in the swear jar
21:46:00 <aveiga> I have a better proposal
21:46:08 <aveiga> change the DHCP reservation
21:46:20 <aveiga> and keep the valid lifetime low
21:46:30 <ijw> Renumber the machine?
21:46:33 <aveiga> yup
21:46:39 <ijw> Hm
21:46:47 <ijw> How about change the router firewall
21:46:59 <ijw> So where before you would n.. things, you let incoming connections in
21:47:17 <ijw> different change, but same place
21:47:26 <aveiga> actually
21:47:35 <aveiga> DHCPv6 supports having multiple addresses
21:47:44 <aveiga> we could inject both in the renew
21:47:50 <aveiga> well
21:47:51 <ijw> That's a rather nice idea
21:47:53 <aveiga> tell it rebind fail
21:47:56 <aveiga> then start over
21:48:11 <sc68cal> kind of like it
21:48:19 <aveiga> effectively use DHCP to inject it without renumbering
21:48:26 <ijw> However, the thing here is that even with private (fixed) v4 addresses I have external access
21:48:26 <aveiga> no loss of existing bindings/TCP sessions
21:48:50 <aveiga> are we doing private v6? I propose we ignore ULA
21:49:03 <ijw> So the question is whether this is about having two addresses for one machine or about the kind of inbound access that machine has, philosophically
21:49:04 <aveiga> actually, that was selfish
21:49:08 <aveiga> we should support it
21:49:30 <aveiga> eh, it's reachability on an address that isn't the machine's primary access
21:49:32 <sc68cal> I think from the outside it's just about being able to move an IP across boxes
21:49:47 <aveiga> because you can ssh to the fixed before a flaot is assigned
21:49:50 <sc68cal> dynamically without mucking around inside the machines
21:49:52 <aveiga> and you can reserve floats
21:49:52 <ijw> You see, that's two things - reachability and primary access - why can't it be primary?
21:50:13 <ijw> sc68cal may have it
21:50:18 <aveiga> because you'd rebind daemons or kill tcp sessions
21:50:27 <ijw> Though it's a very slow way of moving the address, you know
21:50:33 <sc68cal> I think primary access just leaked in because of the design of nova-network
21:50:39 <sc68cal> to the floating ip concept
21:50:43 <aveiga> we shouldn't break existing access while adding a float
21:50:54 <sc68cal> but elastic IPs in amazon was reachability
21:50:56 <aveiga> yeah, but I can see that as being useful
21:50:58 <ijw> Only if you change the address, not if you use the same one and it's routeable (which it would want to be if it were to have the equivalent of a fixed address, which if it's on a router has external dialout access)
21:51:24 <aveiga> I think the real issue is WHICH address
21:51:47 <ijw> So the minimal solution is there's no second address, by default it can dial out and with special permissions it can dial in.  But that removes transferrability
21:52:01 <aveiga> one reason for reserving floats and putting them on a new VM is for upstream security outside of OpenStack
21:52:24 <aveiga> yeah, transferrability is a key concept of flaots
21:52:28 <aveiga> they float between VMs
21:52:54 <aveiga> I don't think you can support flaoting IPs and ignore that feature
21:53:09 <aveiga> whether we like it or not, people are using it in that manner already
21:53:18 <ijw> OK, so it's a secondary address.  What pool are we drawing from?
21:53:21 <aveiga> this sounds like a bigger topic though
21:53:31 <aveiga> and we're close to time
21:53:43 <ijw> Yeah - clearly there's no simple answer here
21:53:46 <aveiga> want to put this on the agenda for next week or take it to the ML (or the neutron channel)?
21:53:52 <ijw> Both, I think
21:53:57 <aveiga> maybe some fols in the neutron channel have opinions here?
21:54:35 <aveiga> ok, I think we're done here
21:54:40 <aveiga> sc68cal: care to do the honors?
21:54:45 <ijw> To my mind it's one of the biggest stumbling blocks, possibly second only to ensuring all your addresses are routeable and non-overlapping
21:55:09 <sc68cal> sure - if nobody has anything else we can end early
21:55:20 <aveiga> yeah, I think making prov modes mutually exclusive helps there, but I agree
21:55:30 <aveiga> and on that, I need to head out to get dinner anyway
21:55:31 <ijw> Well, I think we have more than enough work for a week.
21:55:38 <aveiga> +1
21:55:44 <sc68cal> Alright then - see everyone next week
21:55:49 <ijw> o/
21:55:49 <sc68cal> #endmeeting