Re: [openstack-dev] [Neutron][IPv6] Neutron Routers and LLAs
I'm going to bump this thread based on some of the discussions we had today during the IRC meeting. I also added a comment to a review on the tempest side after our discussion (I made some adjustments to my comment for context and clarification) https://review.openstack.org/#/c/93400/ >> The only time that the gateway will be specified >> in advance for a V6 subnet is if you are using an external device or >> something not orchestrated by OpenStack. >> >> We discussed this today, in the meeting, at 14:24:09 >> >> http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-05-27-14.01.log.html >> >> Basically, if you are going to create a router in Neutron for a v6 >> subnet, we plan on having the router attachment step populate the >> gateway attribute of the subnet, since we will be wiring it up and >> will have a LLA for the router. For now, we are not addressing the problem of multiple routers attached to different subnets - since we need to do some research on that. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Neutron Routers and LLAs
Robert, I have plan to file a BP to add egress rule to stop RA sending from VM. However, we will still need rules to dropped rogue RA for provider network RA, right? There is no other ways we can tell which RA is legitimate from OpenStack's perspective except using the LLA gateway provided by network admin. Thoughts? Xuhan On Thu, May 8, 2014 at 8:22 PM, Robert Li (baoli) wrote: > Hi Xuhan, > > I agree that such subnet shouldn’t be allowed to be added in a neutron > router. > > However, I have some reservations in creating a subnet with an external > LLA gateway address. First of all, it seems that the sole purpose of > providing the gateway IP is to install an RA rule to permit RAs from that > gateway. Secondly, what if the gateway IP needs to be changed? Would that > incur updates in the neutron subnets that refer to it? I think that we need > a better strategy for RA spoofing. Currently, rogue RAs are dropped at the > receiving end. Would it be better to stop them at the source and to allow > RAs being SENT from the legitimate sources only? > > thanks, > Robert > > > > On 4/25/14, 5:46 AM, "Xuhan Peng" wrote: > > 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-). 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) 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" >> 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-ve
Re: [openstack-dev] [Neutron][IPv6] Neutron Routers and LLAs
Hi Xuhan,
I agree that such subnet shouldn’t be allowed to be added in a neutron router.
However, I have some reservations in creating a subnet with an external LLA
gateway address. First of all, it seems that the sole purpose of providing the
gateway IP is to install an RA rule to permit RAs from that gateway. Secondly,
what if the gateway IP needs to be changed? Would that incur updates in the
neutron subnets that refer to it? I think that we need a better strategy for RA
spoofing. Currently, rogue RAs are dropped at the receiving end. Would it be
better to stop them at the source and to allow RAs being SENT from the
legitimate sources only?
thanks,
Robert
On 4/25/14, 5:46 AM, "Xuhan Peng"
mailto:pengxu...@gmail.com>> wrote:
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-). 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)
mailto:ba...@cisco.com>> 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"
mailto:sean_colli...@cable.comcast.com>>
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 :::/64
>>>
>>> Created a new subnet:
>>>
>>>+--+
>>>+
>>> | Field | Value |
>>>
>>>+--+
>>>+
>>> | allocation_pools | {"start": ":::1", "end":
>>>"::::::fffe"} | | cidr | :::/64 | |
>>>dns_nameservers | | | enable_dhcp | True | | gateway_ip | fe80::2001:1
>>>| | host_routes | | |
Re: [openstack-dev] [Neutron][IPv6] Neutron Routers and LLAs
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-). 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) 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"
> 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 :::/64
> >>>
> >>> Created a new subnet:
> >>>
> >>>+--+
> >>>+
> >>> | Field | Value |
> >>>
> >>>+--+
> >>>+
> >>> | allocation_pools | {"start": ":::1", "end":
> >>>"::::::fffe"} | | cidr | :::/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
> >>> |
> >>>+--+-+--
> >>>-
Re: [openstack-dev] [Neutron][IPv6] Neutron Routers and LLAs
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"
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 :::/64
>>>
>>> Created a new subnet:
>>>
>>>+--+
>>>+
>>> | Field | Value |
>>>
>>>+--+
>>>+
>>> | allocation_pools | {"start": ":::1", "end":
>>>"::::::fffe"} | | cidr | :::/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 whe
[openstack-dev] [Neutron][IPv6] Neutron Routers and LLAs
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.
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 :::/64
>>
>> Created a new subnet:
>> +--++
>> | Field | Value |
>> +--++
>> | allocation_pools | {"start": ":::1", "end":
>> "::::::fffe"} | | cidr | :::/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.
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.2014-03-18-14.02.log.html
[3]: https://review.openstack.org/#/c/76125/
--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
