Subject: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft

From: John Schnizlein <[email-masked]>
Date: Wed, 07 Jul 2004 15:10:30 -0400

Just before the section of the RFC you quoted is the part that
recommends that the client issue an ARP request to discover if
the address is already in use. This part seems most like the 
conflict detection part of ZeroConf.

The part you quoted is there for the case when there is no other
host with the address in question, but there might have been
previously. That is why the (other host's) ARP caches are
cleared.

The combination of both the request and the reply, which is 
clearer from the longer context of the text, first checks for
a duplicate address, then provides other hosts a cache update
for the host newly using the address.

The broader context of the specification quoted here for
convenience:

   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 08:54 AM 7/7/2004, [email-masked] wrote:

>RFC 2131, in section 4.4.1 says that "The client SHOULD broadcast an ARP reply to announce the client's new IP address ..." 
>
>This is the so-called 'gratuitous ARP'. 
>
>The Internet Draft for IPv4 Address Conflict Detection (http://files.stuartcheshire.org/draft-cheshire-ipv4-acd-00.txt) refers to this as an "ARP announcement" and defines it as an ARP request rather than a reply.  This definition is also in other Zeroconf drafts. 
>
>In products I have looked at (with BSD-derived stacks) it seems that the gratuitous ARP is sent as a request  (except when it is sent by the DHCP client). 
>
>
>Is there a need for consistency across the various mechanisms?  (DHCP client, IPv4 ACD, IPv4 Link Local, etc.)? 
>
>Brian Batke 
>Rockwell Automation 
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/dhcwg

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

---

From: "Hans-Hermann Krost" <[email-masked]>
Date: Wed, 7 Jul 2004 23:34:51 +0200

Now I am confused,

my knowledge is that, an update in the ARP cache is only be done by an ARP
request. This tells us RFC 826.

So the gratuitous ARP, which is a ARP request with special parameters, will
be used to
1. detect a already used IP address and
2. to update the ARP cache of the hosts/routers on the client's subnet

Hans-Hermann

-----Ursprungliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]]Im Auftrag
von John Schnizlein
Gesendet: Mittwoch, 7. Juli 2004 21:11
An: [email-masked]
Cc: [email-masked]
Betreff: Re: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft

John

At 08:54 AM 7/7/2004, [email-masked] wrote:

