On Sun, Jan 6, 2013 at 4:56 PM, Sheng Yang <sh...@yasker.org> wrote: > 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). >
If there is no other opinions, I would begin with DHCPv6 in shared network as first step. --Sheng > > --Sheng >
