cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <w...@widodh.nl>
Subject Re: IPv6 progress in Basic Networking
Date Mon, 25 Apr 2016 11:09:14 GMT

> Op 25 april 2016 om 12:45 schreef Abhinandan Prateek <abhinandan.prateek@shapeblue.com>:
> 
> 
> 
> At shapeblue we are also working towards enabling ipv6 specially for advanced networking/ospf.
> Our approach is more of bottom up where we plan to streamline basic networking entities
and extend them so that they are ipv6 aware. 

Great! Advanced and Basic will indeed overlap much.

Have you read my Wiki page? https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking

My idea is **NOT** to use DHCPv6 (IA_NA), but simply use SLAAC. I found out that DHCPv6 is
still badly supported in most Linux distributions and SLAAC works fine.

It is just important that Privacy Extensions are disabled in the Instance. Otherwise it will
generate temporary IPv6 addresses.

Since we know the MAC address and the /64 prefix we can *calculate* the address a Instance
will take. With that we do not have to store the address in a database.

Security Grouping can be configured accordingly.

No need to configure a DHCPv6 server on deployment of an Instance. It really simplifies life.
Less code is better :)

> This way we ensure that these entities can then be used by both advanced and basic networks.
> Some of that code has already made its way in this PR https://github.com/apache/cloudstack/pull/1371/commits/2156a039cef38a397d15f6186eb515bef59bd45a
.
> 
> This work will have some good overlap, and will be eager to learn and suggest as the
PR progresses.

Looks good. I never work with VPC/Advanced Network, so I wouldn't know.

But inside a VR you would run radvd which will send out Router Advertisements. There is no
need for DHCPv6 either since addresses obtain their IPv6 address using SLAAC.

Wido

>  
> 
> 
> 
> On 20/04/16, 8:54 PM, "Wido den Hollander" <wido@widodh.nl> wrote:
> 
> >Hi,
> >
> >Lately I've been working on IPv6 integration on CloudStack. Not much code has
> >been written (non actually), my work has mainly been getting things straight in
> >my head.
> >
> >Honestly, the work has been focused on the use-case at PCextreme Aurora Compute:
> >- Basic Networking
> >- Single IPv6 address per Instance
> >- Security Grouping on IPv6
> >- IPv6 Prefix Delegation
> >
> >Most of the things are still described here:
> >https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> >
> >What I have working at PCextreme currently is:
> >- IPv6 using SLAAC
> >- DHCPv6 Prefix Delegation using ISC Kea
> >
> >The Kea configuration I'm using for my test is available on Github:
> >https://gist.github.com/wido/202b09dd9999574e016f6e99798036cd
> >
> >On my Instance I'm able to get an address and a prefix:
> >
> >$ ip -6 addr show dev eth0
> >
> >2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> >    inet6 2a00:f10:305:0:432:b2ff:fe00:479/64 scope global dynamic 
> >       valid_lft 2591904sec preferred_lft 604704sec
> >    inet6 fe80::432:b2ff:fe00:479/64 scope link 
> >       valid_lft forever preferred_lft forever
> >
> >$ dhclient -6 -P -d -v eth0
> >
> >RCV: Reply message on eth0 from fe80::8618:8802:c5f6:6029.
> >RCV:  X-- IA_PD b2:00:04:79
> >RCV:  | X-- starts 1461164082
> >RCV:  | X-- t1 - renew  +1000
> >RCV:  | X-- t2 - rebind +2000
> >RCV:  | X-- [Options]
> >RCV:  | | X-- IAPREFIX 2a00:f10:500::/60
> >RCV:  | | | X-- Preferred lifetime 86400.
> >RCV:  | | | X-- Max lifetime 172800.
> >
> >This is know *ALL* happening outside the scope of CloudStack, but my next steps
> >are to start writing code.
> >
> >For IPv6 there is *NO* need to store addresses in a database. Using the /64
> >subnet + the MAC address you can calculate the address the Instance will obtain
> >using SLAAC (Stateless address autoconfiguration).
> >
> >Looking from the database perspective, using the IPv6 information in the 'vlan'
> >and the 'ip6_cidr' field.
> >
> >ip6_cidr should *always* be a /64 and from there you can calculate the
> >Instance's address.
> >
> >The 'listNics' API call can calculate the 'ip6address' for the response. Using
> >the macaddress and the ip6cidr this can easily be calculated.
> >
> >The security grouping part is second, the same goes for the Prefix Delegation
> >support. Those will require more code. But just the IPv6 address in the response
> >is easy to do.
> >
> >This means that DHCPv6 is *ONLY* needed when Prefix Delegation (IA_PD) is used,
> >but otherwise it is just SLAAC. Easy and simple to deploy.
> >
> >Wido
> 
> Regards,
> 
> Abhinandan Prateek
> 
> abhinandan.prateek@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue

Mime
View raw message