Chapter 7: Automatic Assignment of IP Addresses with BOOTP and DHCP Objectives – IP Addressing and Subnetting INC IPV6

Chapter 7

Automatic Assignment of IP Addresses with BOOTP and DHCP Objectives

Solutions in this chapter:

 Introduction to Automatic Assignment of IP Addresses

 Address Management with These Tools

 Comparing BOOTP and DHCP

 BOOTP and DHCP and Routed Networks

 BOOTP Implementation Checklist

 DHCP Implementation Checklist

Introduction

This section starts with a general overview of dynamic addressing, along with a short history of the development of dynamic addressing protocols.

For IT Professionals

Understanding RFCs

To understand the history, evolution, and current status of networking standards, an IP professional should have an understanding of the Request for Comments (RFC) process, and the particular RFCs involved in defining a particular service or protocol. Copies of the RFCs are available on the Internet in a variety of locations, but one of the most accessible is www.rfc-editor.org/rfc.html. This site provides FTP downloads of individual RFCs, listed in numerical order, as well as the ability to download a compressed file containing all current RFCs.

The RFC process does not provide for revisions of a particular RFC, but rather they are revised by creating a new RFC with a new number. RFCs that are revisions of an earlier RFC will list the RFCs they are replacing. It can be interesting to follow the trail of RFCs back using this information, to see the evolution of the topic over time. For our purposes, the following RFCs provide a wealth of information about the process of dynamic address assignment, specifically BOOTP and DHCP protocols.

RFC951: Bootstrap Protocol (BOOTP)

This RFC was published in September 1985 and outlined the BOOTP protocol.

RFC1542: Clarifications and Extensions for the Bootstrap Protocol

This RFC, published in October 1993, was intended to clarify some issues relating to BOOTP, as well as deal with some new technology issues, such as Token Ring bit-ordering problems. This RFC also replaced an earlier RFC1532, which covered some of the same topics.

RFC2131: DHCP Protocol

This is a relatively recent RFC, published in March 1997. It supercedes an earlier RFC1541, which was published in 1993. It is a definitive reference for DHCP.

RFC2132: DHCP Options and BOOTP Vendor Extensions

This is also a recent RFC, published in March 1997. It is a compilation of all previous work done in the area of DHCP and BOOTP options. It also refers to several earlier RFCs on the same topic, including RFC1497 and RFC1533.

Most of the RFCs are not as complicated and technical as you might expect, and can make for interesting reading. They often reflect the current state of the technology at the time they were written, and don’t always accurately predict the future, looking at them in retrospect. One example is the use of broadcasts for returning a BOOTREPLY message. The RFC writers envisioned this as a stopgap measure, until the protocol stacks could be redesigned to respond to unicasts prior to receiving an IP address assignment. However, a look at modern DHCP servers, such as Windows NT, reveals that they may still rely on the broadcast process to return replies to a client.

So, the next time you hear an RFC number mentioned in connection with a protocol or service, don’t hesitate to dial up an FTP site and retrieve a copy of it. It will definitely be informative, may be interesting, and if nothing else, will cure occasional insomnia.

The Role of Dynamic Address Assignment

Over the last two decades we have witnessed a tremendous growth in the size of networks. This growth has occurred in the geographic spread of the network, as well as in the number of nodes per network. Just within the last two decades, the change from a host-based computing model using terminals, to a client/server model with user workstations, has caused an exponential growth in the average number of nodes per network.

These phenomena have driven the need for distributed management tools, where those charged with administering the network can remotely configure and manage network nodes from a central location.

One of these tools is dynamic address assignment, a process of 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.

Dynamic address assignment provides several benefits to the administrator. It greatly reduces the time spent in 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 who 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. 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 was defined in RFC951, 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, 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.

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.

Address Management with These Tools

The following section will explain in detail both the BOOTP and DHCP processes, and will offer some comparisons between BOOTP and DHCP.

For Managers

When NOT to Use BOOTP and DHCP?

Having heard about ail the wonderful things that BOOTP or DHCP can do, it can be tempting to think of this as an all-purpose solution to the task of IP addressing. However, it is important to remember that BOOTP or DHCP are not appropriate to all addressing situations. In fact, it is very important to know when NOT to use these dynamic addressing tools.

First, these protocols were not designed for configuring router interfaces. DHCP address assignments that use address pools may also be inappropriate for any network node that needs a consistent, predictable address. A particular problem in this area has to do with name-to-address resolution performed by DNS servers. Since most DNS servers do not have a dynamic update capability, allowing DHCP to give out a non-specific address to a node can result in a DNS record that does not match the assigned address. This means no one can reach that host by name until the DNS record is updated. There are tools by many vendors that can provide for dynamic updates between DHCP and DNS, thus alleviating this problem.

In a client/server environment, it is often a common practice to use DHCP to address the client workstations, while using manual addressing, or at least a specific address reservation, for the servers.

DHCP servers, in particular, must be statically configured, since they can’t issue their own address. Static address assignments must be considered when designing address pools for DHCP, since it is necessary to avoid duplicate address assignments. It frequently makes sense to set aside a contiguous range of addresses for static assignments that can be expressed easily as exclusions within an address pool range. It may also make sense simply to choose a range of the lowest or highest node numbers in a subnet range for static assignments and to define a dynamic address pool range that starts before or after these addresses, as appropriate.

This problem of duplicate IP addresses raises another issue. Because IP addresses have to be unique on the network, it is not possible to have two servers giving out the same range of IP addresses at the same time, unless the servers use some kind of synchronization mechanism. This makes it difficult to provide redundancy for your DHCP server. BOOTP servers are not subject to this issue, since they use a static database that explicitly matches each client with their assigned address.

The problem of redundant DHCP servers can be solved in the following way: Since a DHCP server can handle multiple address pools or scopes, two DHCP servers can be configured so that each has a primary scope that includes 75–80 percent of the addresses in their total address range. In addition, each server has a second scope that includes the 20-25 percent of the address range not handled by the primary server. Should one server fail, the other server has an emergency pool of addresses for the other server’s address range that it can issue until the primary server comes back on line.

The BOOTP Packet

The BOOTP packet (see Figure 7.1) is a special-purpose UDP datagram, which is carried inside a standard IP datagram, on a variety of data-link frames. The source IP address for this packet will be the client’s IP address if the client knows it, or 0.0.0.0 if it doesn’t. The destination IP address will be set to the server address if known, or will be the local broadcast address, 255.255.255.255, if the server address is unknown.

Figure 7.1 BOOTP packet structure.

The UDP header will contain BOOTP-specific source and destination port numbers. These numbers are 68 for the client, and 67 for the BOOTP server. The client sends requests using 67 (BOOTP server) as the destination port and the server replies using 68 (BOOTP client) as destination port.

Table 7.1 represents the field definitions within the data field of the UDP datagram that make up the BOOTP packet structure. The fields are ordered according to their position in the table, reading from left to right, one row at a time.

Table 7.1

Fields and Field Lengths for the BOOTP Packet

Field Descriptions and Comments

This section explains each one of the field names listed in Table 7.1. It will explain the purpose of the field, as well as the possible values that the field can contain.

OP

This field is set to one of two values as follows:

The BOOTREQUEST op code is set by the client when they wish to request services from the BOOTP Server. The BOOTREPLY op code is set by the server when it replies to a client request. These codes are also used the same way with DHCP.

HTYPE

This is the hardware address type. This field will contain one of the values listed in Table 7.2. The most common values today would be 1 for 10MB Ethernet and 6 for Token Ring.

Table 7.2

Hardware Address Type Codes

Name Number
Ethernet 1
Ethernet3 2
Ether 1
Ether3 2
Ieee803 6
Tr 6
Token Ring 6
Pronet 4
Chaos 5
Arcnet 7
Ax.25 3

HLEN

This is the length of the hardware address, expressed in bytes. For an Ethernet interface with the standard MAC address of 48 bytes, this field would contain 6.

HOPS

This field is used to indicate the number of routers or gateways through which the BOOTP packet has passed. It is set to zero by the client and then incremented as it passes through a router.

XID

This field is a transaction identifier. It is a random number generated by the client when it sends a BOOTREQUEST message. It will be returned in the server’s BOOTREPLY message, so that the client can match its request with the appropriate reply.

