Date: Fri, 17 Jan 1997 23:10:05 -0800 From: Akihiro Tominaga <tomy@gunpowder.Stanford.EDU> To: brian@awfulhak.demon.co.uk Cc: hackers@freebsd.org Subject: Re: (wide) DHCP negotiation using the REQUEST_IPADDR option Message-ID: <199701182013.MAA27661@gunpowder.Stanford.EDU> References: <199701180211.CAA04695@awfulhak.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199701180211.CAA04695@awfulhak.demon.co.uk>
"Re: (wide) DHCP negotiation using the REQUEST_IPADDR option "
"Brian Somers <brian@awfulhak.demon.co.uk>" wrote:
> In my scenario, the server 'Z' has an explicit (bootp style MAC
> address) reference that says IP 10.1.1.1 and the client is asking
> for IP 10.0.0.1.
>
> IMHO, the server must NAK as it is obviously responsible for telling
> the client that it's wrong.
>
> I think you're looking on it as if I've changed the entry from
> one server to another - the old server still has a lease, but should
> be quiet non-the-less in case it NAKs before the correct server ACKs.
> The difference is that the 'Z' server is still responsible for
> telling the client (in my setup).
No. Please consider about the following case.
A client is assigned 10.0.0.1 from server 'A'.
The server 'A' goes down with some trouble.
The client can't extend lease for 10.0.0.1 then gives up to use it.
The client is assigned 10.0.0.2 from server 'B'.
The lease for 10.0.0.1 expires.
The server 'A' comes up again. It has expired lease of 10.0.0.1
The client can't extend the lease for 10.0.0.2, because of some trouble.
Now, the client goes to init-reboot state, and send DHCPREQUEST with
requested-IP address "10.0.0.2".
Although server 'B' sends back ACK, but server 'A' sends back NAK
previously, the client cannot use "10.0.0.2".
Do you understand?
> If 'Z' doesn't NAK the client, there's no way of ever changing an
> IP number until it expires (unless you can tell the client to stop
> suggesting the old IP number). This is disasterous if you set up a
> bad IP for a client, and boot the client before realizing the
> mistake.....
This situation happens many time.
I'm asking to DHCPv4 ML, so I obey the consensus at there.
Thank you for your bug report, again.
--
Visiting Researcher of Stanford Univ.
Mosquito Net Project.
Keio Univ.
WIDE Project.
Akihiro Tominaga (tomy@mosquitonet.stanford.edu)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701182013.MAA27661>