Subject: [dhcwg] ARP reply vs. ARP request to announce address acquired from DHCP

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jan 2003 13:53:50 -0600

>> So were you commenting on the probe or the announcement?
>
> The announcement.   All DHCP clients that I know of do the reply 
> instead of the request - i.e., they're out of spec.   :'}

So, just to be clear about my faux pas last week, RFC2131 says to do an 
ARP *reply* to announce that it has its new IP address, but existing 
clients send an ARP *request* with the newly-acquired DHCP address in 
source and destination IP address fields - for example, here's what 
Win98SE transmits (I have a 10baseT switch that filters unicasts, so I 
only got the broadcasts):

13:33:08.865011 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] 
xid:0xea456228 vend-rfc1048 DHCP:REQUEST CID:01:00:03:ff:66:34:0a 
RQ:10.0.1.5 SID:10.0.1.1 HN:"Windows 98SE^@" 
FQDN:0.0.0.87.105.110.100.111.119.115.32.57.56.83.69.0 
VC:77.83.70.84.32.57.56 PR:SM+DN+DG+NS+WNS+WNT+WSC+VO+CLASS (ttl 128, 
id 256, len 346)
13:33:08:925932 arp who-has 10.0.1.5 tell 10.0.1.5

This is what is recommended in the Stevens TCP/IP book.   I think the 
reason this is so common is that the ARP announcement is part of the 
interface configuration process, and is not done by the DHCP client, so 
the people that read the DHCP spec aren't the ones that write the code 
that does the announcement.   This is certainly the case with the ISC 
DHCP client.   On Unix systems of which I am aware, it's not possible 
to do ARP processing outside the kernel.   Since the ISC DHCP client 
runs on Unix, it's pretty much stuck with whatever the operating system 
provides.

So in fact all the DHCP clients of which I am aware are technically out 
of spec with RFC2131.   I don't think this is a big problem, or that 
RFC2131 needs to be immediately updated.   The language in RFC2131 is 
specifying generic behavior that all IP stacks should implement 
regardless of whether or not they support DHCP, and therefore RFC2131's 
recommendation is just that - a recommendation.   So it's actually very 
helpful that Stuart is coming out with a document that's not 
DHCP-specific that states how this should be done, and it's also fine 
that it contradicts the recommendation stated in RFC2131.   I'm not 
sure we need to say that this draft updates RFC2131 - I leave that up 
to those more knowledgable about the IETF process to decide.

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

---

From: Brad Hards <[email-masked]>
Date: Tue, 14 Jan 2003 07:10:26 +1100

> runs on Unix, it's pretty much stuck with whatever the operating system
It may not be possible on all Unix systems, but it _is_ possible to do general 
ARP processing on many systems. We do this on zcip (http://zeroconf.sf.net), 
which runs in userspace. It does take some BSD type kernel extensions, but 
they are provided by the various BSDs ([free, net, open]) and Linux systems. 
I'm not sure about other unices.

Brad

- -- 
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you?

---

From: Thamer Al-Harbash <[email-masked]>
Date: Mon, 13 Jan 2003 19:27:43 -0500 (EST)

> runs on Unix, it's pretty much stuck with whatever the operating system

The dhcpcd package specifically fires off an ARP reply after
setting its interface up last I checked. My own code, dhcp-agent,
has this feature in the old release and in its -current.

> of spec with RFC2131.

I'm surprised you haven't implemented this in the ISC dhcp suite
or think others havent for any technical reason. It's actually
pretty straight forward under UNIX since with a DHCP program you
generally talk to the network rawly and it's literally just a
matter of writing the packet to the raw network device and going
on with business as usual.

It's an entirely different matter if the other operating systems
on the LAN will take note of it.

-- 
Thamer Al-Harbash            http://www.whitefang.com/
          team dresch made me do it
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jan 2003 21:27:46 -0600

The thing that is missing on the Unix side is not the ability to *send* 
an ARP packet, but the ability to see the reply.   It didn't work when 
I looked at it ~five years ago, and I haven't bothered since.

I'll bet that when dhcpcd configures the interface, it generates the 
ARP request anyway, even though dhcpcd is sending an ARP reply.

---

From: Thamer Al-Harbash <[email-masked]>
Date: Mon, 13 Jan 2003 22:50:33 -0500 (EST)

> I looked at it ~five years ago, and I haven't bothered since.

I can't think of any packet capturing facility that would not let
you see ARP. dhcp-agent happily ARPs. In -current you can find
the code in dhcp-arp-discovery.c

> ARP request anyway, even though dhcpcd is sending an ARP reply.

Linux 2.4 doesn't seem to be generating any ARP requests on
toggling and interface up, down, and changing addresses. I've
used a tool called arping myself to force other ARP caches to be
updated when changing interface addresses.

I can test against BSD and Solaris too but serial conning them is
too much of a pain right now :-) Were you using a windows box to
with your earlier test?

I understand preventing the OS from sending an ARP request
instead of a reply is impossible short of fiddling with a local
firewall facility which is not always available.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jan 2003 23:23:12 -0600

> the code in dhcp-arp-discovery.c

BPF wasn't passing arp-reply packets at the time.   Perhaps it does 
now, or perhaps it's handled differently in lpf.   I thought it was 
rather odd at the time, but at the time fixing it wasn't my main 
priority, so I didn't look any further.

