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