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

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:
>>>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 ...
>
>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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg