Path: utzoo!attcan!uunet!convex!killer!osu-cis!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!ames!pasteur!ucbvax!pinocchio.UUCP!bzs
From: bzs@pinocchio.UUCP (Barry Shein)
Newsgroups: comp.protocols.tcp-ip
Subject: Dynamic IP address assignment
Message-ID: <8811231554.AA05701@pinocchio.UUCP>
Date: 23 Nov 88 15:54:57 GMT
References: <26200@bu-cs.BU.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 42


From: kwe@bu-cs.bu.edu  (kwe@bu-it.bu.edu (Kent W. England))
>	Age the arp cache.  Then set a "re-use" timer on the IP
>address to be, say 3x, the arp cache time-out.
>	Of course, how do you know when an IP address is released?
>There oughta be a protocol.

The arp cache in Unix is already aged, other O/S's might handle it
differently although that's the obvious approach. The question is at
what rate to age, there's a real thrash issue there.

Another approach might be to re-arp on failure or just compare
incoming packets with the current table (eg. I get a packet from host
foo I already have the IP and ether address for, if I have a different
pair in my table I flush them and either just use the new one directly
or re-arp.) Unix currently considers a new hardware address a security
breach ("Duplicate IP address for xxxxx!").

I don't think an IP release protocol in general would work since
hitting the power switch on the machine will probably release the IP
address in a dynamic environment, at least eventually. Just as well
to just have a way to replace any stale address when needed rather
than remove ones when they're not, storage issues are usually minor
and aging occurs anyhow, particularly as caches fill.

The other problem of course is security, the more ways I have to
manipulate the arp cache with external packets the more ways I have to
spoof or disrupt the system.

Then again the current mechanisms are quite vulnerable to this
already, but if it's being reworked one might think about these issues
as it's made more complicated.

Some sort of challenge might help (eg. I just received a packet which
says that IPx is at a different hardware address, before updating my
table send a packet to the old address and if it responds do something
like alert the console.) No new protocol would be needed, just a ping
or something. It still leaves open the problem of my jumping in and
being an imposter for your system if I notice you down, an easy thing
to do with a program and no manual intervention.

	-Barry Shein, ||Encore||