Subject: [dhcwg] Proposed Resolution to DNA Issue 24: Conflict with ACD document

From: Bernard Aboba <[email-masked]>
Date: Sat, 6 Aug 2005 07:52:11 -0700 (PDT)

The text of DNA Issue 24 is enclosed below.

This problem originates because when the host is testing reachability on
a private network, it is possible that it has connected to a MLN, but not
the instance that it had anticipated.  By sending a broadcast ARP Request
with its own IPv4 address in arp$spa, the host pollutes the ARP cache.

To avoid this, one possible solution is to avoid putting its own address
in arp$spa.  However, another possible solution is to unicast the ARP
Request with its own IPv4 address in arp$spa.  This addresses the concern
about ARP cache pollution, since only the destination gateway will receive
the request.  If the gateway is not present, then the reachability test
will timeout.  By not puting the unspecified address in arp$spa, the
host avoids a potential conflict with hosts implementing ACD.

The proposed resolution is as follows:

Change Section 2.2.1 to the following:

"2.2.1.  Packet Format

   The reachability test is performed by sending an ARP Request.
   If the host has an operable routable IPv4 address other than a
   private address on a MLN, then it SHOULD set the sender protocol
   address field (ar$spa) to that address.  It is assumed that the
   host had previously done duplicate address detection so that
   an address conflict is unlikely.  The ARP Request SHOULD use the
   host's MAC address as the source, and the broadcast MAC address
   as the destination.  The host sets the target protocol address
   (ar$tpa) to the IPv4 address of the default gateway being tested,
   and uses its own MAC address in the sender hardware address field
   (ar$sha).  The host sets the target hardware address field (ar$tha)
   to 0.

   If the host has a private address as defined in [RFC1918], then
   it SHOULD set the sender protocol address field (ar$spa) to that
   address.  To avoid potential ARP cache pollution, the ARP Request
   SHOULD use the host's MAC address as the source, and the default
   gateway MAC address as the destination.  The host sets the target
   protocol address (ar$tpa) to the IPv4 address of the default
   gateway being tested,  and uses its own MAC address in the sender
   hardware address field (ar$sha).  The host sets the target hardware
   address field (ar$tha) to 0.

   If a valid ARP Reply is received, the MAC address in the sender
   hardware address field (ar$sha) and the IPv4 address in the sender
   protocol address field (ar$spa) are matched against the list of
   networks and associated default gateway parameters.  If a match is
   found,  then if the host has an operable routable IPv4 address on the
   matched network, the host continues to use that IPv4 address, subject
   to the lease re-acquisition and expiration behavior described in
   [RFC2131], Section 4.4.5.

   Checking for a match on both the IPv4 address and MAC address of the
   default gateway enables the host to confirm reachability even where
   it has moved between two private networks.  In this case the IPv4
   address of the default gateway could remain the same, while the MAC
   address would change, so that both addresses need to be checked.

   The risk of an address conflict is greatest when the host moves
   between private networks, since in this case the completion of
   Duplicate Address Detection on the former network does not provide
   assurance against an address conflict on the new network.  Until a
   host with a private address has confirmed the operability of its IPv4
   configuration, it SHOULD NOT respond to ARP Requests, and SHOULD NOT
   broadcast ARP Requests containing its address within the sender protocol
   address field (ar$spa).  However, where the host has an operable
   routable non-private address on a MLN, it MAY send ARP Requests using
   its address within the sender protocol address field (ar$spa) prior
   to confirming its IPv4 configuration, and MAY respond to ARP
   Requests.

   Sending an ICMP Echo Request [RFC792] to the default gateway IPv4
   address does not provide the same level of assurance since this may
   require an ARP Request/Reply exchange.  Where the host has moved
   between two private networks, this could result in ARP cache
   pollution.

   Where a host moves from one private network to another, an ICMP Echo
   Request can result in an ICMP Echo Response even when the default
   gateway has changed, as long as the IPv4 address remains the same.
   This can occur,  for example, where a host moves from one home
   network using prefix 192.168/16 to another one.  In addition, if the
   ping is sent with TTL > 1, then an ICMP Echo Response can be received
   from an off-link gateway.  As a result, if the MAC address of the
   default gateway is not checked, the host can mistakenly confirm
   attachment to a MLN, potentially resulting in an address conflict.
   As a result, sending of an ICMP Echo Request SHOULD NOT be used as a
   substitute for the DNAv4 procedure.

   If the initial ARP Request does not elicit a response, the host waits
   for REACHABILITY_TIMEOUT.  Where IPv4 address acquisition occurs in
   parallel, the host MAY retransmit;  otherwise the host SHOULD move on
   to the IPv4 address acquisition phase.  If a valid ARP Reply is
   received, but cannot be matched against known networks, the host
   assumes it does not have an operable IPv4 configuration."

