On 25/04/16, 4:39 PM, "Wido den Hollander" <w...@widodh.nl> wrote:
> >> Op 25 april 2016 om 12:45 schreef Abhinandan Prateek >> <abhinandan.prat...@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" <w...@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.prat...@shapeblue.com >> www.shapeblue.com >> 53 Chandos Place, Covent Garden, London WC2N 4HSUK >> @shapeblue Regards, Abhinandan Prateek abhinandan.prat...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