SECS

This field is filled in by the client to indicate the elapsed time since it first sent a BOOTREQUEST message. Thus, the first message will have a value of zero in this field, and it will be incremented if the client has to send several requests before it gets a reply. Historically, there has been some inconsistency in the use of this field by different implementations, but it was intended to be used as a means of identifying packets that should be handled on a priority basis by a forwarding agent.

FLAG

In the original definition of the packet structure in RFC951 (September 1985), this field was labeled as unused, and was reserved for future enhancements. By the time that RFC 1542 (October 1993) was written, the working group was struggling with the problem of returning boot replies to a requesting client. Since the client would not know his IP address until AFTER receiving the packet, it was often necessary to broadcast the reply back to the client. With this in mind, RFC 1542 renamed this field and specified that the highest-order bit would be set by the client to indicate that a BROADCAST reply was required. The rest of the bits were reserved for future use, with a default setting of zero if unused.

CIADDR

This client uses this field to indicate its currently assigned IP address, if the client knows it. If not, it sets this field to 0.0.0.0. Since this protocol was designed for remote booting, BOOTP can be used for bootfile retrieval by a client that already knows its address.

YIADDR

The BOOTP server uses this field to indicate to the client the IP address it is being assigned. In those cases where the server unicasts a reply to the client, this address will be used as the destination.

SIADDR

This IP address is returned by the BOOTP server, which indicates the server that will be accessed to load the boot file used in the second step of the boot process.

GIADDR

Though this field is called the gateway IP address, this is a little misleading, in that it really refers to the address of a BOOTP relay agent. It is used to facilitate the transfer of BOOTP messages between a client and server located on different IP subnets. This agent will be a node on the client’s network, and when the agent forwards a BOOTREQUEST, it changes this field from 0.0.0.0 to its own address. Then the BOOTP server can unicast its reply to this address on the client’s subnet.

This field has been subject to some misinterpretation, in that it is sometimes confused with a router gateway address for the client. This interpretation has been fueled by the fact that a router can act as a relay agent, in which case the GIADDR may be a router interface. To alleviate this confusion, an option was defined in the VEND (options) field that explicitly defines a router (gateway) address. The client can use this when requesting its boot file, in the second stage of the BOOTP process.

CHADDR

This is the client’s hardware address. It is interpreted in conjunction with the HTYPE (hardware address type) field and the HLEN (hardware address length). It is provided by the client in a BOOTREQUEST message, and is used by the server to identify the entries in the BOOTP database associated with this client. It was also designed to provide a server with a MAC address for the client, which it could store in its ARP cache to avoid having to use an all-ones broadcast in a BOOTREPLY.

SNAME

The client can use this field to specify a particular server from which it wishes to obtain a boot file. In this case the name would be a domain name that could be resolved using a DNS server or a HOSTS file. If this is left blank, the server will return an address in the SIADDR field that specifies the boot file server address for the client.

FILE

This field is used to indicate the name of the boot file to be downloaded by the client in the second phase of the BOOTP process. The client can use this field to request a particular boot filename, or the server can use this field to identify the boot filename in a BOOTREPLY message, based on a client’s entry in the BOOTP database.

VEND/OPTION

This field originally was defined as a vendor-extensions field, with a fixed length of 64 bytes. Later, it was defined more generically as an OPTION field, with a variable length. It was intended to convey additional information to the client. Using this field, the client could specify its interest in additional parameters, and the server could supply parameters matching this request, provided that the requested information existed in the BOOTP database. To facilitate the interpretation of this field, the first four octets of the field describe a magic cookie, which is a value that identifies the format for the rest of the field. A vendor could use a specific set of octet values to define the field format, or a generic cookie could be used to indicate the standard option format, which will be described later in this chapter. The values used for a standard format are 99.130.83.99 in the first four octets.

BOOTP Process Details

The following section will outline in detail the process between the client and server. It includes a description of the packet contents in each direction.

Client BOOTREQUEST

The client will create a packet with the following settings:

 The IP destination address = 255.255.255.255.

 The IP source address and CIADDR = 0.0.0.0, if unknown, or client’s address, if known.

 The UDP header length field is set to the length of the packet in bytes.

 The UDP source port = 68 (BOOTP Client).

 The UDP destination port = 67 (BOOTP Server).

 The OP field is set to 1 (BOOTREQUEST).

 The HTYPE field is set to the hardware address type.

 The HLEN field is set to the length of the hardware address.

 The XID field is set to a random value representing the transaction identifier.

 The SECS field is set to zero if this is the first boot request, otherwise it is set to the time since the first boot request.

 The FLAGS field has the high-order bit set to one if the client can only receive a broadcast BOOTREPLY; all other bits are set to zero.

 The GIADDR will be set to 0.0.0.0.

 The CHADDR is set to the MAC address of the client.

 The SNAME field may be filled in with the name of a server from which the client wishes to boot.

 The FILE field may be filled with the name of the boot file from which the client wishes to boot.

 The VEND field may be filled with a list of optional parameters the client is requesting.

If the client does not receive a reply to a BOOTREQUEST after a certain time period, the client will retransmit the packet with an updated SECS field, showing the elapsed time since the first BOOTP request.

Server BOOTREPLY

When a server receives a BOOTREQUEST message, it will perform the following checks:

 The SNAME field is checked, to see if the client requested a specific server. If it did, and the server does not match the current server, the packet may be forwarded using a BOOTP Relay agent function, and the GIADDR will be updated with the server’s address, if it is not already filled in. Alternatively, it may be just discarded, depending on the server.

 The CIADDR field will be checked. If it is zero, the server will check the HTYPE, HLEN, and CHADDR fields and will use them to identify a record for this client in the database. If it finds a record, it puts the client’s assigned address in the YIADDR field. If no record is found in the BOOTP server’s database, the packet is discarded.

 The server will now check the FILE field. If a filename is specified, the server will check it against its database. If a match is found, the server will put the complete path to the filename in this field. If the filename doesn’t match the database, the serve assumes the client is asking for a file this server does not know about, and it drops the packet.

 The VEND field is now checked for any special information or instructions that the client wishes to convey to the server. The list of vendor options will be covered later in this chapter.

The server then creates its reply packet with the following settings:

 The IP destination address = See Table 7.3 to determine the IP destination address.

Table 7.3

Values in Client Fields and Corresponding Addressing Strategy for Server

Table 7.3 outlines the behavior of the server in passing back the BOOTREPLY packet, based on the field contents of the BOOTREQUEST packet from the client.

Field Values in the BOOTREPLY packet

The server will create the BOOTREPLY packet with the following field values:

 The IP source address = the address of the server.

 The UDP header length field is set to the length of the packet in bytes.

 The UDP destination port = 68 (BOOTP Client) normally, unless returning to a BOOTP Relay Agent (see Table 7.3).

 The UDP source port = 67 (BOOTP Server).

 The OP field is set to 2 (BOOTREPLY).

 The HTYPE field is unchanged.

 The HLEN field is unchanged.

 The XID field is left unchanged, to match this reply with the client’s original request.

 The SECS field is left unchanged.

 The FLAGS field is left unchanged if the broadcast bit is set. If zero, the server may set the BROADCAST flag if it knows the client can only receive broadcasted replies.

 The CIADDR is left unchanged.

 The YIADDR is set to the client’s assigned IP address from the server’s database.

 THE SIADDR is filled in with the server’s own IP address, providing it will handle the next phase of the boot process, which involves serving the boot file.

 The GIADDR is left unchanged.

 The CHADDR is left unchanged.

 The SNAME field is left unchanged.

 The FILE field may be filled with the full path and filename of the boot file for this client, based on the database record.

 The VEND field may be filled with the list of optional parameters from the database record.

When the client receives the BOOTREPLY record from the server, it checks the fields in the packet to ensure that the reply is for it and not some other client. It looks for a match in the CIADDR, CHADDR, and XID fields.

The BOOTP Server Database

RFC 951 includes a section that outlines a suggested format for the BOOTP database. This database was envisioned as a flat text file database composed of two sections, separated by a line beginning with a percent (%) sign.

