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.