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

[Philip Homburg <[e-mail]>]

> 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.

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

If you want to group devices in address ranges that are easy to identify,
DHCPv6 can also do this.

SLAAC was meant for the unmanaged situation where devices can generate addresses
without any outside support.