--------------------------------------------------------------------------
Issue 24: Conflict with ACD Draft
Submitter name: James Carlson
Submitter email address: [email-masked]
Date first submitted: April 28, 2005
Reference:
Document: DNA-11
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

While trying to implement these mechanisms, I think I've found a
conflict between these two documents. I realize that it's pretty late
(you're already in AD review), but could you please look into this?

In the linklocal draft, section 2.2.1 says:

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 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 IPv4 Link-Local address at the same time.

This means that if a request (ares_op$REQUEST) packet with ar$spa set
to zero and ar$tpa set to the local address is received (a "probe"),
then we should treat it as a collision and not assign the address.

Unfortunately, the dna draft uses *exactly* these probe packets in its
section 2.2.1 to detect whether the "primary default gateway" is
reachable:

The reachability test is performed by sending an ARP Request. The
ARP Request SHOULD use the host's MAC address as the source, and the
broadcast MAC address as the destination. The host sets the target
protocol address (ar$tpa) to the IPv4 address of the primary default
gateway, and uses its own MAC address in the sender hardware address
field (ar$sha). The host sets the target hardware address field
(ar$tha) to 0.

 If the host has a private address as defined in [RFC1918], then it
SHOULD set the sender protocol address field (ar$spa) to the
unspecified address (0.0.0.0). This is to avoid a potential address
conflict when the host changes its point of attachment from one
private network to another.

The end result of this is that if the router and some arbitrary end
node connect at the same time, the router will see the "reachability
probes" from the end node and *incorrectly* assume that someone else
is claiming his address -- and thus fail to assign the address
properly.

The three possible resolutions I can see are:

- Change the dna draft so that it requires a *regular* ARP
Request message (ar$spa set to the local address), and
requires that the system does any linklayer-draft related
probing before attempting to do reachability.

- Change the linklayer draft to remove that second clause --
so that probes are not seen as conflicts.

- Just live with it, because if routers fail to operate in
practice, that's fine. (Or because I've missed something
really important that prevents the problem, though I don't
see what.)

For what it's worth, I see the first of those three as the most
reasonable. Probing someone else's address with an ar$spa set to zero
doesn't make a lot of sense to me.

-- 
James Carlson, KISS Network <[email-masked]>
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

[Bernard Aboba]

Thanks very much for these comments. In DNAv4 the probe is used to
confirm reachability of the default router on the MLPA. The default
router address may be a private address, or it may be a globally routable
address, but it should never be a linklocal address in 169.254/16.
Therefore it should not cause a conflict with IPv4 Link Local
address assignment. If it would help, we could explicitly state that a
probe MUST NOT be sent to a default router with an IPv4 Link Local
address.

[James Carlson]

I think that would likely help a bit, but I'm still concerned that,
due to the expired Cheshire duplicate address detection draft that
eerily mirrors the linklocal draft, there are likely to be
implementations that use the probing procedure for _all_ addresses,
not just those described in linklocal.

In other words, if folks are detecting duplicate addresses using
probes (as I strongly suspect they are), then the dna probe will still
cause problems, even if it's never probing a link-local address.

[Bernard Aboba]

The reason why arp$spa is set to zero when the default gateway has a
private address is that it is possible for a host to have changed networks
without changing prefixes. For example, the host could move from one home
network to another home network, both of which have a gateway address of
192.168.1.1. If arp$spa contained the actual address of the host then
this could pollute the ARP table.

[James Carlson] Yes, I realize that.

I think it's reasonable to observe, though, that just a few cases
exist and none of them lead to needing to set ar$spa to zero:

