In this column we'll describe how to manage the automatic allocation of IP addresses (and other useful information) in a Linux environment for hosts connected to a broadcast-style network like Ethernet. For convenience, we'll refer to these networks as Ethernet, but the same principles apply to many different types of underlying protocols such as FDDI, Token Ring, and AX.25.

What advantages does dynamic assignment offer?

There are a number of situations where dynamic IP address assignment provides benefit. Some of the more important of these are:

Diskless workstations

This was the application that generated the first standard implementations of dynamic IP address assignment. Diskless workstations typically have no stored configuration data. Instead, when they are booted they request configuration data from their network connection. One very important configuration item is the IP address they should use in order to download their operating system.

Itinerant hosts

If you're a laptop owner, you'll understand the nuisance it is to have to manually reconfigure your network configuration every time you move, for example, from your docking station at home, to your GPRS-based mobile telephone while traveling to your docking station at work. Dynamic address assignment automates the low-level network configuration for you when you connect to each new network.

Allows "overbooking" of IP address space

IP addresses are a scarce resource. If you have a number of potential hosts on your network, but an actual occupancy rate that is significantly lower than the total, dynamic assignment allows you to efficiently manage the number of IP addresses required to support large numbers of potential hosts. Internet service providers routinely support quite large numbers of customer on pools of IP addresses that are quite small, this is sometimes called "overbooking." Dial-up modem, ADSL, and cable modem technologies are prime examples of network technologies that typically exploit this mechanism.

Reduces documentation and duplicates IP address clashes

Manually and statically assigning IP addresses to hosts requires accurate and up-to-date documentation in order to prevent duplicate IP address problems. Nearly all dynamic address assignment systems provide logging and reporting capabilities that make the IP address assignment process largely self-documenting.

Reduces user-induced faults

In office environments, it is common to have more than one IP network supporting the user desktop computers. It is common for users to move from desk to desk and often they will consider it reasonable to move their computer with them when they do. Unfortunately if they happen to move from one Ethernet port supporting one IP network on one desk, to another identical-looking Ethernet port supporting another IP network their computer will require reconfiguration to work. Inevitably this results in a call to the IT help-desk wanting someone to "come fix my PC." Dynamic IP address assignment handles this situation elegantly by providing them with a new address from their new network when they first boot up, completely avoiding the manual intervention required to get them working at their new desk.

Discourages inappropriate configuration of servers

Dynamic address assignment can help to discourage inappropriate configuration of some types of application servers on user desktop computers. Most application servers require the end-user to know the IP address of the server machine in order to connect, having the IP address change periodically on user desktop computers frustrates attempts to run those types of servers on them. It's important to note that it's only a frustration and not an insurmountable problem. Dynamic DNS server technology exists specifically to overcome this problem, and some application servers use directory services or other mechanisms to advertise their presence and at what address they're available. Their IP address then becomes largely irrelevant.

When is dynamic address assignment inappropriate?

Dynamic address assignment isn't all good news. There are a number of situations where it is inappropriate, and some where it complicates management.

Application services that use IP as part of authentication.

Some application services use the source IP address of client machines as a component of the client authentication. It is common for NFS, the Network File Service, to allow differing access rights based on the IP address of the client machine; all hosts on a network may be allowed read-only rights, but certain select hosts may be allowed read/write access. Clearly you don't want the client machines changing IP address if you want this mechanism to work. NFS is by no means alone, the TCP wrapper daemon and any application using it might similarly demand static addresses. The secure shell service (ssh) can also rely on the IP address of a host as part of the authentication credentials required to open a session to it.

IP filtering/NAT/accounting by host address won't work.

Normally any IP filtering or NAT (Network Address Translation) rules would apply to whole IP networks, but occasionally you'll want to allow certain hosts special holes through your firewall. Naturally if you want to do this it's important that that host always has the same IP address. Similarly if you're using IP accounting techniques to analyze traffic distribution on your network, the results will be most useful if the high-volume hosts always have the same address.

Some services just won't work without trickery.

Some application services rely almost completely on statically assigned IP addresses. Examples of these are SMTP (Simple Mail Transfer Protocol), and the "talk" service. You can make use of dynamic DNS to help reduce the pain of SMTP in this environment, but it would be far more common to completely avoid it and have the users use a protocol like IMAP (Internet Mail Access Protocol) or POP (Post Office Protocol) to retrieve their mail from a central server that does has a statically assigned IP address. The "talk" program and protocol is annoyingly fussy about IP addresses and the host names associated with them, so again substitution is the sensible recourse; go for one of the open instant-messaging systems instead.

Fault finding can be made more difficult.

If you're trying to track errant behaviour on your network, dynamic IP address assignment can make the task of identifying a misbehaving machine much more difficult. You're forced to rely on Ethernet addresses to identify a machine, and they're not as easily remembered nor are they often recorded.

