Subject: [dhcwg] DNA Issue 7: ARP contents

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Oct 2003 16:07:21 -0700 (PDT)

Issue 7: ARP contents
Submitter: Dieter Siegmund
Submitter email address: [email-masked]
Date first submitted: October 2, 2003
Reference:
Document: DNAv4-02
Comment type: T
Priority: S
Section: 2.2
Rationale/Explanation of issue:

I have a comment regarding the spec:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-02.txt

In section "2.2. Packet Format", it suggests sending an ARP probe
(sender IP 0.0.0.0) to check the router MAC address against a known value.

One problem I've run into in the past (and still do today) is that some
routers refuse to answer ARP probe's. In particular, the Cisco router here
at Apple, and a FlowPoint DSL router I have at home only respond to an ARP
Request with a "legitimate" sender IP address.

Have you also encountered this?

Regards,
Dieter Siegmund
Core OS Networking

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

---

From: Greg Daley <[email-masked]>
Date: Thu, 09 Oct 2003 10:03:59 +1000

Hi Bernard,

For issue seven, I think that what's trying to be achieved
with the ARP probe is reachability confirmation.

We don't expect a response in the case of the IP subnet
changing (or the router's IP address going away).

In the case where we have a globally unique address,
there is no harm (because we own and have checked
the address) in sending the arp packet with
an (ar$spa) value which matches the currently
configured address.  If we are on the same subnet,
then this will be responded to appropriately.
If we are not on the same subnet, we won't get a
response anyway.

Of course, in IPv4, the big issue is the potential
presence of rfc 1918 addresses on the link
(which may readily be determined in the case
that the router, or the currently configured IP address
belongs to a non-unique class of addresses).

In these cases, it may be worth setting the (ar$spa)
to 0.0.0.0, but as mentioned by Dieter, this may mean that
function is impaired on some subnets, where routers
do not support unspecified sources.

I don't have a solution to this case, except to fall
back to DHC.   It may also be reasonable to suggest that
if reachability checks to the current router have failed
before, one shouldn't do them and instead rely on DHC,
until subnet change occurs.

Please tell me if I'm just being thick headed about this.

Greg Daley

---

From: Greg Daley <[email-masked]>
Date: Thu, 09 Oct 2003 14:25:03 +1000

Hi Bernard,

Bernard Aboba wrote:
> That was more or less my reaction as well.  Using the valid DHCP lease
> address appears to do no harm in this case.

I hope I wasn't just saying what you'd already
fixed (I hadn't seen the issues list since
you posted the issue).

> For an RFC 1918 address the potential downside is that the host has moved
> to an alternative point of attachment using the same RFC 1918 prefix.
> Sending an ARP probe including the allocated address could result in an
> address conflict unless the host could confirm that it was in fact on the
> expected network.  So I think that using 0.0.0.0 for this case is
> necessary, but it may not work.  If not, then the host will need to send a
> DHCPREQUEST.

I think that's what I was trying to express, but
your mechanism is clearly more well explained
(looks like text for a draft...)

> In practice the reachability checks are done because it is possible that
> the point of attachment may have changed.  In practice one would probably
> only want to deprecate the particular RFC 1918 prefix that has failed and
> perhaps only for a short period of time.  On the whole I'm not sure that
> the added complexity is worth it.

Indeed.  It would only be while that particular
IP Router was detected as faulty.  Thus it would
only have to fail once to be put into a "don't check"
state.

Once the subnet or router changed, this state would
be irrelevant.

> I think you're more or less on target.

Good.

When I first read your issue post, I thought
we had a show stopper.

Greg

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 9 Oct 2003 07:37:05 -0700 (PDT)

The text of DNA Issue 7 is enclosed below.  The proposed fix is as
follows:

In Section 2.2, change:

"Since the host has not yet confirmed the subnet on which
it is attached, it MUST set the sender protocol address field
(ar$spa) to 0.0.0.0.  This prevents poisoning of the ARP cache with a
(potentially invalid) sender IPv4 address.

Since the ARP Response is sent to the sender hardware address, the
contents of the sender protocol address field do not affect delivery
of the ARP Response.  Since existing implementations do not create an
ARP cache entry for 0.0.0.0, using this as the sender protocol
address is harmless."

To:

"If the host has a valid globally routable IP address on the most
likely point of attachment, 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.

However if the host has a private address as defined in [RFC1918],
then it SHOULD set the protocol address field (ar$spa) to
0.0.0.0. This is to avoid an address conflict in the case
where the host has changed its point of attachment from one
private network to another.

Note that some routers will refuse to answer an
ARP Request sent with the protocol address field (ar$spa)
set to the unspecified address. In this case the reachability
test will fail and the host will need to attempt to obtain an
address."

------------------------------------------------------------------
Issue 7: ARP contents

One problem I've run into in the past (and still do today) is that some
routers refuse to answer ARP probe's. In particular, the Cisco router here
at Apple, and a FlowPoint DSL router I have at home only respond to an
ARP Request with a "legitimate" sender IP address.

Regards,
Dieter Siegmund
Core OS Networking

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Oct 2003 19:04:50 -0700 (PDT)