Over the last decades, we have witnessed tremendous growth in the size of networks. This growth has occurred in the geographic spread of the network, as well as an exponential rise in the number of nodes per network.
The role of dynamic address assignment is to provide IP addresses to our network devices (client) as they are needed, using a database as a source of IP addresses and related parameters. The information in this database is provided by a server to clients needing address configuration. These servers match a client with their address records in the database and return the information stored there to the client. The client then sets its IP configuration using the parameter values returned.
Benefits of Dynamic IP Address Assignment
Dynamic address assignment provides several benefits to the administrator. It greatly reduces the time spent configuring clients, since the process occurs automatically across the network rather than having to visit each workstation. Instead, administrators spend their time configuring the database. It can also help prevent configuration problems such as duplicate address assignments or input errors. It may even provide a mechanism for recovering and reusing assigned addresses that are no longer being used.
A key feature of dynamic address assignment concerns the protocols that are used between the requesting client and the server that provides address information. These protocols define the process of obtaining configuration information. They specify the format of the packets used to convey information between client and server and may define the range of information that can be distributed to the client. The rest of this chapter will focus on these protocols.
A Brief History
It’s ironic to note that the original impetus for much of the development of dynamic addressing protocols was not fueled directly by the desire for remote IP address configuration. Rather, it was based on the need to define a protocol that could be used to boot a diskless host across the network.
The focus on diskless booting was a product of the times since during the 1980s when the original BOOTP RFC was released, there was a flirtation with the diskless workstation architecture not unlike the current interest in terminal servers and “network computers.”
Diskless workstations used centralized disk storage, which could reduce the total costs of mass storage during an era when these costs were very high. They also held the promise of greater control over the data, centralized backup and administration, and file sharing.
The central challenge posed by the diskless workstation was how to get it booted when it had no drives to boot from. The solution involved the use of the network interface card, with a programmable ROM chip that contained enough code to figure out its IP address, locate a server to transfer down a boot file, and then execute the boot file to get the rest of its instructions.
The RARP Protocol
To enable this PROM to communicate with the servers providing addresses and boot files, several methods were devised. Early attempts at doing this involved the use of RARP (reverse address resolution protocol). RARP is a protocol that a client can use to request an address from a RARP server, using its MAC address as its identifier. Unfortunately, RARP was designed to operate directly on top of the data-link layer and thus does not use network-layer (IP) addresses. It’s therefore not routable, and can’t be used in subnetted environments.
The BOOTP Protocol
The BOOTP protocol was defined in RFC 951, released in September 1985. It described a protocol that would use a UDP datagram, on top of IP, to exchange address and booting information. The BOOTP packet contained fields for the assigned address, address of the boot file server, and name of the boot file, and also provided a “vendor extensions or options” field, which could convey numerous other parameters. BOOTP also was designed specifically to be capable of operating across a subnetted network, using a BOOTP Relay agent.
The DHCP Protocol
The DHCP protocol, first defined in RFC 1541 in October 1993, was designed to be a refinement and extension of the BOOTP protocol. It used the same packet structure as BOOTP, but made extensive use of the vendor field (now called the options field) to convey DHCP-specific information. Enhancements provided by DHCP included the ability to define ranges of addresses to be given out, rather than having to provide individual entries in a database for each client. It also provided the ability to lease an address for a finite time period and recover addresses that were no longer being used.
Read our DHCP protocol main article.
Some of the more recent developments in this area include the tying together of DHCP servers and DNS servers so that dynamic address assignments can be communicated to the DNS server. The DNS server then updates its host-name-to-address-resolution database with the proper addresses.
