new issue: [LL39] Remove multiple interface discussion from probe details

We need to evaluate whether to make this change.

===========================================================================
Description of Issue  Remove multiple interface discussion from probe 
details
Submitter Name  Thomas Narten
Submitter Email Address  [email protected]
Date first submitted  04 Nov 03
Reference
Comment Type ['T'echnical | 'E'ditorial]  T
Priority ['S' Must fix | '1' Should fix | '2' May fix ]  S
Section  2.2.1
Rationale/Explanation of issue:
Lengthy description of problem:

1)

 > If during this period, from the beginning of the probing process
 > until PROBE_MAX seconds after the last probe packet is sent, the host
 > receives any ARP packet (Request *or* Reply) where the packet's

including ARP packets on other interfaces?


----------------

2)


 > ³sender IP address' is the address being probed for, then the host
 > MUST treat this address as being in use by some other host, and MUST
 > select a new pseudo-random address and repeat the process. In
 > addition, if during this period the host receives any ARP probe where
 > the packet's 'target IP address' is the address being probed for, and
 > the packet's 'sender hardware address' is not the hardware address of
 > any of the host's interfaces, then the host MUST similarly treat this
 > as an address collision and select a new address as above. This can
 > occur if two (or more) hosts attempt to configure the same Link-Local
 > IPv4 address at the same time.


Can we remove the wording that talks about multiple interfaces? This
document should really assume that the algorithm runs on a single
interface, leaving all multi-homing issues to Section 3 (since we
aren't being complete). The above is actually wrong, in some sense,
because if an implementation is stupid enough to try and configure the
same LL address on multiple interfaces that are attached to the same
link, it will not detect the problem above, when it maybe
should... Text later in the document suggests the same address on
multiple interfaces should be treated as an error.

(note: same wording appears later in document)


------------------------


3)


 > Care must be taken if a multihomed host can support more than one
 > interface on the same link, all of which support Link-Local IPv4
 > autoconfiguration. If these interfaces attempt to allocate the same
 > address, they will defend the host against itself - causing the
 > claiming algorithm to fail. The simplest solution to this problem is
 > to run the algorithm independently on each interface configured with
 > Link-Local IPv4 addresses.


Not according to the algorithm, per above...

Requested Change:

1) Change 2.2.1 text



If during this period, from the beginning of the probing process
until PROBE_MAX seconds after the last probe packet is sent, the host
receives any ARP packet (Request *or* Reply) where the packet's
'sender IP address' is the address being probed for, then the host
MUST treat this address as being in use by some other host, and MUST
select a new pseudo-random address and repeat the process.

to

If during this period, from the beginning of the probing process
until PROBE_MAX seconds after the last probe packet is sent, the host
receives any ARP packet (Request *or* Reply)

on the interface where the probe is being performed

where the packet's
'sender IP address' is the address being probed for, then the host
MUST treat this address as being in use by some other host, and MUST
select a new pseudo-random address and repeat the process.

-----------------------

2) Change 2.2.1 text

In
addition, if during this period the host receives any ARP probe where
the packet's 'target IP address' is the address being probed for, and
the packet's 'sender hardware address' is not the hardware address of
any of the host's interfaces, then the host MUST similarly treat this
as an address collision and select a new address as above. This can
occur if two (or more) hosts attempt to configure the same Link-Local
IPv4 address at the same time.

To:

In
addition, if during this period the host receives any ARP probe where
the packet's 'target IP address' is the address being probed for, and
the packet's 'sender hardware address' is not the hardware address of


the interfaces the host is attempting to configure,

then the host MUST similarly treat this
as an address collision and select a new address as above. This can
occur if two (or more) hosts attempt to configure the same Link-Local
IPv4 address at the same time.



And in section 2.5

From:

At any time, if a host
receives an ARP packet (request *or* reply) where the 'sender IP
address' is the host's own IP address, but the 'sender hardware
address' does not match any of the host's own interface addresses,
then this is a conflicting ARP packet, indicating an address
collision.



To:

At any time, if a host
receives an ARP packet (request *or* reply) where the 'sender IP
address' is the host's own IP address, but the 'sender hardware
address' does not match

the hardware address of the interface the host is attempting to configure

then this is a conflicting ARP packet, indicating an address
collision.

---------------------------

3) This text is now OK. The text above (from 2.2.1 and 2.5) which required
a host to compare received ARP messages *on any interface* with those of
an interface being configured has been removed.