The first section contains a series of mappings from a generic (short alias) name to a complete path name for a boot file. If the client does not specify a filename, and the database does not contain a different filename for this client, the server will use the first name listed in this section as the boot filename returned.

The second section contains listings for each client, along with their assigned parameters. The client’s hardware address type (HTYPE) and hardware address (CHADDR) fields are used as the index to match a record with the requesting client. Besides the hardware address type and the actual hardware address, each record contains the host name, the assigned IP address, and a reference to the generic filename from section one, which maps to a full path to the boot file. It may also include an optional suffix, which will be appended to the bootfile path to indicate a unique file, as in “filename.client1, filename.client2”, etc. Comment lines can be indicated by beginning the line with a # symbol.

Following is a generic example of a BOOTP database file, as described in the RFC. There are variations to this file format between different BOOTP servers, but this offers a general idea.

# Sample Database Format

# Section one: generic name to path mappings

bootfile1 usr\bootfiles\boot bootfile2 alt\bin\startup

% Section one ends, Section two begins

host-one HTYPE1 CHADDR1 IPaddress1 bootfile1 suffix1
host-two HTYPE2 CHADDR2 IPaddress2 bootfile2 suffix2

This server will match the HTYPE and CHADDR of a BOOTP request to a record in the database. For example, if these match the record for host-one, the server will return IPaddress1 to the client. It will also look at the generic name bootfile1 and translate it to the full path name using section one of the database file. It will then append the suffix1 to the filename and return it as the full path name in the FILE field of the BOOTREPLY packet. This full path would be usr\bootfiles\boot.suffix1.

How Does DHCP Work?

This section begins with an overview of the DHCP process. It is followed by a detailed description of the process, which includes explanations of the DHCP message types, as well as DHCP-specific option codes. It will also address the issue of BOOTP and DHCP interoperability, and will conclude with a discussion of DHCP address pools.

DHCP Process Overview

DHCP was designed to be an extension of, and replacement for, the BOOTP protocol. It uses the same packet structure, many of the same processes, and was designed for backward compatibility with BOOTP. It also has the ability to use BOOTP Relay Agents to enable client/server communication across subnet boundaries. It differs from BOOTP in that it provides a number of dynamic addressing methods not supported by the earlier protocol.

DHCP supports three address assignment methods. The first of these is called manual address assignment. This is roughly equivalent to the BOOTP process, where an administrator must manually configure entries in a database for each client, and the client then gets these parameters assigned through the BOOTP/DHCP process.

The second and third assignment methods involve the use of a DHCP-specific feature called an address pool or scope. In these cases, the administrator doesn’t build a table correlating each client with a database record. Instead, a pool of addresses is defined. The addresses are handed out on an as-requested basis. There may also be a set of optional parameters defined for this address pool that are returned to each client along with an address. This alleviates the need to configure each client individually, but also makes it somewhat unpredictable which address a given client will receive.

One way addresses can be assigned from the address pool is to provide them to the client for a finite period of time, called a lease. This is referred to as dynamic address assignment. With a lease, a client is passed a parameter with the address that indicates the maximum time it can hold the address without renewing the lease. Each time the client reboots, it will renew the lease. If it stays booted for a long period of time, it will reach a point called the T1 time, when it will attempt to renew its address from the server it was originally acquired from. If it fails in this attempt, it will reach a second threshold called the T2 time, when it will attempt to renew its address by broadcasting to any available server, just as it did the first time it was assigned an address. The DHCP server keeps track of the addresses it hands out and the lease periods associated with them. If a client fails to renew its lease, the DHCP server will reclaim the address and reuse it with a different client. This feature is particularly useful for environments where addresses are scarce, or where the clients connect to the network on a temporary basis. It may be possible to use a lease reservation to reserve a specific address from the pool for a particular client.

The third assignment method, called automatic address assignment, uses the address pool, but instead of using a finite lease period, the addresses are simply handed out to the client indefinitely. Since BOOTP clients have no concept of a lease, and no lease renewal capability, this method would allow them to use the address pool feature of DHCP, but not the leasing feature.

One of the challenges for the DHCP server is to ensure that it does not hand out addresses that are already in use. There are a number of mechanisms that help achieve this. First, the server and/or client may perform a check by pinging the network for the address before it hands it out. If it gets a response, it knows the address is in use. For addresses that the DHCP server provides, it keeps a database of what addresses have been assigned to which clients, and their lease periods. Lastly, a DHCP server can specifically exclude from its address pool those addresses, or address ranges, that have been previously assigned to hosts through other means.

Both the DHCP server and the client maintain a persistent record of their address assignments. This means that if the server goes down, it will still remember all of its address assignments when it reboots. The client also maintains a record of its assigned address and other parameters, so that if it restarts it will be able to renew its existing assignments with the DHCP server, rather than looking like a new client. The process of assigning a set of parameters to a client is referred to as binding. A client remains bound to its parameters until either its lease period expires, or it relinquishes its assignments with a DHCPRELEASE message.

DHCP Process Details

DHCP uses the BOOTP packet format, with a few modifications, and also makes use of the packet exchange process between client and server. For example, the UDP ports for DHCP and BOOTP are the same. The OP codes used by BOOTP to indicate a client BOOTREQUEST and a server BOOTREPLY are also used by DHCP. DHCP differs in the extensive use of the VEND field.

In DHCP, the VEND (vendor extensions) field is renamed the OPTIONS field, and changed from a fixed length of 64 bytes to a variable length field. Each DHCP message will contain a DHCP Message Type option in this field, which identifies the packet’s role in the DHCP process. In addition to the message types, DHCP also uses options to pass DHCP-specific parameters such as the lease period, as well as parameters common to DHCP and BOOTP, such as the subnet mask.

Each message sent from a DHCP client will have an OP code of 1 (BOOTREQUEST) and a destination UDP port of 67 (BOOTP Server). It may have different DHCP message types however, depending on whether it is requesting a new address, renewing a lease, or releasing an assignment. Similarly, each server message will have an OP code of 2 (BOOTREPLY) and a UDP port destination of 68 (BOOTP client) unless going through a BOOTP Relay agent.

Each DHCP packet, whether from server or client, will contain information in the OPTIONS field. The first four octets will contain the generic magic cookie, 99.130.83.99, discussed earlier. It will then contain a series of option parameters, of the following form:

TAG (option code) SIZE PARAMETER VALUE

Each option takes up one byte for the TAG code, one byte for the size, and then some number of bytes, as stated in the SIZE byte, for PARAMETER VALUE. Each DHCP packet must contain one of the DHCP Message type options, in addition to any other options defined.

Unlike the two-step process used by BOOTP, in which a client makes a BOOTREQUEST and the server responds with a BOOTREPLY, the DHCP process normally requires four steps for a new client. In this process, the client broadcasts a BOOTREQUEST packet with a DHCP message type, DHCPDISCOVER. This means it is looking for a DHCP server. The server responds with a BOOTREPLY message using the DHCP message type, DHCPOFFER. This means the server is offering a set of parameters to the client. The client will then issue another BOOTREQUEST packet with the DHCP message type, DCHPREQUEST. This informs the server that the client accepts the offered parameters. The server then issues a final BOOTREPLY packet containing the DHCPACK message type, indicating an acknowledgement of the client’s acceptance. This process is outlined in Figure 7.2.

Figure 7.2 Normal DHCP transaction.

There is a great deal of flexibility, and therefore a great deal of variation, in the DHCP process. For example, a client may request certain parameters in its DHCPDISCOVER or DHCPREQUEST packets. The client may also be doing a lease renewal, rather than an initial discovery, in which case the process will only include a DHCPREQUEST from the client, followed by a DHCPACK from the server.

To preserve backwards compatibility with BOOTP, the server will return the assigned IP address in the YIADDR field of the BOOTP packet. It may also include various configured options in its reply, conveyed within the OPTION (VEND) field of the packet.

One way of discovering the flexibility of the DHCP process is to look at the various DHCP Message Types and their purpose, outlined in Table 7.4.

Table 7.4

DHCP Message Type