Private address happens to be in the range of the local
network (i.e., risk of pollution):

Address node has isn't currently in use, and thus use
of the address in ar$spa is harmless, even if the
address is 'from' another network and even if it might
"pollute" the local ARP caches. This can be checked
by doing DAD (probe own address) first.

Address node has is in use by another node on the new
network, in which case the node is on a new network or
just has to start over. Can terminate effort (without
probing default gateway) immediately. This can be
checked by doing DAD first.

Private address is not in the range of the local network
(i.e., no risk of pollution because no valid node is using
that address):

DAD will tell node that address is "ok" to use, as
it's not currently in use, but subsequent real
resolution (nonzero ar$spa) of the default router will
show that either it's at a different hardware address
or just doesn't respond.

In other words, I don't see a case in which a probe as defined in
linklocal needs to be used, provided that duplicate address detection
is available. There's nobody to poison.

[Bernard Aboba]

> In other words, if folks are detecting duplicate addresses using
> probes (as I strongly suspect they are), then the dna probe will still
> cause problems, even if it's never probing a link-local address.

Do you know of an example of this? I wouldn't be surprised if hosts send
probes with ar$spa set to zero to detect duplicates (since this
avoids polluting the ARP cache if there is a duplicate out there).

It's assuming that these probes imply a duplicate that seems a bit
unusual.

> In other words, I don't see a case in which a probe as defined in
> linklocal needs to be used, provided that duplicate address detection
> is available. There's nobody to poison.

Unfortunately, the point of using DNAv4 is to avoid DAD. If DAD were
required it would be faster to just send a DHCPREQUEST to verify the
address and forget DNAv4 altogether. We could specify that behavior when
the host has a private address, if it were necessary to avoid setting
ar$spa to zero.

[James Carlson]

> Do you know of an example of this? I wouldn't be surprised if hosts send
> probes with ar$spa set to zero to detect duplicates (since this
> avoids polluting the ARP cache if there is a duplicate out there).

I'll bet that Stuart Cheshire does; that's why I copied him. The
behavior described above is from Apple.

> It's assuming that these probes imply a duplicate that seems a bit
> unusual.

Except that's exactly what the current zeroconf linklocal draft says.
See section 2.2.1 of that draft, where it says this:

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 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 IPv4 Link-Local address at the same time.

This is exactly the probe we're talking about.

[Bernard Aboba]

I just reread the following document:
http://www.watersprings.org/pub/id/draft-cheshire-ipv4-acd-03.txt

It includes the following statement:

This document standardizes the widely-used natural interpretation of
an ARP Request where the Target Protocol Address is non-zero but the
Sender Protocol Address is zero, namely that it is a question without
an associated assertion (an "ARP Probe").

The idea that the probe is a statement without an assertion is backed up
by the text in Section 2.4:

Address conflict detection should not be limited to only the time of
initial interface configuration, when a host is sending ARP probes.
Address conflict detection is an ongoing process that is in effect
for as long as a host is using an address. At any time, if a host
receives an ARP packet (request *or* reply) where the 'sender IP
address' is (one of) the host's own IP address(es), but the 'sender
hardware address' does not match any of the host's own interface
addresses, then this is a conflicting ARP packet, indicating some
other host also thinks it is validly using this address. To resolve
the address conflict, a host must respond to a conflicting ARP packet
as described in either (a), (b) or (c) below:

I read this as implying that a probe with ar$spa set to zero is not
interpreted as a conflict.

[Stuart Cheshire]

>I think that would likely help a bit, but I'm still concerned that,
>due to the expired Cheshire duplicate address detection draft that
>eerily mirrors the linklocal draft, there are likely to be
>implementations that use the probing procedure for _all_ addresses,
>not just those described in linklocal.

James is right. This behavior is common today -- my draft just documents
it.

>I read this as implying that a probe with ar$spa set to zero is not
>interpreted as a conflict.

Except when two hosts are probing simultaneously. Then each treats the
other's probe as a conflict. This is necessary to avoid the simultaneous
probing race condition.

[James Carlson]

