WG ACTION: ACCEPT [LL51] Embellish Address Ambiguity problem statement

Erik Guttman <[email protected]> Tue, 30 Mar 2004 17:40:22 +0200 (MEST)
Newsgroups gmane.ietf.zeroconf
Message-ID <Pine.SOL.3.96.1040330173914.27834K-100000@suncc41>
Action: Accept the change.

LL51

Description of Issue: Embellish Address Ambiguity problem statement
Submitter Name:       Alex Zinin
Submitter Email:      [email protected]
Date submitted:       20 Feb 04
Reference:            
(T=tech, E=edit):     T
Priority (S must, 1 Should, 2 May fix): 2
Section:               3.2
Rationale/Explanation: 
Long Description:

> 3.2.  Address Ambiguity
>
>    This is a core problem with respect to Link-Local IPv4 addresses
>    configured on more than one interface. What should a host do when
it
>    needs to send to Link-Local destination L and L can be resolved
using
>    ARP on more than one link?

I would add that even if a given LL address is resolved using just one
link at a given moment, the choice will still be ambiguous without
interface specification, as a second later another host with the same
LL address may become available on another link.

Proposed Change:

Change from:

3.2.  Address Ambiguity

   This is a core problem with respect to Link-Local IPv4 addresses
   configured on more than one interface. What should a host do when it
   needs to send to Link-Local destination L and L can be resolved using
   ARP on more than one link?

To:

3.2.  Address Ambiguity

   This is a core problem with respect to Link-Local IPv4 addresses
   configured on more than one interface. What should a host do when it
   needs to send to Link-Local destination L and L can be resolved using
   ARP on more than one link?  
   
   Even if the address L can be resolved on only one link at a given
   moment, there is no guarantee that it will   remain unambiguous in 
   the future.  Additional hosts on other interfaces may claim the 
   address L as well.