>RFC 2131, in section 4.4.1 says that "The client SHOULD broadcast an ARP
reply to announce the client's new IP address ..."
>The Internet Draft for IPv4 Address Conflict Detection
(http://files.stuartcheshire.org/draft-cheshire-ipv4-acd-00.txt) refers to
this as an "ARP announcement" and defines it as an ARP request rather than a
reply.  This definition is also in other Zeroconf drafts.
>
>In products I have looked at (with BSD-derived stacks) it seems that the
gratuitous ARP is sent as a request  (except when it is sent by the DHCP
client).
>
>
>Is there a need for consistency across the various mechanisms?  (DHCP
client, IPv4 ACD, IPv4 Link Local, etc.)?

---

From: John Schnizlein <[email-masked]>
Date: Wed, 07 Jul 2004 18:40:59 -0400

Sorry for the confusion. ARP is unfortunately a constant source of it.

First, regarding "update in the ARP cache is only be done by an ARP
request" note that RFC 826 explicitly does not discriminate between
request or reply messages before updating its table:

" When an address resolution packet is received, the receiving
  Ethernet module gives the packet to the Address Resolution module
  which goes through an algorithm similar to the following.
  Negative conditionals indicate an end of processing and a
  discarding of the packet.

  ?Do I have the hardware type in ar$hrd?
  Yes: (almost definitely)
    [optionally check the hardware length ar$hln]
    ?Do I speak the protocol in ar$pro?
    Yes:
      [optionally check the protocol length ar$pln]
      Merge_flag := false
      If the pair <protocol type, sender protocol address> is
          already in my translation table, update the sender
           hardware address field of the entry with the new
           information in the packet and set Merge_flag to true. 
    ?Am I the target protocol address?
    Yes:
      If Merge_flag is false, add the triplet <protocol type,
          sender protocol address, sender hardware address> to
          the translation table.
      ?Is the opcode ares_op$REQUEST?  (NOW look at the opcode!!)
      Yes:
        Swap hardware and protocol fields, putting the local
            hardware and protocol addresses in the sender fields.
        Set the ar$op field to ares_op$REPLY
        Send the packet to the (new) target hardware address on
            the same hardware on which the request was received.

   Notice that the <protocol type, sender protocol address, sender
   hardware address> triplet is merged into the table before the
   opcode is looked at.  This is on the assumption that communication
   is bidirectional; if A has some reason to talk to B, then B will
"

This fact, and an implementation wrinkle, led to the common practice
that ARP processes usually "glean" IP-to-MAC mappings even when they
are not party to the request. The implementation wrinkle is that 
many host protocol stacks send replies to the broadcast hardware
address rather than unicast to the requester's MAC address.

The operational fact (despite the clear specification above) that
replies are broadcast led to the recommendation that the DHCP client
complete the request-reply of as-practiced ARP to update (possibly
"gleaned") ARP entries in the other hosts on the subnet.

I have never understood what the special terminology of "gratuitous 
ARP" meant, and suspect its meaning morphed over time. The DHCP 
specification was intended to facilitate communication, given the
practices encoded in host protocol stacks at the time. Now, we 
should either continue to respect this tradition of making things
work (despite traditional loose implementation) or fix ARP. If we
were to fix ARP now, in the age of ethernet switches rather than
the physical broadcast of fat, yellow ethernet cables, I would
focus the fix on the behavior of switches to accommodate existing
hosts. The reason is that it is not nice to break the host that
has been working for years without any upgrade to its legacy stack.
The worst action of the IETF would be to break existing implementations
in pursuit of new protocol ideas.

John

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 7 Jul 2004 23:34:16 -0400

Hans:

You are not correct. See RFC 826:

The cache will be updated for *EITHER* a request or reply because the opcode
isn't checked until much later.

So, either a REQUEST or REPLY will work. However, the REQUEST sent during
the probe is not a normal REQUEST as it is sent with "0 as the sender's IP
address". So, that's why the REPLY is needed (and why send a REQUEST when
the host isn't looking for any information).

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Hans-Hermann Krost
> Sent: Wednesday, July 07, 2004 5:35 PM
> To: John Schnizlein; [email-masked]
> Cc: [email-masked]
> Subject: AW: [dhcwg] Gratuitous ARP in DHCP vs. IPv4 ACD Draft
> 
> 
> Now I am confused,
> 
> my knowledge is that, an update in the ARP cache is only be 
> done by an ARP request. This tells us RFC 826.
> 
> So the gratuitous ARP, which is a ARP request with special 
> parameters, will be used to 1. detect a already used IP 
> address and 2. to update the ARP cache of the hosts/routers 
> on the client's subnet
> 
> Hans-Hermann
> 
> 
> 
> Von: [email-masked] [mailto:[email-masked]]Im 
> Auftrag von John Schnizlein
> Just before the section of the RFC you quoted is the part 
> that recommends that the client issue an ARP request to 
> discover if the address is already in use. This part seems 
> most like the conflict detection part of ZeroConf.
> 
> The part you quoted is there for the case when there is no 
> other host with the address in question, but there might have 
> been previously. That is why the (other host's) ARP caches 
> are cleared.
> 
> (http://files.stuartcheshire.org/draft-cheshire-ipv4-acd-00.tx
t) refers to this as an "ARP announcement" and defines it as an ARP request
rather than a reply.  This definition is also in other Zeroconf drafts.
>
>Brian Batke
>Rockwell Automation _______________________________________________
>dhcwg mailing list
>[email-masked]