Dynamic Address Assignment06/14/2001
In many networks, IP addresses are manually assigned to hosts. There are a number of reasons why for most hosts this is an unnecessary and even undesirable arrangement.
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.
Pages: 1, 2