On Wed, Jan 9, 2013 at 12:48 AM, Wido den Hollander <w...@widodh.nl> wrote:
> > > On 01/09/2013 01:17 AM, Sheng Yang wrote: > >> 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<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-<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. >> >> > No objections, but we should prevent that just "something" is implemented > and stays that way. > Sure. I like open discussion more... --Sheng > > Wido > > --Sheng >> >> >>> --Sheng >>> >>> >>
