21:01:11 #startmeeting neutron_ipv6 21:01:11 Hello, Sean 21:01:16 Meeting started Thu Nov 21 21:01:11 2013 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:19 The meeting name has been set to 'neutron_ipv6' 21:02:06 OK - thank you everyone that has decided to attend 21:02:23 The agenda is pretty straight forward 21:03:03 My name is Sean Collins, and I work for Comcast 21:03:17 Great to "see" you, Sean 21:03:19 please feel free to introduce yourselves 21:03:52 I'm Anthony Veiga, IPv6 SME at Comcast 21:03:59 My name is Shixiong. I used to work for Cisco, but recently joined a startup working on OpenStack and IPv6 21:04:11 Howdy folks, Kyle from Cisco. 21:04:18 Hi, Kyle 21:05:16 I am mostly working with aveiga to get OpenStack Neutron to work with the networking environment we have set up at Comcast 21:05:50 As such, we're busy creating bugs and blueprints to cover things that we need done right away, to make it work in our environment, as well as some blueprints that probably would be useful to the community as well 21:06:02 #link https://bugs.launchpad.net/neutron/+bug/1252852 21:06:38 hmm, not sure if that worked or not 21:06:49 #link https://bugs.launchpad.net/nova/+bug/1251235 21:06:59 #link https://bugs.launchpad.net/neutron/+bug/1242933 21:07:06 evening ladies and gents 21:07:22 hi ijw - welcome 21:07:26 interesting...the 2nd bug explained what we saw before.... 21:07:28 o/ 21:07:39 sc68cal: Try #link 21:07:40 Seen that first one, it's bloody annoying 21:07:43 It will show in hte logs. 21:08:06 #link https://bugs.launchpad.net/nova/+bug/1251235 ip6tables rules isssues 21:08:26 for the first one, I think ip6tables also drops ND packets, if I am not mistaken 21:08:40 Didn't when I tried it 21:08:43 The second's very risky - need to source-filter your RAs 21:08:49 shshang: It does 21:08:53 Yeah, that's due to the hairpinning on the bridge device 21:08:56 (speaking as a man of much experience and bitterness with some muppet in the lab sending them out) 21:09:03 #link https://bugs.launchpad.net/nova/+bug/1251235 21:09:16 #link https://bugs.launchpad.net/nova/+bug/1251235 hairpinning issue for DAD 21:09:22 sorry, still getting used to this :) 21:09:32 is there any workaround for the 2nd bug? 21:09:56 shshang: for the hairpin? 21:10:02 yup 21:10:07 the workaround we're using currently is a very painful and manual process to disable hairpinning on the tap 21:10:09 I had to manually disable DAD 21:10:11 shshang: yeah, I have a patch to nova that's in review 21:10:12 on guest VM before 21:10:28 should be linked in the bug report 21:10:55 * haleyb never knew about the -alt channel until today 21:11:02 I see. Thanks for bringing it up 21:11:10 Basically this stuff I've filed has been for our immediate goal, getting IPv6 networks that we have existing outside of openstack, to work with OpenStack the way provider networks does on the v4 side 21:11:34 Obviously, IPv6 has some differences, since OpenStack wants to be the source of truth for things like subnets 21:11:57 and that's where we're running up against issues, where OpenStack gets confused and creates ip6tables rules for ::/128 in the security group rules 21:11:58 we should consider a longer term roadmap of the parts of IPv6 that we need to get working 21:12:05 aveiga: +1 21:12:15 agree 21:12:18 #link https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac 21:12:31 #agreed 21:12:47 That's a blueprint I'm trying to collect all my immediate work, to get IPv6 running inside OpenStack 21:13:10 There is a hacking way to make dnsmasq to announce RA 21:13:14 I don't think you'll be able to determine how routers should work in an hour long IRC meeting, to be honest... 21:13:14 but it is quite a hassle 21:13:14 What I want to make sure we don't do is be blinded by individual goals. I realize there are many people who want IPv6 that aren't necessarily keen on it being done via l2-provier 21:13:48 so that said, we've already got IPv6 via l2-provider/slaac as one implementation 21:14:00 are there others that should be looked at for immediate needs? 21:14:05 We also want to extend DNSmasq so that you can do things like DHCPv6, create subnets on the v6 side and get things on par with the v4 side 21:14:07 #link https://blueprints.launchpad.net/neutron/+spec/dnsmasq-mode-keyword 21:14:11 What are you doing about antispoof with SLAAC? 21:14:27 more long term 21:14:46 ijw: right now, nothing 21:15:06 however, I think the goal should be that when you create a subnet in an IPv6 SLAAC network, we should configure the router 21:15:18 and then use the router's information to populate the source list for RA inpouts 21:16:00 @sc68cal, I am a little bit confused about the #link https://blueprints.launchpad.net/neutron/+spec/dnsmasq-mode-keyword 21:16:07 but again, we're in the baby steps mode right now of just getting it to work at a low level before implementing 21:16:20 What I said about how long it'll take to decide that definitely applies. Firstly, ipv4 routers don't advertise routes, but v6 ones do - so probably we should add a route-advertise flag on the network that both respect. 21:17:36 shshang: what has you confused? 21:18:04 if we only talk about SLAAC here, then the way it is coding today has capability to detect subnet type. And if subnet is IPv6, then trigger RA. 21:18:32 However, if we talk about DHCPv6 and SLAAC, then yes, we need to provide options for user to define what they want 21:18:50 I'm not sure you're allowed to assume that the link-local address is what the MAC suggests it is. 21:19:19 ijw: are you referring to privacy extensions? 21:19:47 They don't apply to link local iirc 21:19:55 oops, missed that part 21:20:02 agreed 21:20:09 what case would exist where the lla isn't EUI-64 derived? 21:20:10 Trying to remember if link local is *required* to or *recommended* to be based on the link address. 21:21:25 in my experiment, VM boots and it has linklocal address in any way. it doesn't need Openstack's help 21:22:24 I don't know that lla is relevant here 21:22:27 the question here is, 1) How Openstack can send RA if we offer SLAAC 2) How OpenStack can store the SLAAC IPv6 address VM calculate 21:22:29 let's take a step back 21:22:38 ijw: looks like it's required http://tools.ietf.org/html/rfc4291#section-2.5.6 21:23:31 shshang: We don't necessarily want OpenStack to issue the RA in all cases 21:23:43 just in cases where an l3 agent is the gateway 21:23:59 Oh, I nearly forgot, Dazhao yu is working on a patch to do the calculations for EUI-64 21:24:05 most guests OSes ignore multiple RAs or ignore RA priority, and as such we'd blackhole them issueing RAs 21:24:16 #link https://review.openstack.org/#/c/56184/ Calculate stateless IPv6 Addresses 21:24:33 I think it just needs to be done against oslo, not neutron 21:26:05 So, it's a bit of a info dump from what aveiga have been doing. 21:26:38 There seems to be a lot of stuff where people have run into the same issues, but nothing seems to go back up into Neutron 21:26:52 like hairpinning, etc. 21:27:35 @aveiga, I can see your points in some setups.......is it a good approach to completely rely on external router? 21:27:45 carlp - tehre's a few 'should' rather than 'must' in rfc2464 that leave it ambiguous 21:28:10 ijw: true, but the diagram shows using the interface address which makes it seem like a must 21:28:35 Yep, but how the interface address is calculated is where the 'should' comes in. That's a 64 bit value, there are options on what you use for it. 21:28:41 ijw, carlp: The instances where it wouldn't don't make sense, because you'd have a MAC collision anyway 21:28:47 ijw: ah, missed that. Sorry 21:29:05 To be fair, we get to tell people what they should do to an extent. Changing MACs in v4 gets you nowhere, too... 21:29:54 aveiga: MAC addresses should be unique in openstack, too much depends on that for them not to be. Especially on the same network segment. 21:30:19 carlp: agreed, hence lla shuld be EUI-64 derived in all cases 21:30:22 In this instance, we're adding the additional requirement that no-one tries to be smart about assigning ipv6 LLs, but that's fine 21:31:28 I'm a bit short on action items, at least for community work 21:31:29 So, it's 30 minutes in, just checking if people have settle on either some bugs or BPs they'd like to focus on. 21:31:33 Icehouse-1 is in 2 weeks. 21:32:11 aveiga and myself are working mostly on the slaac + provider networking, since that's our setup internally 21:32:35 I'm also working to get some Third OParty Testing cycles spun up for this too 21:32:55 but I can only really test the l2-provider model right now 21:33:11 Both of those are solid. I think it makes sense to track that work as action items for next week. 21:33:22 Is anyone else willing to sign up for any of hte other bugs discussed here? 21:33:37 @aveiga: Is your setup completely using external router to send RA, right? 21:33:50 shshang: Yes. 21:34:11 yo gang 21:34:24 quick question, what's the plan to introduce ipv6 in neutrpn ? 21:34:32 mestery: is there a list of bugs? i missed the first 10 minutes 21:34:40 ekarlso: you'll have to read through the logs when we're done 21:34:46 sc68cal may have that list 21:35:15 it should appear in the log when we're done, but if not I'll e-mail the mailing list for good measure 21:35:17 ok, i only know of the two he has 21:35:34 I actually have about 3 more to post. I'm a bit behind on my documentation 21:35:43 sc68cal: so, just to confirm what your SLAAC stuff will leave us with - when you're done with your stuff, we're expecting VMs that assign themselves a global address appropriate to the subnet, right? 21:36:12 this is john brzozowski (jjmb), i run the ipv6 program at comcast - sean asked that introduce myself 21:36:27 ijw: We're expecting SLAAC to work normally as it would in any non-virtualized environment 21:36:35 again, this is for l2-provider models only 21:36:40 ijw: Yes. Although the subnet is not inside openstack at this point 21:36:50 we should also get a blueprint to gether to bring DHCPv6 into the fold 21:37:25 aveiga: I think the dnsmasq bp does cover that, though it could probably use better wording 21:37:51 then we should take that discussion in general to the mailing list and refine it 21:38:06 ok 21:38:07 more needs to happen than just dnsmasq to get that bit working 21:38:30 #action sc68cal discuss DHCPv6 support on the mailing list 21:39:42 Can we discuss the big picture first, before we talk about bug fix? 21:39:54 please 21:40:11 I am curious to see what approach we will take to tackle the IPv6 + Neutron issue 21:40:29 something like the priority and dependancies 21:41:07 one of the key things required to get neutron to be ipv6-capable is for neutron to be able to derive, assign or retrieve the VM's IP address 21:41:18 that might be a good place to start 21:41:20 agreed 21:41:27 that is our goal 21:41:30 or one of our goals 21:43:42 aveiga: can I assign you a task of documenting our usecase? 21:43:56 sure, but let's link it to mailing list discussions 21:44:03 I don't claim to be omniscient 21:44:03 ok 21:44:49 #action aveiga document our immediate needs from Neutron, and open discussion on the mailing list 21:45:17 How can we translate that to the blueprint? 21:45:19 do we want to include any phasing or future requirements? 21:45:23 ie a phased approach 21:45:30 or is this putting the cart before the horse? 21:45:42 @jjmb, agreed 21:45:45 it might be better to gather them all and then prioritize them 21:45:54 perhaps based on the amount of responses from the mailing list 21:46:15 #idea gather up requirements for immediate term, and log term 21:46:50 the immediate phase I would obviously need to be executed upon first... 21:47:17 however it might be useful for all to see and comment on what happens in future releases. aveiga/sc68cal? 21:47:25 As a basic sequence of events, it seems it's basic firewalling and L2 stuff to start (so that SLAAC works at least on provider networks) then we'll move on to RAs and then DHCP, I would think. Longer term and more frightening is what routers actually *do* for v6, because it's not what they do for v4. And a problem for both v6 and v4 is how multiple subnets on a network are supposed to be treated, I think - mestery, unless you know mo 21:47:48 Is there anyone interested in doing a neutron-wide code review looking for instances of addressing that are either cast as ints or pulled from IPv4-only calls? 21:47:54 ijw: well put 21:48:17 @ijw. That sounds like a plan already 21:48:20 aveiga: most of the calls i've seen is through netaddr 21:48:23 ijw: you bring up a good point, since multiple networks on the same subnet isn't a problem in IPv6... 21:48:56 which handles ip stuff - most is stored internally in the DB I believe for addresses 21:48:59 aveiga: 'interested' would be a strong statement, but I think it needs doing. We need to check the remaining bits of nova that neutron relies on too - and while we're at it can we please confirm that multiple subnets do work, and maybe even feed what we discover about operation to the docs people, because I don't think this is as well described as it should be 21:49:05 *stored as strings 21:49:44 ijw: Yes, and I plan on filing a bug soon about this. It turns out that if you even add an ipv6 subnet to a network with an IPv4 subnet, it disables the whole network 21:50:07 aveiga, you are talking about the external network side? 21:50:10 Not sure about everyone else, but I don't want dual stack to require separate interfaces 21:50:13 shshang: yes 21:50:18 Yeah. Try not adding a subnet. Havana's slightly different in that you get an error, but in Grizzly you got no interfae 21:50:19 I have solution for you 21:50:31 aveiga: 4, 46 and 6 should all work 21:50:42 aveiga, we already made dualstack working on external network side 21:50:54 shshang: We did too, by not putting in a subnet at all 21:50:54 v4, v6 on the same interface 21:51:11 we can compare notes outside this meeting though, as I don't want to take up time 21:51:13 shshang: where's the review? 21:51:29 we didn't publish the code yet, but we wrote a white paper 21:51:50 Right. Code review. Volunteer? 21:51:59 o/ (reluctantly, cos someone has to) 21:52:02 aveiga, ijw, if you are interested, we can have a call to review it together 21:52:27 shshang: bung it in gerrit as a WIP and mail the link around, we can comment on it there 21:52:27 actually, I'd prefer documentation and an email thread on the list 21:52:36 ijw: +1 21:52:51 shshang: can I put you down for an action on that item? 21:52:57 ijw, that is a good idea, will do 21:53:11 sc68cal, you mean, load code to github? 21:53:25 #action shshang post code review & link on mailing list 21:53:37 sure, I will do 21:53:39 shshang: put it on gerrit and mark it as WIP 21:54:08 aveiga, ijw, since this is my first time to post code, may need your help a little bit to make sure I did it right 21:54:13 thanks in advance 21:54:25 I can help, but it will be my first time too shortly 21:55:13 Might have more volunteers for the code review, if we can work out how best to file comments 21:55:29 Also a checklist of issues to look for 21:55:42 I think I can finnagle jjmb into helping with that list 21:56:08 sc68cal: put me down for coming up with a list of gotchas that block IPv6 21:56:20 ok 21:56:25 I can work with soem folks internally that already did this on other projects 21:56:36 sc68cal, please put me down for gap list too 21:56:56 ok, not sure if I can link multiple people to it 21:57:13 should probably be shshang aveiga and ijw 21:57:19 sc68cal: can you start a thread on the ML about what to look for? And is there some way we can comment up the code on github or something similar? 21:57:49 ijw: good question - probably the best thing to do is take notes then share on the mailing list 21:58:19 coming up on the end of the hour 21:58:35 #action aveiga ijw shshang start code review looking for IPv4-isms 21:59:14 Thanks everyone for coming, I'm going to get better at working with meetbot as we go along 21:59:19 I promise :) 21:59:30 thanks! 21:59:39 Next week is pretty close to a holiday in the US, so we may reconvene the week after 21:59:58 #endmeeting