Sean and Robert, Sorry for replying this late, but after giving this a second thought, I think it makes sense to not allow a subnet with a LLA gateway IP address to be attached to a neutron router for the following reasons:
1. A subnet with LLA address gateway specified is only used to receive RA from provider router. I could not think of any other use case that a user want to specify LLA address gateway for an Neutron subnet. 2. Attach a subnet with LLA (or even any address outside subnet's cidr) will cause the port have two LLA (or another address outside subnet's cidr) on the subnet gateway port (qr-XXXX). This will confuse dnsmasq about binding with which address. 3. For allowing RA sending from dnsmasq on gateway port, we can use ip command to get the LLA. Currently I use calculation method to get the source address, but I will improve it to use ip command to make sure the source IP is right. Thoughts? If we all agree, I will open a bug to disallow subnet with gateway outside CIDR be attached to a router. Xuhan On Wed, Mar 26, 2014 at 9:52 PM, Robert Li (baoli) <[email protected]> wrote: > Hi Sean, > > Unless I have missed something, this is my thinking: > -- I understand that the goal is to allow RAs from designated sources > only. > -- initially, xuhanp posted a diff for > https://review.openstack.org/#/c/72252. And my comment was that subnet > that was created with gateway ip not on the same subnet can't be added > into the neutron router. > -- as a result, https://review.openstack.org/#/c/76125/ was posted to > address that issue. With that diff, LLA would be allowed. But a > consequence of that is a gateway port would end up having two LLAs: one > that is automatically generated, the other from the subnet gateway IP. > -- with xuhanp's new diff for https://review.openstack.org/#/c/72252, if > openstack native RA is enabled, then the automatically generated LLA will > be used; and if it's not enabled, it will use the external gateway's LLA. > And the diff seems to indicate this LLA comes from the subnet's gateway > IP. > -- Therefore, the change of https://review.openstack.org/#/c/76125/ > seems to be able to add the gateway IP as an external gateway. > -- Thus, my question is: should such a subnet be allowed to add in a > router? And if it should, what would the semantics be? If not, proper > error should be provided to the user. I'm also trying to figure out the > reason that such a subnet needs to be created in neutron (other than > creating L2 ports for VMs). > > -- Another thought is that if the RA is coming from the provider net, then > the provider net should have installed mechanisms to prevent rogue RAs > from entering the network. There are a few RFCs that address the rogue RA > issue. > > see inline as well. > > I hope that I didn't confuse you guys. > > Thanks, > Robert > > > On 3/25/14 2:18 PM, "Collins, Sean" <[email protected]> > wrote: > > >During the review[0] of the patch that only allows RAs from known > >addresses, Robert Li brought up a bug in Neutron, where a > >IPv6 Subnet could be created, with a link local address for the gateway, > >that would fail to create the Neutron router because the IP address that > >the router's port would be assigned, was a link local > >address that was not on the subnet. > > > >This may or may have been run before force_gateway_on_subnet flag was > >introduced. Robert - if you can give us what version of Neutron you were > >running that would be helpful. > > [Robert] I'm using the latest > > > > > >Here's the full text of what Robert posted in the review, which shows > >the bug, which was later filed[1]. > > > >>> This is what I've tried, creating a subnet with a LLA gateway address: > > > >>> neutron subnet-create --ip-version 6 --name myipv6sub --gateway > >>>fe80::2001:1 mynet 2222:3333::/64 > >>> > >>> Created a new subnet: > >>> > >>>+------------------+---------------------------------------------------- > >>>----------------+ > >>> | Field | Value | > >>> > >>>+------------------+---------------------------------------------------- > >>>----------------+ > >>> | allocation_pools | {"start": "2222:3333::1", "end": > >>>"2222:3333::ffff:ffff:ffff:fffe"} | | cidr | 2222:3333::/64 | | > >>>dns_nameservers | | | enable_dhcp | True | | gateway_ip | fe80::2001:1 > >>>| | host_routes | | | id | a1513aa7-fb19-4b87-9ce6-25fd238ce2fb | | > >>>ip_version | 6 | | name | myipv6sub | | network_id | > >>>9c25c905-da45-4f97-b394-7299ec586cff | | tenant_id | > >>>fa96d90f267b4a93a5198c46fc13abd9 | > >>> > >>>+------------------+---------------------------------------------------- > >>>----------------+ > >>> > >>> openstack@devstack-16:~/devstack$ neutron router-list > > > >>> > >>>+--------------------------------------+---------+---------------------- > >>>-------------------------------------------------------+ > >>> | id | name | external_gateway_info > >>> | > >>>+--------------------------------------+---------+---------------------- > >>>-------------------------------------------------------+ > >>> | 7cf084b4-fafd-4da2-9b15-0d25a3e27e67 | router1 | {"network_id": > >>>"02673c3c-35c3-40a9-a5c2-9e5c093aca48", "enable_snat": true} > >>> | > >>> > >>>+--------------------------------------+---------+---------------------- > >>>-------------------------------------------------------+ > >>> > >>> openstack@devstack-16:~/devstack$ neutron router-interface-add > >>>7cf084b4-fafd-4da2-9b15-0d25a3e27e67 myipv6sub > >>> > >>> 400-{u'NeutronError': {u'message': u'Invalid input for operation: IP > >>>address fe80::2001:1 is not a valid IP for the defined subnet.', > >>>u'type': u'InvalidInput', u'detail': u''}} > >>> > > > >During last week's meeting, we had a bit of confusion near the end of the > >meeting[2] about the following bug, and the fix[3]. > > > >If I am not mistaken - the fix is so that when you create a v6 Subnet > >with a link local address, then create a Neutron router to serve as the > >gateway for that subnet - the operation will successfully complete and a > >router will be created. > > > >We may need to take a look at the code that create a router - to ensure > >that only one gateway port is created, and that the link local address > >from the subnet's 'gateway' attribute is used as the address. > > [Robert] We are discussing what's going to happen when such a subnet is > added into a router. The neutron router may have already existed. > > > > > >This is at least my understanding of the problem as it stands today - > >and that this bug and fix does not involve any external gateways or > >physical devices that Neutron does not control - this is exclusively > >about Neutron routers. > > > > > >[0]: https://review.openstack.org/#/c/72252/ > > > >[1]: https://bugs.launchpad.net/neutron/+bug/1284518 > > > >[2]: > > > http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.201 > >4-03-18-14.02.log.html > > > >[3]: https://review.openstack.org/#/c/76125/ > > > > > >-- > >Sean M. Collins > >_______________________________________________ > >OpenStack-dev mailing list > >[email protected] > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
