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 Thu, 28 Apr 2016 08:17:33 GMT
On 25/04/16, 4:39 PM, "Wido den Hollander" <wido@widodh.nl> wrote:



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

Doing bit of research on this makes me believe that this is a preferred way of getting ipv6
address for the instance. Was wondering why we cannot do the same for ipV4, but there I guess
we will run into uniqueness issue.

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

Regards,

AbhinandanĀ Prateek

abhinandan.prateek@shapeblue.comĀ 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
Mime
View raw message