What protocols exist, how do they work?

There are three well-known protocols that manage dynamic IP address assignment for Ethernet networks; a brief description of each follows. If you want an exhaustive description of each protocol, see the relevant RFC documents.

All three protocols are related and make a nice study of evolutionary development and innovation should you be a history buff.

Reverse Address Resolution Protocol 'RARP' (RFC-903)

The Reverse Address Resolution Protocol (RARP) complements the Address Resolution Protocol (ARP) and was designed specifically with diskless workstations in mind.

The ARP protocol is used by hosts wishing to discover the hardware address associated with a particular IP address. The RARP protocol operates in reverse by enabling a host that knows its hardware address to request and discover its IP address by transmitting a specially formulated broadcast query to a RARP server on the same network. The RARP server upon receiving such a request, searches a database to find an IP address associated with the hardware address of the requesting host and replies directly to the requester, offering the IP address that host should use. This is the extent of the RARP protocol.

Unfortunately, in many situations hosts need to learn more than their IP address in order to boot and operate. RARP is not very commonly used any more, but is still sometimes useful -- especially if you are installing Linux on a Sun workstation. Linux implementations of both client and server exist. The man pages supplied with the software should be perfectly adequate to explain how to use it.

Bootstrap Protocol "BootP", (RFC-951)

The Bootstrap Protocol appeared shortly after RARP and addresses two important limitations. First, rather than being based on hardware-layer protocols, it is completely UDP/IP-based, making it somewhat easier to implement. A BootP transaction also supplies more than the IP address the client host should use, it additionally supplies the address of a boot file and the address of the server the boot file should be retrieved from.

BootP is quite simple. The cilent host builds a "bootrequest" message. In this message it places its hardware address. It transmits this message onto the network in a UDP/IP datagram with source port 68 and destination port 67. If the client knows the address of the BootP server, it places the server's address in the IP destination address field, if not it uses the broadcast address 255.255.255.255 (ref: RFC-919) instead.

The BootP server upon receiving a "bootrequest" message consults its local database, searching for an IP address mapped against the hardware address supplied. If a match is found, the BootP server formulates a "bootreply" message containing the IP address allocated and transmits the response to the IP broadcast address. BootP provides space in a "bootreply" message for vendor-specific information.

This mechanism allows a range of other configuration information and data to be provided to the requesting host. RFC-1497, "BOOTP Vendor Information Extensions" describes in detail how this works and defines the coding a wide range of possible configuration data. Suffice it to say, the BootP implementations available for Linux save you the pain of of having to deal at this level by providing direct keyword support for most of these.

Dynamic Host Configuration Protocol 'DHCP' (RFC-2131)

DHCP leverages off the success of BootP and extends it by defining mechanisms for IP address allocation with a wide range of configuration data. DHCP describes backward-compatability with BootP, ensuring that BootP clients can effectively make use of a DHCP server without reconfiguration. DHCP servers can make use of the BootP relay feature provided by many routers.

Dynamic Allocation

A host requests an address and is assigned any of the currently unallocated addresses. The host may be assigned a different address with each request.

Automatic Allocation

When a host requests an address for the first time, an unallocated address is found and assigned. That address is then reserved for use by that host and with every subsequent request from that host the same address is assigned.

Static Allocation

This is the same as "automatic allocation" except that the address that is assigned has been specifically reserved by the network administrator for that host. The host still requests and receives its address automatically using DHCP, but everyone knows in advance what address it will get.

An important concept that DHCP introduces is the idea of "lease" time for an address. A DHCP client may request an address for a period of time, and the DHCP server guarantees not to reallocate the address to another host within that time. The client may, of course, make another request for an address at the expiration of the lease, and the DHCP server will attempt to reallocate the same address when this occurs.

The DHCP implementation most commonly found on Linux systems is that produced by the Internet Software Consortium. It will be available pre-packaged in just about all Linux distributions.

DHCP is easily the most commonly used dynamic address assignment mechanism as just about every desktop machine supports it, and many ADSL and cable-modem providers also use it.

Configuring the DHCP daemon

Let's move on and start configuring. First, some assumptions:

• We have the ISC's DHCP daemon program installed on the host we wish to use as a DHCP server, and that host has a working network configuration.
• Our DHCP server host is directly attached to the same networks as the hosts we wish to manage addresses for. (A DHCP server can have multiple Ethernet cards and be attached to, and serve, multiple networks simultaneously.)
• In our network, we have two subnets with 24-bit prefixes: 192.168.1.0 and 192.168.2.0. In each, we will dynamically allocate addresses from the range .32-.254 to hosts. The remainder of the addresses are reserved for use by application servers, routers, and other shared infrastructure.
• Each network has a router port with address .1 on it.
• All hosts will be assigned names from the testnet.net domain and there is a shared name server with address 192.168.2.16.
• We will offer leases of 10 minutes by default, but hosts may request leases of up to 2 hours if they wish.

