RE: 64bit MAC addresses and SLAAC

Hi Pascal,

> It's not just DAD, it's the whole ND system that has aged and needs a lifting.

I don't think there is any need for changes to ND [RFC4861].

> Think wireless, overlays, NBMA meshes, large L2 domains...

We have all of these aspects covered under the AERO/OMNI approach using ND
per RFC4861 and with a new NBMA interface type.

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
> Sent: Friday, June 19, 2020 6:54 AM
> To: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>; ipv6@ietf.org
> Subject: RE: 64bit MAC addresses and SLAAC
> 
> > > >
> > > Is this really, deep down, the nature of SLAAC? Or the consequence of
> > > not having a very fast and reliable DAD? Arguably one could autoconfig
> > > even IPv4 within a /24 if there's a broker that serializes the
> > > requests and rejects the duplicates.
> >
> > We have that broker, it is called DHCPv6.
> 
> As of today? Depending on what you expect from that broker, e.g., who gets to select the IID, can you use the broker for Address
> Resolution, etc...
> DHCP is a swiss knife. With a few more blades it would fit the bill nicely. ND could too. There are other candidates but I'd rather
> upgrade those two to start with.
> 
> >
> > Absent such a centralized service, a host would have a hard time proving that a
> > address unique, for example, there might be a network split.
> 
> We agree
> 
> > Current DAD is certainly not good enough if there are regular address collisions
> 
> 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.
> 
> > and I doubt anybody is willing to come up with a better DAD just to have nicer
> > looking addresses in SLAAC.
> 
> 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...
> 
> Keep safe;
> 
> Pascal
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------