Droms R. The DHCP handbook

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

has been to help people who need to use DHCP to learn what they need to know to

install and manage a DHCP installation without sending him e-mail.

Ted currently works for Nominum, Inc., a leading vendor of DHCP and DNS

solutions.

000 3273 FM 10/3/02 5:02 PM Page xxx

Dedication

To my father, who inspired me to ask questions and encouraged

me to find answers.

—Ralph Droms

To all my teachers, without whose kindness I would never have

been able to do this, and to all the living beings, may this book

help you in some small way to reach happiness.

—Ted Lemon

Acknowledgments

Thanks to everyone who contributed to this book. We had the pleasure and good

fortune to work with a great team at Pearson. Linda Engelman, Jen Garrett, Dayna

Isley, Kitty Jarrett, Shannon Leuma, Clint McCarty, Lisa Thibault, Karen Wachs, and

Jenny Watson all provided guidance and support every step along the way in the

writing and production of this book.

Without the work of the DHCWG IETF, we wouldn’t have DHCP to write about.

We would like to thank Richard Barr Hibbs and Bernie Volz, our technical editors,

who read the text with diligence that was above and beyond the call of duty. As a

result of their efforts, we clarified some of the more difficult sections in the book. We

also thank Mike Carney and Mark Sirota for their careful reading of the text and

their helpful comments. We are extremely grateful to Thomas Hickman, Kim

Kinnear, and Mark Stapp, all with Cisco Systems, who wrote or contributed to several

chapters, as noted in the text.

From Ralph Droms:

Thanks to Cisco, Bucknell University, Vint Cerf and the Corporation for National

Research Initiatives, Joe D’Andrea and my other friends at Quadritek Systems (now a

part of Lucent Technologies), and Mike Carney of Sun Microsystems for supporting

my activities as chair of the DHCWG and making it possible to write this book.

Doug Comer first gave me an opportunity to learn which end of a packet is up.

I thank Ted for his experience with the practice of networking that he brought to

this project, for his insightful input and careful review of my writing, and for his

vision about how we could make this book truly educational and useful.

000 3273 FM 10/3/02 5:02 PM Page xxxi

My wife, Jan, improved the book with her careful editing and suggestions for organ-

izing its content. Jan, along with our daughters, Stacey and Becca, inspired me to

tackle this project and see it through to completion.

From Ted Lemon:

Thanks to Paul Vixie for his compassion and help both in my professional and

personal life. Thanks to David Conrad for his patience, kindness, and patience.

Thanks to my mother and father for putting up with me and setting an example for

me that I haven’t always been able to appreciate. Thanks to Mel, for her great kind-

ness, and to Signe, Queen of Repartee. Thanks to Scanner, Bob, Wendy, April, Betty,

Stephen, Ben, James, George, Matt, Lucy, Ashton, Cristi, and all the other nice

people at Nominum with whom it is a joy to work. Thanks to Richard Stallman, for

teaching me the key to writing difficult programs: start typing.

Thanks to my wonderful wife, Andrea, for not being sad when I’ve stayed up

through the night working on chapters, and for cheering me up when I’m tired and

depressed, and to Phil and Sylvia, Mike, Debby, Martin, Ellen, and Keith—the best

in-laws I could ever have hoped for. Thanks to Ralph for his thoughtful comments

and to Jenny and Karen for not reaching through the phone lines to throttle me

when I didn’t come up with a chapter on time.

Thanks to Walt Congdon for taking me under his wing and showing me how to be a

good person while pretending to teach me about ham radio. Thanks to my grand-

mother Carrie for showing me to look beyond my own concerns. Thanks to Hughes

Pack for being stern when I needed it. Thanks to Hartley Pfeil for teaching me how

to write. Thanks to Jennifer Bobbe for her patience and support when I was working

on the first edition. Thanks to Kim Kinnear for all his hard work on the failover

protocol and for putting up with all my suggestions, some of which may have been

useful. Thanks to Edward Lemon, Sr., and Robert Dickerson, my grandfathers, for

never believing something couldn’t be done and letting a little of that attitude rub

off on me (would that it had been more). Thanks to my grandmother, Leone Lemon,

for trying to teach me to be considerate.

Last but definitely not least, thanks to Khen Rinpoche Geshe Lobsang Tharchin,

Geshe Michael Roach, the one who calls himself Tenzin Gyatso, Geshe Thupten

Rinchen, Winston McCullough, Elly van der Pas, Lobsang Chukyi, Lobsang

Chunzom, Thupten Chudrun, John Brady, Sal Lupo, Seamus Rutherford, Rebecca

Vinacour, Deborah Bye, Mercedes Bahleda, and Rafael Cervantes for gifts of unsur-

passable value.

000 3273 FM 10/3/02 5:02 PM Page xxxii

We Want to Hear from You!

As the reader of this book, you are our most important critic and commentator. We

value your opinion and want to know what we’re doing right, what we could do

better, what areas you’d like to see us publish in, and any other words of wisdom

you’re willing to pass our way.

You can email or write me directly to let me know what you did or didn’t like about

this book—as well as what we can do to make our books stronger.

Please note that I cannot help you with technical problems related to the topic of this book,

and that due to the high volume of mail I receive, I might not be able to reply to every

message.

When you write, please be sure to include this book’s title and authors as well as

your name and phone or email address. I will carefully review your comments and

share them with the authors and editors who worked on the book.

Email:

networking@samspublishing.com

Mail: Mark Taber

Associate Publisher

Sams Publishing

800 East 96th Street

Indianapolis, IN 46240 USA

Reader Services

For more information about this book or others from Sams Publishing, visit our Web

