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
