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