> Unfortunately, the point of using DNAv4 is to avoid DAD. If DAD were
> required it would be faster to just send a DHCPREQUEST to verify the
> address and forget DNAv4 altogether. We could specify that behavior when
> the host has a private address, if it were necessary to avoid setting
> ar$spa to zero.

That'd solve the problem completely.

(I think it'd also be conceptually cleaner, as basing the detailed
behavior of ARP on address ranges seems a bit suspect to me.)

Bernard Aboba writes:
> The idea that the probe is a statement without an assertion is backed up
> by the text in Section 2.4:

Yep.

> I read this as implying that a probe with ar$spa set to zero is not
> interpreted as a conflict.

Read on -- that draft and the zeroconf draft both say that when you
get a probe where the target is the address you're trying to verify,
you assume there's a conflict. They allow for two cases: the usual
ar$spa update that causes DAD failure *and* a probe of ar$tpa that
causes failure.

[BA]  I think the discussion has narrowed the scenarios in which a problem
could occur:

1) When the default gateway has a linklocal address.

Since DNA wasn't meant to be used in this case, it can be
explicitly prohibited by adding condition e) to Section 2.2:

"e) If the default gateway address is an IPv4 Link-Local address."

2) When the host and gateway are sending ARP probes simultaneously.

The specific text in ACD-03 is as follows:

"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 conflict and signal an error to the configuring agent
as above. This can occur if two (or more) hosts have, for whatever
reason, been inadvertently configured with the same address, and both
are simultaneously in the process of probing that address to see if
it can safely be used."

However, a router would be unwise to behave this way, because:

a. A router typically has no "configuring agent" (human operator,
DHCP server, etc.), and would become unreachable if it were to
abandon its address, taking network connectivity down with it.

b. A router with a statically configured IP address would be unwise
to stop usage of its address based on receipt of an ARP probe, since that
would make it vulnerable to a denial of service attack. Instead, the
router
should only interpret an ARP reply as a true conflict, and should respond
to an ARP probe if it has verified its own address. This would ensure that
a router would win an address conflict battle, imposing the least cost on
the network as a whole.

Note that for a problem to occur, a default gateway would need
to use ARP probes to verify its address, would need to interpret
receipt of a probe while probing as an actual (not potential) address
conflict, and would need to stop use of its address as a result
of a conflict detected via receipt of a probe.

I will do some tests on common routers (Cisco, Linksys, Apple Airport,
etc.) to see how they behave
and will also send out an implementation survey.

NB: I would also argue that any host with a static address would be unwise
to behave as advocated in ACD-03, since such a host could not easily
obtain
another address to use instead and would therefore become disabled.

[Bernard Aboba] Here's what the initial tests seem to show:

Proteon and related code bases: ARP announcement
Cisco IOS: Broadcast ARP Reply
Linksys: No DAD prior to use of an address (no ARP announcement or Probe)

[Bernard Aboba]

The crux of this issue concerns whether routers have implemented:
http://www.watersprings.org/pub/id/draft-cheshire-ipv4-acd-03.txt

The jury is still out on this (I've sent out an implementation survey and
am doing some testing of existing routers). However, from what I've found
so far, this doesn't appear to be common.

Here is the proposed resolution:

Add condition [e] in Section 2.2:

" The host skips the reachability test and proceeds to the IPv4 address
acquisition phase if any of the following conditions are true:
...

[e] If the default gateway address is an IPv4 Link-Local
address. In this case, it is possible that the
reachability test could be misinterpreted as
indication of an address conflict. See [RFC3927]
Section 2.2.1 for details."

Also, change:

"     Note: Some routers may refuse to answer an ARP Probe, in which
      case the reachability test will fail."

To:

" 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."

[James Carlson]

I don't think that note actually fixes anything, because the probe
this local node is sending occurs so soon after attachment that
there's no way for the local node to know whether that router being
probed does duplicate address detection or not.  It can't just guess.

Fundamentally, I'm unconvinced that using ARP probe messages for two
different purposes in the network is actually sound. The hole we're
carving here is that routers using private addresses must avoid DAD
because they'll very likely face a storm of DAD-looking packets on
start-up (e.g., switch powered back on). But since (a) any system may
become a router by configuration and (b) routers are explicitly
encouraged to use static assignment of addresses (see, for example,
the in my opinion flawed advice in RFC 2131 section 1.3), we're just
setting operators (and implementors -- like me) up for failure.

