Path: utzoo!utgpu!watmath!clyde!att!rutgers!mailrus!ames!pasteur!ucbvax!ATHENA.MIT.EDU!mar
From: mar@ATHENA.MIT.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Dynamic IP address assignment
Message-ID: <8811281914.AA00132@TOTO.MIT.EDU>
Date: 28 Nov 88 19:14:36 GMT
References: <5587@saturn.ucsc.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 22

I was a little ambiguous with my wording.  By "broadcasting an ARP
reply", I didn't mean for this broadcast to claim anything about the
broadcast address.  If a machine broadcasts an ARP packet with it's
own IP and hardware addresses as both the requestor and the target,
then this will have the desired effect of updating the ARP caches of
every machine implementing ARP according to RFC826:

    The suggested algorithm for receiving address resolution packets
    tries to lessen the time it takes for recovery if a host does
    move.  Recall that if the  is already in the translation table, then the sender
    hardware address supersedes the existing entry.  Therefore, on a
    perfect Ethernet where a broadcast REQUEST reaches all stations
    on the cable, each station will be get the new hardware address.

It turns out that it doesn't matter if you use a request or a reply
for this to work.  I prefer to use a reply for asthetic reasons, since
I'm not requesting a response.  The algorithm in the RFC to be
followed when receiving an ARP packet of any kind specifies that the
sender's information should be updated in your cache before you ever
look at the opcode or target addresses.
					-Mark