The configuration file for the ISC DHCP daemon is named /etc/dhcpd.conf and contains two types of statements, parameter statements and declaration statements. The parameter statements supply values for a number of DHCP variables such as lease times, and data to supply to client hosts such as gateway addresses. Declaration statements are used to describe collections of hosts to manage and collections of parameter statements to supply to hosts. Parameter statements can appear outside declaration statements and are then considered global parameters, or they may appear within declaration statements and then apply only to the hosts described by that declaration. Parameter statements are terminated with the ; character and declarations are enclosed within the curly brace {} characters.

You can build quite sophisticated configurations, but in most cases a simple one is all that is required. A configuration to meet the requirements specified for our network described above might look something like:

# dhcpd.conf - configuration for simple network
# Our global default configurations
option domain-name "testnet.net";
option domain-name-servers 192.168.2.16;
option subnet-mask 255.255.255.0
default-lease-time 600;
max-lease-time 7200;


# On our .1 subnet we will dynamically allocate 
# address to any host that requests one using 
# either DHCP or BootP.
subnet 192.168.1.0 netmask 255.255.255.0 {
 range dynamic-bootp 192.168.1.32 192.168.1.254;
 option broadcast-address 192.168.1.255;
 option routers 192.168.1.1;
 get-lease-hostnames true;
}


# On our .2 subnet we have a mixture of dynamically 
# assigned addresses and a collection of hosts that 
# should have fixed addresses.
subnet 192.168.2.0 netmask 255.255.255.0 {
 range dynamic-bootp 192.168.2.32 192.168.2.254;
 option broadcast-address 192.168.2.255;
 option routers 192.168.2.1;
}


# Our fixed address hosts belong to a different 
# name domain and should have names assigned to 
# them in addition to addresses.
group {
	option domain-name "apps.testnet.net";
	use-host-decl-names on;
	host guava {
		hardware ethernet 08:00:00:1a:2b:3c;
		fixed-address 192.168.2.16;
	}
	host nectarine {
		hardware ethernet 08:00:00:3b:4f:fa;
		fixed-address 192.168.2.17;
	}
	host banana {
		hardware ethernet 08:00:02:01:55:cb;
		fixed-address 192.168.2.18;
	}
}

More advanced dynamic configuration

In our example we used only a small number of configurable parameters. If you're in a complex environment of mixed computer and operating system types, you will likely need more sophisticated configurations.

If you have any or many diskless workstations, you may need to build a somewhat more complex configuration. The following sample is what you might use if you had a collection of diskless X11 workstations. You can cluster the information that is common to all workstations together inside the group statement and then pass host-specific information in a host statement for each workstation. You can see that this sample passes a wider range of configuration data to the workstations including the addresses of time, font, display manager, printer, and NIS+ servers. Additionally the mango workstation is configured for IP routing and has a static route configured.

group {
 # machine boot parameters
 filename "/tftp/fruit.boot';
 next-server guava.apps.testnet.net;


 # application server parameters
 option ntp-servers 192.168.1.32;
 option x-display-manager 192.168.1.32, 192.168.2.32;
 option font-servers 192.168.1.32, 192.168.2.32;
 option lpr-servers 192.168.1.32;
 option nisplus-domain testnet;
 option nisplus-servers 192.168.1.32, 192.168.2.32;


 # Workstation specific parameters
 host mango {
 hardware ethernet 08:00:02:30:02:ba;
 fixed-address 192.168.2.19;
 option ip-forwarding 1;
 option static-routes 10.1.0.1 192.168.2.1;
 }


 host passionfruit {
 hardware ethernet 08:00:a3:6c:0b:21;
 fixed-address 192.168.2.20;
 }
}

About the Author:
More detailed configuration information is available from the dhcpd.conf, dhcp.leases and dhcp-options man pages, and from the Internet Software Consortium web site.

Terry Dawson is the author of a number of network-related HOWTO documents for the Linux Documentation Project, a co-author of the 2nd edition of O'Reilly's Linux Network Administrators Guide, and is an active participant in a number of other Linux projects.

Linux Network Administrator's Guide (2nd... - The long-overdue second edition of O'Reilly's Linux Network Administrator's Guide, by Olaf Kirch and Terry Dawson, still sports the cowboy colophon, suggesting that netadmins have retained their Lone Ranger personas. While life for a sysadmin has improved over the years with the introduction of the ./Configure utility and build-less rpm distributions, network building and maintenance is still a vast prairie, in its complexity growing faster than the availability of tools and documentation to tame it. Linux document libraries are filled with disparate, obsolete, and/or redundant How-Tos for multiple Ethernet cards, bridging, cable modems, DHCP, Samba, ISDN, DSL, and laptop Ethernet card peculiarities.