DHCP Message Types Message Name Explanation
1 DHCPDISCOVER Client broadcast to locate available servers
2 DHCPOFFER Server to client in response to DHCPDISCOVER with offer of configuration parameters.
3 DHCPREQUEST Client message to servers either (a) requesting offered parameters from one server and implicitly declining offers from all others (b) confirming correctness of previously allocated address after system reboot or (c) extending lease.
4 DHCPDECLINE Client to server indicating network address is already in use; implies that the client is checking for duplicates.
5 DHCPACK Server to client with configuration parameters, including committed network address.
6 DHCPNAK Server-to-client network address is incorrect or client’s lease has expired.
7 DHCPRELEASE Client to server relinquishing network address and canceling remaining lease.
8 DHCPINFORM Client to server asking only for local configuration parameters. Client already has externally configured network address.

DHCP-Specific Options

In addition to the DHCP Message Type options, there are a number of other DHCP-specific options that convey information useful to the DHCP process. This section lists the option types that can be listed in the VEND/OPTIONS field. In some cases, the option codes are used primarily by the server; in others, they can be used by either the client or the server. The remainder of the options, which are common to both DHCP and BOOTP, will be listed later in this chapter.

Requested Address

Option Code Length (Bytes) Parameter Value
50 4 Requested IP address

The client can use this option during a DHCPDISCOVER to request a particular IP address.

Lease Time

Option Code Length (Bytes) Parameter Value
51 4 Lease time (secs)

This option is used in a client’s DHCPDISCOVER or DHCPREQUEST packet to request a specific lease time for an address. It is also used by the server in its DHCPOFFER packet to specify the lease time to the client.

Field Overload

Option Code Length (Bytes) Parameter Value
52 1 Field overload (1-3)

This is an interesting field. It is used in those situations where the client and server have defined a maximum packet size, and then have run out of room for options in the OPTIONS field. In this case, it is possible to use the FILE field and/or the SNAME field to hold additional options. This field indicates the intention to use those fields according to Table 7.5.

Table 7.5

Field Overload Codes

Parameter Value Fields Being Used
1 FILE field
2 SNAME field
3 Both Fields

TFTP Server Name

Option Code Length (Bytes) Parameter Value
66 Variable Alternative TFTP server field

If we have chosen to use the SNAME field to hold additional options, this option can be specified as an alternative way to indicate the server holding the desired boot file for a remote boot.

Bootfile Name

Option Code Length (Bytes) Parameter Value
67 Variable Alternative file field

If we have chosen to use the FILE field to hold options, this option provides an alternative way of conveying the name of the desired boot file.

DHCP Message Type

Option Code Length (Bytes) Parameter Value
53 1 DHCP message number (1-8)

This option is used to convey the type of the DHCP message, as described in the preceding section. Table 7.6 outlines the message numbers and associated definitions.

Table 7.6

DHCP Message Option Codes

DHCP Message Number Message Type
1 DHCPDISCOVER
2 DHCPOFFER
3 DHCPREQUEST
4 DHCPDECLINE
5 DHCPACK
6 DHCPNAK
7 DHCPRELEASE
8 DHCPINFORM

Server Identifier

Option Code Length (Bytes) Parameter Value
54 4 DHCP server address

Servers may include this in DHCPOFFER messages and may also include it in DHCPACK and DHCPNAK messages. This allows the client to know what DHCP server provided the offer, and the client will store this information for use when it renews its address with a DHCPREQUEST packet. DHCP clients can also include this in a DHCPREQUEST packet to indicate which offer it is accepting, when it has received offers from more than one DHCP server. This option was designed to allow the DHCP server to identify itself in a reply, while reserving the SIADDR field in the BOOTP packet for the address of the TFTP server serving the boot files for the remote boot process.

Parameter Request List

Option Code Length (Bytes) Parameter Value
55 Variable List of parameters (options codes)

The client can use this option to specify a list of parameters it wishes to obtain from the DHCP server. This list consists of a series of valid option codes, each taking up one byte.

Error Message

Option Code Length (Bytes) Parameter Value
56 Variable Error Message–Used with DHCPNACK or by a client in a DHCPDECLINE

If a server returns a DHCPNACK to a client, indicating that it cannot fulfill the client’s request, or the client issues a DHCPDECLINE, refusing the offer from a server, this field can be used to convey additional information.

Maximum DHCP Message Size

Option Code Length (Bytes) Parameter Value
57 2 Max. DHCP message size

The client used this option, in a DHCPDISCOVERY or DHCPREQUEST message, to indicate the maximum message size it is willing to accept.

T1 Renewal Time

Option Code Length (Bytes) Parameter Value
58 4 T1 renewal time value (secs)

The server uses this option to define the time at which the client should begin to attempt renewal of its lease. A typical value for this parameter is 50 percent of the lease time.

T2 Rebinding Time

Option Code Length (Bytes) Parameter Value
59 4 T2 rebinding time value (secs)

The server uses this option to define the time at which the client should give up trying to renew a lease with the original server and instead, start trying to rebind to a new DHCP server. The default time is 87.5 percent of the lease time.

Vendor Class ID

Option Code Length (Bytes) Parameter Value
60 Variable Vendor class ID

The original BOOTP packet definition provided the VEND field, now called the OPTION field, to convey vendor-specific information. The mechanism for doing this included using the first four octets of the VEND field to denote a vendor-specific magic cookie. If the field was being used generically, it would have the values 99.130.83.99 in these four octets. With the DHCP extension to BOOTP, every packet now uses this generic cookie value. Therefore, another method had to be provided with DHCP, to denote vendor-specific information. This option was designed to fulfill that purpose. A client will include this option in a DHCPDISCOVER message when it wishes to receive vendor-specific parameters. If the DHCP server can’t respond to these vendor-specific requests, it ignores them. If it can respond, it returns the vendor-specific parameters in the OPTION field using an option code of 43 along with the requested parameters.

Client Identifier

Option Code Length (Bytes) Parameter Value
61 Variable Client identifier

This option is used by DHCP clients to specify a unique identifier. This identifier will be used by the DHCP server to match a specific database record to a client, in the same fashion as a BOOTP server. This field can use the HTYPE and CHADDR values (hardware address type and the hardware address itself) just like a BOOTP server, or it can use an alternative identifier, such as a system’s domain name. The identifier is required to be unique, in order to match the database record and the client properly.

Interoperation between DHCP and BOOTP

Because DHCP was designed to be a replacement for BOOTP, there are often mechanisms built into a DHCP server that preserve the backward compatibility between a BOOTP client and a DHCP server.

A DHCP server provides this compatibility by accommodating both DHCPDISCOVER requests, as well as a BOOTREQUEST from a BOOTP client. The server can distinguish between the two because a DHCP client is required to include a DHCP Message Type option, but a BOOTP client is not.

A DHCP server may maintain both a BOOTP-type database mapping individual clients to a set of specific parameters, and an address pool, with a common set of parameters that are routinely handed out with the addresses. The server may also reserve portions of its address pool for specific clients, and exclude ranges of addresses within the pool that are known to be preassigned. When receiving a client request, the server may check its database to see if a specific record for that client exists. If so, it returns the parameters in the database record. If not, it can assign parameters based on the configuration of its address pool. In this way, a BOOTP client can be assigned an address from a DHCP address pool.

There are some considerations to bear in mind when a BOOTP client gets an address from a DHCP server address pool. First, the client has no concept of leases, so the address must be given out with an infinite lease period. Also, there is no ability for the client to renew an existing lease, so if the client reboots, it will make a new BOOTREQUEST, which will result in it being assigned a new address from the pool. Meanwhile, the DHCP server has stored the client’s original address as an infinite lease, and cannot recover it for reuse. The client will also not engage in the DISCOVER-OFFER-REQUEST-ACKNOWEDGEMENT process, so the server must store the address assignment as soon as it sends the BOOTREPLY, rather than waiting for a client request, in response to its offer.

It is also possible that a DHCP client may be able to obtain address information from a BOOTP server. Since the address information in each case is returned in the YIADDR field of the packet, and any options are returned in the OPTIONS/VEND field, there is a high degree of cross-compatibility. A DHCP client in this case would check the OPTIONS field to determine if the BOOTREPLY from the server included a DHCP message type, and if not, it would assume it was talking to a BOOTP server. In cases where both a DHCP and BOOTP server respond, the DHCP client should always choose the DHCP server.

