1. About DHCP
The Dynamic Host Configuration Protocol provides an excellent solution to two significant problems with IP addressing.
- As the number of hosts connected to the internet continues to grow exponentially there is developing a shortage of available IP addresses.
- As portable computers roam between different networks their IP addresses need to change accordingly, preferably without the need for user intervention.
The central idea of DHCP is that when a computer is attached to a particular network, it may inquire particular details of its environment, and be supplied with an IP address from a special pool. Another mode of operation allows the computer to receive the same address each time, lowering the administrative burden of managing PCs.
If you are a college or departmental network administrator and you wish to join the scheme, then you may need to surrender a pool of IP addresses from your network to be used for DHCP. All addresses in the pool must be registered in the DNS. If you are assigning DNS entries to a large dynamic pool then the networks team may be able to assist in bulk-registration.
The hardware (MAC) addresses of registered clients must be supplied. Client registration is normally on a per-subnet basis. Units with multiple subnets may choose whether or not their registrations are active across all subnets or on just one. It is now possible for IT Services to configure peer trust relationships between units, so host registrations for one unit are valid on another.
On shared subnets, DHCP may be problematic. It is not possible for two different units to use the IT Services DHCP service on a shared subnet simultaneously. One unit may do so, but must use MAC address registration to ensure that clients belonging to other units cannot obtain leases from the IT Services DHCP servers.
You may also register hosts with fixed IP addresses to use DHCP (the fixed addresses must NOT be within your dynamic pool!). Indeed some subnets will only do this and dispense altogether with the need for a dynamic pool.
2. Technical information
The central DHCP service runs on two servers, dhcp-b.ox.ac.uk and dhcp-c.ox.ac.uk. The two servers are physically on separate networks within IT Services, giving some degree of redundancy in the event of network problems. Inter-server communications allow the servers to exchange state information for load-balancing and resilience.
All broadcast requests on port 67 within the university are intercepted by the routers, and forwarded to the two central DHCP servers. However, the servers will ignore requests coming from a subnet unless that subnet has been registered to the IT Services DHCP service. Furthermore, no response to a request will be given unless the client MAC address is registered, OR the request comes from a subnet configured to allow any client machine to request an address by DHCP, irrespective of whether it is registered. Thus the central servers should not accidentally interfere with the operation of any DHCP server operated by an individual unit.
In the event that both DHCP servers make a DHCP offer to a requesting client, the client will respond and take an address from the first to reply. The address offered by the second DHCP server will be released and made available to other requesting clients.
The default lease time is four hours, although it is possible to request this to be changed this on a per-subnet basis.
Note that DHCP can cause problems on subnets which are "shared" between two or more units (usually college annexes or small departments), leading to the allocation of an address in another unit's namespace.
3. Services and documentation for network administrators
- DHCP updates form (to register)
- DHCP updates form (to delete)
- Query DHCP server logs
- Summary of networks using IT Services DHCP service
You may query the currently active DHCP configuration for MAC addresses or other terms. Note that requests queued but not yet active will not be shown.
|Search for ethernet address:|
|Search for allocated address (if applicable):|
|Search via name:|
Further documentation is available: