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

From: Stuart Cheshire <[email-masked]>
Date: Tue, 12 Jul 2005 16:47:17 +0100

I just read draft-ietf-dhc-dna-ipv4-13.txt.

I support the goals, but I think the current document misses the target.
I have a long list of comments, but these are the three major ones:

1. Hints and heuristics

It seems to me that the reliance on hints and heuristics is vastly 
overstated. The biggest and best heuristic of network attachment is the 
MAC address of the default gateway, which can be verified with a trivial 
ARP request (i.e. the proposed DNA mechanism itself), thereby negating 
much of the usefulness of all the other hints. The document even has a 
section for IP-layer hints, and then says they're pointless and shouldn't 
be used. Given than an ARP request can be answered in under 1ms, any hint 
or heuristic has to be significantly faster than that, or it's 
self-defeating.

The argument in Appendix A that you don't want to delay the normal DHCP 
INIT-REBOOT process while waiting for DNA is bogus. There's no reason why 
a host that wants rapid attachment to the network (which is, after all, 
the whole point of DNA) wouldn't do both simultaneously, and then just 
wait and see which approach yields a fruitful result quickest.

2. Why only one MLN candidate?

Why limit a host to picking just one candidate network to verify?

The drafts says, "In the absence of other information, the MLN defaults 
to the network to which the host was most recently attached." Consider a 
laptop computer that moves daily between Ethernet at work and Ethernet at 
home. If each time it picks its most recently attached as its best guess, 
it's going to be wrong 100% of the time.

It would be much better if a device simply sent ten ARP Requests for the 
last ten default gateway addresses it has seen, and then sees which, if 
any, are answered.

If you don't want to hit the network with ten back-to-back wire-rate ARP 
Requests, then they can be staggered 100ms apart, starting with the most 
recently seen network, then the previous, and so on.

Most network gateways should be able to answer an ARP Request almost 
instantaneously, since answering ARP Requests is something they have to 
do all the time anyway, and if they're slow at that, then that would 
adversely impact the performance of pretty much all IP traffic flowing 
through the gateway.

This stream of ARP Requests would of course be going on concurrently with 
DHCP INIT-REBOOT processing, and as soon as one of them yields a fruitful 
result, the device should stop.

It's simple, it's fast, and it yields the desired result.

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 <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: John Schnizlein <[email-masked]>
Date: Tue, 12 Jul 2005 13:06:01 -0400

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:

> ...