Re: LL32 Multihoming

WG chair hat on

We have rough consensus on this point already.  It would be nice if
the document was as clear as possible.  We should not get derailed
by again considering whether the algorithm can be run without
independence maintained between instances (interfaces) where it is
applied.  This has been ruled out.

WG chair hat off

Philip Nye wrote:
>>From: "Stuart Cheshire" <[email protected]>
>>
>>I wrote that I thought this text was overly simplistic. What precisely
>>does "independently" mean? If the algorithm is run independently on each
>>interface, does that mean it needs to be aware of the other interfaces,
>>or not?

independent (adj) free from the influence, control or determination of
   another or others [Webster's]

If an algorithm is run independently, then it is not aware of others
running the same algorithm.  Since the algorithm prevents assignment
of the same address to two different interfaces, a host running the
algorithm independently on two interfaces would end up with two
distinct addresses.

> The only difference between two interfaces on the same host and two
> interfaces on different hosts is that in the former case communication MAY
> take place internally rather than taking network bandwidth. The algorithm
> need only be aware of other interfaces insofar as it may make life difficult
> for a host if it has the same LL address on multiple interfaces. 

This is a situation which is useful to avoid, as Erik Nordmark pointed
out.  If a host intentionally attempts to configure the same LL address
on more than one interface, the host will be vulnerable to an attack
whereby a conflict on one attached link will result in a reconfiguration
of multiple interfaces.  An attacker would prevent link-local
configuration not only on the link it is attached to, but also on all
links the host was attached to.  Example.

     good====i1 HOST i2======evil

The host attempts to configure address A on interfaces i1 and i2.  Evil
prevents this by responding it owns A.  The host must cycle through
more and more addresses.  The host cannot communicate with good until
it can find an address that is not claimed by evil, which will never
happen.

We did not have to deal with this situation in our security 
considerations section precisely because we stated that hosts
run the address selection algorithm *independently* on each
interface.

 > In this
> case, it is probably a good idea to avoid picking an address which is
> already selected for another interface.
> 
> If the two interfaces happen to be on the same network then the algorithm
> MUST ensure that they get different addresses.
> 
> How about adding the following two paragraphs at the end of section 3.4.
> 
> "In particular ARP packets which appear to claim an address which is
> assigned to a specific interface, indicate conflict only if they are
> received on that interface and their hardware address is of some other
> interface."
> 
> "If a host has two interfaces on the same network, then claiming and
> defending on those interfaces must ensure that they end up with different
> addresses just as if they were on different hosts."

I am OK with this text, but I believe this goes without saying.

Erik