DHCP Address Scopes

In the previous section on BOOTP, we discussed the format of the BOOTP database file. DHCP servers can also provide this functionality, which maps a specific client identifier to a set of parameters recorded in the database for that particular client. In addition, DHCP provides the ability to define a range of addresses, called an address pool or scope.

An address scope is simply a range of addresses that can be used in response to client requests. There is no one-to-one mapping of clients to parameters, but rather it is a first-come-first-served approach to address assignments. As the server gives out the addresses, it records the client who received the address, and flags the address as having been assigned, so it doesn’t use the address again.

In addition to addresses, an address scope may be configured with a set of options that will be returned to each client with their address assignments. These can be defined at a scope level, so that rather than configuring each client record in a database, these parameters are shared with all clients. Typical parameters might be the subnet mask, default gateway, DNS servers, etc.

A DHCP scope has the ability to exclude some addresses within its range, to avoid duplicate assignment of addresses already in use by statically configured hosts, or those getting addresses via some other means.

A DHCP server can also maintain multiple scopes, with each scope and its associated options being defined for a given subnet. Through the use of BOOTP Relay agents, a DHCP server may service clients on multiple subnets. It can use the GIADDR field in the BOOTREQUEST packet to determine which subnet the request is coming from, and will respond with information from the appropriate scope for that subnet.

To reduce the randomness of the address assignments from the address pool, an address within the pool may be set aside for a specific host through a reservation process. This allows us to predict which address will be assigned to that client, while preserving its ability to obtain common parameters from the scope-defined options.

Comparing BOOTP and DHCP

Both BOOTP and DHCP use a server to provide automatic IP address configuration to clients. They also use the same packet format, which was designed originally for BOOTP and adopted later, with modifications, for DHCP. Both protocols provide the means to issue an IP address to a client. They also provide a way to indicate a server and filename on that server, which can be downloaded and used to boot the client. They both also include the ability to convey other configuration parameters as well, such as the gateway address, or the address of DNS servers.

DHCP and BOOTP can both use databases that are indexed using a client identifier such as the hardware address. By matching this client identifier to a record in the database, the server can locate the information requested by the client, and transmit it back in a reply message. Both DHCP and BOOTP can make use of BOOTP Relay Agents, which allow a client and server on different subnets to exchange BOOTREQUEST and BOOTREPLY messages.

DHCP protocol is an extension of the BOOTP protocol and is intended to be a replacement for that earlier protocol. DHCP makes extensive use of the VEND field (later called the OPTIONS field) in the original BOOTP packet to convey additional information between the client and server. In addition to BOOTP’s ability to transmit addresses and information based on one-to-one entries in a database, DHCP can also assign addresses based on a stated range of addresses, sometimes called the address pool or scope. It also differs from BOOTP in that BOOTP assigns addresses permanently, whereas DHCP can be configured to lease addresses for a finite period of time. It will recover these addresses and reuse them if the client does not renew its lease on the address.

How BOOTP Works

The following section will provide an overview of the BOOTP process. This will be followed by a detailed description of the BOOTP packet structure. We will then take a more detailed look at the client and server processes that occur during a BOOTP exchange. Lastly, we will look at an example of a BOOTP database file.

BOOTP Process Overview

The BOOTP process consists of two phases. The first phase is the address and parameter acquisition phase, which is the focus of our interest. The second phase involves accessing a file server, typically a TFTP server, and downloading a file that can be used to boot the client. The BOOTP client functionality was designed to reside on a PROM that is generally located on the client’s network interface card.

Both the client and the server communicate using a standard packet format, which is referred to as a BOOTP packet. A client makes a BOOTREQUEST and the server responds with a BOOTREPLY.

A client may use packet fields to indicate pieces of information it already knows, such as its IP address, or the boot filename it wishes to retrieve, or it may leave those fields blank when it wants to learn the values from the server.

The BOOTP process also provides for a forwarding function, to be performed by a BOOTP Relay Agent. This agent is a node on the same subnet as a client, which is configured to pass request and reply messages between clients and servers when they reside on different subnets.

DHCP/BOOTP Options

The last field in the original BOOTP packet specification was a field called the VEND field, used to convey information called vendor extensions. Later RFCs modified not only the name of this field, changing it to OPTIONS, but also changed it from a 64-byte fixed length to a variable length. Similarly, the information conveyed in these fields were renamed simply, options.

Each option has been through a review process by the IANA (Internet Assigned Number Authority) and has a code, sometimes called a tag, assigned by them. New options can be proposed by requesting a new tag code and then submitting a description of the option for approval.

Each option is expressed as a series of bytes that use up space in the BOOTP packet’s VEND/OPTION field. The format of each option is as follows:

First Byte Second Byte Succeeding Bytes
Tag or Option Code Length of data portion Data portion

All the options originally defined as BOOTP vendor-extensions have been incorporated as options by DHCP. In addition, there are a series of DHCP-specific options that are not recognized by BOOTP. These options were discussed in the previous section dealing with the DHCP process, and will not be repeated here. For the sake of organization, these will be grouped into sections that share a similar function.

Due to the number of options available, it is not possible to explain the function of each one. Some will be familiar, whereas some others may be extremely obscure, having become obsolete, or else intended for specific environments that existed at the time the option was formulated. They are listed here for the sake of completeness.

BOOTP Options from RFC 1497

The source used for the following options list is RFC2132, published in March of 1997, which incorporated option information from a number of earlier RFCs, including RFCs 1497 and 1533. This first section includes those options defined in RFC 1497. The organization of the rest of this section will also follow the format of RFC2132, since it presents the option codes roughly in ascending numerical order.

Pad

Option Code Length (Bytes) Parameter Value
0 1 Align on word boundaries (no data)

This option is used as a filler to extend the option fields to 32-bit word boundaries or to pad out the VEND field after an END option.

End

Option Code Length (Bytes) Parameter Value
255 1 End of data in field (no data)

This code indicates the end of information in the vendor/option field.

Subnet Mask

Option Code Length (Bytes) Parameter Value
1 4 Client subnet mask

This code specifies the client’s subnet mask.

Time Offset

Option Code Length (Bytes) Parameter Value
2 4 Time offset from GMT

This code can be used to define the client’s time zone relative to Greenwich Mean Time.

Router List

Option Code Length (Bytes) Parameter Value
3 Multiples of 4 List of router addresses

This specifies a list of routers available to the client, listed in order of preference.

Time Server List

Option Code Length (Bytes) Parameter Value
4 Multiples of 4 List of time server addresses

This specifies a list of time servers available to the client, in order of preference.

Name Server List

Option Code Length (Bytes) Parameter Value
5 Multiples of 4 List of name server addresses

This specifies a list of IEN 116 Name Servers available to the client, in order of preference.

DNS Server List

Option Code Length (Bytes) Parameter Value
6 Multiples of 4 List of DNS server addresses

This specifies a list of DNS Servers available to the client, in order of preference.

Log Server List

Option Code Length (Bytes) Parameter Value
7 Multiples of 4 List of log server addresses

This specifies a list of MIT-LCS UDP log servers available to the client, in order of preference.

Cookie Server List

Option Code Length (Bytes) Parameter Value
8 Multiples of 4 List of cookie server addresses

This specifies a list of RFC865-compliant cookie servers available to the client, in order of preference.

LPR Server List

Option Code Length (Bytes) Parameter Value
9 Multiples of 4 List of LPR server addresses

This specifies a list of Line Printer Remote (LPR) Servers available to the client, in order of preference.

Impress Server List

Option Code Length (Bytes) Parameter Value
10 Multiples of 4 List of impress server addresses

This specifies a list of Imagen Impress servers available to the client, in order of preference.

Resource Location Server List

Option Code Length (Bytes) Parameter Value
11 Multiples of 4 List of resource location servers

This specifies a list of RFC887 Resource Location servers available to the client, in order of preference.

Host Name

Option Code Length (Bytes) Parameter Value
12 Variable Host name of client

This option specifies client’s name, which may or may not include the domain name.

Boot File Size

Option Code Length (Bytes) Parameter Value
13 2 Boot file length (512KB blocks)

