On Thu, Jan 3, 2013 at 1:59 PM, Chiradeep Vittal < chiradeep.vit...@citrix.com> wrote:
> > > On 1/3/13 3:20 AM, "Hugo Trippaers" <htrippa...@schubergphilis.com> wrote: > > > > > > >> -----Original Message----- > >> From: John Kinsella [mailto:j...@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 > >> <htrippa...@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). --Sheng
