Subject: link local address handling while changing hw address of interface

From: Hannes Frederic Sowa <[email-masked]>
Date: Thu, 4 Apr 2013 19:51:50 +0200

Hello!

What is the proposed action if the hardware address of an interface is
changed regarding link-local addresses while the interface is up? I see
a few possibilities here but have not yet found an answer in the rfcs:

a) generate a new link-local interface address in addition to the old one
b) drop the old one and generate a new one
c) don't change any addresses (this is e.g. current behavior in linux)

I would be happy if you could give me some pointers.

Thanks,

  Hannes

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Apr 2013 07:53:43 +0100

> I would be happy if you could give me some pointers.

Does it matter? It seems that all three will work properly.

c) will surely only apply until the interface is restarted; then you
will get b) automatically.

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Fri, 05 Apr 2013 11:30:20 +0200

>  Does it matter? It seems that all three will work properly.

=> I fully agree: RFCs are only about link-local interface ID
generation and as soon as it works no detail really matter.

>  will get b) automatically.

=> note the "restart" is OS dependent. On OSs where the IID is generated
just after board initialization (BSDs for instance) it gives c) which
is IMHO a good solution (simple and, stable).

Regards

[email-masked]

PS: in conclusion this is "implementation dependent" and there is no
(not yet?) a good reason to change this.

---

From: Andrew McGregor <[email-masked]>
Date: Sat, 6 Apr 2013 00:53:48 +1100

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.

Andrew.
On 5 Apr 2013 04:54, "Hannes Frederic Sowa" <[email-masked]>
wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Apr 2013 15:20:14 +0100

On 05/04/2013 14:53, Andrew McGregor wrote:
> made a new interface and so the old address end point has gone away. 

At layer 2, yes, but you haven't done anything at layer 3, and NUD/ND
will pick up the new layer3:layer2 relationship.

> It is

A layer 2 switch will do its thing, but that doesn't affect layer 3.

> link local is therefore pointless, and the Linux behaviour is simply wrong.

It's just a bit lazy, as far as I can see.

    Brian

> ------------------------------------------------------------------------
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 5 Apr 2013 15:35:43 +0000

> At layer 2, yes, but you haven't done anything at layer 3, and NUD/ND will pick up the new layer3:layer2 relationship.

There is also a privacy angle to this. Suppose that a visitor to a café changes their MAC address in order to avoid tracking. Keeping the same IP addresses would somewhat defeat the purpose. Of course, there is always a way to use "ipconfig renew" or some equivalent command, but you have a race condition between "starting to use the new MAC" and "removing the old address." The only way to address that condition is to make MAC change and address renewal an atomic operation.

-- Christian Huitema

---

From: Mark Smith <[email-masked]>
Date: Fri, 5 Apr 2013 14:57:33 -0700 (PDT)

>________________________________
> From: Christian Huitema <[email-masked]>
>To: Brian E Carpenter <[email-masked]>; Andrew McGregor <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Saturday, 6 April 2013 2:35 AM
>Subject: RE: link local address handling while changing hw address of interface
> 
>Some of the modern wired network cards can support multiple unicast destination addresses, mainly to support virtualisation if I understand correctly, although I'm not sure about any 802.11 cards. An interesting idea would be to utilise this capability to cover a transition period between an old MAC address to a new one for privacy reasons. Alternatively most, if not all NICs could be put into promiscuous mode during this transition period to support receiving traffic for the old as well as new MAC address.
>
>Given the recent use of Wifi MAC addresses to supposedly uniquely track visitors to a store, and the far worse than expected level of MAC address global uniqueness that HD Moore discovered, I'd be inclined to start looking at periodically changing my MAC address in public arenas.
>
>
>Regards,
>Mark.
>

---

From: Francis Dupont <[email-masked]>
Date: Sun, 07 Apr 2013 14:21:15 +0200

>  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

---

From: Francis Dupont <[email-masked]>
Date: Sun, 07 Apr 2013 14:25:52 +0200

In your previous mail you wrote:

>  The only way to address that condition is to make MAC change and address
>  renewal an atomic operation.

=> in fact it is not required to be really atomic, only to seem to be
atomic for an external observer (i.e., it is enough to shutdown the NIC
during the operation).

Regards

---

From: Andrew McGregor <[email-masked]>
Date: Mon, 8 Apr 2013 09:13:28 +1000

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.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 08 Apr 2013 10:20:12 +0200

Le 2013-04-08 01:13, Andrew McGregor a écrit :
> 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.

What if I *want* to keep the address? For example, what if I want to 
preserve established TCP sessions?

I think once you start playing with MAC addresses, you are expected to 
know what you're doing. Both generating a new address and keeping the 
old one can be desirable depending on what you want to accomplish. I 
don't see any value in a generic recommendation here, beyond the usual 
"this may void your warranty". ;)

Simon

---

From: Francis Dupont <[email-masked]>
Date: Tue, 09 Apr 2013 09:40:35 +0200

>  MAC-derived address, but it is impolite to continue to use the old link

=> I still believe you assume too much about layer 2 (MAC) and layer 3
(IPv6) address relationship. The worst which can happen is "impolite"
and of course when you mess the MAC addressing you can't expect address
generation based on MAC will still work without conflict.
 BTW a MAC address is attached to a device according to the IEEE spec,
not to an interface, so there is at least one computer vendor who
interprets device as the whole computer, not a NIC...

Regards

PS: the only point IMHO could be standardized (as a BCP) is to use
interface IDs not based on MACs when there are some interests to
change a MAC (it seems common sense, i.e., no need to provide long
explanations). And implementations should give an easy way to do this
(from my past experience this could be more critical).