cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <>
Subject IPv6 in VPC (was Re: IPv6 plan - questions)
Date Mon, 06 Jan 2014 20:11:26 GMT
I've discussed this a bit with various subject matter experts at our
datacenters/business, and so far we're leaning toward a rollout like

* VPC has no global IPv6 prefix (super CIDR as current private space),
it's simply IPv6 enabled or not. Admins can choose to route a /60 or a
/48 to a vpc and carve it up among the networks there, but it's not
required or enforced by cloudstack.

* VPC networks get assigned one or multiple IPv6 prefixes, each prefix
can be marked 'SLAAC', 'DHCP', or 'Manual'.

* Mgmt server allows calling external plugins for pushing routes to
routers upstream of VPCs (SDN or router API), but could be manually
done by admins as well

* Work could be done in stages, e.g. SLAAC/manual network ranges would
be fairly straightforward, whereas DHCP ranges would require
programming scripts and ip allocation code.

* An issue was raised about privacy concerns with SLAAC using MAC, but
we think this revolves more around clients than servers; that is, a
client moving around the country would be traceable because of the
MAC, but a server always has the same address anyway.

* Still need to figure out what to do about ACLs, that's a whole
separate issue, but a plan needs to be in place. Do we care about port
forwarding, static NAT, Load Balancing etc as well? Or at least think
about what impact these decisions have.

* We assume there will be an ipv6 public range assignable, allocated
for VPC routers/static nat/loadbalancers to pull from.

