Open Stack

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_Veiga at 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 - ジェームズ <thiagocmartinsc at gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Thursday, May 15, 2014 at 14:18
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at 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.ubuntu at 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.cloud at 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 at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> 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/20140516/3952fd45/attachment.html>