15:00:10 <sc68cal> #startmeeting neutron_ipv6
15:00:11 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:15 <openstack> The meeting name has been set to 'neutron_ipv6'
15:00:16 <ihrachyshka> o/
15:00:33 <dane_leblanc> o/
15:01:06 <sc68cal> topic #code reviews
15:01:12 <sc68cal> doh
15:01:16 <sc68cal> #topic code reviews
15:01:40 <sc68cal> If anyone has any reviews they'd like to discuss, the floor is yours
15:02:46 <john-davidge> We've pushed a WIP review for the Prefix Delegation work today https://review.openstack.org/#/c/158697/
15:02:53 <john-davidge> general feedback would be much appreciated :)
15:03:38 <sc68cal> excellent, i'll add it to my queue
15:03:45 <john-davidge> thanks
15:04:16 <dboik> I have a patch up for https://bugs.launchpad.net/neutron/+bug/1424760
15:04:18 <openstack> 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 <dboik> https://review.openstack.org/#/c/158508/
15:04:37 <dboik> would appreciate any comments
15:04:51 <dane_leblanc> dboik: will review that today
15:04:58 <sc68cal> ^ +1
15:05:04 <dboik> thanks
15:07:09 <sc68cal> Excellent - I'll be trying to play catch-up later this week on my reviews :)
15:08:21 <sc68cal> #topic bugs
15:08:36 <sc68cal> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6&orderby=-id&start=0 IPv6 tagged bugs
15:09:59 <sc68cal> Any new bugs that anyone wants to discuss?
15:10:21 <dane_leblanc> For 1357068...
15:10:33 <dane_leblanc> #link https://review.openstack.org/#/c/114437/
15:11:03 <dane_leblanc> I was going to push up a patch set that reverts to xuhanp's original patchset (version 1)
15:11:32 <dane_leblanc> With an explanation in the commit comment about why we don't think an arping equivalent is needed for IPv6
15:12:12 <dane_leblanc> I think we're covered for IPv6 with ND, RA, and duplicate address detection
15:12:43 <SridharG> dane_leblanc: +1
15:12:44 <sc68cal> 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 <dane_leblanc> If anyone thinks we need an arping equivalent for some feature (e.g. for HA router)...
15:12:52 <dane_leblanc> Then we can file a new bug
15:13:11 <rackertom> dane_leblanc: ++
15:13:34 <sc68cal> found it - https://review.openstack.org/#/c/154644/
15:14:15 <sc68cal> ah, he abandoned it in favor of mine, which i abandoned in favor of dane_leblanc 's
15:14:36 <rackertom> That error message could be better. :D
15:14:43 <dane_leblanc> I think xuhanp's original fix of just checking for IPv4 in the gratuitous arp method is the way to go.
15:14:50 <sc68cal> dane_leblanc: Agreed
15:15:18 <haleyb> dane_leblanc: but i thought your other patch fixed things as well, right?
15:15:27 <ihrachyshka> dane_leblanc, maybe not just commit message, but also code comment
15:15:37 <dane_leblanc> haleyb: This is a  real bug, should be fixed outside of my blueprint patches
15:16:30 <dane_leblanc> 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 <SridharG> Reg https://bugs.launchpad.net/neutron/+bug/1372882, appreciate your comments if there are any alternate mechanisms to address it.
15:17:44 <openstack> Launchpad bug 1372882 in neutron "Neutron should drop certain outbound ICMPv6 packets" [Undecided,In progress] - Assigned to Sridhar Gaddam (sridhargaddam)
15:18:02 <haleyb> dane_leblanc: so just stop the error for now, but your blueprint change fill fix it correctly?
15:18:59 <dane_leblanc> haleyb: My blueprint will use (depend on) this fix
15:19:52 <dane_leblanc> haleyb: I'm proposing that the fix _is_ to stop the error, assumption is we don't need arping for IPv6
15:20:50 <sc68cal> 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 <sc68cal> from a neutron port
15:21:14 <SridharG> yes sc68cal I agree.
15:21:14 <sc68cal> in some instances
15:21:33 <haleyb> dane_leblanc: i'll just leave further comments for the patch
15:21:53 <SridharG> So, I'll go ahead and abandon my patch.
15:21:56 <dane_leblanc> haleyb: Great, thanks!
15:23:06 <sc68cal> SridharG: ok. We'll have to try and talk with robert at some point and think up how to proceed
15:23:49 <SridharG> ok sc68cal. But what you said is also true, NFV would have some usecases where they do not want this fix.
15:24:21 <sc68cal> 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 <sc68cal> when they need it
15:24:58 <rackertom> 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 <sc68cal> rackertom: Outbound, from a VM
15:25:15 <rackertom> IMO, this is a bad idea.
15:25:31 <rackertom> I can think of several reasons why I'd want a VM to RA to a net
15:25:53 <sc68cal> rackertom: Yes, but should we allow it by default, or require explicit rule
15:26:06 <sc68cal> I think a secure default is probably preferred.
15:26:12 <rackertom> I think we should make no rules about it. Allow it by default.
15:26:28 <rackertom> Make it works as close to the real world as possible
15:27:06 <SridharG> 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 <SridharG> sc68cal: I'll have to double check though.
15:27:30 <rackertom> 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 <sc68cal> SridharG: Yeha, that's a tricky bit too
15:27:59 <sc68cal> rackertom: yes, that's covered in RFC 7381
15:28:17 <sc68cal> but they also discuss filtering ICMPv6 packets for security purposes
15:28:26 <rackertom> 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 <sc68cal> OUTBOUND
15:28:45 <sc68cal> not inbound
15:29:00 <rackertom> Yeah, I understand.
15:29:10 <baoli> 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 <rackertom> Several of these companies have virtual devices
15:30:00 <sc68cal> true, but we would assume they have control plane pieces that would handle the filtering
15:30:10 <sc68cal> to make those virtual devices work properly
15:31:05 <sc68cal> 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 <rackertom> I've not read RFC 7381, so I should do that before continuing. :D
15:31:44 <sc68cal> RFC 4890 goes into more depth about the issue
15:32:20 <haleyb> 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 <sc68cal> haleyb: true, which is what we do today
15:32:54 <sc68cal> but someone brought up a good point, which is if there are non-neutron devices on the same L2 segment
15:33:18 <sc68cal> and they don't get the same filtering rules that the openstack side gets, when filtering inbound RAs
15:35:41 <rackertom> 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 <haleyb> i guess i don't have the context of the bug to further the discussion...
15:36:25 <sc68cal> haleyb: https://bugs.launchpad.net/neutron/+bug/1372882
15:36:26 <openstack> Launchpad bug 1372882 in neutron "Neutron should drop certain outbound ICMPv6 packets" [Undecided,In progress] - Assigned to Sridhar Gaddam (sridhargaddam)
15:37:06 <baoli> rackertom: I kind of agree with you
15:37:11 <haleyb> sc68cal: thanks, i'll take a look
15:37:16 <sc68cal> rackertom: fair enough - it's a policy question and everyone is going to have a different policy for their network
15:37:42 <rackertom> 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 <sc68cal> 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 <rackertom> 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 <sc68cal> My secret hope is that nobody is running a L2 segment that has both openstack and non-openstack ports
15:40:16 <rackertom> We can all dream. :D
15:40:20 <sc68cal> :)
15:41:30 <sc68cal> Any other bugs? otherwise I'll turn it over to open discussion
15:42:13 <sc68cal> #topic open discussion
15:43:39 <rackertom> sc68cal: I hope I'm not coming across as a jerk. I certainly don't want to.
15:43:59 <sc68cal> 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 <rackertom> 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 <rackertom> I can only imagine.
15:45:28 <sc68cal> Some network engineers are mad at us for allowing ICMPv6 at all :) - they want to force static allocations
15:46:06 <sc68cal> through config-drive to the guests ....
15:46:49 <rackertom> Mmmm, that's one approach.
15:48:48 <sc68cal> I also wish we could get someone to work on OVS, for support for tunneling over ipv6
15:49:17 <haleyb> sc68cal: vxlan over ipv6?
15:49:23 <sc68cal> yep
15:49:28 <sc68cal> 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 <sc68cal> we need to get some info from the user survey about ipv6 deployments
15:50:49 <haleyb> 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 <sc68cal> 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 <sc68cal> unless we want to try and create L3 traffic isolation for IPv6 ...
15:54:23 <haleyb> sc68cal: i was more thinking an ipv6-only-ish deployment
15:57:31 <sc68cal> Ok, well until next week, thank you everyone for joining.
15:57:39 <sc68cal> rackertom: don't be a stranger!
15:58:15 <rackertom> 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 <rackertom> But I have some skewed views of its usage due to working for a DNS provider for a while. :D
15:58:41 <sc68cal> :)
15:59:00 <sc68cal> take care everyone
15:59:02 <sc68cal> #endmeeting