Re: LL32 Multihoming

> Stuart talked about a concern regarding IP address collision with one's own 
> interfaces. Since a host CAN validate the source MAC address of the packets 
> that come back it's possible to determine if you're arguing iwth yourself. 
> It's still true someone could spoof your MAC address in an ARP packet to 
> cause damage, but as we know that's a place where ARP has issues, and we 
> can't solve them here.
> 
> Erik, you're talking about reconfiguration based on claims (possibly bogus) 
> of use of IP address. Aside from someone spoofing the MAC address as well, 
> it isn't clear your response aligns with the problem Stuart raised.

Stuart raised multiple points and I'm not sure which one you are concerned
with.

One of them was that it might be helpful for an implementation to checks
its *own* v4ll addresses assigned to its interfaces to avoid assigning
itself the same v4ll address on multiple interfaces. This issue is
local to the implementation and might make a lot of sense for instance
if there are APIs (e.g. IP_MULTICAST_IF) that identify an interface
using an IPv4 address.

Another one was the 2(b) that was quoted, which is to ensure that no remote
v4ll address on any interface conflicts with any v4ll address assigned
to any interface.
This one I think is a bad idea for two reasons:
1. It isn't necessary. A node using v4ll addresses on multiple interfaces
   must have API and application support for always specifying the interface
   to qualify remote v4ll addresses, because even if its local addresses
   don't conflict with any remote address it needs to be able to deal
   with conflicting remote addresses across interfaces.
2. It allows an attacker (or non-malicious brokeness) on one interface to
   disable v4ll on all interfaces on the multihomed node.

   Erik