Subject: Server broadcast proposal

From: Dale Worley <[email-masked]>
Date: Thu, 28 Sep 2000 16:26:08 -0400

There are a number of nagging problems with DHCP that it seems to me
could be solved with a single mechanism -- a message type for a DHCP
server to periodically announce to the clients on its network(s)
certain information (options) that apply to all clients.  Let us call
this message SERVERBROADCAST for the time being.  I am organizing my
thoughts on this subject (perhaps for an Internet Draft) and am
looking for your feedback.

SERVERBROADCAST could be used to solve a number of problems:

- When a DHCP server comes up on a network, to induce changeover from
no-addresses or auto-configured addresses to DHCP-assigned addresses
quickly and more-or-less simultaneously.

- To enable a DHCP server to force clients to give up their current
leases and obtain new leases.

- To enable a DHCP server to announce changes in the lists of network
resources (time servers, print servers, Novell servers, etc.) that are
distributed via various DHCP options.

The main concept is that a DHCP server sends a SERVERBROADCAST message
to all its network(s) when it starts up, and periodically thereafter.
The SERVERBROADCAST message contains options that are apply to all
clients on its network(s).  The DHCP clients listen for and take action
on all options in any received SERVERBROADCAST message.

* Network loading

The intention is that SERVERBROADCAST messages will add very little
load to the network.  The re-sending period should be reasonably long
(1 minute or 5 minutes), and the number of DHCP servers on any network
will be small (typically 3 or less).

In order to prevent the responding clients from flooding the DHCP
server with requests for addresses, it may be a good idea to specify
that they should wait a random (but short) period of time between
receiving a SERVERBROADCAST and acting on it.

* Relaying

SERVERBROADCAST messages should be forwarded to all network(s) that
the DHCP server services.  That is, all the network(s) from which DHCP
requests are forwarded to the server.  In principle, bootp/DHCP relays
should forward SERVERBROADCAST messages in the opposite direction that
they would forward bootp requests.  Of course, this only works on
relays that are updated to do so, but it's hard to see any mechanism
for correctly handling these needs over multiple subnets without
direct support from the relays.

* DHCP Auto-Configuration (option 116)

Option 116 with an argument of 1 specifies that the client should not
use an auto-configured IP address.  When this option is received in a
SERVERBROADCAST message, the client must cease using up any
auto-configured IP address.  (Presumably it then attempts to obtain a
DHCP-assigned address.)

This allows a DHCP server that comes on line to force all the clients on
a network to reconfigure their addresses "at once", reducing the
duration of effective network partitioning due to re-addressing.

* FORCERENEW option to require client to get a new DHCP lease

The FORCERENEW option (as yet unassigned) requires the client to
attempt to renew any DHCP lease that it now has.  If the lease cannot
be renewed, the client must give it up.  (Presumably the client will
then attempt to obtain a new lease.)

(If the server also wishes to force clients to give up auto-configured
addresses, it uses the DHCP Auto-Configuration option as well.)

Since the reception of a SERVERBROADCAST message is non-reliable, the
SERVERBROADCAST FORCERENEW option needs to be re-sent periodically.
In order to permit clients to not respond to each re-send, the
FORCERENEW option needs to contain a "version" identifier.  If the
current lease was issued with the same version identifier, the client
need not renew it.

Since the point of FORCERENEW is to correct the situation where the
server's persistent memory of what leases have been issued has been
lost, the version identifiers cannot be a simple sequence number
(which would itself have to be saved in persistent memory), but rather
needs to be generated by a process like the one used to generate
Universally Unique IDentifiers.  (See draft-leach-uuids-guids-01.txt.)
Thus we probably want to make the version identifiers be 128 bit (16
byte) binary quantities.

This means that when the server issues leases it should provide a
FORCERENEW option giving the version identifier that is currently
being sent in the FORCERENEW option in SERVERBROADCAST messages.

(Presumably leases issued without a FORCERENEW option (the
backward-compatible case) would be defined to have a constant version
identifier, e.g., 0x00000000000000000000001.  Thus if a new-style DHCP
server suddenly comes on line, FORCERENEW will invalidate all the old
leases.)

* Resources

A number of options provide information to the DHCP client about
clients that provide various services.  Some examples are:

   14      Merit Dump File   N          Client to dump and name
                                        the file to dump it to
   15      Domain Name       N          The DNS domain name of the 
                                        client
   41      NIS Servers       N          NIS Server Addresses
   42      NTP Servers       N          NTP Server Addresses
   44      NETBIOS Name Srv  N          NETBIOS Name Servers
   48      X Window Font     N          X Window Font Server
   49      X Window Manager  N          X Window Display Manager
   69      SMTP-Server       N          Simple Mail Server Addresses
   70      POP3-Server       N          Post Office Server Addresses
   71      NNTP-Server       N          Network News Server Addresses
   72      WWW-Server        N          WWW Server Addresses
   73      Finger-Server     N          Finger Server Addresses
   74      IRC-Server        N          Chat Server Addresses
   75      StreetTalk-Server N          StreetTalk Server Addresses
   76      STDA-Server       N          ST Directory Assistance Addresses
   78      Directory Agent   N          directory agent information
   85      NDS Servers       N          Novell Directory Services
   112	   Netinfo Address   N		NetInfo Parent Server Address

