[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-13.txt



I don't see any struggle between the probe definition here and what is in RFC 2131:
The client SHOULD perform a
check on the suggested address to ensure that the address is not
already in use. For example, if the client is on a network that
supports ARP, the client may issue an ARP request for the suggested
request. When broadcasting an ARP request for the suggested address,
the client must fill in its own hardware address as the sender's
hardware address, and 0 as the sender's IP address, to avoid
confusing ARP caches in other hosts on the same subnet.


I see no need to invent other source-IP addresses, which could only confuse things. The extra semantics of signaling intentions which might or might not be acted upon are superfluous. What document specifies that use of zero as the source IP address implies that the host intends to use the target IP address?

I cannot see how using any value other than source-IP-address = zero could possibly solve the case where a router refuses to answer an ARP probe. Is it that a router that refuses to answer an ARP probe with zero as its source IP address might answer a probe with a different source IP address?

Because there is no single universal solution for an IPv4 host to determine if/to-what network it is attached, the comprehensive identification of valuable hints seems appropriate.

John

On Jul 12, 2005, at 11:47 AM, Stuart Cheshire wrote:

...
3. Probe packets

The document struggles with its incompatibility with the existing
widespread use of a zero-sender ARP as an ARP Probe, which means, "I want
to know if this address is in use, AND IF NOT I INTEND TO USE IT MYSELF."
This is the issue James Carlson pointed out.


This document needs an ARP Request with these semantics: "I just want to
know if this address is in use, and I have no intention of claiming it as
my own address; I may believe I already have an address of my own, but
I'm not yet willing to reveal what that is."


What could that packet be?

Given that the host does not want to announce its address until it is
certain of it, it can't put that address in ar$spa.

The host can't put zero in ar$spa, because that implies, "I intend to use
ar$tpa as my own."


Therefore, it has to put something else. It just has to be a non-zero
value that can't be an actual IP address already in use by a host on that
link.


There are many possibilities:

0.0.0.1
127.0.0.1
255.255.255.255

Any of those values would work. They are not zero, so the packet doesn't
look like a probe, and they're not any IP address that could be in use by
any other host on that link, so they can't inadvertently stomp over
someone else's ARP cache entry.


Fixing this would eliminate much of the specification that's currently
awkward, clumsy, self-contradictory and unimplementable. For example:

Note: Some routers may refuse to answer an ARP Probe, in which
case the reachability test will fail. A host also may encounter a
router that utilizes ARP Probes for DAD, as described in [ACD].
Such routers will not interpret ARP Probes as an indication of an
address conflict, except where they are themselves doing Duplicate
Address Detection (DAD). To avoid triggering conflict detection
on these routers, a host implementing DNAv4 that receives ARP
Probe from a router SHOULD NOT send ARP Probes to that router as
part of the DNAv4 reachability test.


A host "that receives ARP Probe from a router SHOULD NOT..."

How does a host KNOW it will receive ARP Probes from a router? How long
should it wait to see? DNA is supposed to be fast, right, so how long do
we want it to wait? Even after it's waited, how does it know the router
is not booting up and, at that very instant, is about to send its own ARP
Probes? How does a host know it's a router sending ARP Probes, and not
some other host on the network performing DNA? What does it mean by,
"SHOULD NOT send ARP Probes to that router as part of the DNAv4
reachability test"? I thought that sending ARPs was ALL of the DNAv4
reachability test. What other parts are there?


Using ARP Requests with a 0.0.0.1 source address would eliminate all of
these self-contradictions and awkward special cases.

Stuart Cheshire <cheshire at apple.com>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


_______________________________________________ dhcwg mailing list dhcwg at ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg


_______________________________________________ dhcwg mailing list dhcwg at ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg