Droms R. The DHCP handbook

Подождите немного. Документ загружается.

006 3273 CH04 10/3/02 5:01 PM Page 56

PART II

DHCP Theory of

Operation

IN THIS PART

5 The DHCP Client/Server Model

6 The Format of DHCP Messages

7 Transmitting DHCP Messages

8 DHCP Message Exchanges

9 DHCP Options

10 Failover Protocol Operation

11 DHCP–DNS Interaction

007 3273 Part II 10/3/02 4:58 PM Page 57

007 3273 Part II 10/3/02 4:58 PM Page 58

IN THIS CHAPTER

• DHCP Goals and Design

Decisions

• Related TCP/IP Protocols

• The DHCP Client/Server

Architecture

DHCP Client/Server

Model

Expanding on the specific examples of DHCP in opera-

tion given in the previous chapters, this chapter summa-

rizes DHCP theory and principles and explains why some

DHCP features are included in the specification in their

current form. This chapter describes the following:

• Some of the goals and constraints within which

DHCP was designed

• The relationship between DHCP and other, related

protocols

• The client/server architecture DHCP uses

DHCP Goals and Design Decisions

As earlier chapters explain, DHCP’s primary goal is to auto-

matically configure networked computers that use TCP/IP.

Because TCP/IP is used in such diverse environments, the

TCP/IP stack includes several parameters that can be

configured for a specific computer and network (see RFC

1122). After using DHCP to obtain this TCP/IP stack

configuration information, a networked computer can

exchange packets with other computers on the network.

Administrative Control, Correctness, and

Reliability

A network administrator can use DHCP to control the

configuration of individual computers according to a set of

particular requirements. DHCP provides a way to convey

configuration parameters to the computers being managed

without dictating policies about how those computers

should be configured.

008 3273 CH05 10/3/02 5:05 PM Page 59

CHAPTER 5 DHCP Client/Server Model60

For example, a DHCP server is not required to respond to every DHCP message it

receives. If the network policy does not enable automatic configuration of computers

not previously connected to the network, the network administrator can simply

configure the DHCP server to ignore

DHCPDISCOVER messages from hosts that are not

already known to the DHCP server. This design goal enables the network administra-

tor to use DHCP in a variety of situations and to implement a range of IP address

and configuration policies. A DHCP server acts as an “administrative assistant,”

interpreting the configuration policies the network administrator develops and

passing network along specific parameters to individual computers, based on those

policies.

Assigning IP Addresses Dynamically

The most obvious policy a network administrator develops for a DHCP server is one

that controls the assignment of IP addresses to computers. Dynamic assignment of

IP addresses enables new computers to join a network and obtain configuration para-

meters without manual intervention. The danger in dynamic address assignment is

that two computers might obtain the same IP address, and this prevents both

computers from using the network. Such duplicate address assignment can be very

difficult to find. Therefore, DHCP is designed to eliminate any possibility that the

same IP address might be assigned to two computers at the same time.

In conjunction with dynamic address allocation, DHCP enables automatic address

reuse. Because only a limited number of IP addresses are available in any IP subnet,

the DHCP server can run out of addresses to allocate, unless it can recover addresses

that are no longer in use. The solution to address reuse in DHCP is to assign

addresses for a finite period of time, known as a lease. When the lease on an IP

address expires, the DHCP server can safely reassign that address to a different client.

In this way, a server can reassign the IP addresses from computers that have left the

network to computers that subsequently join the network.

When Servers Are Unavailable

Because access to the DHCP service is critical to the operation of an organization’s

computers (and, therefore, to the function of the organization as a whole), the

DHCP specification allows two or more DHCP servers to provide service to the same

network. Computers using DHCP broadcast an initial message to locate DHCP

servers and must be prepared to receive responses from more than one server.

Likewise, when extending a lease on an address, a computer broadcasts its request to

find any available DHCP server if the original server doesn’t respond. This means

that if one DHCP server is not functioning, another server can continue to provide

service.

008 3273 CH05 10/3/02 5:05 PM Page 60

The DHCP specification also anticipates the possibility that no DHCP servers are

available. When a computer restarts, if it can’t reach a DHCP server, it can use its old

IP address as long as the lease on that address has not expired. If it has not been

moved to a new network segment, the computer can start using the network even if

the DHCP server is down.

Relay Agents

A DHCP client must contact DHCP servers before the client has been assigned an IP

address. Without an IP address, the client can only transmit messages on its local

network segment by using IP broadcast. Therefore, every network segment on which

DHCP service will be provided must have some sort of DHCP service provider. DHCP

provides for relay agents, which are very simple DHCP message forwarders that can be

deployed on individual network segments. Relay agents enable DHCP service to be

provided by just a few servers in a centrally managed location.

Avoiding Manual Configuration and Reducing Changes to

Configuration

DHCP is an effective tool for managing thousands of computers, in part because it

provides automated configuration services for new computers that were not previ-

