<div dir="ltr"><div>I would say that since v4 dhcp_mode is core, the DHCPv6/RA setting should similarly be core.  <br><br>To fill others in, we've had discussions on the rest of the patch and Shixiong is working on it now, the current plan is:<br>

<br></div><div>New subnet attribute ipv6_address_auto_config (not catchy, but because of the way that ipv6 works it's not simply DHCPv6) with the four values:<br><br>off - no packets sent to assign addresses for this subnet, do it yourself<br>

slaac - RA packet sent telling the machine to choose its own address from within the subnet; it will choose an address based on its own MAC; because we're talking servers here, this will explicitly *not* work with ipv6 privacy extensions, because - as with the ipv4 implementation - we need one, fixed, *known* address that's planned in advance to make firewalling etc. work<br>

dhcpv6-stateless - RA packet allocates address before, plus DHCPv6 running to provide additional information if requested<br>dhcpv6-stateful - DHCPv6 will assign the address set on the port rather than leaving the machine to work it out from the MAC, along with other information as required.  (For the other settings, the address on the port will be hard coded to the MAC-based address; for this one it may well be hardcoded initially but will eventually be modifiable as for the v4 address.)<br>

<br></div><div>Port firewalling (i.e. security groups, antispoof) will consume the information on the port and subnet as usual.<br></div><div><br></div><div>Obviously you can, as before, use static address config in your VM image or config-drive setup, independent of the above options; this just determines what network functions will be set up and running.<br>

</div><div>-- <br></div>Ian.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 13 January 2014 18:24, Collins, Sean <span dir="ltr"><<a href="mailto:Sean_Collins2@cable.comcast.com" target="_blank">Sean_Collins2@cable.comcast.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I posted a message to the mailing list[1] when I first began work on the<br>
subnet mode keyword, asking if anyone had a suggestion about if it<br>
should be an API extension or can be a change to the core API.<br>
<br>
> I don't know if adding the "dhcp_mode" attribute to Subnets should be<br>
> considered an API extension (and the code should be converted to an API<br>
> extension) or if we're simply specifying behavior that was originally undefined.<br>
<br>
In the months since, we have iterated on the commit, and have continued<br>
working on IPv6 functionality in Neutron.<br>
<br>
Nachi recently -1'd the review[2], saying that it needs to be an API<br>
extension.<br>
<br>
I disagree that it should be an API extension, since I have added<br>
behavior that sets the subnet_mode keyword to default with the attribute<br>
is not specified, for backwards compatibility. Any plugin that inherits<br>
from the NeutronDbPluginV2 class will have backwards compatibility.<br>
<br>
Suggestions?<br>
<br>
[1]: <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-October/017087.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-October/017087.html</a><br>
[2]: <a href="https://review.openstack.org/#/c/52983/" target="_blank">https://review.openstack.org/#/c/52983/</a><br>
<span class="HOEnZb"><font color="#888888">--<br>
Sean M. Collins<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div>