Instead of sending a probe of some other node's address as though we
were preparing to *use* that address as our own (the operation that I
believe to be flawed), it makes sense to me that the node should first
validate that its own address is not a duplicate on the "new" network
by probing its own address (using DAD), and *then* sending out a
regular ARP request (not a probe) for the router's IP address to
verify that the local network is the same as before.

I realize that waiting for the local address to pass DAD potentially
makes the procedure slower than desired (perhaps as long as a second,
if shortened timers are used), but leaving DAD in this completely
ambiguous state (is it an actual conflict, or is it just an innocuous
probe? -- no way to tell) is a far worse outcome.

Alternatively, the following text needs to be struck from the DAD
documents (and implementations):

 [...] 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
interface the host is attempting to configure, then the host MUST
similarly treat this as an address conflict and select a new address
as above.

[Bernard Aboba]

To be clear, I'm not saying that routers shouldn't implement DAD. I think
the issue is whether a router should give up its address on receiving an
ARP Probe (e.g. sender address unspecified).

I've sent out an implementation survey and tested a number of
routers. None of them send out ARP Probes, and neither do they give up
their address on receiving an ARP Probe. For example, the Cisco router I
tested broadcasted an ARP Reply; Proteon and related code bases broadcast
an ARP
announcement; the LINKSYS router I looked at does not do DAD prior to
using an address at all.

So in practice, routers don't seem to treat ARP Probes as evidence of a
conflict. The question is whether they should.

In thinking this over, I believe that the existing behavior is in fact
correct. A router should not give up a configured address easily --
since this would result in a service outage for hosts. Giving up an
address in response to a question (ARP Probe) would make routers more
fragile.

> Instead of sending a probe of some other node's address as though we
> were preparing to *use* that address as our own (the operation that I
> believe to be flawed)

The ACD document indicates that it is the "ARP Announcement" (send
address = target address) that is an assertion, not the ARP Probe.
The ARP Probe is described as a "question without an assertion". So
I don't believe an ARP Probe can be interpreted as an indication that a
host is intending to use an address.

> Alternatively, the following text needs to be struck from the DAD
> documents (and implementations):
>
> [...] 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
> interface the host is attempting to configure, then the host MUST
> similarly treat this as an address conflict and select a new address
> as above.

At a minimum, I'd advocate that this text be restricted to hosts. Since
no routers appear to implement it, this wouldn't require an implementation
change.

[Stuart Cheshire]

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.

[John Schnizlein]

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.

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

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 6 Aug 2005 16:22:17 -0700 (PDT)

James Carlson has pointed out that the DNAv4 host could send a unicast ARP
Request in all cases, which would simplify the logic and also minimize the
chance of ARP cache pollution where a private network is being run in
address space other than that allocated in [RFC1918].  With this
simplification, the new proposed text for Section 2.2.1 is as follows:

