Hi, Anthony: Thanks a lot for the quick response! I didn't think about the provider network scenarios. I feel grateful you brought it up. I will add provider network to the chart.
Here is my understanding: Private network: VM is attached to a subnet with NO default gateway at all, i.e. completely isolated Provider network: VM is attached to a physical network with a physical router acting as gateway, which is outside of OpenStack’s control From implementation perspective, both cases are identical since Openstack won’t see the gateway port on neutron router. Hence, Openstack should not be responsible to send IPv6 RA. Being said, the code I am developing will perform a check: 1) If an IPv6 subnet does NOT have gateway port on neutron router (i.e. either private or provider network), then only the first two highlighted combinations are considered as valid. Because the rest five options requires RA announcement. 2) If an IPv6 subnet does have gateway port on neutron router (i.e public network), then only the last five highlighted combinations are considered as valid. Because the first two options turn off RA announcement, which makes existing gateway port on neutron router useless. Please keep me honest here……. Thanks again! Shixiong On Feb 1, 2014, at 7:16 PM, Veiga, Anthony <anthony_ve...@cable.comcast.com> wrote: > See Inline > >> Hi, guys: >> >> While I am implementing the code to support IPv6 two mode keywords, a >> question came to my mind and I would like to see your opinions. >> >> If you look at the table below, you will notice that the first two >> combinations highlighted with red underline have “ipv6_ra_mode” set to OFF. >> I think these two options only make sense if the tenant subnet is PRIVATE, >> i.e. the subnet is not attached to any router. In this case, OpenStack >> should NOT send RA; On the flip side, if the subset is PUBLIC, i.e. the >> subnet is attached to a router, then the corresopnding port on the router >> should be THE default gateway for the tenant subnet, hence, need to handle >> RA announcement. > > > These options also make sense if you consider the first column of your chart. > In both of these cases, they are listed as having an external router. This > is REQUIRED for a provider network where the routed is not owned by > OpenStack. Please do NOT consider these private-only. > >> >> In summary, I believe it doesn’t make sense to allow OpenStack to create >> default gateway for a tenant network, but suppress RA from the default >> gateway port on Neutron router. If so, the default gateway port is pretty >> much useless. This is the way I am coding now. However, I might overlook >> some scenarios. Please chime in if you see any use cases beyond what this >> table covers. > > > If my upstream router is on-link, then I need to set it as the gateway (for > security purposes, we need to be able to filter RAs from rogue agents). > However, I still want OpenStack to handle address assignment. > >> >> Thanks! >> >> Shixiong >> >> P.S. The PDF file of this table is uploaded to my Dropbox. Here is the link: >> https://www.dropbox.com/s/9bojvv9vywsz8sd/IPv6%20Two%20Modes%20v3.0.pdf >> >> >> <PastedGraphic-1.png> >> >> >> > <PastedGraphic-1.png>_______________________________________________ > 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
