You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Manan Shah <ma...@citrix.com> on 2012/12/19 20:11:25 UTC
[ASFCS41] IPv6 Support
Hi,
I would like to update the existing JIRA ticket on IPv6 support and I have also added a requirements page to track this feature. Please provide feedback on the requirements.
JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-452
Requirements: https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+Support+in+CloudStack
Regards,
Manan Shah
Re: [ASFCS41] IPv6 Support
Posted by Sheng Yang <sh...@yasker.org>.
On Wed, Jan 16, 2013 at 1:07 PM, Chiradeep Vittal
<Ch...@citrix.com> wrote:
> I would assume a 'modern' OS as well. Centos 6.2 / Ubuntu 12.04 / Windows
> 2008(and above).
> Did you configure /etc/dhcpv6/dhcpc6.cnf with:
> duid LL eth0
Which guest OS/dhclient you're referring to?
--Sheng
>
>
>
> On 1/15/13 7:01 PM, "David Nalley" <da...@gnsa.us> wrote:
>
>>On Tue, Jan 15, 2013 at 9:10 PM, Sheng Yang <sh...@yasker.org> wrote:
>>> On Mon, Jan 14, 2013 at 3:34 PM, Sheng Yang <sh...@yasker.org> wrote:
>>>> On Mon, Jan 14, 2013 at 10:51 AM, Sheng Yang <sh...@yasker.org> wrote:
>>>>>
>>>>> On Mon, Jan 14, 2013 at 10:45 AM, Chiradeep Vittal
>>>>> <Ch...@citrix.com> wrote:
>>>>>>
>>>>>> You can if you assume that it is of LL-type. Windows requires a
>>>>>>registry
>>>>>> fix to generate an 'LL' type DUID.
>>>>>
>>>>>
>>>>> Does dhcp6c support it? Didn't see a word from the document about
>>>>>DUID type,
>>>>> and it genereate LLT type by default Probably I should try another
>>>>>dhcpv6
>>>>> client.
>>>>>>
>>>>>>
>>>>>> You can also get dnsmasq to ignore the duid and use the mac.
>>>>>
>>>>>
>>>>> Haven't confirmed it's possible to use the mac, asking dnsmasq mailing
>>>>> list...
>>>>
>>>> Get answer from Dnsmasq's author Simon, it's impossible to use MAC to
>>>> identify client right now, since there is no such dhcpv6 standard.
>>>>
>>>> So it looks like we need stick to DUID-LL.
>>>
>>> I am failed to generated DUID-LL from the latest version of dhcp6c in
>>> CentOS 5.6. Is DUID-LL poorly supported by dhcpv6 client? Any other
>>> suggestion?
>>>
>>> User may need to install new dhcpv6 client to use with CloudStack,
>>> that sounds not that good...
>>>
>>> I am working on the FS right now, since we have the key steps(except
>>> DUID-LL, which should be a dhcpv6 client issue), and likely able to
>>> get it done tomorrow.
>>>
>>> Since we're working on advance shared network, it's easier to deal
>>> with createNetwork API rather than createVlanAndIpRange API.
>>>
>>
>>Unless something has changed recently, EL5 had horrendous IPv6
>>support, and many things that should have worked, simply didn't.
>>
>>--David
>
Re: [ASFCS41] IPv6 Support
Posted by Chiradeep Vittal <Ch...@citrix.com>.
I would assume a 'modern' OS as well. Centos 6.2 / Ubuntu 12.04 / Windows
2008(and above).
Did you configure /etc/dhcpv6/dhcpc6.cnf with:
duid LL eth0
On 1/15/13 7:01 PM, "David Nalley" <da...@gnsa.us> wrote:
>On Tue, Jan 15, 2013 at 9:10 PM, Sheng Yang <sh...@yasker.org> wrote:
>> On Mon, Jan 14, 2013 at 3:34 PM, Sheng Yang <sh...@yasker.org> wrote:
>>> On Mon, Jan 14, 2013 at 10:51 AM, Sheng Yang <sh...@yasker.org> wrote:
>>>>
>>>> On Mon, Jan 14, 2013 at 10:45 AM, Chiradeep Vittal
>>>> <Ch...@citrix.com> wrote:
>>>>>
>>>>> You can if you assume that it is of LL-type. Windows requires a
>>>>>registry
>>>>> fix to generate an 'LL' type DUID.
>>>>
>>>>
>>>> Does dhcp6c support it? Didn't see a word from the document about
>>>>DUID type,
>>>> and it genereate LLT type by default Probably I should try another
>>>>dhcpv6
>>>> client.
>>>>>
>>>>>
>>>>> You can also get dnsmasq to ignore the duid and use the mac.
>>>>
>>>>
>>>> Haven't confirmed it's possible to use the mac, asking dnsmasq mailing
>>>> list...
>>>
>>> Get answer from Dnsmasq's author Simon, it's impossible to use MAC to
>>> identify client right now, since there is no such dhcpv6 standard.
>>>
>>> So it looks like we need stick to DUID-LL.
>>
>> I am failed to generated DUID-LL from the latest version of dhcp6c in
>> CentOS 5.6. Is DUID-LL poorly supported by dhcpv6 client? Any other
>> suggestion?
>>
>> User may need to install new dhcpv6 client to use with CloudStack,
>> that sounds not that good...
>>
>> I am working on the FS right now, since we have the key steps(except
>> DUID-LL, which should be a dhcpv6 client issue), and likely able to
>> get it done tomorrow.
>>
>> Since we're working on advance shared network, it's easier to deal
>> with createNetwork API rather than createVlanAndIpRange API.
>>
>
>Unless something has changed recently, EL5 had horrendous IPv6
>support, and many things that should have worked, simply didn't.
>
>--David
Re: [ASFCS41] IPv6 Support
Posted by David Nalley <da...@gnsa.us>.
On Tue, Jan 15, 2013 at 9:10 PM, Sheng Yang <sh...@yasker.org> wrote:
> On Mon, Jan 14, 2013 at 3:34 PM, Sheng Yang <sh...@yasker.org> wrote:
>> On Mon, Jan 14, 2013 at 10:51 AM, Sheng Yang <sh...@yasker.org> wrote:
>>>
>>> On Mon, Jan 14, 2013 at 10:45 AM, Chiradeep Vittal
>>> <Ch...@citrix.com> wrote:
>>>>
>>>> You can if you assume that it is of LL-type. Windows requires a registry
>>>> fix to generate an 'LL' type DUID.
>>>
>>>
>>> Does dhcp6c support it? Didn't see a word from the document about DUID type,
>>> and it genereate LLT type by default Probably I should try another dhcpv6
>>> client.
>>>>
>>>>
>>>> You can also get dnsmasq to ignore the duid and use the mac.
>>>
>>>
>>> Haven't confirmed it's possible to use the mac, asking dnsmasq mailing
>>> list...
>>
>> Get answer from Dnsmasq's author Simon, it's impossible to use MAC to
>> identify client right now, since there is no such dhcpv6 standard.
>>
>> So it looks like we need stick to DUID-LL.
>
> I am failed to generated DUID-LL from the latest version of dhcp6c in
> CentOS 5.6. Is DUID-LL poorly supported by dhcpv6 client? Any other
> suggestion?
>
> User may need to install new dhcpv6 client to use with CloudStack,
> that sounds not that good...
>
> I am working on the FS right now, since we have the key steps(except
> DUID-LL, which should be a dhcpv6 client issue), and likely able to
> get it done tomorrow.
>
> Since we're working on advance shared network, it's easier to deal
> with createNetwork API rather than createVlanAndIpRange API.
>
Unless something has changed recently, EL5 had horrendous IPv6
support, and many things that should have worked, simply didn't.
--David
Re: [ASFCS41] IPv6 Support
Posted by Sheng Yang <sh...@yasker.org>.
On Mon, Jan 14, 2013 at 3:34 PM, Sheng Yang <sh...@yasker.org> wrote:
> On Mon, Jan 14, 2013 at 10:51 AM, Sheng Yang <sh...@yasker.org> wrote:
>>
>> On Mon, Jan 14, 2013 at 10:45 AM, Chiradeep Vittal
>> <Ch...@citrix.com> wrote:
>>>
>>> You can if you assume that it is of LL-type. Windows requires a registry
>>> fix to generate an 'LL' type DUID.
>>
>>
>> Does dhcp6c support it? Didn't see a word from the document about DUID type,
>> and it genereate LLT type by default Probably I should try another dhcpv6
>> client.
>>>
>>>
>>> You can also get dnsmasq to ignore the duid and use the mac.
>>
>>
>> Haven't confirmed it's possible to use the mac, asking dnsmasq mailing
>> list...
>
> Get answer from Dnsmasq's author Simon, it's impossible to use MAC to
> identify client right now, since there is no such dhcpv6 standard.
>
> So it looks like we need stick to DUID-LL.
I am failed to generated DUID-LL from the latest version of dhcp6c in
CentOS 5.6. Is DUID-LL poorly supported by dhcpv6 client? Any other
suggestion?
User may need to install new dhcpv6 client to use with CloudStack,
that sounds not that good...
I am working on the FS right now, since we have the key steps(except
DUID-LL, which should be a dhcpv6 client issue), and likely able to
get it done tomorrow.
Since we're working on advance shared network, it's easier to deal
with createNetwork API rather than createVlanAndIpRange API.
--Sheng
>
> --Sheng
>
>
>>
>> --Sheng
>>
>>
>>>
>>>
>>> On 1/14/13 9:54 AM, "Sheng Yang" <sh...@yasker.org> wrote:
>>>
>>> >On Sun, Jan 13, 2013 at 11:21 PM, Hugo Trippaers <
>>> >HTrippaers@schubergphilis.com> wrote:
>>> >
>>> >> Side note, but where are we going to do development? I think we should
>>> >>get
>>> >> our work in a feature branch as soon as possible so we can all
>>> >>contribute
>>> >> to the development.
>>> >>
>>> >> Sheng, can you push any work you have done to a branch? I'll check and
>>> >>see
>>> >> if I need to commit any of my changes then.
>>> >>
>>> >
>>> >We'd like to have the work based on Chiradeep's network refactor branch,
>>> >but currently we're waiting for Javelin to be merged.
>>> >
>>> >And I am dong some PoC right now, so no code is written so far. I just
>>> >found it's not that straightforward to get the dnsmasq work as we
>>> > thought.
>>> >
>>> >We need DUID from client(not MAC) to hand out ipv6 addresses, but I am
>>> > not
>>> >sure if that's something we can know from mgmt server side.
>>> >
>>> >--Sheng
>>> >
>>> >>
>>> >> Cheers,
>>> >>
>>> >> Hugo
>>> >>
>>> >> -----Original Message-----
>>> >> From: John Kinsella [mailto:jlk@stratosec.co]
>>> >> Sent: vrijdag 11 januari 2013 19:50
>>> >> To: cloudstack-dev@incubator.apache.org
>>> >> Subject: Re: [ASFCS41] IPv6 Support
>>> >>
>>> >>
>>> >> On Jan 10, 2013, at 11:09 AM, Sheng Yang <sh...@yasker.org> wrote:
>>> >>
>>> >> > On Tue, Jan 8, 2013 at 10:57 PM, John Kinsella <jl...@stratosec.co>
>>> >>wrote:
>>> >> >> From a quick glance at it's man page, looks like it can do v4 and v6
>>> >> >> leases at the same time...
>>> >> > You mean dhcpd?
>>> >> >
>>> >>
>>> >> No, dnsmasq looked like it could...
>>> >>
>>> >> > I am exploring all the possibility right now.
>>> >> >
>>> >> > Currently dnsmasq in our systemvm doesn't support DHCPv6, so we would
>>> >> > either update to a newer version dnsmasq, or using other dhcp
>>> >>server(e.g.
>>> >> > dhcpd) on DHCPv6.
>>> >> >
>>> >> > But replacing the dhcp server is a big work, all the configuration
>>> >> > need to be rewritten. Regarding dhcpd, I haven't figured out how much
>>> >> > effort we need to spend if we want to switch.
>>> >> >
>>> >> > There is one possible solution for this release: say, using dhcpd
>>> >> > only
>>> >> > for IPv6, to reduce our effort of introducing IPv6(if it's easier
>>> >> > than
>>> >> > moving to dhcpd). And then we can make the choice in the later
>>> >>release.
>>> >> >
>>> >> > John, do you have some experiences can share regarding dhcpd?
>>> >> >
>>> >> > Also, regarding your problem, have you used cloudstack to distribute
>>> >> > IP? I don't think we support leasing on two /28s in advance network
>>> >>now?
>>> >>
>>> >> So, in my lab env I've made a few changes to the server and UI to allow
>>> >> multiple IP blocks in basic network (haven't tried in advanced yet),
>>> >>then
>>> >> additionally I'm passing a netmask down to the agent, then that's
>>> >> passed
>>> >> through to dhcp_entry.sh, and then into edithosts.sh, which I've
>>> >>updated to
>>> >> support dhcpd. The one thing I wanted to do but haven't is to update
>>> >> edithosts.sh to support both dnsmasq as well as dhcpd.
>>> >>
>>> >> Note: this was done in-house without community involvement as I didn't
>>> >> expect general interest in this, but I'm happy to use experience gained
>>> >>to
>>> >> write similar support in the ASF tree.
>>> >>
>>> >> Johh
>>> >>
>>>
>>
Re: [ASFCS41] IPv6 Support
Posted by Sheng Yang <sh...@yasker.org>.
On Mon, Jan 14, 2013 at 10:51 AM, Sheng Yang <sh...@yasker.org> wrote:
>
> On Mon, Jan 14, 2013 at 10:45 AM, Chiradeep Vittal
> <Ch...@citrix.com> wrote:
>>
>> You can if you assume that it is of LL-type. Windows requires a registry
>> fix to generate an 'LL' type DUID.
>
>
> Does dhcp6c support it? Didn't see a word from the document about DUID type,
> and it genereate LLT type by default Probably I should try another dhcpv6
> client.
>>
>>
>> You can also get dnsmasq to ignore the duid and use the mac.
>
>
> Haven't confirmed it's possible to use the mac, asking dnsmasq mailing
> list...
Get answer from Dnsmasq's author Simon, it's impossible to use MAC to
identify client right now, since there is no such dhcpv6 standard.
So it looks like we need stick to DUID-LL.
--Sheng
>
> --Sheng
>
>
>>
>>
>> On 1/14/13 9:54 AM, "Sheng Yang" <sh...@yasker.org> wrote:
>>
>> >On Sun, Jan 13, 2013 at 11:21 PM, Hugo Trippaers <
>> >HTrippaers@schubergphilis.com> wrote:
>> >
>> >> Side note, but where are we going to do development? I think we should
>> >>get
>> >> our work in a feature branch as soon as possible so we can all
>> >>contribute
>> >> to the development.
>> >>
>> >> Sheng, can you push any work you have done to a branch? I'll check and
>> >>see
>> >> if I need to commit any of my changes then.
>> >>
>> >
>> >We'd like to have the work based on Chiradeep's network refactor branch,
>> >but currently we're waiting for Javelin to be merged.
>> >
>> >And I am dong some PoC right now, so no code is written so far. I just
>> >found it's not that straightforward to get the dnsmasq work as we
>> > thought.
>> >
>> >We need DUID from client(not MAC) to hand out ipv6 addresses, but I am
>> > not
>> >sure if that's something we can know from mgmt server side.
>> >
>> >--Sheng
>> >
>> >>
>> >> Cheers,
>> >>
>> >> Hugo
>> >>
>> >> -----Original Message-----
>> >> From: John Kinsella [mailto:jlk@stratosec.co]
>> >> Sent: vrijdag 11 januari 2013 19:50
>> >> To: cloudstack-dev@incubator.apache.org
>> >> Subject: Re: [ASFCS41] IPv6 Support
>> >>
>> >>
>> >> On Jan 10, 2013, at 11:09 AM, Sheng Yang <sh...@yasker.org> wrote:
>> >>
>> >> > On Tue, Jan 8, 2013 at 10:57 PM, John Kinsella <jl...@stratosec.co>
>> >>wrote:
>> >> >> From a quick glance at it's man page, looks like it can do v4 and v6
>> >> >> leases at the same time...
>> >> > You mean dhcpd?
>> >> >
>> >>
>> >> No, dnsmasq looked like it could...
>> >>
>> >> > I am exploring all the possibility right now.
>> >> >
>> >> > Currently dnsmasq in our systemvm doesn't support DHCPv6, so we would
>> >> > either update to a newer version dnsmasq, or using other dhcp
>> >>server(e.g.
>> >> > dhcpd) on DHCPv6.
>> >> >
>> >> > But replacing the dhcp server is a big work, all the configuration
>> >> > need to be rewritten. Regarding dhcpd, I haven't figured out how much
>> >> > effort we need to spend if we want to switch.
>> >> >
>> >> > There is one possible solution for this release: say, using dhcpd
>> >> > only
>> >> > for IPv6, to reduce our effort of introducing IPv6(if it's easier
>> >> > than
>> >> > moving to dhcpd). And then we can make the choice in the later
>> >>release.
>> >> >
>> >> > John, do you have some experiences can share regarding dhcpd?
>> >> >
>> >> > Also, regarding your problem, have you used cloudstack to distribute
>> >> > IP? I don't think we support leasing on two /28s in advance network
>> >>now?
>> >>
>> >> So, in my lab env I've made a few changes to the server and UI to allow
>> >> multiple IP blocks in basic network (haven't tried in advanced yet),
>> >>then
>> >> additionally I'm passing a netmask down to the agent, then that's
>> >> passed
>> >> through to dhcp_entry.sh, and then into edithosts.sh, which I've
>> >>updated to
>> >> support dhcpd. The one thing I wanted to do but haven't is to update
>> >> edithosts.sh to support both dnsmasq as well as dhcpd.
>> >>
>> >> Note: this was done in-house without community involvement as I didn't
>> >> expect general interest in this, but I'm happy to use experience gained
>> >>to
>> >> write similar support in the ASF tree.
>> >>
>> >> Johh
>> >>
>>
>
Re: [ASFCS41] IPv6 Support
Posted by Sheng Yang <sh...@yasker.org>.
On Mon, Jan 14, 2013 at 10:45 AM, Chiradeep Vittal <
Chiradeep.Vittal@citrix.com> wrote:
> You can if you assume that it is of LL-type. Windows requires a registry
> fix to generate an 'LL' type DUID.
>
Does dhcp6c support it? Didn't see a word from the document about DUID
type, and it genereate LLT type by default Probably I should try another
dhcpv6 client.
>
> You can also get dnsmasq to ignore the duid and use the mac.
>
Haven't confirmed it's possible to use the mac, asking dnsmasq mailing
list...
--Sheng
>
> On 1/14/13 9:54 AM, "Sheng Yang" <sh...@yasker.org> wrote:
>
> >On Sun, Jan 13, 2013 at 11:21 PM, Hugo Trippaers <
> >HTrippaers@schubergphilis.com> wrote:
> >
> >> Side note, but where are we going to do development? I think we should
> >>get
> >> our work in a feature branch as soon as possible so we can all
> >>contribute
> >> to the development.
> >>
> >> Sheng, can you push any work you have done to a branch? I'll check and
> >>see
> >> if I need to commit any of my changes then.
> >>
> >
> >We'd like to have the work based on Chiradeep's network refactor branch,
> >but currently we're waiting for Javelin to be merged.
> >
> >And I am dong some PoC right now, so no code is written so far. I just
> >found it's not that straightforward to get the dnsmasq work as we thought.
> >
> >We need DUID from client(not MAC) to hand out ipv6 addresses, but I am not
> >sure if that's something we can know from mgmt server side.
> >
> >--Sheng
> >
> >>
> >> Cheers,
> >>
> >> Hugo
> >>
> >> -----Original Message-----
> >> From: John Kinsella [mailto:jlk@stratosec.co]
> >> Sent: vrijdag 11 januari 2013 19:50
> >> To: cloudstack-dev@incubator.apache.org
> >> Subject: Re: [ASFCS41] IPv6 Support
> >>
> >>
> >> On Jan 10, 2013, at 11:09 AM, Sheng Yang <sh...@yasker.org> wrote:
> >>
> >> > On Tue, Jan 8, 2013 at 10:57 PM, John Kinsella <jl...@stratosec.co>
> >>wrote:
> >> >> From a quick glance at it's man page, looks like it can do v4 and v6
> >> >> leases at the same time...
> >> > You mean dhcpd?
> >> >
> >>
> >> No, dnsmasq looked like it could...
> >>
> >> > I am exploring all the possibility right now.
> >> >
> >> > Currently dnsmasq in our systemvm doesn't support DHCPv6, so we would
> >> > either update to a newer version dnsmasq, or using other dhcp
> >>server(e.g.
> >> > dhcpd) on DHCPv6.
> >> >
> >> > But replacing the dhcp server is a big work, all the configuration
> >> > need to be rewritten. Regarding dhcpd, I haven't figured out how much
> >> > effort we need to spend if we want to switch.
> >> >
> >> > There is one possible solution for this release: say, using dhcpd only
> >> > for IPv6, to reduce our effort of introducing IPv6(if it's easier than
> >> > moving to dhcpd). And then we can make the choice in the later
> >>release.
> >> >
> >> > John, do you have some experiences can share regarding dhcpd?
> >> >
> >> > Also, regarding your problem, have you used cloudstack to distribute
> >> > IP? I don't think we support leasing on two /28s in advance network
> >>now?
> >>
> >> So, in my lab env I've made a few changes to the server and UI to allow
> >> multiple IP blocks in basic network (haven't tried in advanced yet),
> >>then
> >> additionally I'm passing a netmask down to the agent, then that's passed
> >> through to dhcp_entry.sh, and then into edithosts.sh, which I've
> >>updated to
> >> support dhcpd. The one thing I wanted to do but haven't is to update
> >> edithosts.sh to support both dnsmasq as well as dhcpd.
> >>
> >> Note: this was done in-house without community involvement as I didn't
> >> expect general interest in this, but I'm happy to use experience gained
> >>to
> >> write similar support in the ASF tree.
> >>
> >> Johh
> >>
>
>
Re: [ASFCS41] IPv6 Support
Posted by Chiradeep Vittal <Ch...@citrix.com>.
You can if you assume that it is of LL-type. Windows requires a registry
fix to generate an 'LL' type DUID.
You can also get dnsmasq to ignore the duid and use the mac.
On 1/14/13 9:54 AM, "Sheng Yang" <sh...@yasker.org> wrote:
>On Sun, Jan 13, 2013 at 11:21 PM, Hugo Trippaers <
>HTrippaers@schubergphilis.com> wrote:
>
>> Side note, but where are we going to do development? I think we should
>>get
>> our work in a feature branch as soon as possible so we can all
>>contribute
>> to the development.
>>
>> Sheng, can you push any work you have done to a branch? I'll check and
>>see
>> if I need to commit any of my changes then.
>>
>
>We'd like to have the work based on Chiradeep's network refactor branch,
>but currently we're waiting for Javelin to be merged.
>
>And I am dong some PoC right now, so no code is written so far. I just
>found it's not that straightforward to get the dnsmasq work as we thought.
>
>We need DUID from client(not MAC) to hand out ipv6 addresses, but I am not
>sure if that's something we can know from mgmt server side.
>
>--Sheng
>
>>
>> Cheers,
>>
>> Hugo
>>
>> -----Original Message-----
>> From: John Kinsella [mailto:jlk@stratosec.co]
>> Sent: vrijdag 11 januari 2013 19:50
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: [ASFCS41] IPv6 Support
>>
>>
>> On Jan 10, 2013, at 11:09 AM, Sheng Yang <sh...@yasker.org> wrote:
>>
>> > On Tue, Jan 8, 2013 at 10:57 PM, John Kinsella <jl...@stratosec.co>
>>wrote:
>> >> From a quick glance at it's man page, looks like it can do v4 and v6
>> >> leases at the same time...
>> > You mean dhcpd?
>> >
>>
>> No, dnsmasq looked like it could...
>>
>> > I am exploring all the possibility right now.
>> >
>> > Currently dnsmasq in our systemvm doesn't support DHCPv6, so we would
>> > either update to a newer version dnsmasq, or using other dhcp
>>server(e.g.
>> > dhcpd) on DHCPv6.
>> >
>> > But replacing the dhcp server is a big work, all the configuration
>> > need to be rewritten. Regarding dhcpd, I haven't figured out how much
>> > effort we need to spend if we want to switch.
>> >
>> > There is one possible solution for this release: say, using dhcpd only
>> > for IPv6, to reduce our effort of introducing IPv6(if it's easier than
>> > moving to dhcpd). And then we can make the choice in the later
>>release.
>> >
>> > John, do you have some experiences can share regarding dhcpd?
>> >
>> > Also, regarding your problem, have you used cloudstack to distribute
>> > IP? I don't think we support leasing on two /28s in advance network
>>now?
>>
>> So, in my lab env I've made a few changes to the server and UI to allow
>> multiple IP blocks in basic network (haven't tried in advanced yet),
>>then
>> additionally I'm passing a netmask down to the agent, then that's passed
>> through to dhcp_entry.sh, and then into edithosts.sh, which I've
>>updated to
>> support dhcpd. The one thing I wanted to do but haven't is to update
>> edithosts.sh to support both dnsmasq as well as dhcpd.
>>
>> Note: this was done in-house without community involvement as I didn't
>> expect general interest in this, but I'm happy to use experience gained
>>to
>> write similar support in the ASF tree.
>>
>> Johh
>>
Re: [ASFCS41] IPv6 Support
Posted by Sheng Yang <sh...@yasker.org>.
On Sun, Jan 13, 2013 at 11:21 PM, Hugo Trippaers <
HTrippaers@schubergphilis.com> wrote:
> Side note, but where are we going to do development? I think we should get
> our work in a feature branch as soon as possible so we can all contribute
> to the development.
>
> Sheng, can you push any work you have done to a branch? I'll check and see
> if I need to commit any of my changes then.
>
We'd like to have the work based on Chiradeep's network refactor branch,
but currently we're waiting for Javelin to be merged.
And I am dong some PoC right now, so no code is written so far. I just
found it's not that straightforward to get the dnsmasq work as we thought.
We need DUID from client(not MAC) to hand out ipv6 addresses, but I am not
sure if that's something we can know from mgmt server side.
--Sheng
>
> Cheers,
>
> Hugo
>
> -----Original Message-----
> From: John Kinsella [mailto:jlk@stratosec.co]
> Sent: vrijdag 11 januari 2013 19:50
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [ASFCS41] IPv6 Support
>
>
> On Jan 10, 2013, at 11:09 AM, Sheng Yang <sh...@yasker.org> wrote:
>
> > On Tue, Jan 8, 2013 at 10:57 PM, John Kinsella <jl...@stratosec.co> wrote:
> >> From a quick glance at it's man page, looks like it can do v4 and v6
> >> leases at the same time...
> > You mean dhcpd?
> >
>
> No, dnsmasq looked like it could...
>
> > I am exploring all the possibility right now.
> >
> > Currently dnsmasq in our systemvm doesn't support DHCPv6, so we would
> > either update to a newer version dnsmasq, or using other dhcp server(e.g.
> > dhcpd) on DHCPv6.
> >
> > But replacing the dhcp server is a big work, all the configuration
> > need to be rewritten. Regarding dhcpd, I haven't figured out how much
> > effort we need to spend if we want to switch.
> >
> > There is one possible solution for this release: say, using dhcpd only
> > for IPv6, to reduce our effort of introducing IPv6(if it's easier than
> > moving to dhcpd). And then we can make the choice in the later release.
> >
> > John, do you have some experiences can share regarding dhcpd?
> >
> > Also, regarding your problem, have you used cloudstack to distribute
> > IP? I don't think we support leasing on two /28s in advance network now?
>
> So, in my lab env I've made a few changes to the server and UI to allow
> multiple IP blocks in basic network (haven't tried in advanced yet), then
> additionally I'm passing a netmask down to the agent, then that's passed
> through to dhcp_entry.sh, and then into edithosts.sh, which I've updated to
> support dhcpd. The one thing I wanted to do but haven't is to update
> edithosts.sh to support both dnsmasq as well as dhcpd.
>
> Note: this was done in-house without community involvement as I didn't
> expect general interest in this, but I'm happy to use experience gained to
> write similar support in the ASF tree.
>
> Johh
>
RE: [ASFCS41] IPv6 Support
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
Side note, but where are we going to do development? I think we should get our work in a feature branch as soon as possible so we can all contribute to the development.
Sheng, can you push any work you have done to a branch? I'll check and see if I need to commit any of my changes then.
Cheers,
Hugo
-----Original Message-----
From: John Kinsella [mailto:jlk@stratosec.co]
Sent: vrijdag 11 januari 2013 19:50
To: cloudstack-dev@incubator.apache.org
Subject: Re: [ASFCS41] IPv6 Support
On Jan 10, 2013, at 11:09 AM, Sheng Yang <sh...@yasker.org> wrote:
> On Tue, Jan 8, 2013 at 10:57 PM, John Kinsella <jl...@stratosec.co> wrote:
>> From a quick glance at it's man page, looks like it can do v4 and v6
>> leases at the same time...
> You mean dhcpd?
>
No, dnsmasq looked like it could...
> I am exploring all the possibility right now.
>
> Currently dnsmasq in our systemvm doesn't support DHCPv6, so we would
> either update to a newer version dnsmasq, or using other dhcp server(e.g.
> dhcpd) on DHCPv6.
>
> But replacing the dhcp server is a big work, all the configuration
> need to be rewritten. Regarding dhcpd, I haven't figured out how much
> effort we need to spend if we want to switch.
>
> There is one possible solution for this release: say, using dhcpd only
> for IPv6, to reduce our effort of introducing IPv6(if it's easier than
> moving to dhcpd). And then we can make the choice in the later release.
>
> John, do you have some experiences can share regarding dhcpd?
>
> Also, regarding your problem, have you used cloudstack to distribute
> IP? I don't think we support leasing on two /28s in advance network now?
So, in my lab env I've made a few changes to the server and UI to allow multiple IP blocks in basic network (haven't tried in advanced yet), then additionally I'm passing a netmask down to the agent, then that's passed through to dhcp_entry.sh, and then into edithosts.sh, which I've updated to support dhcpd. The one thing I wanted to do but haven't is to update edithosts.sh to support both dnsmasq as well as dhcpd.
Note: this was done in-house without community involvement as I didn't expect general interest in this, but I'm happy to use experience gained to write similar support in the ASF tree.
Johh
Re: [ASFCS41] IPv6 Support
Posted by John Kinsella <jl...@stratosec.co>.
On Jan 10, 2013, at 11:09 AM, Sheng Yang <sh...@yasker.org> wrote:
> On Tue, Jan 8, 2013 at 10:57 PM, John Kinsella <jl...@stratosec.co> wrote:
>> From a quick glance at it's man page, looks like it can do v4 and v6
>> leases at the same time…
> You mean dhcpd?
>
No, dnsmasq looked like it could...
> I am exploring all the possibility right now.
>
> Currently dnsmasq in our systemvm doesn't support DHCPv6, so we would
> either update to a newer version dnsmasq, or using other dhcp server(e.g.
> dhcpd) on DHCPv6.
>
> But replacing the dhcp server is a big work, all the configuration need to
> be rewritten. Regarding dhcpd, I haven't figured out how much effort we
> need to spend if we want to switch.
>
> There is one possible solution for this release: say, using dhcpd only for
> IPv6, to reduce our effort of introducing IPv6(if it's easier than moving
> to dhcpd). And then we can make the choice in the later release.
>
> John, do you have some experiences can share regarding dhcpd?
>
> Also, regarding your problem, have you used cloudstack to distribute IP? I
> don't think we support leasing on two /28s in advance network now?
So, in my lab env I've made a few changes to the server and UI to allow multiple IP blocks in basic network (haven't tried in advanced yet), then additionally I'm passing a netmask down to the agent, then that's passed through to dhcp_entry.sh, and then into edithosts.sh, which I've updated to support dhcpd. The one thing I wanted to do but haven't is to update edithosts.sh to support both dnsmasq as well as dhcpd.
Note: this was done in-house without community involvement as I didn't expect general interest in this, but I'm happy to use experience gained to write similar support in the ASF tree.
Johh
Re: [ASFCS41] IPv6 Support
Posted by Sheng Yang <sh...@yasker.org>.
On Tue, Jan 8, 2013 at 10:57 PM, John Kinsella <jl...@stratosec.co> wrote:
> On Jan 8, 2013, at 4:38 PM, Sheng Yang <sh...@yasker.org> wrote:
>
> > On Tue, Jan 8, 2013 at 4:31 PM, John Kinsella <jl...@stratosec.co> wrote:
> >
> >>
> >> On Jan 8, 2013, at 4:17 PM, Sheng Yang <sh...@yasker.org>
> >> wrote:
> >>>
> >>> If there is no other opinions, I would begin with DHCPv6 in shared
> >> network
> >>> as first step.
> >>
> >>
> >> Sure, one suggestion: I've been using ISC's dhcpd instead of dnsmasq
> as
> >> they have some silly limitations (in "test" but I keep meaning to
> >> contribute). Might be a good time to switch?
> >>
> >
> > Well, I think dhcpd cannot be using as DNS server. So seems you need to
> > have both dhcpd and dnsmasq running. That's not that convenient as one in
> > all solution…
>
> I have dnsmasq running as a caching DNS resolver but not answering DHCP
> requests. It might not be convenient, but at least it follows the RFC. :)
>
> > And what's the limitation you're talking about regarding dnsmasq?
>
> dnsmasq will only offer leases within a single IP block on a given NIC.
> e.g. if you want to offer leases on two /28s through eth0, dnsmasq can't do
> it.
>
> From a quick glance at it's man page, looks like it can do v4 and v6
> leases at the same time…
>
You mean dhcpd?
I am exploring all the possibility right now.
Currently dnsmasq in our systemvm doesn't support DHCPv6, so we would
either update to a newer version dnsmasq, or using other dhcp server(e.g.
dhcpd) on DHCPv6.
But replacing the dhcp server is a big work, all the configuration need to
be rewritten. Regarding dhcpd, I haven't figured out how much effort we
need to spend if we want to switch.
There is one possible solution for this release: say, using dhcpd only for
IPv6, to reduce our effort of introducing IPv6(if it's easier than moving
to dhcpd). And then we can make the choice in the later release.
John, do you have some experiences can share regarding dhcpd?
Also, regarding your problem, have you used cloudstack to distribute IP? I
don't think we support leasing on two /28s in advance network now?
--Sheng
Re: [ASFCS41] IPv6 Support
Posted by John Kinsella <jl...@stratosec.co>.
On Jan 8, 2013, at 4:38 PM, Sheng Yang <sh...@yasker.org> wrote:
> On Tue, Jan 8, 2013 at 4:31 PM, John Kinsella <jl...@stratosec.co> wrote:
>
>>
>> On Jan 8, 2013, at 4:17 PM, Sheng Yang <sh...@yasker.org>
>> wrote:
>>>
>>> If there is no other opinions, I would begin with DHCPv6 in shared
>> network
>>> as first step.
>>
>>
>> Sure, one suggestion: I've been using ISC's dhcpd instead of dnsmasq as
>> they have some silly limitations (in "test" but I keep meaning to
>> contribute). Might be a good time to switch?
>>
>
> Well, I think dhcpd cannot be using as DNS server. So seems you need to
> have both dhcpd and dnsmasq running. That's not that convenient as one in
> all solution…
I have dnsmasq running as a caching DNS resolver but not answering DHCP requests. It might not be convenient, but at least it follows the RFC. :)
> And what's the limitation you're talking about regarding dnsmasq?
dnsmasq will only offer leases within a single IP block on a given NIC. e.g. if you want to offer leases on two /28s through eth0, dnsmasq can't do it.
From a quick glance at it's man page, looks like it can do v4 and v6 leases at the same time…
Re: [ASFCS41] IPv6 Support
Posted by Sheng Yang <sh...@yasker.org>.
On Tue, Jan 8, 2013 at 4:31 PM, John Kinsella <jl...@stratosec.co> wrote:
>
> On Jan 8, 2013, at 4:17 PM, Sheng Yang <sh...@yasker.org>
> wrote:
> >
> > If there is no other opinions, I would begin with DHCPv6 in shared
> network
> > as first step.
>
>
> Sure, one suggestion: I've been using ISC's dhcpd instead of dnsmasq as
> they have some silly limitations (in "test" but I keep meaning to
> contribute). Might be a good time to switch?
>
Well, I think dhcpd cannot be using as DNS server. So seems you need to
have both dhcpd and dnsmasq running. That's not that convenient as one in
all solution...
And what's the limitation you're talking about regarding dnsmasq?
--Sheng
Re: [ASFCS41] IPv6 Support
Posted by John Kinsella <jl...@stratosec.co>.
On Jan 8, 2013, at 4:17 PM, Sheng Yang <sh...@yasker.org>
wrote:
>
> If there is no other opinions, I would begin with DHCPv6 in shared network
> as first step.
Sure, one suggestion: I've been using ISC's dhcpd instead of dnsmasq as they have some silly limitations (in "test" but I keep meaning to contribute). Might be a good time to switch?
Re: [ASFCS41] IPv6 Support
Posted by Sheng Yang <sh...@yasker.org>.
On Wed, Jan 9, 2013 at 12:48 AM, Wido den Hollander <wi...@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.Vittal@citrix.com> wrote:
>>>
>>>
>>>>
>>>> On 1/3/13 3:20 AM, "Hugo Trippaers" <HTrippaers@schubergphilis.com**>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> -----Original Message-----
>>>>>> From: John Kinsella [mailto:jlk@stratosec.co]
>>>>>> Sent: Wednesday, January 02, 2013 10:05 PM
>>>>>> To: cloudstack-dev@incubator.**apache.org<cl...@incubator.apache.org>
>>>>>> Subject: Re: [ASFCS41] IPv6 Support
>>>>>>
>>>>>> Good comments - keep 'em coming!
>>>>>>
>>>>>> On Jan 2, 2013, at 1:01 AM, Hugo Trippaers
>>>>>> <HTrippaers@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
>>>
>>>
>>
Re: [ASFCS41] IPv6 Support
Posted by Wido den Hollander <wi...@widodh.nl>.
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.Vittal@citrix.com> wrote:
>>
>>>
>>>
>>> On 1/3/13 3:20 AM, "Hugo Trippaers" <HT...@schubergphilis.com>
>>> wrote:
>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: John Kinsella [mailto:jlk@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
>>>>> <HT...@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).
>>
>
> 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.
Wido
> --Sheng
>
>>
>> --Sheng
>>
>
Re: [ASFCS41] IPv6 Support
Posted by Sheng Yang <sh...@yasker.org>.
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.Vittal@citrix.com> wrote:
>
>>
>>
>> On 1/3/13 3:20 AM, "Hugo Trippaers" <HT...@schubergphilis.com>
>> wrote:
>>
>> >
>> >
>> >> -----Original Message-----
>> >> From: John Kinsella [mailto:jlk@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
>> >> <HT...@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).
>
If there is no other opinions, I would begin with DHCPv6 in shared network
as first step.
--Sheng
>
> --Sheng
>
Re: [ASFCS41] IPv6 Support
Posted by Sheng Yang <sh...@yasker.org>.
On Thu, Jan 3, 2013 at 1:59 PM, Chiradeep Vittal <
Chiradeep.Vittal@citrix.com> wrote:
>
>
> On 1/3/13 3:20 AM, "Hugo Trippaers" <HT...@schubergphilis.com> wrote:
>
> >
> >
> >> -----Original Message-----
> >> From: John Kinsella [mailto:jlk@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
> >> <HT...@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).
--Sheng
Re: [ASFCS41] IPv6 Support
Posted by Chiradeep Vittal <Ch...@citrix.com>.
On 1/3/13 3:20 AM, "Hugo Trippaers" <HT...@schubergphilis.com> wrote:
>
>
>> -----Original Message-----
>> From: John Kinsella [mailto:jlk@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
>> <HT...@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
RE: [ASFCS41] IPv6 Support
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
> -----Original Message-----
> From: John Kinsella [mailto:jlk@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
> <HT...@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.
>
> 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.
Re: [ASFCS41] IPv6 Support
Posted by John Kinsella <jl...@stratosec.co>.
Good comments - keep 'em coming!
On Jan 2, 2013, at 1:01 AM, Hugo Trippaers <HT...@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
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...
>> 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...
RE: [ASFCS41] IPv6 Support
Posted by Hugo Trippaers <HT...@schubergphilis.com>.
Heya,
Took the liberty of copying the proposal into email as this makes discussion much easier. Comment inline like a regular email.
> IPv6 Support
>
> 1 Background
> CloudStack does not support IPv6 today. Users/Customers are starting to ask for IPv6 support in CloudStack. With some users running out of IPv4 addresses, this should be a important requirement. With complete IPv6 support, customers would be able to deploy Public/Private clouds on both IPv4 and IPv6 environments
Agreed, we are already running out of IPv4 space today. So I've also been working on getting some IPv6 support into CloudStack, mainly for isolated networks.
>
> 2 Requirements
> Moved all of the requirements from the following JIRA ticket.
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-452
>
> This is quite a large feature, but we are lacking complete IPv6 support at this moment.
>
> We should support IPv6 for:
> - The Management server itself
> - Communication with the Hypervisors
> - Communication with the System VMs
>
> Those three are probably the easiest work, we also need to support IPv6 for instances.
>
> In both the Advanced and Basic zone Instances should be able to get a non-NAT true and native IPv6 address.
>
> We should also not limit them to having one IP, they should be able to get multiple IPv6 addresses.
>
> In the basic zone it can be done pretty easily by having the Virtual Router also hand out IPv6 over DHCPv6 and have your router in the network handle the gateway work.
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.
>
> > In the advanced zone it becomes more difficult.
>
> 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.
>
> But static routing can become a problem, so you might want to use OSPF, LISP or even iBGP for getting those prefixes to the VR.
Not many network admins I know would be comfortable with dynamic routing protocols for this purpose. Especially in a cloud where the number of changes could potentially be very high. (People constantly creating and destroying networks and VR's) This would trigger to much calculations and require serious power of the routers dealing with those networks. With a sizable number of VRs this could cripple the device. Out of the three my vote would be the (i)BGP solution, but I foar more prefer a static setup. The admin prepares a set of "public ip", "route" mappings in the router(s) and the database, CloudStack can then allocate this public ip to a VR and the associated route will be there on the external router to route the traffic. A nice additional feature would be an option to add the external router to the orchestration and dynamically provision and remove the routes.
>
> 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.
>
> In the Advanced Zone you COULD keep everything behind the VR IPv4 and have the VR do IPv6 loadbalancing, but that would still not be true IPv6 connectivity.
This is probably not a good idea :-) In my experience this will work, but give all kinds of unexpected failures (like protocols where the IP is passed inside the protocol). Think about the application that is connected on an IPv4 socket but receives (or is requested to return) an IPv6 addy in the protocol.
>
> 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.
>
> There is no functional spec on this yet, but we have to keep this in mind that we need IPv6 support. People are running out of IPv4 space.
What would be considered a functional spec? I think that there are more than enough use cases to which I can add my personal use case that I can't get an IPv4 allocation to extend the public ip range on one of my clouds at the moment. The shortage is real and causing problems for me already.
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.
>
> 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.
>
> 4 Upgrade Scenarios
> Following upgrade scenarios should be supported:
>
> No upgrade scenarios need to be handled, as this is a new functionality.
We might need to consider a scenario where a user might want to add IPv6 support to an existing network. If we change service offerings to determine support for IPv4 or IPv6 we need to convert existing network offerings to support IPv4.
>
> -----Original Message-----
> From: Manan Shah [mailto:manan.shah@citrix.com]
> Sent: Wednesday, December 19, 2012 8:13 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: [ASFCS41] IPv6 Support
>
> Hi,
>
> I would like to update the existing JIRA ticket on IPv6 support and I have also
> added a requirements page to track this feature. Please provide feedback on
> the requirements.
>
> JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-452
> Requirements:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+Support+in
> +CloudStack
>
> Regards,
> Manan Shah
RE: [ASFCS41] IPv6 Support
Posted by Anthony Xu <Xu...@citrix.com>.
Some questions,
Will CS support IPv6 in basic zone/network?
Does that mean CS support both host and guest IPv6 in 4.1?
Anthony
> -----Original Message-----
> From: Sheng Yang [mailto:sheng@yasker.org]
> Sent: Thursday, December 20, 2012 1:02 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [ASFCS41] IPv6 Support
>
> On Thu, Dec 20, 2012 at 11:45 AM, Sheng Yang <sh...@yasker.org> wrote:
> > On Wed, Dec 19, 2012 at 1:17 PM, Chip Childers
> > <ch...@sungard.com> wrote:
> >> On Wed, Dec 19, 2012 at 4:06 PM, Chiradeep Vittal
> >> <Ch...@citrix.com> wrote:
> >>>
> >>>
> >>> On 12/19/12 12:44 PM, "Chip Childers" <ch...@sungard.com>
> wrote:
> >>>
> >>>>On Wed, Dec 19, 2012 at 3:12 PM, David Nalley <da...@gnsa.us> wrote:
> >>>>> On Wed, Dec 19, 2012 at 3:02 PM, Chiradeep Vittal
> >>>>> <Ch...@citrix.com> wrote:
> >>>>>> Since it is a vast topic, I added subtasks in the Jira bug to
> make it
> >>>>>>more
> >>>>>> manageable.
> >>>>>>
> >>>>>>https://issues.apache.org/jira/browse/CLOUDSTACK-
> 452?subTaskView=all#iss
> >>>>>>uet
> >>>>>> able
> >>>>>>
> >>>>>
> >>>>> This is indeed a massive feature - are you sure that this is
> >>>>> achievable in the 4.1 timeframe???
> >>>>>
> >>>>> --David
> >>>>>
> >>>>
> >>>>I don't see fix versions of the Jira records set to 4.1.0. I'm
> going
> >>>>to set them to the "Future" release as fix version, and if the
> folks
> >>>>developing the feature are able to pull some component into 4.1.0,
> we
> >>>>can discuss that specifically.
> >>>
> >>> I see that the subtasks have been moved into separate bugs. For the
> >>> record, these are
> >>> https://issues.apache.org/jira/browse/CLOUDSTACK-673 to CLOUDSTACK-
> 679
> >>>
> >>>
> >>
> >> They are all still sub tasks of the parent though... I just changed
> >> the fix versions of the parent and child tasks.
> >
> > I think for 4.1, we can get non-isolated network works. Because it
> > only involved DNS and DHCP, should be a nice first step.
> >
> > For LB and firewall, that's much more complex, we can do it later.
> >
> > --Sheng
>
> One question regarding security group in advance network. Anyone has
> an estimate on how much effort it would take to support ipv6 with it?
> If we would have dual stack.
>
> --Sheng
Re: [ASFCS41] IPv6 Support
Posted by Sheng Yang <sh...@yasker.org>.
On Thu, Dec 20, 2012 at 11:45 AM, Sheng Yang <sh...@yasker.org> wrote:
> On Wed, Dec 19, 2012 at 1:17 PM, Chip Childers
> <ch...@sungard.com> wrote:
>> On Wed, Dec 19, 2012 at 4:06 PM, Chiradeep Vittal
>> <Ch...@citrix.com> wrote:
>>>
>>>
>>> On 12/19/12 12:44 PM, "Chip Childers" <ch...@sungard.com> wrote:
>>>
>>>>On Wed, Dec 19, 2012 at 3:12 PM, David Nalley <da...@gnsa.us> wrote:
>>>>> On Wed, Dec 19, 2012 at 3:02 PM, Chiradeep Vittal
>>>>> <Ch...@citrix.com> wrote:
>>>>>> Since it is a vast topic, I added subtasks in the Jira bug to make it
>>>>>>more
>>>>>> manageable.
>>>>>>
>>>>>>https://issues.apache.org/jira/browse/CLOUDSTACK-452?subTaskView=all#iss
>>>>>>uet
>>>>>> able
>>>>>>
>>>>>
>>>>> This is indeed a massive feature - are you sure that this is
>>>>> achievable in the 4.1 timeframe???
>>>>>
>>>>> --David
>>>>>
>>>>
>>>>I don't see fix versions of the Jira records set to 4.1.0. I'm going
>>>>to set them to the "Future" release as fix version, and if the folks
>>>>developing the feature are able to pull some component into 4.1.0, we
>>>>can discuss that specifically.
>>>
>>> I see that the subtasks have been moved into separate bugs. For the
>>> record, these are
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-673 to CLOUDSTACK-679
>>>
>>>
>>
>> They are all still sub tasks of the parent though... I just changed
>> the fix versions of the parent and child tasks.
>
> I think for 4.1, we can get non-isolated network works. Because it
> only involved DNS and DHCP, should be a nice first step.
>
> For LB and firewall, that's much more complex, we can do it later.
>
> --Sheng
One question regarding security group in advance network. Anyone has
an estimate on how much effort it would take to support ipv6 with it?
If we would have dual stack.
--Sheng
Re: [ASFCS41] IPv6 Support
Posted by Sheng Yang <sh...@yasker.org>.
On Wed, Dec 19, 2012 at 1:17 PM, Chip Childers
<ch...@sungard.com> wrote:
> On Wed, Dec 19, 2012 at 4:06 PM, Chiradeep Vittal
> <Ch...@citrix.com> wrote:
>>
>>
>> On 12/19/12 12:44 PM, "Chip Childers" <ch...@sungard.com> wrote:
>>
>>>On Wed, Dec 19, 2012 at 3:12 PM, David Nalley <da...@gnsa.us> wrote:
>>>> On Wed, Dec 19, 2012 at 3:02 PM, Chiradeep Vittal
>>>> <Ch...@citrix.com> wrote:
>>>>> Since it is a vast topic, I added subtasks in the Jira bug to make it
>>>>>more
>>>>> manageable.
>>>>>
>>>>>https://issues.apache.org/jira/browse/CLOUDSTACK-452?subTaskView=all#iss
>>>>>uet
>>>>> able
>>>>>
>>>>
>>>> This is indeed a massive feature - are you sure that this is
>>>> achievable in the 4.1 timeframe???
>>>>
>>>> --David
>>>>
>>>
>>>I don't see fix versions of the Jira records set to 4.1.0. I'm going
>>>to set them to the "Future" release as fix version, and if the folks
>>>developing the feature are able to pull some component into 4.1.0, we
>>>can discuss that specifically.
>>
>> I see that the subtasks have been moved into separate bugs. For the
>> record, these are
>> https://issues.apache.org/jira/browse/CLOUDSTACK-673 to CLOUDSTACK-679
>>
>>
>
> They are all still sub tasks of the parent though... I just changed
> the fix versions of the parent and child tasks.
I think for 4.1, we can get non-isolated network works. Because it
only involved DNS and DHCP, should be a nice first step.
For LB and firewall, that's much more complex, we can do it later.
--Sheng
Re: [ASFCS41] IPv6 Support
Posted by Chip Childers <ch...@sungard.com>.
On Wed, Dec 19, 2012 at 4:06 PM, Chiradeep Vittal
<Ch...@citrix.com> wrote:
>
>
> On 12/19/12 12:44 PM, "Chip Childers" <ch...@sungard.com> wrote:
>
>>On Wed, Dec 19, 2012 at 3:12 PM, David Nalley <da...@gnsa.us> wrote:
>>> On Wed, Dec 19, 2012 at 3:02 PM, Chiradeep Vittal
>>> <Ch...@citrix.com> wrote:
>>>> Since it is a vast topic, I added subtasks in the Jira bug to make it
>>>>more
>>>> manageable.
>>>>
>>>>https://issues.apache.org/jira/browse/CLOUDSTACK-452?subTaskView=all#iss
>>>>uet
>>>> able
>>>>
>>>
>>> This is indeed a massive feature - are you sure that this is
>>> achievable in the 4.1 timeframe???
>>>
>>> --David
>>>
>>
>>I don't see fix versions of the Jira records set to 4.1.0. I'm going
>>to set them to the "Future" release as fix version, and if the folks
>>developing the feature are able to pull some component into 4.1.0, we
>>can discuss that specifically.
>
> I see that the subtasks have been moved into separate bugs. For the
> record, these are
> https://issues.apache.org/jira/browse/CLOUDSTACK-673 to CLOUDSTACK-679
>
>
They are all still sub tasks of the parent though... I just changed
the fix versions of the parent and child tasks.
Re: [ASFCS41] IPv6 Support
Posted by Chiradeep Vittal <Ch...@citrix.com>.
On 12/19/12 12:44 PM, "Chip Childers" <ch...@sungard.com> wrote:
>On Wed, Dec 19, 2012 at 3:12 PM, David Nalley <da...@gnsa.us> wrote:
>> On Wed, Dec 19, 2012 at 3:02 PM, Chiradeep Vittal
>> <Ch...@citrix.com> wrote:
>>> Since it is a vast topic, I added subtasks in the Jira bug to make it
>>>more
>>> manageable.
>>>
>>>https://issues.apache.org/jira/browse/CLOUDSTACK-452?subTaskView=all#iss
>>>uet
>>> able
>>>
>>
>> This is indeed a massive feature - are you sure that this is
>> achievable in the 4.1 timeframe???
>>
>> --David
>>
>
>I don't see fix versions of the Jira records set to 4.1.0. I'm going
>to set them to the "Future" release as fix version, and if the folks
>developing the feature are able to pull some component into 4.1.0, we
>can discuss that specifically.
I see that the subtasks have been moved into separate bugs. For the
record, these are
https://issues.apache.org/jira/browse/CLOUDSTACK-673 to CLOUDSTACK-679
Re: [ASFCS41] IPv6 Support
Posted by Chip Childers <ch...@sungard.com>.
On Wed, Dec 19, 2012 at 3:12 PM, David Nalley <da...@gnsa.us> wrote:
> On Wed, Dec 19, 2012 at 3:02 PM, Chiradeep Vittal
> <Ch...@citrix.com> wrote:
>> Since it is a vast topic, I added subtasks in the Jira bug to make it more
>> manageable.
>> https://issues.apache.org/jira/browse/CLOUDSTACK-452?subTaskView=all#issuet
>> able
>>
>
> This is indeed a massive feature - are you sure that this is
> achievable in the 4.1 timeframe???
>
> --David
>
I don't see fix versions of the Jira records set to 4.1.0. I'm going
to set them to the "Future" release as fix version, and if the folks
developing the feature are able to pull some component into 4.1.0, we
can discuss that specifically.
Re: [ASFCS41] IPv6 Support
Posted by David Nalley <da...@gnsa.us>.
On Wed, Dec 19, 2012 at 3:02 PM, Chiradeep Vittal
<Ch...@citrix.com> wrote:
> Since it is a vast topic, I added subtasks in the Jira bug to make it more
> manageable.
> https://issues.apache.org/jira/browse/CLOUDSTACK-452?subTaskView=all#issuet
> able
>
This is indeed a massive feature - are you sure that this is
achievable in the 4.1 timeframe???
--David
Re: [ASFCS41] IPv6 Support
Posted by Chiradeep Vittal <Ch...@citrix.com>.
Since it is a vast topic, I added subtasks in the Jira bug to make it more
manageable.
https://issues.apache.org/jira/browse/CLOUDSTACK-452?subTaskView=all#issuet
able
On 12/19/12 11:40 AM, "Manan Shah" <ma...@citrix.com> wrote:
>John, as you suggested, I have moved all of the requirements to the
>requirements page.
>
>Regards,
>Manan Shah
>
>
>
>
>On 12/19/12 11:29 AM, "John Kinsella" <jl...@stratosec.co> wrote:
>
>>Personally I'd prefer to put all the info in one place - maybe copy the
>>Jira content into the wiki page.
>>
>>Bringing dynamic routing protocols into the picture worries me, but I
>>haven't thought through the options, yet.
>>
>>Will be happy to test as this progresses - my nets are v6 numbered
>>already, but not being actively used!
>>
>>On Dec 19, 2012, at 11:12 AM, Manan Shah <ma...@citrix.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I would like to update the existing JIRA ticket on IPv6 support and I
>>>have also added a requirements page to track this feature. Please
>>>provide feedback on the requirements.
>>>
>>> JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-452
>>> Requirements:
>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+Support+in+C
>>>l
>>>oudStack
>>
>>
>
Re: [ASFCS41] IPv6 Support
Posted by Manan Shah <ma...@citrix.com>.
John, as you suggested, I have moved all of the requirements to the
requirements page.
Regards,
Manan Shah
On 12/19/12 11:29 AM, "John Kinsella" <jl...@stratosec.co> wrote:
>Personally I'd prefer to put all the info in one place - maybe copy the
>Jira content into the wiki page.
>
>Bringing dynamic routing protocols into the picture worries me, but I
>haven't thought through the options, yet.
>
>Will be happy to test as this progresses - my nets are v6 numbered
>already, but not being actively used!
>
>On Dec 19, 2012, at 11:12 AM, Manan Shah <ma...@citrix.com>
> wrote:
>
>> Hi,
>>
>> I would like to update the existing JIRA ticket on IPv6 support and I
>>have also added a requirements page to track this feature. Please
>>provide feedback on the requirements.
>>
>> JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-452
>> Requirements:
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+Support+in+Cl
>>oudStack
>
>
Re: [ASFCS41] IPv6 Support
Posted by John Kinsella <jl...@stratosec.co>.
Personally I'd prefer to put all the info in one place - maybe copy the Jira content into the wiki page.
Bringing dynamic routing protocols into the picture worries me, but I haven't thought through the options, yet.
Will be happy to test as this progresses - my nets are v6 numbered already, but not being actively used!
On Dec 19, 2012, at 11:12 AM, Manan Shah <ma...@citrix.com>
wrote:
> Hi,
>
> I would like to update the existing JIRA ticket on IPv6 support and I have also added a requirements page to track this feature. Please provide feedback on the requirements.
>
> JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-452
> Requirements: https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+Support+in+CloudStack
[ASFCS41] IPv6 Support
Posted by Manan Shah <ma...@citrix.com>.
Hi,
I would like to update the existing JIRA ticket on IPv6 support and I have also added a requirements page to track this feature. Please provide feedback on the requirements.
JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-452
Requirements: https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+Support+in+CloudStack
Regards,
Manan Shah