This option specifies the size of the client’s default boot file.

Merit Dump File

Option Code Length (Bytes) Parameter Value
14 Variable Merit dump file name

This option is used to define the path and filename for the file to be used as a core dump repository, if the client should crash.

Domain Name

Option Code Length (Bytes) Parameter Value
15 Variable Client’s Internet domain name

This option lists the DNS domain name that the client should use.

Swap Server

Option Code Length (Bytes) Parameter Value
16 4 Swap server’s IP address

This option lists the address of the client’s swap server.

Root Path

Option Code Length (Bytes) Parameter Value
17 Variable Pathname to client’s root disk

This option is used to define a path designated as the root drive for this client.

Extensions Path

Option Code Length (Bytes) Parameter Value
18 Variable File name of extensions file

This option can be used to define the filename of a file that can be used as an extension to the VEND/OPTIONS field. It uses exactly the same format for listing options, and is designed to be retrieved using TFTP.

IP Layer Parameters per Host

Options in the following section are concerned with IP network-layer parameters, as they relate to the host globally, rather than to a particular interface configuration.

IP Forwarding Enable/Disable

Option Code Length (Bytes) Parameter Value
19 1 IP forwarding (enable=1)

This option specifies whether the client should configure its IP layer for packet forwarding. A value of 0 means disable IP forwarding, and a value of 1 means enable IP forwarding.

Nonlocal Source Routing Enable/Disable

Option Code Length (Bytes) Parameter Value
20 4 Source route forwarding (enable=1)

This option configures the client behavior in regard to whether or not it will forward packets with source-routing information.

Policy Filter Option

Option Code Length (Bytes) Parameter Value
21 Multiples of 8 Allowed source routing destination IP address/mask pairs

This option contains a list of IP address and mask pairs used to specify a list of source-routing next-hop addresses used for filtering. Any source-routed datagram whose next-hop address does not match one of the filters should be discarded by the client.

Maximum Datagram Reassembly Size

Option Code Length (Bytes) Parameter Value
22 2 Maximum datagram reassembly size in bytes

This option is used to define a maximum allowable size for the reassembly of an IP datagram that has been fragmented during transmission across the network.

Default IP Time-to-Live

Option Code Length (Bytes) Parameter Value
23 1 Default IP TTL (1-255)

The value of this option will be used as the default value for TTL in the IP header of outbound datagrams.

Path MTU Aging Timeout Option

Option Code Length (Bytes) Parameter Value
24 4 MTU aging timeout (secs)

The MTU (Maximum Transmission Unit) is the maximum packet size allowed on a given network segment. It is periodically tested using a polling mechanism called Path MTU Discovery. This option can set the polling interval.

Path MTU Plateau Table

Option Code Length (Bytes) Parameter Value
25 Multiples of 2 List of MTU sizes to check

The Path MTU Discovery process works by cycling through a set of potential MTU values, to find the maximum suitable value. This option contains a list of MTU sizes, arranged from smallest to largest, that this polling process can try.

IP Layer Parameters per Interface

Options in this section are intended to apply to a particular interface on a client. If multiple interfaces need to be configured, the client should issue individual requests for each interface.

Interface MTU Option

Option Code Length (Bytes) Parameter Value
26 2 MTU value for interface (bytes)

This option assigns an MTU value for a specific interface.

All Subnets Are Local Option

Option Code Length (Bytes) Parameter Value
27 1 All subnet MTUs are the same (1 = yes)

This option tells the client whether or not all subnets the client is connected to share the same MTU value. A value of zero indicates that some subnets may have smaller MTUs.

Broadcast Address

Option Code Length (Bytes) Parameter Value
28 4 Subnet broadcast address

This option specifies the address used for subnet broadcasts on the interface subnet.

Perform Mask Discovery

Option Code Length (Bytes) Parameter Value
29 1 Enable subnet mask discovery (1 = yes)

This option determines whether or not the client will perform ICMP mask discovery.

Mask Supplier

Option Code Length (Bytes) Parameter Value
30 1 Respond to subnet mask ICMP request (1 = yes)

The ICMP mask discovery process relies on a host to respond to the mask requests. This option enables the host to reply to mask discovery requests.

Perform Router Discovery

Option Code Length (Bytes) Parameter Value
31 1 Perform router discovery (yes = 1)

This option determines whether or not the client should perform router discovery (RFC 1236).

Router Solicitation Address

Option Code Length (Bytes) Parameter Value
32 4 Address of server for router discovery requests

This option provides the address of the node servicing router discovery requests.

Static Route List

Option Code Length (Bytes) Parameter Value
33 Multiples of 8 Static routes listing destination address, next-hop router address

This option provides a list of static routes. Each entry includes the destination network and the next-hop router address for that destination.

Link Layer Parameters per Interface

Options in this section apply to a particular interface, and contain parameters related to the data-link layer.

Trailer Encapsulation

Option Code Length (Bytes) Parameter Value
34 1 Use trailers with ARP (yes = 1)

This option determines whether or not the client will negotiate the use of trailers with the ARP protocol as specified in RFC 893.

ARP Cache Timeout

Option Code Length (Bytes) Parameter Value
35 4 Timeout value for ARP cache entries (secs)

This option specifies a maximum age for ARP cache entries.

Ethernet Encapsulation

Option Code Length (Bytes) Parameter Value
36 1 Encapsulation type (Ethernet II=0, 802.3 = 1)

This option is used to specify the Ethernet encapsulation type. Valid values are Ethernet II or 802.3 Ethernet.

TCP Parameters

This section contains per-interface parameters dealing with TCP.

TCP Default TTL

Option Code Length (Bytes) Parameter Value
37 1 TCP default TTL (1-255)

Outbound TCP packets will have the value defined in this option entered into the IP-level TTL field.

TCP Keepalive Interval

Option Code Length (Bytes) Parameter Value
38 4 Keepalive interval (secs)

This option defines an interval between keepalive messages on the TCP connection. A value of 0 disables periodic keepalive messages.

TCP Keepalive Garbage

Option Code Length (Bytes) Parameter Value
39 1 Send garbage octet (yes =1)

This option is used to preserve compatibility, without older TCP implementations that require an octet of random characters as part of the keepalive message.

Application and Service Parameters

Options in this section deal with miscellaneous parameters related to services or applications.

Network Information Service Domain

Option Code Length (Bytes) Parameter Value
40 Variable Name of client’s NIS domain

This option specifies the client’s Network Information Service (NIS) Domain.

Network Information Server List

Option Code Length (Bytes) Parameter Value
41 Multiples of 4 List of NIS server addresses

This option specifies a list of NIS server addresses available to the client, in order of preference.

Network Time Protocol Server List

Option Code Length (Bytes) Parameter Value
42 Multiples of 4 List of NTP server addresses

This option specifies a list of Network Time Protocol (NTP) server addresses available to the client, in order of preference.

Vendor-Specific Information

Option Code Length (Bytes) Parameter Value
43 Variable Vendor-specific information

This option is used in conjunction with option code 60, The Vendor Class Identifier, to pass vendor-specific parameters. These parameters will use the same Tag-Length-Parameter arrangement as a standard option code.

NetBIOS over TCP/IP Name Server List

Option Code Length (Bytes) Parameter Value
44 Multiples of 4 List of NBNS server addresses

This option contains a list of NetBIOS name servers that can perform NetBIOS name-to-address translation for the client.

NetBIOS over TCP/IP Datagram Distribution Server List

Option Code Length (Bytes) Parameter Value
45 Multiples of 4 List of NBDD server addresses

This option specifies a list of NBDD server addresses available to the client, in order of preference.

NetBIOS over TCP/IP Node Type

Option Code Length (Bytes) Parameter Value
46 1 NetBIOS Node type code

This option defines the NBT Node type of the client. This node type defines what methods the client will use to do NetBIOS name resolution. The values and meanings are listed in Table 7.7.

Table 7.7

NetBIOS over TCP/IP Node Type Codes

Hex Value Node Type Behavior
0×1 B-node Broadcast
0×2 P-node Use name server
0×4 M-node Broadcast, then use name server
0×8 H-node Use name server, then broadcast

NetBIOS over TCP/IP Scope

