Open Stack

I would say that since v4 dhcp_mode is core, the DHCPv6/RA setting should
similarly be core.

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:

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:

off - no packets sent to assign addresses for this subnet, do it yourself
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
dhcpv6-stateless - RA packet allocates address before, plus DHCPv6 running
to provide additional information if requested
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.)

Port firewalling (i.e. security groups, antispoof) will consume the
information on the port and subnet as usual.

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.
-- 
Ian.


On 13 January 2014 18:24, Collins, Sean <Sean_Collins2 at cable.comcast.com>wrote:

> Hi,
>
> I posted a message to the mailing list[1] when I first began work on the
> subnet mode keyword, asking if anyone had a suggestion about if it
> should be an API extension or can be a change to the core API.
>
> > I don't know if adding the "dhcp_mode" attribute to Subnets should be
> > considered an API extension (and the code should be converted to an API
> > extension) or if we're simply specifying behavior that was originally
> undefined.
>
> In the months since, we have iterated on the commit, and have continued
> working on IPv6 functionality in Neutron.
>
> Nachi recently -1'd the review[2], saying that it needs to be an API
> extension.
>
> I disagree that it should be an API extension, since I have added
> behavior that sets the subnet_mode keyword to default with the attribute
> is not specified, for backwards compatibility. Any plugin that inherits
> from the NeutronDbPluginV2 class will have backwards compatibility.
>
> Suggestions?
>
> [1]:
> http://lists.openstack.org/pipermail/openstack-dev/2013-October/017087.html
> [2]: https://review.openstack.org/#/c/52983/
> --
> Sean M. Collins
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140113/be63230a/attachment.html>