"2.2.1.  Packet Format

   The reachability test is performed by sending an ARP Request.  The
   host SHOULD set the target protocol address (ar$tpa) to the IPv4
   address of the default gateway being tested, and the sender protocol
   address field (ar$spa) to its own IPv4 address.  The ARP Request
   SHOULD use the host's MAC address as the source, and the default
   gateway MAC address as the destination.  The host includes its MAC
   address in the sender hardware address field (ar$sha), and sets the
   target hardware address field (ar$tha) to 0.

   If a valid ARP Reply is received, the MAC address in the sender
   hardware address field (ar$sha) and the IPv4 address in the sender
   protocol address field (ar$spa) are matched against the target
   hardware address field (ar$tpa) and the target protocol address field
   (ar$tpa) in the ARP Request.  If a match is found,  then if the host
   has an operable routable IPv4 address on the matched network, the
   host continues to use that IPv4 address, subject to the lease re-
   acquisition and expiration behavior described in [RFC2131], Section
   4.4.5.

   The risk of an address conflict is greatest when the host moves
   between private networks, since in this case the completion of
   Duplicate Address Detection on the former network does not provide
   assurance against an address conflict on the new network.  Until a
   host with a private address has confirmed the operability of its IPv4
   configuration, it SHOULD NOT respond to ARP Requests, and SHOULD NOT
   broadcast ARP Requests containing its address within the sender
   protocol address field (ar$spa).  However, where the host has an
   operable routable non-private address on a MLN, it MAY send ARP
   Requests using its address within the sender protocol address field
   (ar$spa) prior to confirming its IPv4 configuration, and MAY respond
   to ARP Requests.

   Sending an ICMP Echo Request [RFC792] to the default gateway IPv4
   address does not provide the same level of assurance since where the
   host has moved between two private networks, an ICMP Echo Request can
   result in an ICMP Echo Response even when the default gateway has
   changed, as long as the IPv4 address remains the same.  This can
   occur,  for example, where a host moves from one home network using
   prefix 192.168/16 to another one.  In addition, if the ping is sent
   with TTL > 1, then an ICMP Echo Response can be received from an off-
   link gateway.  As a result, if the MAC address of the default gateway
   is not checked, the host can mistakenly confirm attachment to a MLN,
   potentially resulting in an address conflict.  In addition, if the
   ICMP Echo Request results in a broadcast ARP Request being sent with
   the host's IPv4 address in ar$spa,  this can result in ARP cache
   pollution.  As a result, sending an ICMP Echo Request SHOULD NOT be
   used as a substitute for the DNAv4 procedure.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 6 Aug 2005 16:58:17 -0700 (PDT)

Here is the revised proposed resolution:

In Section 1.2, delete the definitions of "ARP Probe" and "ARP
Announcement".

In the References, delete the reference to [ACD].

Change Section 2.2 to the following:

"2.2.  Reachability Test

   If the host has an operable routable IPv4 address on a MLN, a host
   conforming to this specification SHOULD perform a reachability test
   for that MLN, in order to confirm the configuration.

   The host skips the reachability test for a MLN if any of the
   following conditions are true:

   [a] The host does not have an operable routable IPv4
       address on a MLN.  In this case, the reachability
       test cannot confirm that the host has an operable
       routable IPv4 address, so completing the
       reachability test would serve no purpose.
       A host MUST NOT use the reachability test to
       confirm configuration of an IPv4 Link-Local
       address.

   [b] The host does not know the default gateway(s) on
       a MLN.  In this case, insufficient information
       is available to carry out the reachability test.

   [c] If secure detection of network attachment is required.
       The reachability test utilizes ARP which is insecure,
       whereas DHCPv4 can be secured via DHCPv4 authentication,
       described in [RFC3118].  See Section 5 for details.

   For a particular MLN, the host MAY test the reachability of the
   primary default gateway, or it MAY test reachability of the primary
   and secondary default gateways in series or in parallel.  In order to
   ensure configuration validity,  the host SHOULD only configure
   default gateway(s) which pass the reachability test.

   In situations where more than one network is available on a given
   link, and more than one reachability test is performed in parallel,
   potentially with an attempt to obtain IPv4 configuration via DHCPv4,
   it is possible for the host to confirm more than one configuration.
   In this case, a DNAv4 implementation SHOULD prefer the configuration
   provided via DHCPv4.

2.2.1.  Packet Format

   The reachability test is performed by sending an ARP Request.  The
   host MUST set the target protocol address (ar$tpa) to the IPv4
   address of the default gateway being tested, and the sender protocol
   address field (ar$spa) to its own IPv4 address.  The ARP Request MUST
   use the host's MAC address as the source, and the default gateway MAC
   address as the destination.  The host includes its MAC address in the
   sender hardware address field (ar$sha), and sets the target hardware
   address field (ar$tha) to 0.

   If a valid ARP Reply is received, the MAC address in the sender
   hardware address field (ar$sha) in the ARP Reply is matched against
   the target hardware address field (ar$tpa) in the ARP Request, and the
   and the IPv4 address in the sender protocol address field (ar$spa) of
   the ARP Reply is matched against the target protocol address field
   (ar$tpa) in the ARP Request.  If a match is found,  then if the host
   has an operable routable IPv4 address on the matched network, the
   host continues to use that IPv4 address, subject to the lease re-
   acquisition and expiration behavior described in [RFC2131], Section
   4.4.5.