OF RECORD

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.

Executive Summary

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.

Purpose

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 Non-compliance, below).

Definitions

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 essential.

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 charges.

Scope

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 if uncertain.

Statement of Policy

  1. 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.
  2. 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.
  3. 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.
  4. 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 clients.
  5. 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.

  1. 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.
  2. 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 configuration syntax.
  3. 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 to handle.
  4. 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 segment(s).
  5. The use of Dynamic BOOTP is discouraged because addre assignments last forever. DHCP should be used instead.

Compliance

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.

References

Almanac, Vol. 47, No. 4, September 19, 2000

| FRONT PAGE | CONTENTS | JOB-OPS | CRIMESTATS | COUNCIL BYLAWS, 2000 | POLICIES OF RECORD: PennNet Host Security, Opereration of DHCP & BOOTP Servers, Affirmative Action, Sexual Harassment and Privacy in the Electronic Environment | TAT: "Facing Reality" (L. Hunter) | TALK ABOUT TEACHING ARCHIVE | BETWEEN ISSUES | SEPTEMBER at PENN |