Re: [openstack-dev] [Neutron][IPv6] BP:Store both IPv6 LLA and GUA address on router interface port
Hi Xuhan, Thank you for your summary. see comments inline. --Robert On 2/27/14 12:49 AM, "Xuhan Peng" mailto:pengxu...@gmail.com>> wrote: As the follow up action of IPv6 sub-team meeting [1], I created a new blueprint [2] to store both IPv6 LLA and GUA address on router interface port. Here is what it's about: Based on the two modes (ipv6-ra-mode and ipv6-address-mode) design[3], RA can be sent from both openstack controlled dnsmasq or existing devices. RA From dnsmasq: gateway ip that dnsmasq binds into should be link local address (LLA) according to [4]. This means we need to pass the LLA of the created router internal port (i.e. qr-) to dnsmasq spawned by openstack dhcp agent. In the mean while, we need to assign an GUA to the created router port so that the traffic from external network can be routed back using the GUA of the router port as the next hop into the internal subnet. Therefore, we will need some change to the current logic to leverage both LLA and GUA on router port. [Robert]: in this case, a LLA address is automatically created based on the gateway port's MAC address (EUI64 format). If it's determined that the gateway port is enabled with IPv6 (due to the two modes), then an RA rule can be installed based on the gateway port's automatic LLA. if a service VM is running on the same subnet that supports IPv6 (either by RA or DHCPv6), then the service VM is attached to a neutron port on the same subnet (the gateway port). In this case, the automatic LLA on that port can be used to install the RA Rule. This is actually the same as in the dnsmasq case: use the gateway port's automatic LLA. RA from existing device on the same link which is not controlled by openstack: dnsmasq will not send RA in this case. RA is sending from subnet's gateway address which should also be LLA according to [4]. Allowing subnet's gateway IP to be LLA is enough in this case. Current code works when force_gateway_on_subnet = False. [Robert] if it's a provider network, the gateway already exists. I believe that the behavior of the —gateway option in the subnet API is to indicate the gateway's true IP address and install default route. In the IPv6 case, however, due to the existence of RA, the gateway doesn't have to be provided. In this case, a neutron gateway port doesn't have to be created, either. Installing a RA rule to prevent RA from malicious source should be done explicitly. A couple of methods may be considered. For example, an option such as —alow-ra can be introduced in the subnet API, or the security group rule can be enhanced to allow specification of message type so that a RA rule can be incorporated. In any case, I don't believe that the gateway behavior should be modified. In addition, I don't think that this functionality (IPv6 RA rule) has to be provided right now, but can be introduced when it's completely sorted out. The above is just my two cents. thanks. RA from router gateway port (i.e. qg-): the LLA of the gateway port (qg-) should be set as the gateway of tenant subnet to get the RA from that. This could be potentially calculated by [5] or by other methods in the future considering privacy extension. However, this will make the tenant network gateway port qr- useless. Therefore, we also need code change to current router interface attach logic. If you have any comments on this, please let me know. [1] http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-02-25-14.02.html [2] https://blueprints.launchpad.net/neutron/+spec/ipv6-lla-gua-router-interface [3] https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes [4] http://tools.ietf.org/html/rfc4861 [5] https://review.openstack.org/#/c/56184/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] BP:Store both IPv6 LLA and GUA address on router interface port
Robert, Thanks for your comments! See my replies inline. On Thu, Feb 27, 2014 at 9:56 PM, Robert Li (baoli) wrote: > Hi Xuhan, > > Thank you for your summary. see comments inline. > > --Robert > > On 2/27/14 12:49 AM, "Xuhan Peng" wrote: > >As the follow up action of IPv6 sub-team meeting [1], I created a new > blueprint [2] to store both IPv6 LLA and GUA address on router interface > port. > > Here is what it's about: > > Based on the two modes (ipv6-ra-mode and ipv6-address-mode) design[3], > RA can be sent from both openstack controlled dnsmasq or existing devices. > > RA From dnsmasq: gateway ip that dnsmasq binds into should be link local > address (LLA) according to [4]. This means we need to pass the LLA of the > created router internal port (i.e. qr-) to dnsmasq spawned by openstack > dhcp agent. In the mean while, we need to assign an GUA to the created > router port so that the traffic from external network can be routed back > using the GUA of the router port as the next hop into the internal subnet. > Therefore, we will need some change to the current logic to leverage both > LLA and GUA on router port. > > > [Robert]: in this case, a LLA address is automatically created based on > the gateway port's MAC address (EUI64 format). If it's determined that the > gateway port is enabled with IPv6 (due to the two modes), then an RA rule > can be installed based on the gateway port's automatic LLA. > if a service VM is running on the same subnet that supports IPv6 (either > by RA or DHCPv6), then the service VM is attached to a neutron port on the > same subnet (the gateway port). In this case, the automatic LLA on that > port can be used to install the RA Rule. This is actually the same as in > the dnsmasq case: use the gateway port's automatic LLA. > > [Xuhan] I agree there is no need to create another LLA for gateway port in this case since one is automatically created. We can probably use the calculation method introduced by this patch ( https://review.openstack.org/#/c/56184/) to accomplish this, and create a RA rule based on this address. As you pointed out in my code review, the ICMPv6 type filter is not supported by current security group. We will need a new blueprint to enable this. I will try to create one soon. > > RA from existing device on the same link which is not controlled by > openstack: dnsmasq will not send RA in this case. RA is sending from > subnet's gateway address which should also be LLA according to [4]. > Allowing subnet's gateway IP to be LLA is enough in this case. Current code > works when force_gateway_on_subnet = False. > > > [Robert] > if it's a provider network, the gateway already exists. I believe that the > behavior of the --gateway option in the subnet API is to indicate the > gateway's true IP address and install default route. In the IPv6 case, > however, due to the existence of RA, the gateway doesn't have to be > provided. In this case, a neutron gateway port doesn't have to be created, > either. Installing a RA rule to prevent RA from malicious source should be > done explicitly. A couple of methods may be considered. For example, an > option such as --alow-ra can be introduced in the subnet API, or the > security group rule can be enhanced to allow specification of message type > so that a RA rule can be incorporated. > [Xuhan] This is a problem that we may not be able to solve in Icehouse considering the time left. However, I think the gateway port is not created until we attach the subnet on the router. Therefore, for a workaround in Icehouse, we can allow LLA as the gateway IP passed to subnet creation, so RA from the provider network gateway LLA can also be allowed. The logic to create RA rule can looks like this: 1. if gateway ip of a subnet is GUA (when dnsmasq or a service VM is sending RA): calculate the gateway port's LLA based on port's MAC address, then allow RA from this LLA. 2. if gateway ip of a subnet is LLA (for provider network existing gateway) allow RA from this LLA. In next release, we can evaluate how to allow RA from existing gateway in a better way. Thoughts? > In any case, I don't believe that the gateway behavior should be > modified. In addition, I don't think that this functionality (IPv6 RA rule) > has to be provided right now, but can be introduced when it's completely > sorted out. > > The above is just my two cents. > > thanks. > > > > > RA from router gateway port (i.e. qg-): the LLA of the gateway port > (qg-) should be set as the gateway of tenant subnet to get the RA from > that. This could be potentially calculated by [5] or by other methods in > the future considering privacy extension. However, this will make the > tenant network gateway port qr- useless. Therefore, we also need code > change to current router interface attach logic. > If you have any comments on this, please let me know. > > [1] > http://eavesdrop.openstack.org/meetings
Re: [openstack-dev] [Neutron][IPv6] BP:Store both IPv6 LLA and GUA address on router interface port
Hi Yuhan Sorry I am slow to respond, but I was catching up on some emails and found this one from you. Regarding your comments on the RA from the router gateway port... I disagree that the LLA for the qg- interface is (or should be) the gateway for the tenant's subnet. On the contrary, it should be the LLA of the qr- to which the dnsmasq binds [2]. Using [1] as a starting point, packets arriving on the qr- interface are routed across (via linux) in the qrouter-namespace, taking the default route (gateway-ip) as specified in [1] to unknown destinations. In a future release, we may need to consider implementing support for accepting RA from service providers' upstream routers on the qg- interface, but whether we allow a SLAAC address on the external gateway port needs further discussion (perhaps a topic for the IPv6 sub-team IRC). SLAAC requires a /64 subnet which might be considered a bit of overkill for what's typically a point-to-point connection. Let's see about adding it to the topics to discuss. Cheers, Randy [1] https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port [2] https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace On Thu, Feb 27, 2014 at 12:49 AM, Xuhan Peng wrote: > As the follow up action of IPv6 sub-team meeting [1], I created a new > blueprint [2] to store both IPv6 LLA and GUA address on router interface > port. > > Here is what it's about: > > Based on the two modes (ipv6-ra-mode and ipv6-address-mode) design[3], RA > can be sent from both openstack controlled dnsmasq or existing devices. > > RA From dnsmasq: gateway ip that dnsmasq binds into should be link local > address (LLA) according to [4]. This means we need to pass the LLA of the > created router internal port (i.e. qr-) to dnsmasq spawned by openstack > dhcp agent. In the mean while, we need to assign an GUA to the created > router port so that the traffic from external network can be routed back > using the GUA of the router port as the next hop into the internal subnet. > Therefore, we will need some change to the current logic to leverage both > LLA and GUA on router port. > > RA from existing device on the same link which is not controlled by > openstack: dnsmasq will not send RA in this case. RA is sending from > subnet's gateway address which should also be LLA according to [4]. > Allowing subnet's gateway IP to be LLA is enough in this case. Current code > works when force_gateway_on_subnet = False. > > RA from router gateway port (i.e. qg-): the LLA of the gateway port > (qg-) should be set as the gateway of tenant subnet to get the RA from > that. This could be potentially calculated by [5] or by other methods in > the future considering privacy extension. However, this will make the > tenant network gateway port qr- useless. Therefore, we also need code > change to current router interface attach logic. > If you have any comments on this, please let me know. > > [1] > http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-02-25-14.02.html > [2] > https://blueprints.launchpad.net/neutron/+spec/ipv6-lla-gua-router-interface > [3] https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes > [4] http://tools.ietf.org/html/rfc4861 > [5] https://review.openstack.org/#/c/56184/ > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] BP:Store both IPv6 LLA and GUA address on router interface port
Randy, I may need some time to review your latest code change to the blueprint you mentioned. But I think we can discuss this in the coming IPv6 sub team meeting. Xuhan On Mon, Mar 3, 2014 at 11:20 AM, Randy Tuttle wrote: > Hi Yuhan > > Sorry I am slow to respond, but I was catching up on some emails and found > this one from you. Regarding your comments on the RA from the router > gateway port... > > I disagree that the LLA for the qg- interface is (or should be) the > gateway for the tenant's subnet. On the contrary, it should be the LLA of > the qr- to which the dnsmasq binds [2]. Using [1] as a starting point, > packets arriving on the qr- interface are routed across (via linux) in > the qrouter-namespace, taking the default route (gateway-ip) as specified > in [1] to unknown destinations. > > In a future release, we may need to consider implementing support for > accepting RA from service providers' upstream routers on the qg- > interface, but whether we allow a SLAAC address on the external gateway > port needs further discussion (perhaps a topic for the IPv6 sub-team IRC). > SLAAC requires a /64 subnet which might be considered a bit of overkill for > what's typically a point-to-point connection. Let's see about adding it to > the topics to discuss. > > Cheers, > Randy > > [1] > https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port > [2] > https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace > > > > On Thu, Feb 27, 2014 at 12:49 AM, Xuhan Peng wrote: > >> As the follow up action of IPv6 sub-team meeting [1], I created a new >> blueprint [2] to store both IPv6 LLA and GUA address on router interface >> port. >> >> Here is what it's about: >> >> Based on the two modes (ipv6-ra-mode and ipv6-address-mode) design[3], RA >> can be sent from both openstack controlled dnsmasq or existing devices. >> >> RA From dnsmasq: gateway ip that dnsmasq binds into should be link local >> address (LLA) according to [4]. This means we need to pass the LLA of the >> created router internal port (i.e. qr-) to dnsmasq spawned by openstack >> dhcp agent. In the mean while, we need to assign an GUA to the created >> router port so that the traffic from external network can be routed back >> using the GUA of the router port as the next hop into the internal subnet. >> Therefore, we will need some change to the current logic to leverage both >> LLA and GUA on router port. >> >> RA from existing device on the same link which is not controlled by >> openstack: dnsmasq will not send RA in this case. RA is sending from >> subnet's gateway address which should also be LLA according to [4]. >> Allowing subnet's gateway IP to be LLA is enough in this case. Current code >> works when force_gateway_on_subnet = False. >> >> RA from router gateway port (i.e. qg-): the LLA of the gateway port >> (qg-) should be set as the gateway of tenant subnet to get the RA from >> that. This could be potentially calculated by [5] or by other methods in >> the future considering privacy extension. However, this will make the >> tenant network gateway port qr- useless. Therefore, we also need code >> change to current router interface attach logic. >> If you have any comments on this, please let me know. >> >> [1] >> http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-02-25-14.02.html >> [2] >> https://blueprints.launchpad.net/neutron/+spec/ipv6-lla-gua-router-interface >> [3] https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes >> [4] http://tools.ietf.org/html/rfc4861 >> [5] https://review.openstack.org/#/c/56184/ >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
