Subject: RE: DHCP server startup announcement

From: Jerry Roy <[email-masked]>
Date: Mon, 25 Sep 2000 10:32:22 -0700

Hello all,

Why not have the DHCP relays that the DHCP Server hears from have a
mechanism that allows the relay to forward the "server available" only out
onto the segments that the relay has responsibility.

Best Regards,

Jerry Roy
Flashcom, Inc.

-----Original Message-----
From: Bernie Volz [mailto:[email-masked]]
Sent: Monday, September 25, 2000 5:07 AM
To: DHCPv4 discussion list
Subject: RE: DHCP server startup announcement

FYI - This won't work completely because while great for clients that are on
the same physical link as the server, what happens if the server and clients
aren't on the same link (broadcast can't reach the clients). While relays
that are on the same physical link  as the server, could forward, there are
likely relays that will not be and they won't receive the broadcast.

One option might be for the server to send a directed broadcast to all of
the networks it is configured to support. (Perhaps the reconfigure-01.txt
draft already says that).

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Erik Guttman [mailto:[email-masked]]
Sent: Monday, September 25, 2000 3:00 AM
To: DHCPv4 discussion list
Cc: DHCPv4 discussion list
Subject: Re: DHCP server startup announcement

Stuart Cheshire wrote:
> When a DHCP client fails to find a DHCP server, it typically keeps 
> broadcasting DHCP DISCOVERs at a low rate (e.g. one every five minutes).
...
> One thought that occurs to me is that we could borrow from 
> draft-ietf-dhc-pv4-reconfigure-01.txt -- the server could broadcast a 
> FORCERENEW (perhaps with all zeroes in the chaddr field) effectively 
> saying, "To any client that currently has no server-assigned address, and 
> would like one, a server is now available for you to send a DISCOVER."

I fully support this direction.  This will make it much easier for
auto configured clients to discover DHCP servers.  One of the problems
with the 'polling model' is that devices will discover the DHCP server
at different times.  During this 'transition' phase, some devices could
potentially be unable to communicate.  This could be avoided by having
devices discover the DHCP server through an announcement and transition
en masse.  Considering that - there should be some randomizing interval
so that hosts that receive the FORCERENEW don't all try to hit the DHCP
server at once :-)

Erik

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Sep 2000 10:46:58 -0700

> onto the segments that the relay has responsibility.

The DHCP relay agent is the sacred cow of the DHCP protocol - a lot of
backwards-bending was done to avoid having to modify them.   So
they're basically pretty stupid devices, and having them do this
probably wouldn't work.

However, since the DHCP server has to know what networks it serves,
and since this is an optional feature, it might be okay to have the
DHCP server simply do directed broadcasts to each of the subnets it
supports.

			       _MelloN_

---

From: Thomas Narten <[email-masked]>
Date: Mon, 25 Sep 2000 14:18:06 -0400

> DHCP server simply do directed broadcasts to each of the subnets it

Operationally, enablement of directed broadcast is frowned upon these
days, as it enables a class of DOS attacks (e.g., smurf attacks).

THomas

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Sep 2000 11:21:57 -0700

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.

			       _MelloN_

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 25 Sep 2000 11:35:50 -0700

> certainly the most common case.

Well, the multicast bootp relay extension would work with this too. The
server would only have to send the message to the multicast address that
the relay agents were listening on.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

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

> the relay agents were listening on.

Wouldn't that wind up going back to the server, not to the client?   :'}

			       _MelloN_