RE: [EXTERNAL] Re: 64bit MAC addresses and SLAAC

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Phil

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> On Behalf Of Philip Homburg
> Sent: jeudi 18 juin 2020 10:20
> To: [e-mail]
> Cc: Pascal Thubert (pthubert) <[e-mail]>
> Subject: Re: [EXTERNAL] Re: 64bit MAC addresses and SLAAC
> 
> > E.g., machines do not have complexes but may be complex to locate and
> > manage. Whether we at 6MAN like it or not, some standards out there
> > tie the role of a device to its IPv6 address, so you can replace the
> > device with a spare, give it the same IPv6 address / keys and keep
> > using it/managing it as you did. Look at ISA100.11a for an example.
> > Note on the side that Internet connectivity is the least of the
> > concerns of a control network. In fact the risk of being connected
> > unknowingly to the Internet is a deterrent for IPv6 adoption (vs.
> > mission - specific and proprietary protocols).
> >
> > Also +1 to Kerry. Some standards (including ours) can do a preferred
> > treatment if the IPv6 address derives from the MAC. Note that this
> > looks antinomic with the spare part goal above; that would indeed be
> > antinomic for burn-in MAC addresses; but there are also standards out
> > there that use a shorter assigned MAC address, e.g., to reduce the
> > frame size and save energy and bandwidth; in that case you can have
> > both properties of deriving the IPv6 address from the MAC and
> > replacing a failing device by a virtually identical one.
> 
> I don't understand the behavior of first picking SLAAC over DHCPv6 and then
> trying to modify SLAAC to do something it is not designed to do.

It does not matter what our preconception is of what SLAAC is for. What matters is what it can do. 

In the case of IPv6 over IEEE 802.15.4, there is a centralized assignment of the short MAC address, and then SLAAC can derive the IP address from that MAC address to enable stateless compression.
Nothing wrong with that if that serves the purpose.

> If you want to have stable addresses with the ability to replace hardware, use
> DHCPv6. It is meant to provide this mapping.

DHCP is an extra round trip. Some standards accept that cost (e.g., Wi-SUN) some will not. Also, in the Wi-SUN case, the device is identified separately with certs and all, and the IPv6 address is assigned later, which is probably cleaner and certainly more expensive.
When people want the address to be known by the management system and associated to the role / position of the device, the easiest is usually the pre-provisioning, and forcing DHCP in that picture is a hard sell. 

Keep safe,

Pascal