incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <w...@widodh.nl>
Subject Re: [ASFCS41] IPv6 Support
Date Wed, 09 Jan 2013 08:48:25 GMT


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

Wido

> --Sheng
>
>>
>> --Sheng
>>
>

Mime
View raw message