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

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