cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sheng Yang <sh...@yasker.org>
Subject Re: [ASFCS41] IPv6 Support
Date Wed, 09 Jan 2013 00:17:08 GMT
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.

--Sheng

>
> --Sheng
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message