OIT Networking & Monitoring Services

OIT DHCP and BootP Services

Contents

  1. DHCP Service
    1. Requirements
    2. What Information Does DHCP Service Provide?
    3. What is a Lease?
  2. BootP Service
  3. Multiple-Interface Devices
    1. Avoid Two Interfaces Simultaneously Attached to the Same Network
  4. Forcing a DHCP Lease to Be Discarded
  5. Advanced Customization
  6. Private DHCP or BootP Servers, or BootP Relay Agents
  7. When is Service Unavailable?
  8. Announcements
  9. Related Resources

DHCP Service

DHCP, the Dynamic Host Configuration Protocol, allows a device attached to the network to automatically learn some or all of its network configuration, including its IP (Internet) address.

This frees you from manually configuring that information on the device, and shields you from needing to reconfigure the device when any of that information changes. A variety of services OIT provides require your client to support DHCP.

For devices attached to the network via OIT Ethernet Service, we usually recommend using OIT DHCP Service if the device supports it, particularly for workstations running recent versions of Apple OS X and Windows operating systems. (Older devices and some other operating systems may not support DHCP, but instead may support an older less-capable protocol called "BootP"; see BootP Service below.)

We normally recommend but do not require using OIT DHCP Service for clients attached via OIT Ethernet Service while they are attached on their home networks. (Equivalently, we normally recommend but do not require using DHCP for use of OIT Static IP Service.)

Clients attached via OIT Ethernet Service outside their home networks must use DHCP to obtain OIT Mobile IP Service. If the client does not have a properly-functioning DHCP client, it will not be able to use OIT Mobile IP Service.

All wireless services provided by OIT rely upon specialized DHCP services provided by OIT, not on the "OIT DHCP and BootP Services" described in this document. Documentation describing the behavior of those specialized DHCP services is not presently available.

A device must use OIT DHCP Service to be able to use Temporary Unregistered Dormnet (TUD) IP Address Service or Visitor IP (VIP) Service. These services are not available for clients that do not have a properly-functioning DHCP client.


Requirements

To use OIT DHCP Service, your device must meet the following requirements:


What Information Does OIT DHCP Service Provide?

OIT DHCP Service provides your device with the information below. Note that the information can vary depending on whether your device is attached to the network in its "home" location (so it receives static IP service) or is visiting another location (so it receives "OIT Mobile IP Service").

The kind of information OIT DHCP Service can (and needs to) provide to clients has grown over time. Therefore, you are cautioned that the list above is not static; from time-to-time we do enhance the information we provide to clients.


What is a Lease?

The IP address (and other information) DHCP provides is "leased" to your device for a specific period.

This assignment happens when your device uses DHCP to discover its IP address; on many devices that happens when the device is started, or when the first IP-based program is run. If your registered device is attached to the network in its "home" location (anywhere on its home network), you are using OIT Static IP Service; OIT DHCP Service will grant a lease for the static IP address that appears in your device's Host Database entry (assuming that static IP address is not on wirelessnet).

