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 theis 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