Re: 64bit MAC addresses and SLAAC

[Philip Homburg <[e-mail]>]

> > We have that broker, it is called DHCPv6.
> 
> As of today? 

I don't think the protocol has any limitations in this regard. I.e,
a host could wait for an RA with a PIO option, generate an address and then
use DHCPv6 to obtain that address.

Whether any host does that or any dhcp server supports it is a different 
question. It doesn't need protocol changes.

> Depending on what you expect from that broker, e.g.,
> who gets to select the IID, 

The host can propose an IID, the DHCPv6 server is the final authority.

> can you use the broker for Address
> Resolution, etc...  

Obviously, DHCPv6 is not going to do address resolution.

> > Current DAD is certainly not good enough if there are regular address colli
> sions
> 
> Define "regular". I will agree if it is the opposite of quasi-impossible,
> which is how we get SLAAC to work.  Thus your original shortcut
> that SLAAC=>randomIID though deep down it does not, it's just how
> we do it with distributed DAD.

Current SLAAC has to work with current DAD. Only after we change DAD, we can
consider changing SLAAC. 

Having two hosts with the same IP address on a subnet is very hard to 
troubleshoot. So we have to keep the chance of that happening very low.

Using 64-bit pseudo random numbers is a very effective way of doing that.

> It's not just DAD, it's the whole ND system that has aged and needs
> a lifting. Think wireless, overlays, NBMA meshes, large L2 domains...

Address resolution using multicast can trivially be disabled
(except for link local) by marking prefixes as offlink.

I think that offers plenty of flexibility.