Subject: RE: DHCP server startup announcement

From: Nathan Lane <[email-masked]>
Date: Mon, 25 Sep 2000 13:37:15 -0500

> From:	Ted Lemon [SMTP:[email-masked]]
> Subject:	Re: DHCP server startup announcement 
> 
> 
> Mark Sirota suggested offline that one could just use the relay
> agent's broadcast bit capability to send the packet to the local
> subnet.  The main problem with this is that it means you have to
> configure the server with the IP addresses of all the relay agents.
> OTOH, the server may already know all their IP addresses, in an
> environment where relay agents are all running on embedded routers -
> certainly the most common case.
> 
However, this could become complicated by many implementations that attach
the relay agent to the physical interfaces of a network instead of the
virtual in an HSRP or VRRP environment.  In an environment where more than a
simple pairing of HSRP or VRRP exists, we could introduce some serious
instabilities.  

Wouldn't this announcement have to be periodic to do any good anyway?

Finally, there is no relay agent on a secondarily assigned network.  I'm at
a loss at the moment to how this configuration would be handled.  (Some
relay agents will forward "spoofed" giaddrs, some will not.)

-Nathan Lane

**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to 
whom they are addressed.  If you have received this email 
in error destroy it immediately.
**********************************************************************

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Sep 2000 12:39:54 -0700

> simple pairing of HSRP or VRRP exists, we could introduce some serious

In this case, the server has to know that this is going on.
Obviously it only needs to send to one of the router addresses on a
given physical network.

> Wouldn't this announcement have to be periodic to do any good anyway?

Nope.   If the server is up when the client comes up, the client will
discover it.  It's only if the server _isn't_ up when the client
starts that the client needs to get this message.

			       _MelloN_

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 27 Sep 2000 15:40:10 +0200

>starts that the client needs to get this message.

I had trouble once with a DHCP server that handed out very long term 
leases, and lost its memory when rebooted, handing out the same numbers 
again to new clients.
If a FORCERENEW command had been available, the vendor could have had an 
alternative to using nonvolatile storage.

          Harald

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Sep 2000 14:54:40 -0700

> alternative to using nonvolatile storage.

Understood.   But how would you deal with the problem of a network
outage at the time that you decided to recover from this using
DHCPFORCERENEW?   Broadcast the DHCPFORCERENEW every five seconds?
Also, what's being proposed here is a DHCPFORCERENEW that would cause
clients *without* existing DHCP-assigned addresses to try to get
DHCP-assigned addresses, so this wouldn't help in your case.

			       _MelloN_

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 28 Sep 2000 16:46:14 +0200

>DHCPFORCERENEW?   Broadcast the DHCPFORCERENEW every five seconds?

argh - yes.
if we want to complexify this thing, DHCPFORCERENEW should have a 
timestamp, saying "all leases from before this timestamp are declared 
invalid", meaning that we could safely rebroadcast it - but this looks like 
a patch upon a kluge upon a bad implementation - forget it; DHCP doesn't 
deal well with server forgetfulness, and fixing that requires more than an 
off-the-top-of-the-head design idea.

>DHCP-assigned addresses, so this wouldn't help in your case.

it should then be called YOUCANASKNOW rather than FORCERENEW, since it 
doesn't want to force a renew......

thanks for listening!

---

From: Ted Lemon <[email-masked]>
Date: Fri, 29 Sep 2000 11:52:33 -0700

> doesn't want to force a renew......

I can't argue that point.   I'd personally rather we didn't overload
options - perhaps it should be DHCPADVERTISE.   This is sort of
related to Dale's proposal, although I think Dale's proposal goes a
bit too far - his DHCPFORCERENEW with a timestamp would have to be
signed, and signing such a packet for all clients is a hard problem.
DHCPADVERTISE wouldn't have quite the same security implications.

			       _MelloN_