Now that it is not uncommon for client systems to remain up for a year
or more, it would be good if there was a method for the server to
actively update this information that it provides to the clients.

Including these options in a SERVERBROADCAST message is a way to do
this.

Dale
-- 
Dale R. WORLEY    Project Manager - UPnP        <[email-masked]>
Virata Corp.	  Applications Infrastructure   http://emweb.com

---

From: Bernie Volz <[email-masked]>
Date: Thu, 28 Sep 2000 16:55:15 -0400

Dale:

I do think you'll need to consider some issues here that are important and
potentially impact the usefulness of this:

1) Security. Preventing denial of service attacks by changing information
regarding critical resources.

2) Multiple servers with potentially different configuration information -
which server should a client listen to, should it take whatever it receives
(therefore potentially causing a switching of this infomation between
several possible values should different servers be advertisig different
information).

And, in general just to deal with the multiple server issue since this
increases the broadcast traffic with each server added and thus also the
processing burden on all clients.

Note also that we'd need to review the implications to the FAILOVER
protocol. For example, if failover partners are in "NORMAL" state
(communicating), it might be reasonable to assign only ONE the
responsibility of doing periodic broadcasts. However, that might also have
client implications (since clients don't necessarily know the addresses of
both servers and hence may behave differently in certain instances).

3) Impact on existing clients. The DHC WG has been VERY careful (overly so
in my opinion) about making such changes. What will happen to today's
clients that receive these broadcasts? How can you assure they won't cause
problems for existing implementations?

4) Relaying. Relays are not necessarily connected to the same physical
network segment as the DHCP servers. Therefore, how does the DHCP Server
inform the relays. This could be potentially solved by directed broadcasts
to all configured subnets within the server, but that also opens up
potential issues (since directed broadcasts are often considered a security
threat and disabled).

There are likely other issues that will be raised by WG members. These are
the ones that come to (my) mind immediately.

- Bernie

-----Original Message-----
From: Dale Worley [mailto:[email-masked]]
Sent: Thursday, September 28, 2000 4:26 PM
To: DHCPv4 discussion list
Subject: Server broadcast proposal

* Network loading

* Relaying

* Resources

Dale

---

From: Nathan Lane <[email-masked]>
Date: Thu, 28 Sep 2000 16:21:31 -0500

The mentioned issues are all good issues within DHCP.  However, here are
some comments:

Two out of the three issues raised that SERVERBROADCAST would solve can be
solved, to one extent or another, within the confines of the existing
protocol, relay agents, clients, etc.  By implementing a short renew
interval with a long lease time, a fairly fine degree of parameter changing
and IP changing can be accomplished in a short amount of time.  It is agreed
there are clients that don't accept a lower t1 value, but there are also
clients that claim to be DHCP that don't have the concept of unbinding their
IP address at lease end.

One of the biggest issues that I see with SERVERBROADCAST would be mass
numbers of clients all coming in at exactly the same time.  The mechanism
would have to have a backoff or jitter interval to spread the clients out.
By the time all that complexity is added, what is gained over a shorter (but
carefully implemented) renew interval?

>From what I've seen, relay agents are sort of a sacred cow in the WG.  They
are very difficult to modify as they are often not under the control of the
same people that manage DHCP.  

Another issue is security.  It would not only be opening up a large DoS
attack hole, but a more insidious hijacking attack.  There are ways around
this, but the very opening of another port with a listener on it really
raises a number of security concerns.

-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: Steve Mattson <[email-masked]>
Date: Thu, 28 Sep 2000 23:15:47 -0400

Date:    Thu, 28 Sep 2000 16:26:08 -0400
  To:      DHCPv4 discussion list <[email-masked]>
  From:    Dale Worley <[email-masked]>
  Subject: Server broadcast proposal
  ...
  - To enable a DHCP server to announce changes in the lists of network
  resources (time servers, print servers, Novell servers, etc.) that are
  distributed via various DHCP options.
  ...
  * Resources
  
  ...

  Dale

Our group manages a number of network services for two essentially
separate organizations which have different needs but share the same
facilities and networks.  We run one set of DHCP servers for both
organizations and serve different sets of network configurations 
based on DHCP client affiliations.  The set of common services 
between the two classes of clients is basically limited to 
information about the subnet involved such as netmask.  We would
not be able to effectively load up the SERVERBROASCAST packets
for these networks in response to a server change within one
organization that did not result in a common server set with the
other.

An alternative may be to have the SERVERBROASCAST packets only 
indicate that a change may have taken place on the DHCP server 
end and that the DHCP client should initiate a poll for updated 
configuration information.  This would be similar to a DNS master 
sending out a NOTIFY packet to the slaves it is aware of in the 
sense that the slaves must then initiate the check to see if the 
event on the master was relevant to each slave or not.  

You would also cut down on the size of the packets that DHCP 
clients must repeatedly process.  Broadcasting such a packet 
once a minute per DHCP server per three or so on your network 
doesn't require much processor power on the server end, true.  
Analyzing three packets per minute per how ever many DHCP clients 
you have on your networks, even if only to determine that the 
version number macthes that of the last broadcast you saw from 
that DHCP server, starts to add up after a while.  The broadcast 
packets should be as small as possible.

Steve Mattson
University of Michigan