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.
To use OIT DHCP Service, your device 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.
OIT DHCP Service is not available on the following OIT networks: bargainnet, basnet, basnet2, beepbeepbeepnet, cryptnet, ctl-pstn-net-1, ctl-pstn-net-2, directornet, ee-net-2, expressnet, eis-firewall-heartbeat-1, eis-firewall-sync-1, extern-linknet*, fragilenet, f5-heartbeat-1, fw-servernet-*, fwzone-dev-*, iacnet, ips-private, jumbo-net, kachingnet, knockknocknet, lb-servernet-*, lightnet, lightnet2, linknet*, nortel-cs2100-internal-net, novanet, oit-eis-aws-supernet-0001, opensesamenet, papyrusnet, pci-servernet-*, pci-vm-mgmt, pci-vmotion, pci-storage, pingpongnet plinknet*, ppn-vss-testnet, promax-net-1, puhepnet, pu-net-12-161-8-0, russnet, sbc-heartbeatnet-*, science-dmz-net, skeletonnet, smilenet, sonnet, stellanet, telegraphnet, tbnnet, tgardner-net, uhs-net-1, valetnet, viewnet, viewnet2, voip-servernet, voip-servernet2, voipnet*, voltnet, and wattnet.
OIT DHCP Service is also not available on the following OIT networks: vapornet100, visitornet101, and wingnet. On those networks, OIT operates specialized DHCP services (not OIT DHCP Service). The behavior of those specialized DHCP services is not described by this document. Detailed documentation of the specialized DHCP services provided by OIT on those networks is not presently available.
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.
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 must not run two DHCP clients (or both a DHCP and a BootP client) simultaneously on a single physical interface. (If it malfunction in this way, some services for it may be blocked; see Running Multiple Simultaneous DHCP Clients on a Single Network Interface Can Interfere With Service.)
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.
The htype assigned to both Ethernet and Wireless is 01, so the client must specify 01 as its htype. And because the hlen associated with that htype is 06, the client must specify 06 as its hlen.
For example, say the DHCP message specifies an htype of 01 and a chaddr of 00 01 02 a0 bc d3 (also written as 0:1:2:a0:bc:d3, 00:01:02:a0:bc:d3, or 000102a0bcd3). If the message also includes a DHCP Client Identifier, its value must be 01 00 01 02 a0 bc d3.
For more details, see DHCP Client Identifier Must Match Client Hardware Type and Hardware Address.
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. 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 the servers providing OIT DHCP Service and OIT BootP Service to reliably communicate with these devices (after all, traffic from/to them is deliberately blocked), we cannot reliably provide OIT 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.)
Some customers configure their devices to refuse to respond to PING. They do so in the belief that this will make their devices less visible, and therefore less subject to attack. Whether this is effective is debatable.
Some devices support features that allow them to remain online while in a sleeping or low power state. (These features go by a variety of names; some include "Power Management" or "ARP Offload.") Some vendors implement these features in such a way that while a device using this feature is online while sleeping or in a lower power state, the device will not respond to PING (but will, for example, respond to IP ARP requests).
A side effect of refusing to respond to PING while remaining online is that when your device malfunctions in such a way as to "overstay a DHCP lease" (for example, your device hangs), DHCP servers will be unable to tell that that IP address is being "stolen." If the IP address your device is now "stealing" is a dynamically assigned IP address (for example, one provided by OIT Mobile IP Service, Temporary Unregistered Dormnet (TUD) IP Service or Visitor IP (VIP) Service), because OIT DHCP Service will be unable to tell that the IP address is in-use, they will lease the IP address to another device, or series of other devices. That disrupts service to the other device(s) on an ongoing basis. (It can even drive the victim into a DHCP offer/request/decline looping state that degrades DHCP service throughout the campus.) To restore service to the victim, OIT will have to block service to your device swiftly.
If your device had responded to PING, the DHCP servers might have been able to notice the problem, log it for OIT staff, and avoid leasing the IP address to another client. OIT staff would then typically notify you of the problem and give you a short time to correct it.
So by operating your device in such a way that it will sometimes (or always) refuse to respond to PING while remaining online, you increase the likelihood that when your device overstays a DHCP lease, OIT will have to block your device immediately rather than give you a short time to correct the problem.
Devices which interfere with service in this way repeatedly may be deemed unsuitable for further use with all services which use DHCP to provide dynamically-assigned IP addresses to clients, and blocked from further use of those services. Such services include, for example: OIT Mobile IP Service, Temporary Unregistered Dormnet (TUD) IP Service, OIT Wireless Service, and Visitor IP (VIP) Service.
Multihoming the device (attaching it simultaneously to more than one 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 PING response, 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. If the device chooses to send its PING response packets in this way, they may never reach the campus DHCP servers. It is best to not multihome a device which will rely upon OIT DHCP Service.
This tag sometimes is added to the entry by OIT staff responsible for operating OIT DHCP Service when a device's DHCP or BootP client software is so badly broken its use significantly degrades or disrupts the service for others.
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").
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 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.
This is based on the canonical fully-qualified DNS name associated with the leased IP address. The value we return is the same as that fully-qualified DNS name, with the first (left-most) component of that name removed. For example, if the fully-qualified DNS name is example.princeton.edu, the default DNS domain we return is princeton.edu.
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.
Also, no NetBIOS-over-TCP/IP Name Servers are provided by default if you are being leased an IP address on the following networks, because these network might not be able to communicate with those servers: lca-dante-audio, lca-dante-audio-secondary, and lca-clear-com-helixnet.
This information is ommitted when we omit a list of NetBIOS-over-TCP/IP Name Servers.
Exception: no NTP server list is provided by default if you are being leased an IP address on the following networks: smoke-signals-net (because OIT NTP Service is not supposed to be provided to this network).
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.
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 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:
All wireless services provided by OIT rely on DHCP, so are not available to BootP clients.
Similarly, TUD Service, Visitor IP Service 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.)
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.
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.
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:
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.
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.
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.