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 Thu, 28 Apr 2016 14:05:27 GMT

> Op 28 april 2016 om 14:22 schreef Nux! <nux@li.nux.ro>:
> 
> 
> Ok Wido, thanks for the clarification, it sounds good.
> 
> From my point of view, if there is a clear relation between IPs and VMs, then as an operator
I am happy.
> 

Yes, there will. So for a POD VLAN you will assing *ONE* IPv6 /64. That gives you roughly
18 trillion addresses to hand out in that POD. Not something will will run out quickly.

With the MAC Address of the Instance you can calculate which address it will obtain. The API
can return that address towards any caller.

So yes, IPv6 address maps to Instance.

Wido

> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> ----- Original Message -----
> > From: "Wido den Hollander" <wido@widodh.nl>
> > To: "Nux!" <nux@li.nux.ro>, dev@cloudstack.apache.org
> > Sent: Thursday, 28 April, 2016 11:41:30
> > Subject: Re: IPv6 progress in Basic Networking
> 
> >> Op 28 april 2016 om 10:50 schreef Nux! <nux@li.nux.ro>:
> >> 
> >> 
> >> Hi, see in-line
> >> 
> >> --
> >> Sent from the Delta quadrant using Borg technology!
> >> 
> >> Nux!
> >> www.nux.ro
> >> 
> >> >>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.
> >> 
> >> Please feel free to correct me, but SLAAC obtained IPv6 addresses will not
> >> always be determinable based on MAC address.
> >> Last I looked at this - because we wanted to somehow use IPv6 in SG zone and
> >> failed :> - some Linux distros and Windows versions can enable privacy
> >> extensions (net.ipv6.conf.all.use_tempaddr).
> >> 
> > 
> > Yes, so a few things are required for the Instances/Templates running. Just like
> > a Instance now has to use DHCP for IPv4 it will have to use SLAAC for IPv6.
> > 
> > All installers right now already support SLAAC. Keep in mind that even if you
> > use Privacy Extensions your system will *ALWAYS* generate the SLAAC address
> > based on the MAC.
> > 
> > Take my desktop here for example:
> > 
> > wido@wido-desktop:~$ ip addr show dev eth0
> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP
> > group default qlen 1000
> >    link/ether c0:3f:d5:68:28:08 brd ff:ff:ff:ff:ff:ff
> >    inet 192.168.5.70/24 brd 192.168.5.255 scope global eth0
> >       valid_lft forever preferred_lft forever
> >    inet6 2001:980:XXX:0:f1ac:3224:c00d:47e4/64 scope global temporary dynamic
> >       valid_lft 7197sec preferred_lft 7197sec
> >    inet6 2001:980:XXX:0:c23f:d5ff:fe68:2808/64 scope global dynamic
> >       valid_lft 7197sec preferred_lft 7197sec
> >    inet6 fe80::c23f:d5ff:fe68:2808/64 scope link
> >       valid_lft forever preferred_lft forever
> > wido@wido-desktop:~$
> > 
> > It generates the temporary address, but next to that it also generates the
> > static address.
> > 
> > For Windows it is easy as well:
> > 
> > netsh interface ipv6 set privacy state=disabled store=persistent
> > netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
> > 
> >> So for the scenario to work, we need to make sure privacy extensions are
> >> switched off - but who knows for how long this will be doable, not to mention
> >> some ISO, PCI etc policies might require it on.
> >> 
> > 
> > As CloudStack we do not have 100% control of the Instances. Same story with IPv4
> > right now. Our docs should just say how to configure a Instance.
> > 
> > But with IPv6 you should also let go of the single address. My proposal is also
> > to enable Prefix Delegation:
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking
> > 
> > Next to the /128 (Single Address) a Instance can get a /60 where it can pick as
> > many random addresses from as it wants.
> > 
> >> Some random reading from the interwebz, he touches on the subject:
> >> https://major.io/2016/04/17/enable-ipv6-privacy-networkmanager/
> >> 
> >> 
> >> IMHO - without knowing all the ugly details behind DHCPv6 and so on - I think
> >> going for DHCP might be the better option in the long run.
> >> 
> > 
> > DHCPv6 is ugly and not properly supported. If we go down that road we suddenly
> > have to:
> > - Store a IPv6 address in a database
> > - Provision a DHCPv6 server
> > 
> > That's additional steps which can fail and make stuff more complex. KISS is want
> > you want.
> > 
> > SLAAC is supported in Linux, *BSD and Windows with EUI-64 based addresses, that
> > is doable.
> > 
> > Again, with IPv4 we currently also require various settings inside the Instance.
> > That will not be different with IPv6.
> > 
> > Wido
> > 
> > > Lucian

Mime
View raw message