cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <Chiradeep.Vit...@citrix.com>
Subject Re: IPv6 in VPC (was Re: IPv6 plan - questions)
Date Fri, 17 Jan 2014 06:32:22 GMT
Are we assuming that the Cloud Provider has a Provider-Independent (PI)
space?
Using a Unique Local Address (ULA) space for the VPC *might* to desirable.
If VPC tiers (subnets) can span zones (not possible today), then NAT66 can
help keep addresses stable as workloads move to a different zone for
availability reasons.
But I see that only Ubuntu has support for NAT66.


On 1/16/14 11:33 AM, "Sheng Yang" <sheng@yasker.org> wrote:

>On Thu, Jan 9, 2014 at 7:04 AM, Daan Hoogland
><DHoogland@schubergphilis.com>wrote:
>
>> H Marcus, We had a small session on how we plan to go about ipv6
>> configuration with your bullet list present. Comments are still
>> brainstorming phase quality but hopefully they will lead to something.
>>
>> > * 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.
>> The idea at Schuberg Philis is that VPCs should have a standard size
>> network assigned to be taken from a pool. We should be able to configure
>> the width of the network.  The idea is that per level (Physical
>> network/vpc/tier) only one width will be used but the size of it is
>> configurable. Default block for a VR / VPC would be a /56 and each
>> individual network would use a /64. Note that in a typical isolated
>>network
>> we only use the first.
>>
>> > * VPC networks get assigned one or multiple IPv6 prefixes, each prefix
>> can be marked 'SLAAC', 'DHCP', or 'Manual'.
>> For networks we are in favor of using SLAAC for configuring routing and
>> addressing, but would advise DHCPv6 to configure DNS and potentially
>>other
>> things (NTP?). No need to register the addresses in CloudStack. We
>>already
>> store the MAC of the NIC so we know which address will be configured on
>>the
>> interface with the configured prefix. Only the router will receive a
>> specific address (prefix::1/64)
>>
>> As mentioned earlier first implementation will do SLAAC. How will SLAAC
>>be
>> configured with ACL's?
>>
>> > * 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
>> We discussed the routing issues in front of the VPC / VR. The goal is to
>> provide cloudstack with a way to deal with routable addresses inside an
>> isolated network, as actually this problem is relevant for both IPv4 and
>> IPv6. However for IPv4 we have a perfectly workable solution with NAT
>>and
>> in the IPv6 world we don't/. So we need to address this issue on how to
>> route a network from the provider edge into an isolated network.
>>
>> For IPv6 we have several options:
>> *       Dynamic routing protocols, here we can think of iBGP, OSPF or
>>any
>> other protocol. Basically cloudstack assigns a block to a VR / VPC and
>>the
>> VPC / VR tells the outside world to route that block to the outside IP
>>of
>> the router.
>> *       Block allocator, cloudstack knows about the supernet (/48 for
>> example) and assigns a block (/56) to a VR or VPC. Cloudstack tells the
>> block allocator to allocate (route) this block to the VR/VPC. Block
>> allocater needs to know about the device being managed (upstream router
>> like cisco/juniper) and configured the route using telnet or an API
>> *       Broker, We introduce a new systemvm, the block broker. The admin
>> routes the /48 to the block broker and CloudStack tells the blok broker
>>to
>> reroute a specific subblock to this VR / VPC
>> *       Static, Admin configures a list of block/ip pairs in the
>>upstream
>> router. CloudStack knows about these pairs and assigns the ip to the VR
>>/
>> VPC and the block will be routed.
>>
>>
>> > * 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.
>> Are we going to put ACL's on networks or hosts or both? What is easiest
>>to
>> implement and enforce?
>>
>
>The routing is controlled by upstream router, so it's straightforward that
>ACL would be done by upstream router.
>
>But after rethink, modifying the upstream router automatically make me
>feel
>unsafe... Probably host side is a better choice, though it would be more
>work to do.
>
>
>> Do we care about portforwarding, static NAT, Load Balancing etc as well?
>> Or at least think
>> about what impact these decisions have.
>> This is not a version 1 consideration?!?
>>
>> > * We assume there will be an ipv6 public range assignable, allocated
>>for
>> VPC routers/static nat/loadbalancers to pull from. How will this range
>>be
>> made available?
>> Is a cidr configured?
>> Will we preconfigure all ranges or have a dynamic availability check?
>>
>> Radvd package is added to the systemvm template. (Done by Hugo this
>> morning)
>>
>> Some standard UI components are needed.
>>
>> (test-)attention needs to go to:
>>
>> HaProxy version/feature matrix has to be reviewed to check for ipv6
>> compatability.
>
>
>> Does dnsmasq work with ipv6?
>>
>
>Yes. Already use it for IPv6 shared network implementation.
>
>
>>
>> Does keepalived work seemslessly?
>>
>
>According to http://www.keepalived.org/, it should work. But seems works
>are still going on.
>
>--Sheng
>
>
>> Ipv6 tables configuration needs to be pushed to the VRs
>>
>> -----Original Message-----
>> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
>> Sent: maandag 6 januari 2014 9:11
>> To: cloudstack-dev@incubator.apache.org
>> Subject: IPv6 in VPC (was Re: IPv6 plan - questions)
>>
>> 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
>> this:
>>
>> * 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 <shadowsor@gmail.com>
>> wrote:
>> > I've put together a rough draft spec:
>> >
>> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Rou
>> > ter
>> >
>> > 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 <shadowsor@gmail.com>
>> 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
>><shadowsor@gmail.com>
>> 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 <sheng@yasker.org>
>>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 <dcahill@midokura.com>
>> wrote:
>> >>>>> 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 <sheng@yasker.org>
>>wrote:
>> >>>>>
>> >>>>>> On Wed, Mar 6, 2013 at 1:36 AM, Dave Cahill
>><dcahill@midokura.com>
>> wrote:
>> >>>>>> > Hi,
>> >>>>>>
>> >>>>>> Hi Dave,
>> >>>>>> >
>> >>>>>> > I've been catching up on IPv6 plans by reading the
functional
>> >>>>>> > specs and Jira tickets - it's great to have so much
material to
>> refer to.
>> >>>>>> >
>> >>>>>> > I still have a few questions though, and I'm hoping
someone
>> >>>>>> > involved 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,
>> >>>>>> > does the UI still allow setting IPv6 addresses?
>> >>>>>> >
>> >>>>>> > If so, do we attempt to pass IPv6 addresses to the
Providers no
>> >>>>>> > 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 the 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,
>> >>>>>> > and the VR is told which IP address to give to the
VM over
>> >>>>>> > DHCP. Would this change with IPv6? "The VR can hand
out /64s to
>> >>>>>> > instances" sounds 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 in the network." - to double-check, does this
mean the
>> >>>>>> > router outside the CloudStack network should send RAs,
but the
>>VR
>> won't send RAs?
>> >>>>>>
>> >>>>>> Yes. Because in phase 1, we support only "advance shared
>> >>>>>> network", in 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
>> >>>>>> > https://issues.apache.org/jira/browse/CLOUDSTACK-452
>> >>>>>> >
>> >>>>>> > [2] IPv6 Support in CloudStack FS
>> >>>>>> > https://cwiki.apache.org/CLOUDSTACK/ipv6-support-in-cloudstack.
>> >>>>>> > html
>> >>>>>> >
>> >>>>>> > [3] IPv6 Support FS
>> >>>>>> > https://cwiki.apache.org/CLOUDSTACK/ipv6-support.html
>> >>>>>>
>>


Mime
View raw message