Option Code Length (Bytes) Parameter Value
47 Variable NetBIOS scope name

This option defines the client as a member of a NetBIOS scope.

X Window System Font Server List

Option Code Length (Bytes) Parameter Value
48 Multiples of 4 List of X Windows Font server addresses

This option specifies a list of X-Windows Font server addresses available to the client, in order of preference.

X Window System Display Manager List

Option Code Length (Bytes) Parameter Value
49 Multiples of 4 Address list of systems running X Windows Display Manager

This option specifies a list of systems available to the client that are running the X Window System Display Manager.

Network Information Service+ Domain

Option Code Length (Bytes) Parameter Value
64 Variable Name of client’s NIS+ domain

This option lists the client’s NIS +(Network Information Service Plus) domain.

Network Information Service+ Servers List

Option Code Length (Bytes) Parameter Value
65 Multiples of 4 List of NIS+ server addresses

This option provides a list of the NIS+ Servers available to the client, in order of preference.

Mobile IP Home Agent

Option Code Length (Bytes) Parameter Value
68 Multiples of 4, usually 4 or 0 List of Mobile IP Home Agent addresses

This option provides a list of the Mobile IP Home Agents available to the client, in order of preference. Usually there is either one of these, or none.

Simple Mail Transport Protocol (SMTP) Server List

Option Code Length (Bytes) Parameter Value
69 Multiples of 4 List of SMTP server addresses

This option provides a list of the SMTP Mail Servers available to the client, listed in order of preference.

Post Office Protocol (POP3) Server List

Option Code Length (Bytes) Parameter Value
70 Multiples of 4 List of POP3 server addresses

This option provides a list of the POP3 Mail Servers available to the client, in order of preference.

Network News Transport Protocol (NNTP) Server List

Option Code Length (Bytes) Parameter Value
71 Multiples of 4 List of NNTP server addresses

This option provides a list of the NNTP News Servers available to the client, in order of preference.

Default World Wide Web (WWW) Server List

Option Code Length (Bytes) Parameter Value
72 Multiples of 4 List of WWW server addresses

This option provides a list of the Web Servers available to the client, in order of preference.

Default Finger Server List

Option Code Length (Bytes) Parameter Value
73 Multiples of 4 List of Finger server addresses

This option provides a list of the Finger Servers available to the client, in order of preference.

Default Internet Relay Chat (IRC) Server List

Option Code Length (Bytes) Parameter Value
74 Multiples of 4 List of Finger server addresses

This option provides a list of the IRC Chat Servers available to the client, in order of preference.

StreetTalk Server List

Option Code Length (Bytes) Parameter Value
75 Multiples of 4 List of StreetTalk server addresses

This option provides a list of the StreetTalk Servers available to the client, in order of preference.

StreetTalk Directory Assistance (STDA) Server List

Option Code Length (Bytes) Parameter Value
76 Multiples of 4 List of STDA server addresses

This option provides a list of the STDA Servers available to the client, listed in order of preference.

RFC2132 completes this list with the DHCP-specific option codes that were covered in the DHCP section of the chapter, and then a section on how to propose new option codes.

BOOTP, DHCP, and Routed Networks

From the first definitions of the BOOTP protocol, a mechanism was specified that could allow a BOOTP client and server on different subnets to exchange BOOTP information. This mechanism was first called a BOOTP Forwarding Agent, but the name was later changed to avoid confusion with a router that provides routine packet forwarding. It’s now referred to as a BOOTP Relay Agent.

Since DHCP was designed to be an extension of BOOTP, it was also designed to use BOOTP Relay Agents. From the standpoint of the agent, it does not care if the packet is a standard BOOTP packet, or a BOOTP packet with DHCP Message type options in the VEND/OPTIONS field. Either way, the process is the same.

The BOOTP Relay Agent

When a BOOTP client issues a BOOTREQUEST packet, typically it does not know the address of the BOOTP server that is going to reply. It therefore sends this packet out as a local broadcast with a destination address of 255.255.255.255. Since local broadcasts are not forwarded between subnets by a router, this message will never reach the server if it is not on the same subnet as the client. To allow this packet to be forwarded, a BOOTP Relay Agent must exist on the same subnet with the client. The Relay Agent recognizes that this broadcast is a BOOTREQUEST based on the destination UDP port number of 67, which is the BOOTP Server port. The agent will then forward this packet as a unicast, with the destination set to the IP address of the BOOTP Server. It knows what address(es) to use in forwarding these packets because the addresses are part of the agent configuration. It will also receive a BOOTREPLY unicast message back from the server, and then send it back to the client on the local subnet, typically as a local broadcast.

The definition of the BOOTP Relay agent did not specify whether this function should be incorporated into a router (gateway) or whether it could be another host on the same subnet as the client. Either implementation is acceptable since the main requirements are that:

 The Agent has to be a node on the same subnet as the client.

 It has to recognize and forward the client request as a unicast message to the server.

 It has to accept unicast messages back from the server that it then resends out on its local subnet to the requesting client.

In spite of the fact that either a host or a router could perform the relay agent function, it was suggested in several RFC discussions that a router provided a logical place to implement this functionality. Therefore, it is common to hear references to an RFC1542-compliant router, which implies BOOTP Relay Agent’s capability in the router (see Figure 7.3). Although it was a valid point, it contributed to the confusion between forwarding agents and relay agents, and also contributed to a related confusion in the meaning of the GIADDR field in the BOOTP packet.

Figure 7.3 The BOOTP Relay Agent Process

The Role of the GIADDR

The GIADDR field in the BOOTP packet plays a significant role in the functioning of BOOTP and DHCP across a routed network. We have learned that the GIADDR is set to 0.0.0.0 by the client when it transmits a BOOTREQUEST. If the BOOTP/DHCP server gets a BOOTREQUEST with the GIADDR set to all zeros, it knows the client is on the local subnet, and will respond directly to it, using UDP destination port 68 (BOOTP Client).

If the server is not local to the client, a BOOTP Relay Agent must exist on the client’s subnet to forward the packet. If this is the case, the agent will examine the GIADDR field of the request, and if the field is all zeroes, it will place its own address in this field. This provides a unicast return address for the server to use in returning its BOOTREPLY message to the client’s subnet. If the GIADDR is not zero, the agent assumes the existing value represents a node on the client’s home subnet, and does not modify it.

When a BOOTP/DHCP server receives a BOOTREQUEST packet with a nonzero GIADDR, it recognizes that the packet was forwarded from a BOOTP Relay Agent. In this case it modifies its response in the BOOTREPLY packet, sending it to the GIADDR as the destination address, and sending it to port 67 (BOOTP Server) instead of port 68 (BOOTP Client). This is necessary because the agent only responds to the server port number, whether the message is a client request or a server response.

Another use of the GIADDR is DHCP-specific: The DHCP server uses the address listed in the GIADDR field to ascertain the client’s subnet. Using this information, the server can determine which scope of addresses, if it has multiple address scopes, to use in responding back to the client.

Other Fields Involved

In addition to the GIADDR field, there are a number of other fields in the BOOTP packet that may be modified by the BOOTP Relay agent, outlined here.

HOPS

The HOPS field in a BOOTREQUEST from a client is initially set to zero. Each time the request packet crosses another router boundary, this field should be incremented by one. There is some ambiguity in the RFCs as to whether this should happen only if the agent is a router, or if the agent should do this regardless of role. It seems more appropriate to a router, since a properly configured relay agent and server will directly unicast between themselves, without the need for any intermediary agents.

The HOPS field was also intended to tell how far away a client was from a server, allowing a threshold to be set beyond which the packet will no longer be forwarded.

CHADDR, YIADDR, HTYPE, HLEN, FLAG

These fields all have a role to play in helping the server and agent determine how they should send back a BOOTREPLY to the client. A previous section of this chapter outlined the various options the BOOTP Server might use to reply to the client based on whether the client can accept unicasts or broadcasts. Since the BOOTP Relay Agent is acting on behalf of the BOOTP server, it will do the same evaluation of these fields to determine the appropriate method, unicast or broadcast, to return a reply to the client.

SECS