ously connected to the network. That is, a computer can use DHCP with no manual

configuration on the part of the user or the network administrator. A computer

equipped with a DHCP client can find a DHCP server, exchange DHCP messages

with that server, and use the information from the DHCP server to configure its

TCP/IP stack. All this occurs as soon as the machine is started, without the network

administrator taking special action for individual computers.

DHCP retains a client’s configuration across client and server restarts. Servers must

record assigned addresses and leases to permanent storage before responding to the

DHCP client so that there is a reliable record of the IP address assigned to each

client. Servers use this record to confirm each client’s address assignment whenever

the DHCP client is restarted. The DHCP specification also recommends that servers

keep address assignment information after the lease has expired. This means that

each client usually gets the same address, even if its lease expires. Clients with local

permanent storage record their configuration information for reconfirmation when

they restart the computer.

DHCP also gives the network administrator the opportunity to update client configu-

rations automatically. Each time a DHCP client contacts the server, the server can

update the client’s configuration parameters. For example, when a new DNS server is

installed, the network administrator updates the DHCP server configuration file, and

each DHCP client is informed of that server the next time it restarts. Even a DHCP

client that remains running and is not restarted periodically will learn of the new

DHCP server when it contacts the server to extend the lease on its IP address.

DHCP Goals and Design Decisions 61

008 3273 CH05 10/3/02 5:05 PM Page 61

Identifying Clients

A server must be able to identify which DHCP client sent a DHCP message so that it

can match that message with an existing entry in its list of assigned addresses or

create a new entry for that client. DHCP provides two different ways for a client to

identify itself: the link-layer address of the interface that the DHCP client is

configuring and the client identifier.

The link-layer address is also known as the MAC address in networks that use IEEE 802

technology. The link-layer address is unique among the devices on a network

segment; in fact, for most network technologies, the link-layer address is unique

among all computers using that same technology. The link-layer address is automati-

cally configured and available without requiring user intervention. The link-layer

address has some limitations as a DHCP identifier, however. It lacks flexibility, the

DHCP identity of a client changes if its network interface adapter changes.

For clients that want to use a different identifier, DHCP defines the client identifier

option. This option tells the server to use the value in the option to identify the

client, rather than using the client’s link-layer address. Some sites, for example,

configure computers to use the computer’s fully qualified domain name as the client

identifier.

Whether the server uses the client’s link-layer address or a client identifier to identify

the DHCP client, the value of the identifier is assumed to be unique only on the

network segment to which the client is attached. The server uses the combination of

the network segment address and the client identifier to look up the client’s informa-

tion in the server’s database of assigned addresses and configurations.

New Functions in DHCP

Several features that were not included in the original protocol specification for

DHCP (that is, RFC 2131) are under development. The features described in this

section are all close to being accepted as IETF standards. To check on the status of

any of these features, see the Dynamic Host Configuration Working Group

(DHCWG) Web page,

www.ietf.org/html.charters/dhc-charter.html.

Communication Between Servers

Although the DHCP specification enables the existence of multiple servers, it doesn’t

include protocols for communication among DHCP servers. As later chapters discuss

in more detail, DHCP servers must exchange information if a network administrator

is to take full advantage of redundant servers. The DHCWG has been working on the

development of an interserver protocol and, at the time of this writing, has a draft

specification for the “DHCP Failover Protocol” ready for final review. Chapter 10,

“Failover Protocol Operation,” describes this interserver protocol.

CHAPTER 5 DHCP Client/Server Model62

008 3273 CH05 10/3/02 5:05 PM Page 62

Automatic DNS Updates

A natural link exists between DHCP and DNS. When a server assigns a new IP

address to a DHCP client, DNS entries for that client must be added or updated. But

when DHCP was first designed, the DNS database could be updated only via manual

entries. No protocol existed through which the DNS database could be updated auto-

matically. The DHCWG decided that this problem was outside the scope of its

charter and declined to develop a solution. Now that dynamic DNS updates are

defined in RFC 2136, the DHCWG has developed a formal definition of the interac-

tions between DHCP and DNS, which is described in Chapter 11, “DHCP/DNS

Interaction.”

Server-Initiated Messages

The definition of DHCP in RFC 2131 includes only message exchanges initiated by

DHCP clients. In some situations where the server has new information to deliver to

the client immediately, it might be desirable for a server to initiate a message

exchange. Initially, the DHCWG rejected proposals for server-initiated message

exchanges as being overly complex to manage and impossible to scale to large DHCP

deployments. Recently, a specification titled “DHCP Reconfigure Extension” has

been accepted by the DHCWG and is awaiting final IETF review for acceptance as

part of the DHCP specification.

New DHCP Options

As the deployment of DHCP continues to expand and new applications for DHCP

are developed, the need for carrying additional information in DHCP messages has

been identified. The DHCWG accepts and reviews proposals for new DHCP options

to carry this information. As the new options are accepted as part of the standard,

