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