cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhinandan Prateek <abhinandan.prat...@shapeblue.com>
Subject Re: IPv6 progress in Basic Networking
Date Mon, 25 Apr 2016 10:45:02 GMT

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. 
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.
 



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