On Sat, Jan 4, 2014 at 6:11 AM, Marcus Sorensen <> wrote:
> I've put together a rough draft spec:
> I basically just laid out some rough ideas. I know there has been a
> lot of discussion in the past about DHCPv6, etc. My hope is that we
> can at least decide on a spec, for future reference.
> On Fri, Jan 3, 2014 at 9:53 PM, Marcus Sorensen <> wrote:
>> It's been a long time since I've heard anything in regards to IPv6,
>> let alone VPC support. Does anyone have plans for this at all?  We'd
>> like to support IPv6, and we have enough CS knowledge and external
>> tools to hack something together, but I'd much prefer to build with
>> the community and/or be forward compatible with what it deploys.
>> I'd like to start with something simple, like perhaps optionally
>> providing a /64 or larger as a parameter when creating a VPC (or a
>> separate call to add an IPV6 block), and network on the vpc. Then it
>> sounds like there's already a mechanism in place for tracking ipv6
>> assignments to nics, that could be leveraged to pass dhcp assignments
>> to routers.
>> Then there's the whole acl thing, that seems like at least as big of a
>> project as mentioned previously.
>> On Mon, Aug 12, 2013 at 3:47 PM, Marcus Sorensen <> wrote:
>>> has there been any further discussion that I might have missed around
>>> ipv6 in VPC?
>>> On Thu, Mar 7, 2013 at 12:09 PM, Sheng Yang <> wrote:
>>>> Hi Dave,
>>>> I am glad it fits your need. That's our target. :)
>>>> --Sheng
>>>> On Thu, Mar 7, 2013 at 2:14 AM, Dave Cahill <>
>>>>> Hi Sheng,
>>>>> Thanks for the quick reply, that helps a lot.
>>>>> My main purpose was to figure out how these changes affect virtual
>>>>> networking and pluggability. Having read through the IPv6 code today,
>>>>> it looks like it will work very nicely with virtual networks.
>>>>> For example, when VMs are assigned an IPv6 address, the IPv6 address
>>>>> is stored in the NicProfile object. So, taking DHCP as an example, if
>>>>> the MidoNet plugin implements the DHCPServiceProvider interface, it
>>>>> will receive the NicProfile as one of the parameters of addDhcpEntry.
>>>>> If we want to implement IPv6, we can then take the IPv6 address from
>>>>> the NicProfile, and just use it as needed.
>>>>> Thanks again for taking the time to respond, and for the detailed FS.
>>>>> Dave.
>>>>> On Thu, Mar 7, 2013 at 4:57 AM, Sheng Yang <> wrote:
>>>>>> On Wed, Mar 6, 2013 at 1:36 AM, Dave Cahill <>
>>>>>> > Hi,
>>>>>> Hi Dave,
>>>>>> >
>>>>>> > I've been catching up on IPv6 plans by reading the functional
>>>>>> > and Jira tickets - it's great to have so much material to refer
>>>>>> >
>>>>>> > I still have a few questions though, and I'm hoping someone
>>>>>> > with the feature can enlighten me.
>>>>>> >
>>>>>> > *[Support for Providers other than Virtual Router]*
>>>>>> > In [3], the spec says "No external device support in plan."
>>>>>> > What does this mean exactly?
>>>>>> Because CloudStack also supports using external devices as network
>>>>>> controller e.g. Juniper SRX as firewall and NetScaler as load
>>>>>> balancer. The words here said is just we don't support these devices
>>>>>> when using IPv6.
>>>>>> >
>>>>>> > For example, if using Providers other than the Virtual Router,
>>>>>> > the UI still allow setting IPv6 addresses?
>>>>>> >
>>>>>> > If so, do we attempt to pass IPv6 addresses to the Providers
>>>>>> > matter what, or do we check whether the Provider has IPv6 support?
>>>>>> Yes, we checked it when you try to create a IPv6 network(currently
>>>>>> only support advance shared network).
>>>>>> >
>>>>>> > *[Networking Modes]*
>>>>>> > Advanced Shared mode and Basic mode are mentioned in the Jira
>>>>>> > ticket [1] - "Isolated Network" is mentioned briefly in [2],
but I
>>>>>> > wanted to check if the Advanced Isolated and VPC modes are on
>>>>>> > roadmap?
>>>>>> There is no "basic isolated" network, so "Isolated" network is what
>>>>>> we're talking about. We haven't got plan for VPC yet.
>>>>>> And one correction: we didn't support "basic" mode for phase 1. We
>>>>>> support only "advance shared network" in phase 1. The supported cases
>>>>>> are described in FS. Jira ticket only provided a rough idea at the
>>>>>> time.
>>>>>> >
>>>>>> > *[IP Address Management / IPAM]*
>>>>>> > From [1], re: handing out IPv6 addresses: "One way could be
that the
>>>>>> > network admin creates a static route for a /48 towards a Virtual
>>>>>> > Router and then the VR can hand out /64s to Instances."
>>>>>> >
>>>>>> > With IPv4, IPAM is handled by the CloudStack management server,
>>>>>> > the VR is told which IP address to give to the VM over DHCP.
>>>>>> > this change with IPv6? "The VR can hand out /64s to instances"
>>>>>> > like the VR is handling IPAM to some extent.
>>>>>> Well, it's not how it works now. Please refer to the FS. The current
>>>>>> implementation works like before. VR get a /64 then handle out IPv6
>>>>>> addresses to VM.
>>>>>> >
>>>>>> > From [3], "Router advertisement should be sent by public gateway
>>>>>> > the network." - to double-check, does this mean the router outside
>>>>>> > CloudStack network should send RAs, but the VR won't send RAs?
>>>>>> Yes. Because in phase 1, we support only "advance shared network",
>>>>>> which case, VR is NOT the gateway. So we assume the gateway router
>>>>>> outside CloudStack should send out RA to the VMs.
>>>>>> But in the phase 2, VR would acting as gateway, then it would send
out RAs.
>>>>>> --Sheng
>>>>>> >
>>>>>> > Thanks,
>>>>>> > Dave.
>>>>>> >
>>>>>> > [1] IPv6 Support main Jira ticket
>>>>>> >
>>>>>> >
>>>>>> > [2] IPv6 Support in CloudStack FS
>>>>>> >
>>>>>> >
>>>>>> > [3] IPv6 Support FS
>>>>>> >

View raw message