There is an issue with using a MAC-based link local address on an interface that does not have that MAC address, which is that any other interface using that MAC that turns up is going to fail DAD. Normally this will be another interface on the same device, but even then it can be an issue. Therefore it is better guidance to say that one should simply change link locals at the time one changes the MAC address... not necessarily to a MAC-derived address, but it is impolite to continue to use the old link local.
On Sun, Apr 7, 2013 at 10:21 PM, Francis Dupont <francis.dup...@fdupont.fr>wrote: > In your previous mail you wrote: > > > B) is usually correct, although this depends on the semantics of the > lower > > layer in question. If it is Ethernet, by changing the MAC address, you > have > > made a new interface and so the old address end point has gone away. It > is > > usually best to drop the link and restart layer 2 at that point, as any > > switch you are connected to will flush the necessary tables at that > point, > > giving the best chance of being left in a working state. Deprecating the > > link local is therefore pointless, and the Linux behaviour is simply > wrong. > > => I deeply disagree: you assume a binding between layers 2 and 3, in > particular between addresses, which does *not* exist. There is no issue > to use any legal link-local address on a particular Ethernet device, > and this is fully independent of the MAC address. > > Regards > > francis.dup...@fdupont.fr >
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