This field allows the client to communicate how long it has been trying to boot. If the client is forced to retransmit its BOOTREQUEST, this value will be nonzero, and can be used to initiate priority handling on the part of the agent and/or the server.

UDP Port Number

Normally, the client always uses UDP port 67 (BOOTP Server) as a destination port, and the server uses UDP port 68 (BOOTP Client) as its destination port in a BOOTREPLY. However, a BOOTP Relay agent responds only to packets with the UDP port set to 67. This means if the server is sending a BOOTREPLY message back through a relay agent, it must address this BOOTREPLY message to the agent’s address (GIADDR) with a UDP destination port of 67 rather than 68. The relay agent will change the destination UDP port number to 68 before it forwards the packet back to the client.

IP TTL Field

A relay agent either will set the TTL field in the IP Datagram header to a configured default value, or it will take the existing value it received, and decrement it by one. This seems to be another specification in the RFC that is more suitable to a router-based relay agent, rather than some other host performing a relay function.

ALL Other Fields

All other fields in the BOOTP packet should be passed between server and client without any modification.

BOOTP Implementation Checklist

Use the following list as a rough guideline to the steps you should take in implementing BOOTP Servers:

1. First determine if you really need to use BOOTP. If you are implementing dynamic addressing it is very possible that DHCP would be a better choice, since DHCP server implementations can often accommodate older BOOTP clients, as well as DHCP clients.

2. Determine the range of addresses you will be issuing, as well as any BOOTP options that you wish to convey along with the address assignment.

3. Gather a list of the hardware addresses and address types for each of the BOOTP clients.

4. Determine if you will be using the remote boot features of BOOTP, or just the address assignment phase. If you are doing remote booting, prepare the appropriate boot files and determine the directory paths for these files.

5. Create the BOOTP database file, using all the information you have gathered.

6. Install and configure the BOOTP server.

7. Configure the clients to act as BOOTP clients.

8. Test the functionality of the BOOTP server.

9. Consider the needs for cross-subnet communication between clients and servers, and configure and test BOOTP Relay agents where appropriate.

DHCP Implementation Checklist

Use the following list as a rough guideline to the steps you should take in implementing DHCP Servers:

1. Determine the range of clients that will use DHCP. Also determine which hosts on the network will have static or reserved address assignments. Consider whether any BOOTP clients exist, and the strategy that will be used by DHCP to assign their addresses.

2. If necessary, configure a BOOTP database file for use by the DHCP server in servicing BOOTP clients. Ensure that any addresses included in this file are not part of any DHCP address pool.

3. Determine the range of addresses that will constitute the address pool. If the DHCP server will service multiple subnets, determine the appropriate address scopes for each subnet and the associated parameter options that you may wish to convey along with the address.

4. Install and configure the DHCP server or servers based on the address ranges, exclusions, reserved addresses, and options that will be associated with each address scope. Also decide on and configure an appropriate lease duration for the addresses.

5. If multiple servers are used, consider partitioning each address pool between two servers, to enhance reliability by providing some redundancy.

6. If clients and servers need to communicate across subnet boundaries, configure BOOTP Relay Agents in appropriate locations.

7. Configure clients to use DHCP.

8. Test the functionality of the DHCP server and Relay Agents.

Summary

In this chapter we discussed the dynamic assignment of IP addresses using the BOOTP and DHCP protocols. We covered the reasons for, and the history behind, the development of these protocols and learned in detail how they work.

BOOTP and DHCP are closely related protocols. Both make use of a specially defined packet that uses a UDP datagram addressed to specific UDP ports, namely port 68 (BOOTP client) and port 67 (BOOTP server). This packet has a payload consisting of fields that allow it to convey address assignments and other parameters, as well as the information a client may need to affect a remote boot across the network. Clients initiate this process with a BOOTREQUEST packet to a server, and the server responds with a BOOTREPLY packet. The BOOTP packet contains a Vendor extensions or Options field that is used to pass additional parameters to the client. BOOTP issues address assignments and other parameters based on a flat-file database that matches a client identifier, usually its hardware address, with the set of parameters listed for that client. Configuration of this file is a manual administrative task.

DHCP was designed to be an extension of BOOTP. It uses the same packet definition, same UDP ports, and the same BOOTREQUEST and BOOTREPLY messages, but it relies very heavily on the Vendor extensions field, which is now called simply the Options field. Each DHCP message uses a DHCP message type option code, to define a part of the DHCP process, as well as other option codes to pass DHCP-specific, as well as generic client configuration parameters.

DHCP provides more options in terms of address assignments. It can hand out addresses from a BOOTP-like database file, or it can hand addresses out on a first-come, first-served basis from an established address pool, sometimes called a scope. DHCP configuration can be much simpler than BOOTP, since it is not necessary to match each client manually to an individual address assignment. An address scope can be defined with a set of parameters, such as mask, default gateway, default DNS servers, etc., that can be distributed to all DHCP clients in that scope. DHCP can also accommodate multiple scopes for different subnets, each with its own set of parameter options.

Unlike BOOTP, DHCP can also be configured to assign addresses for a finite time period, called a lease. DHCP clients are required to renew their lease on an address periodically, or it will be reclaimed by the server once the lease period expires, and will be reassigned to a new client. This is a very useful feature when clients connect temporarily to a network, or where there is a shortage of IP addresses available. DHCP servers maintain a database of all the addresses they have assigned, to whom they were assigned, and how long the lease period is. This prevents the server from handing out duplicate addresses.

To accommodate client requests that cross subnet boundaries, the BOOTP specification includes the definition of a BOOTP Relay agent, which listens for client requests on its local subnet, and forwards them as unicast messages across router boundaries to the server. It performs the reverse function for the server as well. Both BOOTP and DHCP can make use of BOOTP Relay agents.

FAQs

Q: How do I know if my host can be a DHCP or BOOTP client?

A: The ability to act as a DHCP or BOOTP client is built into the IP protocol stack being used by the client. The protocol stack should include the ability to configure itself for dynamic address assignment, in addition to the usual manual configuration. Whether the client uses BOOTP or DHCP is often a function of how old the protocol stack is. Most newer protocol stacks will be configured to use DHCP, since it was designed to replace BOOTP. The documentation provided with the protocol stack should indicate what dynamic addressing capabilities are supported.

Q: When would I use BOOTP instead of DHCP?

A: In most cases it is better to use DHCP instead of BOOTP, if the clients support it. This is because DHCP will do everything that BOOTP will do and more. The configuration process with BOOTP is entirely manual, and can be a formidable task for a large network. By contrast, DHCP can be relatively easy to configure, even for large networks, since you only need to define an address range and a common set of parameters for each address pool to service a large number of clients.

q: What is an RFC 1542-compliant router?

A: This term is often found in documentation dealing with the implementation of DHCP and BOOTP. It refers to the definition of a BOOTP Relay Agent and the functions of that agent. Simply put, an RFC 1542-compliant router is one that can be configured to act as a BOOTP Relay Agent. Remember that the relay agent does not have to be a router, but can be implemented on a host system that resides on the same subnet as the clients.

Q: If I configure multiple scopes on a DHCP server, how does the server know which scope to use for a given client?

A: The way that a DHCP server decides on which scope is to be used for a given client depends on the subnet to which the client is connected. This subnet information comes to the server by means of the GIADDR field in the BOOTP packet. This field is empty when a client is on the same subnet as the server, and contains the address of the BOOTP Relay Agent otherwise. This agent address is on the same subnet as the client, so the server can read this address to determine the client’s connected subnet.

Q: How does DNS work with DHCP?

A: The short answer is, “Not very well.” The problem is that unless each client is assigned a specific address reservation, it is not possible, until after the fact, to determine which IP address was assigned to a client. Since traditional DNS server implementations use a statically-configured database, this can pose some problems. There are several workarounds to this. There are products commercially available that will link DHCP servers and DNS servers, so that when an address assignment is made, the DNS server database is updated. In Microsoft environments, this problem has been handled using a WINS (Windows Internet Name Service) server. WINS clients register themselves dynamically with the WINS server after they have received a DHCP address assignment. The name resolution process checks both DNS and WINS servers to obtain a name resolution. As long as the same name is being used for the NetBIOS name and the Internet host name, this process will result in a name-to-address translation for either name type.