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 Ethernet wiring we usually recommend using DHCP if the device supports it, particularly for workstations running recent versions of Mac 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 DHCP 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.
As OIT Wireless Service relies upon OIT Mobile IP Service, clients attached via OIT Wireless Service must use DHCP to obtain service. If the client does not have a properly-functioning DHCP client, it will not be able to use OIT Wireless Service
A device must use DHCP to be able to use Temporary Unregistered Dormnet (TUD) IP Address Service, Temporary Visitor Wireless Network Access (TVWNA) or Visitor IP (VIP) Service. These services are not available for clients that do not have a properly-functioning DHCP client.
To use OIT's DHCP service, your computer must meet the following requirements:
Devices attached to Ethernet that is bridged to OIT Ethernet Service via a private Ethernet repeater, bridge, or switch also can use OIT's DHCP service.
Devices attached to Ethernet that is bridged to OIT Ethernet Service via OIT-maintained ISDN service also can use OIT's DHCP service.
Devices attached to Ethernet that is connected to the campus network via NAS (a.k.a. DSL.net) DSL service (NAS (a.k.a. DSL.net) is a commercial DSL provider) can use OIT's DHCP service.
OIT DHCP service is not available on the following OIT subnets: dmznet*, extern-linknet*, linknet, pu-net-12-161-8-0, shufflenet, and voip-switchnet.
If your device is attached to private (e.g. departmental) Ethernet or Wireless service, check with the person responsible for supporting the private Ethernet or Wireless service to learn if you may use OIT DHCP Service. If your device is attached to the campus network behind a NAT, it cannot use OIT DHCP Service.
OIT DHCP Service is not available on External Customer Networks.
For example, the entry must include a hardware (e.g. Ethernet or Wireless) address, and have an interface WIRE-TYPE of 'Ethernet' or 'Wireless'. The hardware address specified must be accurate; this hardware address is what our DHCP service uses to uniquely identify the client. (It determines the "DHCP Client Identifier.")
The Host Database entry's ENTRY-TYPE and OPERATING-SYSTEM should be specified as accurately as possible, given the selections provided in the Host Database registration forms.
An IP address must be assigned in the Host Database entry; the IP address' subnet must be appropriate based upon where the device is located. The IP subnet specified in your device's Host Database entry is what the OIT DHCP servers will consider its "home" location. For Wireless interfaces, specify the subnet wirelessnet.
If you relocate your registered device "permanently" or for an extended period (e.g. more than two weeks), you should update its entry in the Host Database to reflect the change. (In addition to updating the BUILDING and ROOM, remember to see if the new location is attached to a different subnet; if so, you should request a new IP address by updating the IP-SUBNET-OR-ADDRESS. This IP subnet what the OIT DHCP servers consider your device's "home" location.)
Each physical interface is eligible for a single DHCP lease at a time. (If a request is received from the physical interface for a new DHCP lease, for a lease on a different IP subnet, or for BootP service, any existing unexpired DHCP lease is forfeited.) A device should not run two DHCP clients (or both a DHCP and a BootP client) simultaneously on a single physical interface.
If your DHCP client stops renewing the lease but keeps using the IP address, eventually the DHCP server will lease the IP address to another client; your client will then interfere with service to the new holder of the lease.
If your client is unable to keep track of time (e.g. your client's clock sometimes resets itself, resulting in it going "backward" in time), your DHCP client software will not operate properly. Similar problems occur if your client hangs often, in such a way that the device's DHCP software stops renewing its lease, but the device continues to use the IP address. If these problems happen repeatedly, your device may be declared unsuitable for use with OIT DHP Service.
These three fields must accurately reflect the hardware address of your device's network interface, and must match the 802 MAC source address (e.g. Ethernet or Wireless source address) of your device's network interface.
Devices that "invent" (e.g. forge) values for these fields are not suitable for use with OIT DHCP Service. For example, a device that transmits its frames using one 802 MAC source address, while specifying a different value in the DHCP chaddr field is unsuitable.
Such a device is typically attached to a private-wire network, and the administrator of the private-wire network has determined that the device does not need to communicate outside the private-wire network. The private-network administrator has arranged (typically through hardware filter, or sometimes software configuration) to prevent traffic from the device from leaving the private-wire network and reaching OIT-wire networks (typically to make the device exempt from the Tigernet Host Charge). The private-network administrator has arranged with hostmaster for the device to be assigned an IP address within a range defined as blocked from reaching the rest of the campus network.
Because it is not possible for OIT's DHCP and BootP servers to reliably communicate with these devices (after all, traffic from/to them is deliberately blocked), we cannot reliably provide DHCP or BootP service to these devices. (If such a device is attached to an IP subnet that does otherwise receive OIT DHCP and BootP service, the device should be configured to not attempt to use DHCP or BootP, to reduce spurious traffic.)
OIT's DHCP servers currently provide 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 "Mobile IP Service").
When receiving OIT Mobile IP Service in another location, your registered device receives an OIT Mobile IP address appropriate for the network which you are visiting.
If your registered device's subnet is specified as wirelessnet, then it always receives a Mobile IP address; it will never receive the IP address that appears for this interface in your device's Host Database entry.
When using TUD Service, an unregistered device receives a TUD IP address appropriate for that service. (The service is not available to registered devices.)
When using Temporary Visitor Wireless Network Access (TVWNA), an unregistered device receives a TVWNA IP address appropriate for that service. (The service is not available to registered devices.)
When using Visitor IP Service, an unregistered device receives a VIP address appropriate for that network. (The service is not available to registered devices.)
This information is ommitted when your device is attached to a network that has no default gateway. That includes the following networks: ppnnet.
This information is ommitted for TVWNA clients.
This information is ommitted when your device is attached to a network that cannot communicate with any appropriate NetBIOS-over-TCP/IP Name Servers. That includes the following networks: ppnnet.
This information is ommitted for TVWNA clients.
This information is ommitted when your device is attached to a network that cannot communicate with any appropriate NetBIOS-over-TCP/IP Name Servers. That includes the following networks: ppnnet.
The kind of information DHCP 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.
The IP address (and other information) DHCP provides is "leased" to your device for a specific period.
This assignment happens when your computer uses DHCP to discover its IP address; on many computers that happens when the computer is started, or when the first IP-based program is run. If your registered computer is attached to the network in its "home" location (anywhere on its home network), you are using OIT Static IP Service; OIT's DHCP servers 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 computer is attached to the network in another location (or the static IP address that appears in your device's entry is on wirelessnet), OIT's DHCP servers will grant a lease for an OIT Mobile IP address.
If your unregistered computer is attached to Dormnet, it will receive a TUD IP address for a limited time. If your unregistered computer is using Visitor IP Service, it will receive an IP address appropriate for that service, If your unregistered computer is using TVWNA, it will receive an IP address appropriate for that service for a limited amount of time.
At this time, the leases we assign 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; those for TVWNA clients typically expire in three hours. Leases for Visitor IP Service clients typically expire in three to six hours.
Assuming your computer 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 computer is shutdown or stops using IP, or your computer loses its eligibility to continue using the service.
To provide a safety margin, your machine 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 DHCP lease expires (all renewal attempts fail), your client's IP stack is responsible for shutting itself down. How this appears to you (and to IP-based software running on your machine) is implementation-dependent.
BootP is an older service; it provides a subset of the services provided by DHCP.
Some operating systems that do not yet support DHCP do support BootP. For Ethernet-attached devices that do not yet support DHCP, we generally recommend you use BootP. You may also need to rely on BootP 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 DHCP also applies to our BootP service, with the exceptions described below:
Because OIT Wireless Service relies on OIT Mobile IP Service, OIT Wireless Service is not available to BootP clients.
Similarly, TUD Service, Visitor IP Service, and TVWNA are not available to BootP clients, because without the concept of a "lease", there is no reasonable way for the server to reclaim IP addresses after they have been used.
If a device attaches to any of those services and tries to use BootP to obtain an IP address, it will fail to obtain an IP address. (If it does so persistently, we may eventually have to block the device from connecting to those services entirely, as the device's repeated BootP attempts waste server capacity and network bandwidth.)
We 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 DHCP and BootP services 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 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 support 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.)
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.
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. 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.
If you make a Host Database change that doesn't cause the DHCP server 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 OIT DHCP servers. 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 computer to obtain new lease parameters, You may do so in any of the following ways:
If your registered device needs additional or different information included in the response it receives from our BootP/DHCP servers, you may be able to customize the response we provide.
You would do so by changing your device's entry in the Host Database, specifically by setting your device's BOOTP-PARAMETERS.
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.