site at

www.samspublishing.com. Type the ISBN (excluding hyphens) or the title of

the book in the Search box to find the book you’re looking for.

000 3273 FM 10/3/02 5:02 PM Page xxxiii

000 3273 FM 10/3/02 5:02 PM Page xxxiv

PART I

Introduction to DHCP

IN THIS PART

1 An Introduction to DHCP

2 An Example of DHCP in Operation

3 Configuring the DHCP Server

4 Configuring TCP/IP Stacks

002 3273 Part I 10/3/02 5:00 PM Page 1

002 3273 Part I 10/3/02 5:00 PM Page 2

IN THIS CHAPTER

• Configuring Devices on a

Network

•AFirst Attempt at Automating

Device Configuration

• The Benefits of DHCP

• Assigning IP Addresses Using

DHCP

• Perceived Problems of DHCP

• Address Allocation

Policies

An Introduction to

DHCP

The Dynamic Host Configuration Protocol (DHCP) auto-

mates the process of configuring new and existing devices

on TCP/IP networks. DHCP performs many of the same

functions a network administrator carries out when

connecting a computer to a network. DHCP enables a

program to automatically manage policy decisions and

bookkeeping tasks. Replacing manual configuration with a

program adds flexibility, mobility, and control to

networked computer configurations.

This chapter provides an overview of how network admin-

istrators allocate, manage, and configure IP addresses,

and it shows how administrators can use DHCP to accom-

plish these same tasks. It also introduces some of the basic

terminology required to understand the capabilities that

the protocol provides and examines some reasons for, and

caveats about, using DHCP.

Configuring Devices on a Network

Any network administrator using TCP/IP can testify that

manually configuring computers attached to a network

is a time-consuming and error-prone process. Indeed, at

almost any site—regardless of whether DHCP is in use—

the address assignment and configuration process is

automated in some way.

One of the authors of this book, Ted Lemon, worked as a

network administrator at the Digital Equipment

Corporation (DEC) campus in Palo Alto, California, before

DHCP was available to simplify the tasks of address

management and configuration. The DEC campus used a

central IP address administration system, which was based

003 3273 CH01 10/3/02 5:01 PM Page 3

CHAPTER 1 An Introduction to DHCP4

on a single list, or host table, of computers, IP addresses, and Domain Name System

(DNS) names for the entire network.

To help introduce you to the tasks that a DHCP server performs, this section

describes, from Ted’s perspective, what network administrators did before DHCP

became widely available.

As part of the network administration task, we network administrators updated the

host table with new computers as they were added to the network and changed the

entries for computers as their names and addresses changed. Periodically, we ran a

shell script on the host table to update the DNS server database. We configured indi-

vidual computers manually, from the entries in the host table, by physically walking

up to each computer and entering the configuration information.

Users had a variety of questions about connecting their computers to the campus

network. Usually, they wanted to know what IP address they could use for their

computers. To respond to such questions, we asked the following:

•Who are you?

• Is this a new device, or was it connected to the network before?

•What is the device’s old IP address?

•Where do you need to install this device?

•In what department do you work?

IP Address Allocation

After we obtained this information, we decided whether to give the user an IP

address. It was usually easy to make this decision; if the user was an employee or a

contractor working in a DEC Palo Alto building, we gave the user an address. Next,

we decided what IP address to assign to the user. To do this, we had to know what

network segments were present at the site, which segment or segments were avail-

able in the user’s office, and how those network segments were configured.

If we supported a single network segment with a single IP subnet, answering these

questions would have been simple, and everyone would have been allocated

addresses from that subnet. However, the DEC Palo Alto campus network consisted

of many network segments, routed together through a backbone network. Thus, it

was a bit more difficult to assign IP addresses. In essence, each network administra-

tor had to remember which network segments were available in which buildings, on

which floors, and, in some cases, in which offices. If we remembered incorrectly, the

address might have been allocated from the wrong subnet or the address might

have already been assigned to another device, and we would have to perform the

process again.

003 3273 CH01 10/3/02 5:01 PM Page 4

After we determined the network segment to which the user’s computer would be

attached, we determined whether any IP addresses were available on it and chose

one for the user. If no IP addresses were available on the segment—and this was

often the case—we examined the host table for addresses that appeared to be no

longer in use. Occasionally, we configured a new network segment and moved some

devices to it to expand the pool of available addresses.

Configuration Information

In addition to choosing an IP address on the correct subnet, we also provided the

user with additional information about the network, which usually consisted of the

following:

• The addresses of the default routers for the network segment to which the

device was to be connected

• The addresses of primary and secondary domain name servers that the device

would use

• The subnet mask and broadcast address

If the device needed specific network services that were not used by all devices on

the network, we also informed the user how to access those services and

programmed that information into the device. For example, we manually configured

a diskless Network File System (NFS) client’s NFS mount information, and we usually

gave different information to each diskless NFS client.

Configuring Network Devices

In general, we got network configuration information into devices in two ways:

•When configuring a knowledgeable user’s machine, we gave the information

directly to that user; thus, it took a minute or two to configure a machine over

the phone or via a single e-mail message exchange.

•For users who could not configure their own machines, we had to determine

where the user was, walk to that user’s station (possibly in a different building),

root, type the necessary information, restart the machine, and then

verify that it worked correctly.

Moving Devices to Different Network Segments

From time to time, a user would move from one office to another, or a user’s

machine would move from a lab into an office. If the network segment (or segments)

to which the user’s devices were attached was not available in the new location,

Configuring Devices on a Network 5

003 3273 CH01 10/3/02 5:01 PM Page 5