the specifications for those options are published as RFCs. To get the latest informa-

tion on newly defined options and the options under development, go to the

DHCWG Web page.

Functions Not Included in DHCP

Several functions or features were not incorporated into the DHCP protocol specifica-

tion (see RFC 2131) because these functions do not comply with the working group’s

original design goals.

One IP Address per Interface

The DHCP specification restricts the use of DHCP to a single IP address for each

network interface on a device. When DHCP was designed, few TCP/IP stacks were

configured that had more than one IP address on a single interface, and it was not

necessary to assign more than one IP address to an interface.

DHCP Goals and Design Decisions 63

008 3273 CH05 10/3/02 5:05 PM Page 63

NOTE

Obtaining multiple IP addresses for a single interface can be done by using a different client

identifier option for each IP address. A DHCP server treats messages with different client iden-

tifiers as though they came from different DHCP clients, even though the link-layer addresses

in those messages might be identical. So, to assign multiple addresses to an interface, the

network administrator should arrange for the DHCP client to make multiple requests to the

server, each with a different client identifier.

DHCPv6, the version of DHCP under development for IPv6, enables the assignment of multi-

ple IP addresses to a single interface. This feature of DHCPv6 is discussed in more detail in

Chapter 25, “DHCP for IPv6.”

Router Configuration

The DHCP specification clearly states that the protocol is not intended to configure

routers. The DHCWG adopted that restriction on the scope of DHCP early on, to

avoid the potential of added complexity in support of router configuration. Because

routers are typically static, and because it is critical to the operation of a network

that routers be correctly configured, interest in expanding DHCP to support router

configuration is minimal.

NOTE

Walt Lazear of Mitre Corporation has done some research into what he calls self-discovering

networks. In such a network, a self-configuring router is connected between a network

segment that already has DHCP service and routing and one or more network segments that

do not. The router has no preconfigured knowledge of its configuration; it uses the DHCP

protocol to contact a DHCP server, which provides it with configuration information. Using

this information, it configures all its interfaces and begins routing. At the same time, it config-

ures its own DHCP server, which the next router in the chain can then use to configure itself.

By deploying these routers in a lattice, network configuration information can propagate from

a central server out to the edges of the network without requiring any intervention on the

part of a knowledgeable user; it is the ultimate in plug-and-play networking.

Related TCP/IP Protocols

Clients can use other TCP/IP protocols, including those listed in Table 5.1, to obtain

some of the configuration information DHCP provides.

CHAPTER 5 DHCP Client/Server Model64

008 3273 CH05 10/3/02 5:05 PM Page 64

TABLE 5.1 Other TCP/IP Configuration Protocols

Protocol Function

Bootstrap Protocol (BOOTP) Provides a static IP address, some IP stack para-

meters and addresses of some network servers.

DHCP is based on BOOTP, and DHCP servers

are easily extended to provide service to

BOOTP clients.

Reverse Address Resolution Protocol (RARP) Provides statically assigned IP address.

Dynamic RARP (DRARP) Provides automated assignment of a static IP

address.

Internet Control Message Protocol (ICMP) Provides the subnet mask and default router.

Service Location Protocol (SLP) Acts as a dynamic directory for identifying and

locating network services; can provide flexible

and dynamic configuration of services that are

also provided through DHCP options.

RARP (see RFC 903) ) and DRARP (see RFC 1931) provide a computer with its IP

address, based on its link-layer address. Both RARP and DRARP use the same message

format as Address Resolution Protocol (ARP; see RFC 826), and they return the IP

address assigned to a link-layer address. A computer that uses RARP or DRARP to

obtain its IP address broadcasts a

request message that contains its link-layer address

on its network segment. A server, which must be connected to the same network

segment, determines the computer’s IP address based on its link-layer address, and it

returns that address in a

reply message.

RARP and DRARP use different methods to determine what IP address to return to a

requesting computer. RARP uses a table of link-layer addresses and IP addresses,

which the network administrator creates and edits manually. DRARP assigns

addresses to new clients automatically, without direct intervention by the network

administrator.

Although RARP and DRARP provide only IP addresses, many computers use Trivial

File Transfer Protocol (TFTP; see RFC 1350) to obtain further configuration informa-

tion from the server that answered the RARP or DRARP request. For example, Sun

diskless workstations use TFTP to download an appropriately configured Unix kernel

after obtaining an IP address from the RARP or DRARP server. Note that at this

writing, newer Sun systems can use DHCP rather than RARP.

ICMP (RFC 792) includes two mechanisms that a computer can use to obtain proto-

col stack parameters. A local authority, such as a router, uses the ICMP subnet mask

message (RFC 950) to inform a computer of the appropriate subnet mask. A

computer uses the ICMP router discovery messages (RFC 1256) to learn about routers

on its local network segment. Two types of router discovery messages exist. The first,

Related TCP/IP Protocols 65

008 3273 CH05 10/3/02 5:05 PM Page 65