You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Marcus Sorensen <sh...@gmail.com> on 2013/08/12 23:47:44 UTC
Re: IPv6 plan - questions
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 <sh...@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 <dc...@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 <sh...@yasker.org> wrote:
>>
>>> On Wed, Mar 6, 2013 at 1:36 AM, Dave Cahill <dc...@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
>>>
Re: IPv6 plan - questions
Posted by Marcus Sorensen <sh...@gmail.com>.
OK. Please include the bullet points from the "ipv6 in vpc" email I sent
out. I changed the subject line.
On Jan 7, 2014 7:06 AM, "Daan Hoogland" <da...@gmail.com> wrote:
> Marcus,
>
> I am trying to hold your fs against network admins at Schuberg Philis
> to see if I have some additions to make. Will let you know (through
> the cwiki or here) once I got more.
>
> regards,
> Daan
>
> On Sat, Jan 4, 2014 at 2:11 PM, Marcus Sorensen <sh...@gmail.com>
> wrote:
> > I've put together a rough draft spec:
> >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Router
> >
> > 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 <sh...@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 <sh...@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 <sh...@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 <dc...@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 <sh...@yasker.org> wrote:
> >>>>>
> >>>>>> On Wed, Mar 6, 2013 at 1:36 AM, Dave Cahill <dc...@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
> >>>>>>
>
Re: IPv6 plan - questions
Posted by Daan Hoogland <da...@gmail.com>.
Marcus,
I am trying to hold your fs against network admins at Schuberg Philis
to see if I have some additions to make. Will let you know (through
the cwiki or here) once I got more.
regards,
Daan
On Sat, Jan 4, 2014 at 2:11 PM, Marcus Sorensen <sh...@gmail.com> wrote:
> I've put together a rough draft spec:
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Router
>
> 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 <sh...@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 <sh...@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 <sh...@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 <dc...@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 <sh...@yasker.org> wrote:
>>>>>
>>>>>> On Wed, Mar 6, 2013 at 1:36 AM, Dave Cahill <dc...@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
>>>>>>
Re: IPv6 plan - questions
Posted by Marcus Sorensen <sh...@gmail.com>.
I've put together a rough draft spec:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Router
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 <sh...@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 <sh...@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 <sh...@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 <dc...@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 <sh...@yasker.org> wrote:
>>>>
>>>>> On Wed, Mar 6, 2013 at 1:36 AM, Dave Cahill <dc...@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
>>>>>
Re: IPv6 plan - questions
Posted by Marcus Sorensen <sh...@gmail.com>.
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 <sh...@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 <sh...@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 <dc...@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 <sh...@yasker.org> wrote:
>>>
>>>> On Wed, Mar 6, 2013 at 1:36 AM, Dave Cahill <dc...@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
>>>>