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