Policy on the Operation of DHCP and BOOTP Servers on PennNet
Effective: May 30, 2000
Authority and Responsibility
Information Systems and Computing's Networking organization is responsible
for the operation of PennNet (Penn's data networks) and therefore has the
authority and responsibility to specify requirements for any devices connecting
to PennNet. This authority extends to device configuration management and
information provided by configuration servers, as incorrect information
could adversely impact the operation of other network-connected devices.
This policy specifies the requirements for Dynamic Host Configuration
Protocol (DHCP) servers and related infrastructure operating on PennNet.
It also provides "best practice" recommendations for server administrators.
The purpose of this policy is to specify the requirements and limitations
for DHCP server operation on PennNet. While DHCP servers can provide a very
efficient and convenient way to manage IP addresses and other configuration
information for a group of network-connected devices, their use under certain
circumstances can cause significant problems (see Risk of
- Broadcast Domain:
- A broadcast domain is a subnet or collection of subnets on which broadcasts
are shared. A machine broadcasting packets can be heard by any other machine
within that broadcast domain. On PennNet, a broadcast domain is typically
a single IP subnet, but that is not necessarily always the case. ISC Network
Operations can assist with determining the limits of your broadcast domain.
- DHCP or BOOTP Server:
- Any device that responds to valid client DHCP or BOOTP requests on
PennNet (henceforth called "server").
- Relay Agent:
- Any device that forwards such requests along to a server, usually residing
on another subnet or broadcast domain.
Risk of Non-compliance
Since DHCP works in part through broadcast client requests, it is easy
to see that within a single broadcast domain, only one DHCP server should
be configured to respond to requests. More than one DHCP server operating
on the broadcast domain could cause unpredictable results, including multiple
and differing responses being returned to a client having made a request,
which in turn can result in unpredictable client operation. For this reason,
some coordination among those operating local and central DHCP servers is
Another problem has to do with providing service to a number of different
academic or administrative units sharing a broadcast domain. One unit may
wish to use DHCP to make IP address leases available to its own clients,
but may find that address leases made available on the broadcast domain
may be offered to and accepted by clients from any o all other units sharing
the broadcast domain. This is undesirable since the pool of address leases
available to any one of the units is both limited and the basis for network
This policy applies to any device acting as a DHCP or BOOTP server or
relay agent on PennNet.
Restrictions on the operation of servers apply to all centrally operated
PennNet subnets. Subnets that are supported by organizations other than
the University's central networking organization are not covered directly
by this policy. Network users are advised to check with their local LSP
Statement of Policy
- Anyone running a server or relay agent on PennNet must register the
server or relay agent with ISC Networking. ISC Networking reserves the
right to disallow a server or relay agent if it would result in a conflict
with another serving the same broadcast domain.
- Authorized servers or relay agents may need to be shut down or reconfigured
at a later date, if another academic or administrative unit sharing the
broadcast domain finds a DHCP-related conflict.
- ISC Networking will not configure central relay agents to point to
any servers other than those centrally operated by ISC Networking. Similarly,
any relay agents must be configured to point only to servers for which
the server administrator has granted permission for the traffic.
- DHCP service offered by ISC Networking is restricted to a subset of
possible DHCP functionality. For example, ISC Networking will not configure
the centrally operated server with special options required by certain
- All IP addresses handed out by a server must be registered in accordance
with the Policy on the use of PennNet IP address space at www.isc-net.upenn.edu/policy/approved/20000124-ipaddress.html.
Recommendations and Best Practices
The following related practices are strongly recommended by ISC Networking.
- Servers running on shared broadcast domains (multiple academic or administrative
units sharing a broadcast domain) should be configured to answer to uniquely
known clients only, perhaps using MAC address as an identifier. Alternatively,
a private subnet can be ordered from ISC Networking for additional cost,
thus isolating the clients and server within a private broadcast domain.
- Servers must be configured with a thorough understanding of the network
topology in order to avoid conflict later. ISC Networking can help to describe
the network topology, but no support is offered for any specific server
- Lease lengths should be chosen carefully; they should be long enough
to avoid unneeded network traffic, but short enough to avoid running out
of leases. There is no default recommendation. Some factors involved in
the decision include the size of the address range, the frequency with
which machines come and go, and the amount of traffic the server is prepared
- Relay agents should be configured to deliver packets to the unicast
IP address of the server(s) rather than the broadcast address of the associated
- The use of Dynamic BOOTP is discouraged because addre assignments last
forever. DHCP should be used instead.
A. Verification: ISC Networking does not plan to actively police
the network in an effort to discover unregistered or misconfigured servers
or relay agents, but will act on those discovered during the normal course
of events in operating and/or troubleshooting the network.
B. Notification: Notification shall be made to the LSP and/or
server administrator for the area whenever possible and practical.
C. Remedy: Remedy will either be the suspension of DHCP services
from the non-compliant server, or removal of the server or relay agent
from the network until such time as the DHCP service can be suspended or
brought into compliance. ISC Networking will offer assistance to the LSP
for the area.
D. Financial Implications: Charges may be assessed for time spent
by ISC Networking in troubleshooting problems attributable to a non-compliant
or misconfigured server or relay agent. Please see the Policy on Troubleshooting
Charges for Violations of PennNet Policies for information on additional
fees that may be assessed to cover the costs incurred in troubleshooting
related to violations of this policy.
E. Responsibility: Responsibility for remedy lies with the network
user. In the vast majority of cases, the area LSP will have involvement
in the implementation of the remedy.
F. Time Frame: Non-compliant servers must be remedied immediately
to reduce risk of networking failures for other network users.
G. Enforcement: Please see the Policy on Computer Disconnection
from PennNet at www.upenn.edu/computing/policy/disconnect.html.
H. Appeals: Please see the Appeals section of the Policy on Computer
Disconnection from PennNet at www.upenn.edu/computing/policy/disconnect.html.
Almanac, Vol. 47, No. 4, September 19, 2000
PAGE | CONTENTS
BYLAWS, 2000 | POLICIES OF RECORD: PennNet
Host Security, Opereration
of DHCP & BOOTP Servers, Affirmative
Harassment and Privacy
in the Electronic Environment | TAT:
"Facing Reality" (L. Hunter) | TALK
ABOUT TEACHING ARCHIVE | BETWEEN
ISSUES | SEPTEMBER at PENN