Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <50ED2ED9.50705@widodh.nl>
References: <6DE00C9FDF08A34683DF71786C70EBF02F5A647E@SBPOMB402.sbp.lan>
	<CD0B3E58.3EE1A%chiradeep.vittal@citrix.com>
	<CA+2rt41giVNPkgzeGDfboDrkhzTToat7FOeqkT-NJWYhKi2naw@mail.gmail.com>
	<CA+2rt40xX3XStALkv-wZ6vR-dQHdD+7yGCYAD38MFFzoKsPFyw@mail.gmail.com>
	<50ED2ED9.50705@widodh.nl>
Date: Thu, 10 Jan 2013 11:11:02 -0800
Message-ID: 
 <CA+2rt4361n+cqVOJwftijXn-UXRP0__udUjXqutEGZ_kJe3O-w@mail.gmail.com>
Subject: Re: [ASFCS41] IPv6 Support
From: Sheng Yang <sheng@yasker.org>
To: cloudstack-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=e89a8f23549d9c0af704d2f3f090

--e89a8f23549d9c0af704d2f3f090
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 9, 2013 at 12:48 AM, Wido den Hollander <wido@widodh.nl> wrote:

>
>
> On 01/09/2013 01:17 AM, Sheng Yang wrote:
>
>> On Sun, Jan 6, 2013 at 4:56 PM, Sheng Yang <sheng@yasker.org> wrote:
>>
>>  On Thu, Jan 3, 2013 at 1:59 PM, Chiradeep Vittal <
>>> Chiradeep.Vittal@citrix.com> wrote:
>>>
>>>
>>>>
>>>> On 1/3/13 3:20 AM, "Hugo Trippaers" <HTrippaers@schubergphilis.com**>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>>  -----Original Message-----
>>>>>> From: John Kinsella [mailto:jlk@stratosec.co]
>>>>>> Sent: Wednesday, January 02, 2013 10:05 PM
>>>>>> To: cloudstack-dev@incubator.**apache.org<cloudstack-dev@incubator.apache.org>
>>>>>> Subject: Re: [ASFCS41] IPv6 Support
>>>>>>
>>>>>> Good comments - keep 'em coming!
>>>>>>
>>>>>> On Jan 2, 2013, at 1:01 AM, Hugo Trippaers
>>>>>> <HTrippaers@schubergphilis.com**> wrote:
>>>>>>
>>>>>>> Technically this is a very sound idea, but scale needs to be
>>>>>>>
>>>>>> discussed.
>>>>>> Having static assignments in a database like we do for IPv4 could have
>>>>>> potential impact as the address space available is multitudes bigger
>>>>>> than in
>>>>>> IPv4. Technically one can have 18.446.744.073.709.551.616 hosts in a
>>>>>> single
>>>>>> /64 network, you don't want to be doing a database query on such a
>>>>>> table to
>>>>>> lookup the IP for a host. (Not that it's very reasonable to assume
>>>>>> this
>>>>>> we
>>>>>> would ever see networks this size) My thinking was more geared to
>>>>>> using
>>>>>> SLAAC for determining  addressing to get this burden away from
>>>>>> cloudstack
>>>>>> management server, but this would make other configuration like the
>>>>>> firewall a lot more difficult. The other issue with using DHCPv6 is
>>>>>> the
>>>>>> pseuso
>>>>>> addressing that a lot of systems use a the moment, lots of relatively
>>>>>> short
>>>>>> lived IPv6 addresses on an interface in addition to the one IPv6
>>>>>> address that
>>>>>> is based on the modified EUI-64. This might be a feature that we would
>>>>>> want
>>>>>> to encourage for security reasons, but again this makes firewalls
>>>>>> potentially
>>>>>> more difficult.
>>>>>>
>>>>>> I'd think if you saved the addresses in numeric form (vs string) it
>>>>>> wouldn't be
>>>>>> too bad...interesting convo at
>>>>>>
>>>>>>  http://stackoverflow.com/**questions/420680/how-to-store-**
>>>> ipv6-compatible-<http://stackoverflow.com/questions/420680/how-to-store-ipv6-compatible->
>>>>
>>>>> address-in-a-relational-**database
>>>>>>
>>>>>
>>>>> Agreed, still querying a huge table is going to be a performance
>>>>> impact.
>>>>> Especially if you take into account that if more tenant are in a
>>>>> network
>>>>> more changes will happen making the load increase above linear.
>>>>>
>>>>
>>>> I think John's point was that you could store only the addresses that
>>>> have
>>>> been allocated, along with a row for the range / cidr block. This is the
>>>> current approach for isolated guest networks for example.
>>>>
>>>>
>>>>>
>>>>>> How SLAAC works in an IaaS - I don't have a good answer there, yet.
>>>>>> Seems
>>>>>> like having a daemon sniff for advertisements/requests/**responses
>>>>>> could
>>>>>> be
>>>>>> one way...
>>>>>>
>>>>>
>>>>> I don't have the solution yet, but I like the thinking about the
>>>>> daemon.
>>>>> I think you could even just query the neighbor tables on the VR, they
>>>>> should be up2date at all times.
>>>>>
>>>>>
>>>>>>  This is a big feature, but I think the Basic zone is the easiest for
>>>>>>>>
>>>>>>> now.
>>>>>>
>>>>>>>
>>>>>>> I would vote for thinking up a good solution for both and doing the
>>>>>>>
>>>>>> advanced zone in one go. But that is very simply because my use case
>>>>>> is
>>>>>> for
>>>>>> advanced networking together with IPv6, we do not use basic networking
>>>>>> in
>>>>>> any of our deployments.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>  NAT in the VR seems like a firewall, but a true statefull firewall
>>>>>>>>
>>>>>>> in the VR
>>>>>> could do the same while the Instances still have publicly routeable
>>>>>>
>>>>> IPv6
>>>>
>>>>> addresses.
>>>>>>
>>>>>>> I think we should focus on true statefull firewalls. This would
>>>>>>>
>>>>>> encourage
>>>>>> people to think more on security and allows the use of IPv6 privacy
>>>>>> extensions right from the host.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>  That said, simply enabling IPv6 will not "fix" the problem until
>>>>>>>
>>>>>> there is a
>>>>>> widespread adoption of IPv6 by endusers. Still let's not play the
>>>>>> chicken and
>>>>>> egg game, but fix IPv6 in CloudStack and take the lead.
>>>>>>
>>>>>>   +11 :)
>>>>>>
>>>>>>  3       UI / UX Requirements
>>>>>>>> All fields (input fields and display fields) that take IP Addresses
>>>>>>>>
>>>>>>> would
>>>>>> need to support both IPv4 and IPv6
>>>>>>
>>>>>>> I think it's bigger than this. Do we need service offerings to tell
>>>>>>>
>>>>>> if a network
>>>>>> should have IPv6, IPv4 or both? In that case we need to be able to
>>>>>> tell
>>>>>> what
>>>>>> kind of addressing needs to be configured and how. Depending on the
>>>>>> solution we choose we need configuration for the static routes and
>>>>>> mappings
>>>>>> to public addresses. It probably also ties in with the multiple
>>>>>> address
>>>>>> per nic
>>>>>> configuration and this also has UI implications. We would need
>>>>>> configuration
>>>>>> screens to configure privacy extensions (ipsec, replacing the VPNs).
>>>>>> Firewall
>>>>>> configurations will become more complex and might need additional
>>>>>> screens
>>>>>> for IPv6 statefull firewall configuration. Also the exisiting network
>>>>>> configuration might need to be tuned to the type of networking, we
>>>>>>
>>>>> don't
>>>>
>>>>> need to give the user the possibility to configure portforwarding on an
>>>>>> IPv6
>>>>>> only network for example.
>>>>>>
>>>>>>>
>>>>>>> In addition simple stuff like the count for available public IP
>>>>>>>
>>>>>> addresses
>>>>>> might need to be revisited to make the difference between IPv4 and
>>>>>> IPv6
>>>>>> clear in the UI.
>>>>>>
>>>>>> I'm thinking as this is a pretty major change, we should have a
>>>>>>
>>>>> separate
>>>>
>>>>> branch for development and (a large amount of) testing...
>>>>>>
>>>>>>
>>>>> +1 This is a major feature when done right and requires a lot of
>>>>> testing.
>>>>> As we are going to be touching a huge part of the code with theis we
>>>>> have
>>>>> to take in account that we have to make unittests for those parts as
>>>>> well
>>>>> as most are missing.
>>>>>
>>>>
>>>> If you see the subtasks for CLOUDSTACK-452, you can see that I've split
>>>> it
>>>> to make it more manageable. I feel that tackling the simplest usecase
>>>> can
>>>> help further clarify the fog around SLAAC vs DHCPv6  and issues around
>>>> routing.
>>>> --
>>>> Chiradeep
>>>>
>>>>
>>>>  I still think get non-isolated network working for 4.1 should be a good
>>> start. Specially, since private network shared the same network with
>>> host,
>>> I think we can start with advanced zone with shared network. The advanced
>>> zone with isolated network would involve all the firewall and LB things,
>>> which is too complex for now. We can get the ipv6 done for public
>>> network,
>>> which can be used by advance shared network.
>>>
>>> Would ipv6 be a part of network offering? I don't think so at this
>>> moment.
>>> Think of if user want to use both IPv4 and IPv6(dual stack) for public
>>> ip,
>>> I think that can be done, but it's likely involve much complexity. But I
>>> think we are likely need to support dual stack.
>>>
>>> Regarding SLAAC vs DHCPv6, if we're using SLAAC, since mgmt server still
>>> need to generate the MAC of VM, we still need to maintain the same scale
>>> of
>>> VM MAC table anyway.
>>>
>>> And, to my understanding, the neighbor table in VR is only a cache, like
>>> ARP cache, I don't think we can say it would contain all the information
>>> in
>>> the current network.
>>>
>>> For public network, there is an another issue is, if we say we only allow
>>> allocate a subnet, and using SLAAC in advance shared network, then we
>>> won't
>>> able to tell what's the IPs remained in the range can be used for other
>>> purposes(e.g. LB, PF).
>>>
>>>
>>   If there is no other opinions, I would begin with DHCPv6 in shared
>> network
>> as first step.
>>
>>
> No objections, but we should prevent that just "something" is implemented
> and stays that way.
>

Sure. I like open discussion more...

--Sheng

>
> Wido
>
>  --Sheng
>>
>>
>>> --Sheng
>>>
>>>
>>

--e89a8f23549d9c0af704d2f3f090--