> Op 28 april 2016 om 10:50 schreef Nux! <[email protected]>:
>
>
> 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
