Re: LL32 Multihoming

Stuart,

This issue reawakens concerns raised by Erik Nordmark which we have
already dealt with in the 'issue resolution process.'

Stuart Cheshire wrote:
 > 2(b). Therefore: It is helpful to ensure that no local interface has
 > an IPv4 address that it identical to *any* peer connected via *any*
 > interface.

We had language like this in the document which was removed because
it gives rise to a new and significant vulnerability. (See LL14)
A host on one link can disrupt hosts on other links (it is not
connected to) if IPv4LL has this property.

Example: Imagine a multihomed host H1 is connected to links 1 and 2.
An attacker is on link 1 and causes H1 to reconfigure by claiming
addresses.  This should only effect link 1, not link 2.  The effects
could be wider than the links immediately connected to the attacker's
multihomed neighbors.  Following the example:  Host H2 is connected to
both link 2 and link 3.  As H1 is forced to reconfigure its address on
link 2 to be unique, this forces H2 to reconfigure as well, which has
consequences on link 3.

LL14 was rejected since LL15 was accepted:  the algorithm being
completely separate on each interface meant that the vulnerability no
longer arises.  Your 2b above conflicts with the accepted LL15 and if
ignored gives rise to the concern in LL14 - which can no longer be 
ignored (rejected.)

Erik