Precisely Anthony! We talked about this topic ("Non-NAT Floating IPv6") here, on the following thread:
-- [openstack-dev] [Neutron][IPv6] Idea: Floating IPv6 - "Without any kind of NAT": http://lists.openstack.org/pipermail/openstack-dev/2014-February/026871.html -- :-D About IPv6 Privacy Extensions, well, if it is too hard to implement, I think that it can be postponed... And only the IPv6 self-generated by SLAAC and previously calculated by Neutron itself (based on Instance's MAC address), should be allowed to pass/work for now... - Thiago On 16 May 2014 12:12, Veiga, Anthony <anthony_ve...@cable.comcast.com>wrote: > I’ll take this one a step further. I think one of the methods for > getting (non-NAT) floating IPs in IPv6 would be to push a new, extra > address to the same port. Either by crafting an extra, unicast RA to the > specific VM or providing multiple IA_NA fields in the DHCPv6 transaction. > This would require multiple addresses to be allowed on a single MAC. > -Anthony > > From: Martinx - ジェームズ <thiagocmarti...@gmail.com> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Thursday, May 15, 2014 at 14:18 > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][IPv6] Privacy extension > > Hello! > > I agree that there is no need for Privacy Extensions in a Cloud > environment, since MAC address are fake... No big deal... > > Nevertheless, I think that should be nice to allow 1 Instance to have > more than 1 IPv6 addr, since IPv6 is (almost) virtually unlimited... This > way, a VM with, for example, a range of IPv6s to it, can have a shared host > environment when each website have its own IPv6 address (I prefer to use > IP-Based virtualhosts on Apache, instead of Name-Based)... > > Cheers! > Thiago > > > On 15 May 2014 14:22, Ian Wells <ijw.ubu...@cack.org.uk> wrote: > >> I was just about to respond to that in the session when we ran out of >> time. I would vote for simply insisting that VMs run without the privacy >> extension enabled, and only permitting the expected ipv6 address based on >> MAC. Its primary purpose is to conceal your MAC address so that your IP >> address can't be used to track you, as I understand it, and I don't think >> that's as relevant in a cloud environment and where the MAC addresses are >> basically fake. Someone interested in desktop virtualisation with >> Openstack may wish to contradict me... >> -- >> Ian. >> >> >> On 15 May 2014 09:30, Shixiong Shang <sparkofwisdom.cl...@gmail.com>wrote: >> >>> Hi, guys: >>> >>> Nice to meet with all of you in the technical session and design >>> session. I mentioned the challenge of privacy extension in the meeting, but >>> would like to hear your opinions of how to address the problem. If you have >>> any comments or suggestions, please let me know. I will create a BP for >>> this problem. >>> >>> Thanks! >>> >>> Shixiong >>> >>> >>> *Shixiong Shang* >>> >>> *!--- Stay Hungry, Stay Foolish ---!* >>> >>> >>> _______________________________________________ >>> 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev