You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Wido den Hollander <wi...@widodh.nl> on 2015/12/18 14:40:00 UTC
Results of a IPv6 brainstorm day
Hi,
Yesterday we from PCextreme, Leaseweb and Schuberg Phillis sat down for
a IPv6 brainstorm session.
We asked a good IPv6 consultant (Sander Steffann) to join us to help us
identify some glitches in our ideas.
We had two ideas:
-
https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
- https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Router
Overall, our ideas looked good, our main concern was security grouping.
How to prevent clients from spoofing and such.
I updated the spec for the Basic Networking with those ideas.
A few things worth noting:
- Link-Local traffic should be allowed for specific ICMPv6-only. No UDP
or TCP!
- A DUID can not be trusted. We need a tagger on the HV which adds the
MAC address as DHCPv6 option 37.
- SLAAC can not be used. DHCPv6+IA only
- We can assign multiple IPs and Prefixes via DHCPv6
- ISC Kea seems very nice as a DHCPv6 server: http://kea.isc.org/wiki
A few RFCs which might be worth reading:
- https://www.ietf.org/rfc/rfc4890.txt
- https://tools.ietf.org/html/rfc6939
- https://tools.ietf.org/html/rfc4861
We will start to work on this, but the CloudStack core is still very,
very, very IPv4 minded and this will need a lot of refactoring.
However, once you understand IPv6 better it is much more simple then
IPv4 imho.
The end goal is that CloudStack can run on IPv6-only without ANY IPv4.
What also resulted from this day:
- Basic Networking can probably be merged with Advanced Networking with
Direct Attached
- Isolated Networks are about the same as a VPC
- We might be able to ditch the SSVM in most situations
Any way, enough work to do!
Wido
Re: Results of a IPv6 brainstorm day
Posted by Daan Hoogland <da...@gmail.com>.
Wido, consider me in. My main objective btw is to give users the
possibility to run there VMs IPv6 only. The management layer is not such a
biggy.
I am still reading up on those rfcs and all the links in them.
On Tue, Dec 22, 2015 at 11:17 AM, Wido den Hollander <wi...@widodh.nl> wrote:
>
>
> On 12/22/2015 04:35 AM, Ian Rae wrote:
> > Great to hear, next time I am happy to commit an engineer from CloudOps
> to
> > participate. We have done quite a bit of work around VPC and also need to
> > solve for IPv6 soon.
> >
> > Thanks for sharing, great initiative/goal and I will make sure the
> CloudOps
> > team reviews and supports this.
> >
>
> Great! The first challenge will be to get the core of ACS aware of IPv6.
> Pass IP addresses is InetAddress instead of a String, etc, etc.
>
> I don't know if a very big team can work on this without very short
> communication between the different people.
>
> But again, any help is appreciated! We need this to go in.
>
> Wido
>
> > On Friday, December 18, 2015, Wido den Hollander <wi...@widodh.nl> wrote:
> >
> >> Hi,
> >>
> >> Yesterday we from PCextreme, Leaseweb and Schuberg Phillis sat down for
> >> a IPv6 brainstorm session.
> >>
> >> We asked a good IPv6 consultant (Sander Steffann) to join us to help us
> >> identify some glitches in our ideas.
> >>
> >> We had two ideas:
> >> -
> >>
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> >> -
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Router
> >>
> >> Overall, our ideas looked good, our main concern was security grouping.
> >> How to prevent clients from spoofing and such.
> >>
> >> I updated the spec for the Basic Networking with those ideas.
> >>
> >> A few things worth noting:
> >> - Link-Local traffic should be allowed for specific ICMPv6-only. No UDP
> >> or TCP!
> >> - A DUID can not be trusted. We need a tagger on the HV which adds the
> >> MAC address as DHCPv6 option 37.
> >> - SLAAC can not be used. DHCPv6+IA only
> >> - We can assign multiple IPs and Prefixes via DHCPv6
> >> - ISC Kea seems very nice as a DHCPv6 server: http://kea.isc.org/wiki
> >>
> >> A few RFCs which might be worth reading:
> >> - https://www.ietf.org/rfc/rfc4890.txt
> >> - https://tools.ietf.org/html/rfc6939
> >> - https://tools.ietf.org/html/rfc4861
> >>
> >> We will start to work on this, but the CloudStack core is still very,
> >> very, very IPv4 minded and this will need a lot of refactoring.
> >>
> >> However, once you understand IPv6 better it is much more simple then
> >> IPv4 imho.
> >>
> >> The end goal is that CloudStack can run on IPv6-only without ANY IPv4.
> >>
> >> What also resulted from this day:
> >> - Basic Networking can probably be merged with Advanced Networking with
> >> Direct Attached
> >> - Isolated Networks are about the same as a VPC
> >> - We might be able to ditch the SSVM in most situations
> >>
> >> Any way, enough work to do!
> >>
> >> Wido
> >>
> >
> >
>
--
Daan
Re: Results of a IPv6 brainstorm day
Posted by Wido den Hollander <wi...@widodh.nl>.
> Op 10 maart 2016 om 22:54 schreef Erik Weber <te...@gmail.com>:
>
>
> On Thu, Mar 10, 2016 at 10:31 PM, Wido den Hollander <wi...@widodh.nl> wrote:
>
> >
> > > Op 10 maart 2016 om 21:15 schreef John Burwell <
> > john.burwell@shapeblue.com>:
> > >
> > >
> > > Wido,
> > >
> > > Curious if you have been able to make any progress on this work. Have
> > you been
> > > able to move it forward? If not, what kind of help would you need?
> > >
> >
> > Yes. Not so much in code inside CloudStack, but mainly in figuring out
> > DHCPv6
> > stuff and searching for the right components.
> >
> > The DHCPv6 part is something that I would like to see handled by Kea.
> > Blogged
> > about my tests with Kea:
> > http://blog.widodh.nl/2016/02/isc-kea-dhcpv6-server/
> >
> >
> AFAIK dnsmasq should support DHCPv6 leases based on MAC-addresses as well,
> should ease the transition a bit to not have to switch the software inside
> the VR.
>
True, but it lacks various things like Prefix Delegeation.
KEA also supports a (SQL) database backend for storing leases and reservations,
something dnsmasq can not do.
Also, Kea supports reservations based on the MAC where dnsmasq only supports
DUID.
Wido
> --
> Erik
Re: Results of a IPv6 brainstorm day
Posted by Erik Weber <te...@gmail.com>.
On Thu, Mar 10, 2016 at 10:31 PM, Wido den Hollander <wi...@widodh.nl> wrote:
>
> > Op 10 maart 2016 om 21:15 schreef John Burwell <
> john.burwell@shapeblue.com>:
> >
> >
> > Wido,
> >
> > Curious if you have been able to make any progress on this work. Have
> you been
> > able to move it forward? If not, what kind of help would you need?
> >
>
> Yes. Not so much in code inside CloudStack, but mainly in figuring out
> DHCPv6
> stuff and searching for the right components.
>
> The DHCPv6 part is something that I would like to see handled by Kea.
> Blogged
> about my tests with Kea:
> http://blog.widodh.nl/2016/02/isc-kea-dhcpv6-server/
>
>
AFAIK dnsmasq should support DHCPv6 leases based on MAC-addresses as well,
should ease the transition a bit to not have to switch the software inside
the VR.
--
Erik
Re: Results of a IPv6 brainstorm day
Posted by Wido den Hollander <wi...@widodh.nl>.
> Op 10 maart 2016 om 21:15 schreef John Burwell <jo...@shapeblue.com>:
>
>
> Wido,
>
> Curious if you have been able to make any progress on this work. Have you been
> able to move it forward? If not, what kind of help would you need?
>
Yes. Not so much in code inside CloudStack, but mainly in figuring out DHCPv6
stuff and searching for the right components.
The DHCPv6 part is something that I would like to see handled by Kea. Blogged
about my tests with Kea: http://blog.widodh.nl/2016/02/isc-kea-dhcpv6-server/
The security grouping part could be done by libvirt:
* https://issues.apache.org/jira/browse/CLOUDSTACK-1164
*
http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201601.mbox/%3C568CE637.4000507%40widodh.nl%3E
This supports both IPv4 and IPv6. So this combined brings us to:
- Kea for DHCPv6
- Libvirt for KVM Security Grouping
I haven't gotten to writing any actual code since this mainly means that a MAJOR
overhaul is needed of the internals of CloudStack. All the code now assumes IPv4
addresses in there...
Wido
> Thanks,
> -John
>
> >
>
> [ShapeBlue]<http://www.shapeblue.com>
> John Burwell
> ShapeBlue
>
> d: +44 (20) 3603 0542 | s: +1 (571) 403-2411
> <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>
>
> e: john.burwell@shapeblue.com | t:
> <mailto:john.burwell@shapeblue.com%20|%20t:> | w:
> www.shapeblue.com<http://www.shapeblue.com>
>
> a: 53 Chandos Place, Covent Garden London WC2N 4HS UK
>
>
> [cid:imagefbc38a.png@a8508906.4c973695]
>
>
> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
> Services India LLP is a company incorporated in India and is operated under
> license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company
> incorporated in Brasil and is operated under license from Shape Blue Ltd.
> ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa
> and is traded under license from Shape Blue Ltd. ShapeBlue is a registered
> trademark.
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based upon
> its contents, nor copy or show it to anyone. Please contact the sender if you
> believe you have received this email in error.
>
>
>
>
> On Dec 22, 2015, at 5:17 AM, Wido den Hollander <wi...@widodh.nl> wrote:
> >
> >
> >
> > On 12/22/2015 04:35 AM, Ian Rae wrote:
> >> Great to hear, next time I am happy to commit an engineer from CloudOps to
> >> participate. We have done quite a bit of work around VPC and also need to
> >> solve for IPv6 soon.
> >>
> >> Thanks for sharing, great initiative/goal and I will make sure the CloudOps
> >> team reviews and supports this.
> >>
> >
> > Great! The first challenge will be to get the core of ACS aware of IPv6.
> > Pass IP addresses is InetAddress instead of a String, etc, etc.
> >
> > I don't know if a very big team can work on this without very short
> > communication between the different people.
> >
> > But again, any help is appreciated! We need this to go in.
> >
> > Wido
> >
> >> On Friday, December 18, 2015, Wido den Hollander <wi...@widodh.nl> wrote:
> >>
> >>> Hi,
> >>>
> >>> Yesterday we from PCextreme, Leaseweb and Schuberg Phillis sat down for
> >>> a IPv6 brainstorm session.
> >>>
> >>> We asked a good IPv6 consultant (Sander Steffann) to join us to help us
> >>> identify some glitches in our ideas.
> >>>
> >>> We had two ideas:
> >>> -
> >>>
> >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> >>> -
> >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Router
> >>>
> >>> Overall, our ideas looked good, our main concern was security grouping.
> >>> How to prevent clients from spoofing and such.
> >>>
> >>> I updated the spec for the Basic Networking with those ideas.
> >>>
> >>> A few things worth noting:
> >>> - Link-Local traffic should be allowed for specific ICMPv6-only. No UDP
> >>> or TCP!
> >>> - A DUID can not be trusted. We need a tagger on the HV which adds the
> >>> MAC address as DHCPv6 option 37.
> >>> - SLAAC can not be used. DHCPv6+IA only
> >>> - We can assign multiple IPs and Prefixes via DHCPv6
> >>> - ISC Kea seems very nice as a DHCPv6 server: http://kea.isc.org/wiki
> >>>
> >>> A few RFCs which might be worth reading:
> >>> - https://www.ietf.org/rfc/rfc4890.txt
> >>> - https://tools.ietf.org/html/rfc6939
> >>> - https://tools.ietf.org/html/rfc4861
> >>>
> >>> We will start to work on this, but the CloudStack core is still very,
> >>> very, very IPv4 minded and this will need a lot of refactoring.
> >>>
> >>> However, once you understand IPv6 better it is much more simple then
> >>> IPv4 imho.
> >>>
> >>> The end goal is that CloudStack can run on IPv6-only without ANY IPv4.
> >>>
> >>> What also resulted from this day:
> >>> - Basic Networking can probably be merged with Advanced Networking with
> >>> Direct Attached
> >>> - Isolated Networks are about the same as a VPC
> >>> - We might be able to ditch the SSVM in most situations
> >>>
> >>> Any way, enough work to do!
> >>>
> >>> Wido
> >>>
> >>
> >>
>
> Find out more about ShapeBlue and our range of CloudStack related services:
> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> |
> CloudStack Software
> Engineering<http://shapeblue.com/cloudstack-software-engineering/>
> CloudStack Infrastructure
> Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack
> Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
Re: Results of a IPv6 brainstorm day
Posted by John Burwell <jo...@shapeblue.com>.
Wido,
Curious if you have been able to make any progress on this work. Have you been able to move it forward? If not, what kind of help would you need?
Thanks,
-John
>
[ShapeBlue]<http://www.shapeblue.com>
John Burwell
ShapeBlue
d: +44 (20) 3603 0542 | s: +1 (571) 403-2411 <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411>
e: john.burwell@shapeblue.com | t: <mailto:john.burwell@shapeblue.com%20|%20t:> | w: www.shapeblue.com<http://www.shapeblue.com>
a: 53 Chandos Place, Covent Garden London WC2N 4HS UK
[cid:imagefbc38a.png@a8508906.4c973695]
Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.
On Dec 22, 2015, at 5:17 AM, Wido den Hollander <wi...@widodh.nl> wrote:
>
>
>
> On 12/22/2015 04:35 AM, Ian Rae wrote:
>> Great to hear, next time I am happy to commit an engineer from CloudOps to
>> participate. We have done quite a bit of work around VPC and also need to
>> solve for IPv6 soon.
>>
>> Thanks for sharing, great initiative/goal and I will make sure the CloudOps
>> team reviews and supports this.
>>
>
> Great! The first challenge will be to get the core of ACS aware of IPv6.
> Pass IP addresses is InetAddress instead of a String, etc, etc.
>
> I don't know if a very big team can work on this without very short
> communication between the different people.
>
> But again, any help is appreciated! We need this to go in.
>
> Wido
>
>> On Friday, December 18, 2015, Wido den Hollander <wi...@widodh.nl> wrote:
>>
>>> Hi,
>>>
>>> Yesterday we from PCextreme, Leaseweb and Schuberg Phillis sat down for
>>> a IPv6 brainstorm session.
>>>
>>> We asked a good IPv6 consultant (Sander Steffann) to join us to help us
>>> identify some glitches in our ideas.
>>>
>>> We had two ideas:
>>> -
>>>
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
>>> -
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Router
>>>
>>> Overall, our ideas looked good, our main concern was security grouping.
>>> How to prevent clients from spoofing and such.
>>>
>>> I updated the spec for the Basic Networking with those ideas.
>>>
>>> A few things worth noting:
>>> - Link-Local traffic should be allowed for specific ICMPv6-only. No UDP
>>> or TCP!
>>> - A DUID can not be trusted. We need a tagger on the HV which adds the
>>> MAC address as DHCPv6 option 37.
>>> - SLAAC can not be used. DHCPv6+IA only
>>> - We can assign multiple IPs and Prefixes via DHCPv6
>>> - ISC Kea seems very nice as a DHCPv6 server: http://kea.isc.org/wiki
>>>
>>> A few RFCs which might be worth reading:
>>> - https://www.ietf.org/rfc/rfc4890.txt
>>> - https://tools.ietf.org/html/rfc6939
>>> - https://tools.ietf.org/html/rfc4861
>>>
>>> We will start to work on this, but the CloudStack core is still very,
>>> very, very IPv4 minded and this will need a lot of refactoring.
>>>
>>> However, once you understand IPv6 better it is much more simple then
>>> IPv4 imho.
>>>
>>> The end goal is that CloudStack can run on IPv6-only without ANY IPv4.
>>>
>>> What also resulted from this day:
>>> - Basic Networking can probably be merged with Advanced Networking with
>>> Direct Attached
>>> - Isolated Networks are about the same as a VPC
>>> - We might be able to ditch the SSVM in most situations
>>>
>>> Any way, enough work to do!
>>>
>>> Wido
>>>
>>
>>
Find out more about ShapeBlue and our range of CloudStack related services:
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
Re: Results of a IPv6 brainstorm day
Posted by Wido den Hollander <wi...@widodh.nl>.
On 12/22/2015 04:35 AM, Ian Rae wrote:
> Great to hear, next time I am happy to commit an engineer from CloudOps to
> participate. We have done quite a bit of work around VPC and also need to
> solve for IPv6 soon.
>
> Thanks for sharing, great initiative/goal and I will make sure the CloudOps
> team reviews and supports this.
>
Great! The first challenge will be to get the core of ACS aware of IPv6.
Pass IP addresses is InetAddress instead of a String, etc, etc.
I don't know if a very big team can work on this without very short
communication between the different people.
But again, any help is appreciated! We need this to go in.
Wido
> On Friday, December 18, 2015, Wido den Hollander <wi...@widodh.nl> wrote:
>
>> Hi,
>>
>> Yesterday we from PCextreme, Leaseweb and Schuberg Phillis sat down for
>> a IPv6 brainstorm session.
>>
>> We asked a good IPv6 consultant (Sander Steffann) to join us to help us
>> identify some glitches in our ideas.
>>
>> We had two ideas:
>> -
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
>> -
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Router
>>
>> Overall, our ideas looked good, our main concern was security grouping.
>> How to prevent clients from spoofing and such.
>>
>> I updated the spec for the Basic Networking with those ideas.
>>
>> A few things worth noting:
>> - Link-Local traffic should be allowed for specific ICMPv6-only. No UDP
>> or TCP!
>> - A DUID can not be trusted. We need a tagger on the HV which adds the
>> MAC address as DHCPv6 option 37.
>> - SLAAC can not be used. DHCPv6+IA only
>> - We can assign multiple IPs and Prefixes via DHCPv6
>> - ISC Kea seems very nice as a DHCPv6 server: http://kea.isc.org/wiki
>>
>> A few RFCs which might be worth reading:
>> - https://www.ietf.org/rfc/rfc4890.txt
>> - https://tools.ietf.org/html/rfc6939
>> - https://tools.ietf.org/html/rfc4861
>>
>> We will start to work on this, but the CloudStack core is still very,
>> very, very IPv4 minded and this will need a lot of refactoring.
>>
>> However, once you understand IPv6 better it is much more simple then
>> IPv4 imho.
>>
>> The end goal is that CloudStack can run on IPv6-only without ANY IPv4.
>>
>> What also resulted from this day:
>> - Basic Networking can probably be merged with Advanced Networking with
>> Direct Attached
>> - Isolated Networks are about the same as a VPC
>> - We might be able to ditch the SSVM in most situations
>>
>> Any way, enough work to do!
>>
>> Wido
>>
>
>
Re: Results of a IPv6 brainstorm day
Posted by Ian Rae <ir...@cloudops.com>.
Great to hear, next time I am happy to commit an engineer from CloudOps to
participate. We have done quite a bit of work around VPC and also need to
solve for IPv6 soon.
Thanks for sharing, great initiative/goal and I will make sure the CloudOps
team reviews and supports this.
On Friday, December 18, 2015, Wido den Hollander <wi...@widodh.nl> wrote:
> Hi,
>
> Yesterday we from PCextreme, Leaseweb and Schuberg Phillis sat down for
> a IPv6 brainstorm session.
>
> We asked a good IPv6 consultant (Sander Steffann) to join us to help us
> identify some glitches in our ideas.
>
> We had two ideas:
> -
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> -
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Router
>
> Overall, our ideas looked good, our main concern was security grouping.
> How to prevent clients from spoofing and such.
>
> I updated the spec for the Basic Networking with those ideas.
>
> A few things worth noting:
> - Link-Local traffic should be allowed for specific ICMPv6-only. No UDP
> or TCP!
> - A DUID can not be trusted. We need a tagger on the HV which adds the
> MAC address as DHCPv6 option 37.
> - SLAAC can not be used. DHCPv6+IA only
> - We can assign multiple IPs and Prefixes via DHCPv6
> - ISC Kea seems very nice as a DHCPv6 server: http://kea.isc.org/wiki
>
> A few RFCs which might be worth reading:
> - https://www.ietf.org/rfc/rfc4890.txt
> - https://tools.ietf.org/html/rfc6939
> - https://tools.ietf.org/html/rfc4861
>
> We will start to work on this, but the CloudStack core is still very,
> very, very IPv4 minded and this will need a lot of refactoring.
>
> However, once you understand IPv6 better it is much more simple then
> IPv4 imho.
>
> The end goal is that CloudStack can run on IPv6-only without ANY IPv4.
>
> What also resulted from this day:
> - Basic Networking can probably be merged with Advanced Networking with
> Direct Attached
> - Isolated Networks are about the same as a VPC
> - We might be able to ditch the SSVM in most situations
>
> Any way, enough work to do!
>
> Wido
>
--
Ian Rae
CEO | PDG
c: 514.944.4008
CloudOps | Cloud Infrastructure and Networking Solutions
www.cloudops.com | 420 rue Guy | Montreal | Canada | H3J 1S6
Re: Results of a IPv6 brainstorm day
Posted by ilya <il...@gmail.com>.
Wido
Thanks for the detailed update!
On 12/18/15 5:40 AM, Wido den Hollander wrote:
> Hi,
>
> Yesterday we from PCextreme, Leaseweb and Schuberg Phillis sat down for
> a IPv6 brainstorm session.
>
> We asked a good IPv6 consultant (Sander Steffann) to join us to help us
> identify some glitches in our ideas.
>
> We had two ideas:
> -
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> - https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+VPC+Router
>
> Overall, our ideas looked good, our main concern was security grouping.
> How to prevent clients from spoofing and such.
>
> I updated the spec for the Basic Networking with those ideas.
>
> A few things worth noting:
> - Link-Local traffic should be allowed for specific ICMPv6-only. No UDP
> or TCP!
> - A DUID can not be trusted. We need a tagger on the HV which adds the
> MAC address as DHCPv6 option 37.
> - SLAAC can not be used. DHCPv6+IA only
> - We can assign multiple IPs and Prefixes via DHCPv6
> - ISC Kea seems very nice as a DHCPv6 server: http://kea.isc.org/wiki
>
> A few RFCs which might be worth reading:
> - https://www.ietf.org/rfc/rfc4890.txt
> - https://tools.ietf.org/html/rfc6939
> - https://tools.ietf.org/html/rfc4861
>
> We will start to work on this, but the CloudStack core is still very,
> very, very IPv4 minded and this will need a lot of refactoring.
>
> However, once you understand IPv6 better it is much more simple then
> IPv4 imho.
>
> The end goal is that CloudStack can run on IPv6-only without ANY IPv4.
>
> What also resulted from this day:
> - Basic Networking can probably be merged with Advanced Networking with
> Direct Attached
> - Isolated Networks are about the same as a VPC
> - We might be able to ditch the SSVM in most situations
>
> Any way, enough work to do!
>
> Wido
>