Application layer protocols 157 Figure 8.10 BootP frame • Op: 8 bits The message type, 1 = BOOTREQUEST, 2 = BOOTREPLY • Htype: 8 bits Same as for ARP/RARP • Hlen: 8 bits Same as for ARP/RARP • Hops: 8 bits Used by relay agents when booting via a relay agent. A client sets this field to 0. • Transaction ID: 32 bits (Also called XID). A random tracking number as for the IP and ICMP protocols • Seconds: 16 bits The seconds elapsed since the client started to boot • Client IP address: 32 bits Set by the client to its IP address, or initially to zero • Your IP address: 32 bits Set by the server to the correct IP address for the client, if the client advertises its IP address as 0 • Server IP address: 32 bits Server IP address, set by the server • Gateway IP address: 32 bits The Gateway (router) address, set by the relay agent • Client hardware address: 16 bytes The client MAC address, set by itself • Server host name: 64 bytes An optional server name, e.g. Garfield or Computer10 • Boot file name: 128 bytes Used by the server to return a fully qualified directory path name to the 158 Practical TCP/IP and Ethernet Networking client, e.g. c:\windows\bootfiles\startup.exe. This is the location on the server from which the boot file has to be downloaded • Vendor-specific area: 64 bytes DHCP options as per RFC 1531 RFC 1532 and RFC 1533 contain subsequent clarifications and extensions to BOOTP. 8.13 DHCP (dynamic host configuration protocol) DHCP, as defined by RFC 1533, 1534, 1541, and 1542 was developed out of BOOTP in an effort to centralize and streamline the allocation of IP addresses. DHCP’s purpose is to centrally control IP-related information and eliminate the need to manually keep track of where individual IP addresses are allocated. When TCP/IP starts up on a DHCP-enabled host, a special message is sent out requesting an IP address and a subnet mask from a DHCP server. The contacted server checks its internal database, then replies with an offer message comprising the information the client requested. DHCP can also respond with a default gateway address, DNS address(es), or a NetBIOS name server, such as WINS. When the IP offer is accepted, it is then extended to the client for a specified period of time, called a lease. If the DHCP server runs out of IP addresses, no IP addressing information can be offered to the clients, causing TCP/IP initialization to fail. DHCP’s advantages include the following: It’s inexpensive. The server software comes built into many operating systems, and the manual effort involved in managing large numbers of IP addresses is reduced. IP configuration information is entered electronically by another system, eliminating the possibility of human error. IP becomes a ‘plug and play operation’. It does, however, have some drawbacks such as: A new user may randomly (delinquently!) enter a fixed IP address on his computer in order to gain immediate access to the network. Later, that number may be assigned by DHCP to a different user and show up as a duplicate. Because the initial input for IP addresses, subnet masks, gateways, DNS addresses, and NetBIOS name server address is done by a human on a PC, it can easily be entered incorrectly. Exclusive reliance on the DHCP server during the TCP/IP initialization phase could result in an initialization failure if that server is down, or otherwise unavailable. Certain applications of TCP/IP, like logging in to a remote network through a firewall, require the use of a specific IP address. DHCP allows for exclusions that prevent certain IP address ranges from being used. If the specific IP address that is needed for remote login has been excluded, the user has a problem. There is an extensive amount of incredibly tedious work involved in maintaining an accurate roster of both used and free IP addresses. 8.13.1 DHCP operation IP lease request This is the first step in obtaining an IP address under DHCP. It is initiated by a host with TCP/IP, configured to obtain an IP address automatically, if booted up. Since the requesting client is not aware of its own IP address, or that belonging to the DHCP server, it will use 0.0.0.0 and 255.255.255.255, respectively. This is known as a DHCP discover Application layer protocols 159 message. The broadcast is created with UDP ports 67 (BOOTP client) and 68 (BOOTP server). This message contains the MAC address and NetBIOS name for the client system to be used in the next phase of sending a lease offer. If no DHCP server responds to the initial broadcast, the request is repeated three more times at 9, 13, and 16-second intervals, plus a random event occurring in the period between 0 and 1000 milliseconds. If still no response is received, a broadcast message is made every five minutes until it is finally answered. If no DHCP server ever becomes available, no TCP/IP communications will be possible. IP lease offer The second phase involves the actual information given by all DHCP servers that have valid addressing information to offer. Their offers consist of an IP address, subnet mask, lease period (in seconds), and the IP address of the proposing DHCP server. These offers are sent to the requesting client’s MAC address. The pending IP address offer is reserved temporarily to prevent it from being taken simultaneously by other machines, which would otherwise create chaos. Since multiple DHCP servers can be configured, it also adds a degree of fault tolerance, should one of the DHCP servers go down. IP lease selection During this phase, the client machine selects the first IP address offer it receives. The client replies by broadcasting an acceptance message, requesting to lease IP information. Just as in stage one, this message will be broadcast as a DHCP request, but this time, it will additionally include the IP address of the DHCP server whose offer was accepted. All other DHCP servers will then revoke their offers. IP lease acknowledgment The accepted DHCP server proceeds to assign an IP address to the client, then sends an acknowledgement message, called a DHCPACK, back to the client. Occasionally, a negative acknowledgment, called a DHCPNACK, is returned. This type of message is most often generated if the client is attempting to lease its old IP address, which has since been reassigned elsewhere. Negative acceptance messages can also mean that the requesting client has an inaccurate IP address, resulting from physically changing locations to an alternate subnet. After this final phase has been successfully completed, the client machine integrates the new IP information into its TCP/IP configuration. It is then usable with all utilities, as if it has been manually entered into the client host. Lease renewal: Regardless of the length of time an IP address is leased, the leasing client will send a DHCPREQUEST to the DHCP server when its lease period has elapsed by 50%. If the DHCP server is available, and there are no reasons for rejecting the request, a DHCP acknowledge message is sent to the client, updating the configuration and resetting the lease time. If the server is unavailable, the client will receive an ‘eviction’ notice stating that it had not been renewed. In this event, that client would still have a remaining 50% lease time, and would be allowed full usage privileges for its duration. The rejected client would react by sending out an additional lease renewal attempt when 87.5% of its lease time had elapsed. Any available DHCP server could respond to this DHCPREQUEST message with a DHCPACK, and renew the lease. However, if the client received a DHCPNACK (negative) message, it would have to stop using the IP address immediately, and start the leasing process over, from the beginning. 160 Practical TCP/IP and Ethernet Networking Lease release If the client elects to cancel the lease, or is unable to contact the DHCP server before the lease elapses, the lease is automatically released. Note that DHCP leases are not automatically released at system shutdown. A system that has lost its lease will attempt to re-lease the same address that it had previously used. 8.13.2 DHCP message format The DHCP message format is based on the BOOTP format, and is illustrated in Fig 8.11. Figure 8.11 DHCP message format The fields are as follows: • Op: 8 bits The message type, 1 = BOOTREQUEST, 2 = BOOTREPLY • Htype: 8 bits Same as for ARP/RARP • Hlen: 8 bits Same as for ARP/RARP • Hops: 8 bits Used by relay agents when booting via a relay agent. A client sets this field to 0 • Transaction ID: 32 bits (Also called XID). A random tracking number as for the IP and ICMP protocols • Seconds: 16 bits The seconds elapsed since the client started to boot • Flags: 16 bits This field contains a 1-bit broadcast flag, as described in RFC 1531 • Client IP address (ciaddr): 32 bits Set by the client to its IP address, or initially to zero Application layer protocols 161 • Your IP address (yiaddr): 32 bits Set by the server to the correct IP address for the client, if the client advertises its IP address as 0 • Server IP address (siaddr): 32 bits Server IP address, set by the server • Gateway IP address (giaddr): 32 bits The gateway (router) address, set by the relay agent • Client hardware address (chaddr): 16 bytes The clients MAC address set by itself • Server name (sname): 64 bytes An optional server name, e.g. Garfield or Computer10 • Boot file name: 128 bytes Used by the server to return a fully qualified directory path name to the client, e.g. c:\windows\bootfiles\startup.exe. This is the location on the server from which the boot file has to be downloaded • Options: Up to 312 bytes DHCP options as per RFC 1531 . bytes Used by the server to return a fully qualified directory path name to the 158 Practical TCP/IP and Ethernet Networking client, e.g. c:windowsootfilesstartup.exe. This is the location. address immediately, and start the leasing process over, from the beginning. 160 Practical TCP/IP and Ethernet Networking Lease release If the client elects to cancel the lease, or is unable. broadcast, the request is repeated three more times at 9, 13, and 16-second intervals, plus a random event occurring in the period between 0 and 1000 milliseconds. If still no response is received,