> too much of a pain right now :-) Were you using a windows box to

BSD definitely sends the ARP - I've captured it in packet traces when 
debugging.   Dunno for sure about Solaris, but it uses the BSD stack, 
so it probably does.   Linux doesn't use the BSD stack, which perhaps 
explains the discrepancy - it could be that Stevens was reporting what 
the BSD stack was already doing, rather than recommending what it 
*should* do.

So the question is, what does this tell us?   Are you saying that 
Stuart's proposal is not the right way to go, or just pointing out new 
information?   I have to say that I find Stuart's rationale for sending 
an ARP request rather than a reply fairly convincing.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Jan 2003 00:03:18 -0600

> No need to update the RFC for this. Just send an ARP reply from
> the client and let the OS send all the requests it wants :-)

That's a fine engineering solution, but it's a lousy protocol solution 
- we can't specify two broadcasts.   A better way to phrase my question 
would be, "are you objecting to what is specified in Stuart's draft?"

---

From: Thamer Al-Harbash <[email-masked]>
Date: Tue, 14 Jan 2003 01:37:24 -0500 (EST)

On Tue, 14 Jan 2003, Ted Lemon wrote:

> A better way to phrase my question

His definition of an ARP announcement is fine by me -- and as you
both mentioned in your postings is in actuality what most systems
are doing.

I would be remiss if I did not point out again that systems that
do not have a BSD derived IP stack may not do this type of
announcement on their own (Linux 2.4 being one I know of). The
DHCP implementations need to perform one of the two contending
types of ARP announcements. The DHCP RFC needs to reflect which
one.

---

From: Thamer Al-Harbash <[email-masked]>
Date: Tue, 14 Jan 2003 00:44:08 -0500 (EST)

> priority, so I didn't look any further.

Might be that you filtered out ARP by only allowing UDP. Just a
thought.

> So the question is, what does this tell us?

It tells us that we can do either ARP replies or requests in our
UNIX dhcp clients and any UNIX-like operating systems (Mac OS
X). There's nothing in RFC 2131 which says "don't send an ARP
request." It just says:

"The client SHOULD broadcast an ARP reply to announce the client's
new IP address and clear any outdated ARP cache entries in hosts
on the client's subnet."

---

From: John Schnizlein <[email-masked]>
Date: Tue, 14 Jan 2003 09:23:57 -0500

I am uncomfortable with the attribution of out-of-spec for DHCP clients.
Since the recommendation (SHOULD) to send an ARP-reply is in the context 
of the client (excerpt below) checking that the offered address is 
actually available, the ARP-request, which you say most clients perform, 
appears perfectly reasonable. Since, without the ARP-request the client 
cannot send a DHCP-decline, it seems the ARP-request is desirable.

In fact, performing both the ARP-request and the ARP-reply avoids the
appearance of an unsolicited ARP on a network segment, which could be an
attempt to steal an IP address. My opinion is that the ARP-announce, 
an ARP-reply without an ARP-request, would be questionable, and 
I was happy to see the ZeroConf specification moving away from it.

RFC 2131  [Page 38 & 39] 
   ... 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.  If the
   network address appears to be in use, the client MUST send a
   DHCPDECLINE message to the server. The client SHOULD broadcast an ARP
   reply to announce the client's new IP address and clear any outdated
   ARP cache entries in hosts on the client's subnet.

John

At 02:53 PM 1/13/2003, Ted Lemon wrote:
>>The announcement. All DHCP clients that I know of do the reply instead of the request - i.e., they're out of spec.   :'}
>
>So, just to be clear about my faux pas last week, RFC2131 says to do an ARP *reply* to announce that it has its new IP address, but existing clients send an ARP *request* with the newly-acquired DHCP address in source and destination IP address fields ...
>
>So in fact all the DHCP clients of which I am aware are technically out of spec with RFC2131.   I don't think this is a big problem, or that RFC2131 needs to be immediately updated.   The language in RFC2131 is specifying generic behavior that all IP stacks should implement regardless of whether or not they support DHCP, and therefore RFC2131's recommendation is just that - a recommendation.   So it's actually very helpful that Stuart is coming out with a document that's not DHCP-specific that states how this should be done, and it's also fine that it contradicts the recommendation stated in RFC2131.   I'm not sure we need to say that this draft updates RFC2131 - I leave that up to those more knowledgable about the IETF process to decide.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Jan 2003 23:56:19 -0600

The text there says that the client should send the ARP *request* to 
check for a conflict.   The ARP request is supposed to use an IP 
address of 0.0.0.0 as the sending station's IP address, so as to avoid 
asserting that the sending station has the assigned IP address.   Only 
after this ARP request has failed to identify a conflict does the 
client send a message asserting that it has the IP address it has been 
assigned.   So the client sends two ARP packets - an ARP request and an 
ARP reply.

What the proposed draft does is to change the recommended behavior for 
asserting an IP address using ARP so that this is done with an ARP 
request rather than an ARP reply.   You should take a look at the 
zeroconf mailing list archives to see Stuart's proposed text that 
explains why this is the right thing to do.   I'm sorry that some of 
this stuff got cross-posted to DHCwg and some didn't, so that you don't 
have the full context.   This whole thing is _very_ confusing, so it's 
a really good thing that Stuart is trying to clarify it.   :'}