If your registered device is attached to the network in another location (or the static IP address that appears in your device's entry is on wirelessnet), OIT DHCP Service will grant a lease for an OIT Mobile IP address.

If your unregistered device is attached to Dormnet, it will receive a TUD IP address for a limited time. If your unregistered device is using Visitor IP Service, it will receive an IP address appropriate for that service,

At this time, the leases OIT DHCP Service assigns for clients using OIT Static IP Service typically expire in twenty-four hours; leases for OIT Mobile IP Service clients typically expire in three to six hours. Leases for TUD Service clients typically expire in one hour. Leases for Visitor IP Service clients typically expire in three to six hours.

Assuming your device remains attached to the network in the same location and continues to use IP, it periodically contacts the DHCP server that granted its lease to "renew" (extend) the lease. This process continues until your device is shutdown or stops using IP, or your device loses its eligibility to continue using the service.

To provide a safety margin, your device actually attempts to renew its lease well before it is due to expire. This time may vary, but at Princeton, it is currently halfway through the lease period. If the particular DHCP server that granted its lease is unavailable, your client continues its renewal attempts (with no ill effects to you) until the server responds, or the lease actually expires.

If your device's DHCP lease expires (all renewal attempts fail), your device's IP stack is responsible for shutting itself down. How this appears to you (and to IP-based software running on your device) is implementation-dependent.


BootP Service

BootP is an older service; it provides a subset of the services provided by DHCP.

Some operating systems that do not support DHCP do support BootP. For OIT Ethernet Service-attached devices that do not yet support DHCP, we generally recommend you use OIT BootP Service. You may also need to rely on OIT BootP Service if your device's DHCP client software does not operate properly, or if some other problem with your device (e.g. a broken clock or frequent OS hangs) prevents it from performing DHCP properly.

In general, the information above describing OIT DHCP Service also applies to OIT BootP Service, with the exceptions described below:


Multiple-Interface Devices

OIT DHCP and BootP Services provide some support for registered devices with multiple physical interfaces. Each interface that is registered in the Host Database with both a unique hardware (e.g. Ethernet or Wireless) address and a unique IP address will receive OIT DHCP or BootP Service if it meets the requirements above. (Any interface registered with just a hardware address, or just an IP address does not receive service.)

For the purposes of OIT DHCP and BootP Services, each registered device's physical interface is treated as a different device. Each interface is assigned a unique DNS name; the entry's first interface is given the same DNS name as the host's fully-qualified canonical name (just as with a single-interface entry). The other interfaces are named differently: if an interface has any interface aliases registered, the interface's first interface alias is made fully-qualified, then used as the DNS name. If an interface has no interface aliases registered, then a DNS name is generated automatically by appending -interfaceNUMBER to the first component of the host's fully-qualified canonical DNS name. E.g. given an entry named foo.bar.Princeton.EDU with a second interface that has no interface aliases, the second interface will be named foo-interface2.bar.Princeton.EDU for the purpose of DHCP and BootP service. This name is what is returned to a DHCP client operating on the devices' second interface, if it explicitly requests its DNS hostname.

As each physical interface is treated as a different device, each has its own "home subnet." Each is independently eligible for its own DHCP lease. Each is independently eligible for OIT Mobile IP Service, and is independently subject to requirements and restrictions on the use of that service.

We do not support DHCP or BootP for devices that require multiple IP addresses (simultaneously) on a single physical interface. A single physical interface is identified by a unique hardware address, and this hardware address is used by the DHCP and BootP servers to uniquely identify a lease. (E.g. we do not support DHCP clients specifying arbitrary "DHCP Client Identifier" values; the DHCP Client Identifier we use is the one implied by the device's hardware address. If a DHCP client specifies a "DHCP Client Identifier" option, we check to verify the value matches the hardware (htype) and hardware address (chaddr) that appear elsewhere in the packet; if they do not match, we ignore the request.)

We do not support DHCP or BootP support for any device that uses the same hardware address on multiple physical interfaces. You must cause each physical interface to use its own unique hardware address. If you cannot do so, then you must only use DHCP or BootP service on that subset of interfaces that can be made to use their own unique hardware addresses; on the remaining interfaces, you must configure them (e.g. manually) so they do not use attempt to use DHCP or BootP service.

Be aware that multihoming a device (attaching it simultaneously to more than one University IP network) can also result in the device not being PINGable from parts of the campus network. This is because the device almost certainly uses the weak-end model for transmiting IP traffic. When it transmits its IP traffic, it may send the packet out one network interface, but using the IP source address of the other network interface. Such traffic will be discarded if it tries to cross campus IP routers as part of our routers' egress filter policies. This is not a DHCP issue, wowever, be aware that if it causes the device to not be PINGable by the DHCP servers, it could lead to the device not meeting the device should respond to PING requirement above.

Avoid Two Interfaces Simultaneously Attached to the Same Network

Our DHCP and BootP services support a device that has multiple interfaces (each with its own unique hardware address and IP address) attached simultaneously to the same IP subnet. However, be aware that the networking software in most operating systems does not work properly if the device has more than one network interface simultaneously attached to the same IP subnet, regardless of whether the device uses DHCP, BootP, or neither service. For example, often the operating system or DHCP client software becomes confused about which IP address belongs to which interface. If that were to happen, and if one (or more) of your interfaces used DHCP or BootP to obtain their IP addresses, having one interface steal the other's IP address is likely to result in your device being declared insuitable for using DHCP and BootP on the campus network. Therefore, if you operate a device with multiple network interface, avoid putting your device into this situation. E.g. if you have two Ethernet interfaces, don't attach both to the same IP subnet at the same time. If you have an Ethernet interface and a Wireless interface, either enable only one interface at a time, or ensure that the two interfaces are attached to different IP subnets. (If you configure your wireless interface to use OIT Wireless Service, OIT guarantees that it will be attached an IP subnet different than your device's Ethernet interface. If you allow your wireless interface to use any other wireless service (e.g. a private/departmental service), there is no such guarantee, and in fact, is the most common cause of multiple-interface clients malfunctioning in this way.) If you have two Wireless interfaces, enable only one at a time.


Forcing a DHCP Lease to Be Discarded

If you make a Host Database change that doesn't cause OIT DHCP Service to invalidate the existing lease, the effect of that change may not be reliably propagated to a DHCP client until any current DHCP lease for that client has been expired or been invalidated on all servers providing OIT DHCP Service. This is because we cannot change the characteristics of a current (unexpired) DHCP lease.

This is usually not a problem, because nearly all Host Database changes either invalidate any current DHCP lease, or affect only fields that have no bearing on a DHCP lease. Situations where it may be a problem include:

In such situations, you need to cause your current DHCP lease to expire or be invalidated on all OIT DHCP servers to force your device to obtain new lease parameters, You may do so in any of the following ways:


Advanced Customization

If your registered device needs additional or different information included in the response it receives from OIT DHCP or BootP Service, you may be able to customize the response provided by OIT DHCP or BootP Service.

You would do so by changing your device's entry in the Host Database, specifically by setting your device's BOOTP-PARAMETERS.


Private DHCP or BootP Servers, or BootP Relay Agents

Customers must not operate their own DHCP or BootP servers on the campus network. Such "rogue" DHCP or BootP servers can quickly disrupt network service to many devices attached to the campus network.

Customers may operate their own DHCP or BootP servers on their own private networks, as long as any reply packets sent by such servers never appear on the campus network. (These reply packets may only appear on the customer's private network.)

Customers must not operate their own BootP Relay Agents on the campus network. Such "rogue" BootP Relay Agents can quickly disrupt network service to many devices attached to the campus network.

When OIT detects a device operating a device in such a way that it functions as a DHCP or BootP server on the campus network, or as a BootP Relay Agent on the campus network, often OIT will block network access for the device to stop it from further disrupting service.


When is Service Unavailable?

OIT DHCP and BootP Service are severely degraded each weekday during 7:00 - 7:01 am, and 7:10 - 7:11 am. The level of degradation is severe enough that many clients will find the service to be unavailable.

This is due to many devices simultaneously waking up at the same time each weekday morning, due to the configuration of DeSC power management. Those devices all request DHCP service simultaneously, exceeding the capacity of OIT DHCP and BootP Services. Staggering the wakeup times of those power-managed devices is presently impractical using the DeSC power management software.


Announcements



A service of OIT Networking & Monitoring Services
The Office of Information Technology,
Princeton University
Last Updated: March 17 2017