15:00:10 #startmeeting neutron_ipv6 15:00:11 Meeting started Tue Feb 24 15:00:10 2015 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:15 The meeting name has been set to 'neutron_ipv6' 15:00:16 o/ 15:00:33 o/ 15:01:06 topic #code reviews 15:01:12 doh 15:01:16 #topic code reviews 15:01:40 If anyone has any reviews they'd like to discuss, the floor is yours 15:02:46 We've pushed a WIP review for the Prefix Delegation work today https://review.openstack.org/#/c/158697/ 15:02:53 general feedback would be much appreciated :) 15:03:38 excellent, i'll add it to my queue 15:03:45 thanks 15:04:16 I have a patch up for https://bugs.launchpad.net/neutron/+bug/1424760 15:04:18 Launchpad bug 1424760 in neutron "SLAAC/DHCPv6-stateless subnets can be deleted with router ports still in-use" [Undecided,In progress] - Assigned to Andrew Boik (drewboik) 15:04:21 https://review.openstack.org/#/c/158508/ 15:04:37 would appreciate any comments 15:04:51 dboik: will review that today 15:04:58 ^ +1 15:05:04 thanks 15:07:09 Excellent - I'll be trying to play catch-up later this week on my reviews :) 15:08:21 #topic bugs 15:08:36 #link https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6&orderby=-id&start=0 IPv6 tagged bugs 15:09:59 Any new bugs that anyone wants to discuss? 15:10:21 For 1357068... 15:10:33 #link https://review.openstack.org/#/c/114437/ 15:11:03 I was going to push up a patch set that reverts to xuhanp's original patchset (version 1) 15:11:32 With an explanation in the commit comment about why we don't think an arping equivalent is needed for IPv6 15:12:12 I think we're covered for IPv6 with ND, RA, and duplicate address detection 15:12:43 dane_leblanc: +1 15:12:44 I think carl_baldwin had a patch he pushed that throws an error whenever that code path is called with an ipv6 subnet .... need to find it in my history 15:12:46 If anyone thinks we need an arping equivalent for some feature (e.g. for HA router)... 15:12:52 Then we can file a new bug 15:13:11 dane_leblanc: ++ 15:13:34 found it - https://review.openstack.org/#/c/154644/ 15:14:15 ah, he abandoned it in favor of mine, which i abandoned in favor of dane_leblanc 's 15:14:36 That error message could be better. :D 15:14:43 I think xuhanp's original fix of just checking for IPv4 in the gratuitous arp method is the way to go. 15:14:50 dane_leblanc: Agreed 15:15:18 dane_leblanc: but i thought your other patch fixed things as well, right? 15:15:27 dane_leblanc, maybe not just commit message, but also code comment 15:15:37 haleyb: This is a real bug, should be fixed outside of my blueprint patches 15:16:30 ihrachyshka: I'll try to come up with a good code comment. Hopefully that won't bring me down a rat hole. 15:17:42 Reg https://bugs.launchpad.net/neutron/+bug/1372882, appreciate your comments if there are any alternate mechanisms to address it. 15:17:44 Launchpad bug 1372882 in neutron "Neutron should drop certain outbound ICMPv6 packets" [Undecided,In progress] - Assigned to Sridhar Gaddam (sridhargaddam) 15:18:02 dane_leblanc: so just stop the error for now, but your blueprint change fill fix it correctly? 15:18:59 haleyb: My blueprint will use (depend on) this fix 15:19:52 haleyb: I'm proposing that the fix _is_ to stop the error, assumption is we don't need arping for IPv6 15:20:50 SridharG: Looks like we're sort of stuck. I know for a fact the NFV people are going to want ICMPv6 packets to be allowed outbound 15:21:00 from a neutron port 15:21:14 yes sc68cal I agree. 15:21:14 in some instances 15:21:33 dane_leblanc: i'll just leave further comments for the patch 15:21:53 So, I'll go ahead and abandon my patch. 15:21:56 haleyb: Great, thanks! 15:23:06 SridharG: ok. We'll have to try and talk with robert at some point and think up how to proceed 15:23:49 ok sc68cal. But what you said is also true, NFV would have some usecases where they do not want this fix. 15:24:21 SridharG: Agreed. perhaps we have to just bite the bullet and block outbound by default and tell the NFV people to push a sec group rule to allow outbound ICMPv6 15:24:28 when they need it 15:24:58 SridharG: Is the purpose of this bug to become the default? Dropping ICMP? And what other ICMP types would you propose be dropped? 15:25:11 rackertom: Outbound, from a VM 15:25:15 IMO, this is a bad idea. 15:25:31 I can think of several reasons why I'd want a VM to RA to a net 15:25:53 rackertom: Yes, but should we allow it by default, or require explicit rule 15:26:06 I think a secure default is probably preferred. 15:26:12 I think we should make no rules about it. Allow it by default. 15:26:28 Make it works as close to the real world as possible 15:27:06 sc68cal: the location at which we are blocking/dropping would have higher priority and even if the user manually adds an outbound ICMPv6 allow rule, AFAIK it would not hit. 15:27:27 sc68cal: I'll have to double check though. 15:27:30 On a physical network, the default is any device sending RA is allowed to do so. If you want, you can add a policy to network gear to disallow certain ports from allowing RA. 15:27:40 SridharG: Yeha, that's a tricky bit too 15:27:59 rackertom: yes, that's covered in RFC 7381 15:28:17 but they also discuss filtering ICMPv6 packets for security purposes 15:28:26 So, companies like Arista, Cumulus, etc. will eventually file a bug saying the neutron layer doesn't allow ICMP type 134 by default and we'll be back to this conversation. 15:28:39 OUTBOUND 15:28:45 not inbound 15:29:00 Yeah, I understand. 15:29:10 Thinking that in a true provider net environ, the provider would run some kind of RA guard somewhere if it's done properly. 15:29:21 Several of these companies have virtual devices 15:30:00 true, but we would assume they have control plane pieces that would handle the filtering 15:30:10 to make those virtual devices work properly 15:31:05 the question is do we make a secure default and make the NFV case do some work to open it up a bit? or leave it less secure by default 15:31:15 I've not read RFC 7381, so I should do that before continuing. :D 15:31:44 RFC 4890 goes into more depth about the issue 15:32:20 having had to track-down someone sending-out RAs from their laptop and becoming one of the default routers for the site, i would err on the side of caution when allowing RAs in 15:32:39 haleyb: true, which is what we do today 15:32:54 but someone brought up a good point, which is if there are non-neutron devices on the same L2 segment 15:33:18 and they don't get the same filtering rules that the openstack side gets, when filtering inbound RAs 15:35:41 sc68cal: That's why I brought up making the physical and virtual worlds act the same. So there's a consistent administrative behavior on both. The default in physical world is open, but it's suggested you filter which ports you allow RA from. I suggest we do the same, but I'll wait to die on that hill until I've read the two RFC you've linked. 15:35:44 i guess i don't have the context of the bug to further the discussion... 15:36:25 haleyb: https://bugs.launchpad.net/neutron/+bug/1372882 15:36:26 Launchpad bug 1372882 in neutron "Neutron should drop certain outbound ICMPv6 packets" [Undecided,In progress] - Assigned to Sridhar Gaddam (sridhargaddam) 15:37:06 rackertom: I kind of agree with you 15:37:11 sc68cal: thanks, i'll take a look 15:37:16 rackertom: fair enough - it's a policy question and everyone is going to have a different policy for their network 15:37:42 haleyb: As the bug reads, the suggestion is to prevent guests from doing things like RA so they don't accidentally become routers. I can easily foresee someone accidentally setting up a linux host, enabling routing, and all of a sudden it starts receiving traffic from all kinds of devices on the physical and virtual network 15:38:25 To clarify, it'd only be able to get physical nodes who don't filter ICMPv6 packets who'd get re-routed 15:38:40 sc68cal: Yeah, agreed. And I understand your argument that perhaps we could be better network citizens by doing "The Right Thing" (tm) 15:39:54 My secret hope is that nobody is running a L2 segment that has both openstack and non-openstack ports 15:40:16 We can all dream. :D 15:40:20 :) 15:41:30 Any other bugs? otherwise I'll turn it over to open discussion 15:42:13 #topic open discussion 15:43:39 sc68cal: I hope I'm not coming across as a jerk. I certainly don't want to. 15:43:59 rackertom: Nah, you're not. If anything it's probably me, just because we've had a lot of pain around ICMPv6 filtering 15:44:03 I can just imagine what will happen a year from now when a network engineer comes steaming in here, annoyed at us for filtering by default. :D 15:44:18 I can only imagine. 15:45:28 Some network engineers are mad at us for allowing ICMPv6 at all :) - they want to force static allocations 15:46:06 through config-drive to the guests .... 15:46:49 Mmmm, that's one approach. 15:48:48 I also wish we could get someone to work on OVS, for support for tunneling over ipv6 15:49:17 sc68cal: vxlan over ipv6? 15:49:23 yep 15:49:28 for gre and vxlan - I think right now the only thing that works for L2 tenant isolation w/ IPv6 networking is VLANs? 15:49:57 we need to get some info from the user survey about ipv6 deployments 15:50:49 well, i have noticed it, and it should be fixed, and i am a kernel developer too :) I need to clone myself 15:51:48 My C is .... not really something I'd like to share with the group, so it'd be better if I didn't work on it 15:53:16 unless we want to try and create L3 traffic isolation for IPv6 ... 15:54:23 sc68cal: i was more thinking an ipv6-only-ish deployment 15:57:31 Ok, well until next week, thank you everyone for joining. 15:57:39 rackertom: don't be a stranger! 15:58:15 I often silently attend these meetings. I'm new to contributing in any way, and IPv6 is kind of an interest of mine. 15:58:34 But I have some skewed views of its usage due to working for a DNS provider for a while. :D 15:58:41 :) 15:59:00 take care everyone 15:59:02 #endmeeting