Charles M. Kozierok The TCP-IP Guide

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

TCP/IP Network Configuration and Management

Protocols (BOOTP, DHCP, SNMP and RMON)

Some folks study the OSI Reference Model just to pass a test and otherwise consider it

“useless”. I think it's important because it shows how the different hardware and software

components of an internetwork fit together. One aspect of this is that the model lets us see

clearly how the functions of networks are implemented by building the higher-layer ones

upon those at lower layers. We start at the bottom layers dealing primarily with hardware,

and build upon them the software and protocols that make networks and internetworks in

the middle layers. The highest layers of the OSI model, especially the application layer, run

on top of the internetwork implemented by the layers below. It is therefore at this level that

we normally talk about the protocols and applications that permit end users to perform

different network communication tasks.

Of course, the users are why we create networks and internetworks in the first place. But

while the application layer is indeed where we find user-oriented protocols, users are not

the only ones who need to make use of network applications at this level. Network adminis-

trators have a number of functions that they must perform on a daily basis to keep networks

running smoothly and efficiently, and many of these use support protocols at higher layers.

Decades ago, an administrator was probably responsible for only a small number of

computers, all in the same building or even the same room. When something in the network

needed to be fixed or changed, the techie would walk over to it and “administer” it. Today, a

company's computers are probably not close at hand; they are likely spread out across a

campus, a country or the entire world. It is no longer feasible to travel to each computer to

perform various maintenance tasks. And with larger networks, trying to manually maintain

thousands of computers, even if they were in the same building, would not be possible.

To make administration practical on modern networks, special application-level protocols

were created that allow administrators to work with distance devices in a more automated

manner over the internetwork itself. It may seem ironic to be using the internetwork to help

administer the internetwork, but many tasks such as device configuration and management

can be performed effectively using software protocols. Using these protocols yields signif-

icant advantages over manual processes, and is part of what keeps the internetworks we

rely on running smoothly.

This section takes a look at two classes of administrative tasks that are served by appli-

cation-layer protocols. The first subsection deals with host configuration, describing the

concepts behind the process, and two protocols used for accomplishing automated configu-

ration of internetwork hosts. The second describes protocols used to remotely manage,

monitor and control remote hardware devices on an internetwork.

As part of this discussion, I describe in detail four TCP/IP protocols that implement host

configuration and management functions. These are the TCP/IP Boot Protocol (BOOTP)

and Dynamic Host Configuration Protocol (DHCP) for host configuration, and the Simple

Network Management Protocol (SNMP) and Remote Network Monitoring Protocol (RMON)

for network management.

Host Configuration and TCP/IP Host Configuration Protocols

(BOOTP and DHCP)

Each host that is placed on a network or internetwork must be set up and configured before

it can be used. Configuration ensures that the host functions properly, and that it is told the

parameters needed for it to successfully communicate with other hosts and devices. In the

“good old days”, administrators would manually set up each host as it was added to the

network, and would also manually make changes to the configuration as they were

required. Modern networks, however, are very large, and manual configuration of hosts is a

time-consuming chore. Furthermore, we often need to make use of features that only

automated configuration can provide, particularly for special hosts that have no internal

storage. It is for these reasons that host configuration protocols were developed.

In this section I describe the concepts behind host configuration protocols, and then illus-

trate the operation of two of the most important ones in use today. I begin with a topic that

provides an overview of host configuration concepts and issues. I describe the TCP/IP

Bootstrap Protocol (BOOTP), the first truly capable automated configuration tool for IP

hosts. I then describe BOOTP's successor, the feature-filled Dynamic Host Configuration

Protocol (DHCP), which is used extensively in modern TCP/IP hardware and software.

Related Information: Technically, the very first host configuration protocol for

TCP/IP was the Reverse Address Resolution Protocol (RARP). RARP is a very

simple, crude protocol that allows very basic host configuration to be performed,

but little else. RARP is very different from BOOTP and DHCP, not only because of its more

limited capabilities, but because it operates between layers two and three like the Address

Resolution Protocol (ARP) upon which it is based. It is therefore covered in the same

section that describes ARP.

Host Configuration Concepts, Issues and Motivation

Putting a host on an internetwork requires that certain setup and configuration procedures

be followed. Hardware must be selected and set up, and software too must be chosen and

installed on the hardware. Once the software is set up, we aren't finished, however: we

must also perform other configuration tasks that tell the software how we want it to operate,

and give it certain parameters so it knows its role on the network and how to function.

The Purposes of Host Configuration

Probably the most important configuration task that must be performed for each host on an

internetwork is to give it an identity, in the form of an address that is unique to it alone. In

TCP/IP networks, each device must be given an IP address. Hosts also often require other

parameters to ensure that they operate properly. For a TCP/IP network, we might want to

tell each host some of the following:

☯ The address of a default router on the local network.

☯ The network mask the host should use.

☯ The addresses of servers providing particular services to the host, such as a mail

server or a DNS name server.

☯ The maximum transmission unit (MTU) of the local network.

☯ What Time To Live (TTL) value to use for IP datagrams.

And possibly, a lot more; there are dozens of different parameters that must be set up for

certain networks. Many of these may be common to all the machines on a network, but IP

addresses must be unique. The administrator must therefore ensure that each is assigned

to only one computer, even as machines are added to and removed from the network.

The Inefficiency of Manual Host Configuration

If you're an administrator in charge of a small ten-host LAN, performing setup and configu-

ration is simple: for each host, you set up the hardware, install the software, and then

configure the software. Even changes and keeping track of IP addresses wouldn't be a big

deal; a single sheet of paper would suffice. However, what happens when your network has

not ten computers but a hundred? How about a thousand? Ten thousand?

As the size of the network grows, the work needed for manual configuration grows with it.

And while initial hardware setup may be time-consuming, at least it is done mainly when the

host is first set up, and rarely changed thereafter. This is not the case with configuration

parameters. If the address of the local router changes on a network with a thousand hosts,

do you really want to go to each host to edit a configuration file? I sure don't!

Cases Where Manual Configuration Is Not Feasible

The drudge work associated with manual configuration is significant, but the problems with

manual configuration go well beyond the inefficiency issue. There are situations where

manual configuration is not just inconvenient, it's actually impossible:

☯ Remote Configuration: An administrator cannot be everywhere; modern networks

can span cities or nations. Unless we want to train every user on how to configure

network hosts, we must use an automated protocol.

☯ Mobile Device Configuration: IP was designed when computers were large and

attached to each other using heavy cables; today we have computers that fit in a shirt

pocket and communicate using radio waves. IP addresses must be assigned based on

the network to which they are attached, and this makes reconfiguration required when

a device is moved. This is not conducive to manual configuration at all.

☯ “Dumb” Host Configuration: Most of the hosts we use today are full-fledged

computers, with their own internal storage. We can assign such a device an address

by entering it into a file that the device reads when it starts up. There are certain

devices, however, that do not include any form of storage. Since they are mass-

produced, they are all identical and cannot have individualized parameters stored

within them. Such a device relies on a configuration protocol to learn what it needs to

function on a network—especially including its individual identity, as we saw above.

☯ Address Sharing: The proliferation of devices attached to the global Internet has led

to a situation where IP addresses must be carefully managed to ensure that they are

not wasted on devices that aren't using them. Some organizations even find

themselves with more potential hosts than they have addresses. A host configuration

protocol can allow an address to be automatically assigned to a host when needed,

and then returned to a common “pool” for reuse when the host leaves the network.

This permits addresses to be shared and reduces the need for more address space.

Automating the Process: Host Configuration Protocols

Even though most of us don't have robots that can automate the hardware portions of the

setup and configuration job, we can employ tools that will make the rest of the job easier.

This includes the use of special host configuration protocols. These protocols allow hosts to

be automatically configured when they are set up, and to have additional parameters

assigned when needed.

Host configuration protocols generally function by having a host send a request for an

address and other parameters, which is satisfied by a response from a server. The infor-

mation in the response is used by the client to set its address, identify a local router, and

perform other necessary setup so it can communicate.

The use of an automated protocol solves all of the problem situations mentioned above. We

can configure devices remotely, rather than having to walk to each one. We can instantly

assign a valid address to mobile devices. We can have “dumb” hosts boot up and obtain the

information they need to operate. Finally, we can maintain a pool of addresses that is

shared by a group of hosts.

Key Concept: Host configuration protocols enable administrators to set up hosts so

that they can automatically determine their address and other key parameters. They

are useful not only because of the effort they save over manual configuration, but

because they enable the automatic setup of remote, storageless or mobile devices.

The Role of Host Configuration Protocols in TCP/IP

You might find it strange that host configuration protocols would exist up here in the “lofty

heights” of the application layer. It certainly sounds like host configuration is a function

related more to the network layer, where internetwork addresses such as IP addresses

function.

In fact, some host configuration protocols, like the rudimentary Reverse Address Resolution

Protocol (RARP), do exist down at that level. However, there are advantages to having host

configuration protocols reside at higher levels. A major one is that the operation of the

protocol is not dependent on the hardware upon which the protocol runs, making it more

universal. Another is being able to convey host configuration messages between networks,

which is not possible with a low-level protocol operating on the local network.

This leads to another fair question: how can a device send and receive messages if it

doesn't know its own address? As we'll see, the answer to this is the local broadcast

capabilities of networks. By broadcasting messages, it is possible for a device with no

assigned IP address to receive configuration information: including an IP address. We'll see

in the next section, discussing the Bootstrap Protocol (BOOTP), how this is done.

TCP/IP Bootstrap Protocol (BOOTP)

Before a device on a TCP/IP network can effectively communicate, it needs to know its IP

address. While a conventional network host can read this information from its internal disk,

some devices have no storage, and so do not have this luxury. They need help from

another device on the network to provide them with an IP address and other information

and/or software they need to become active IP hosts. This problem of getting a new

machine up and running is commonly called bootstrapping, and to provide this capability to

IP hosts, the TCP/IP Bootstrap Protocol (BOOTP) was created.

In this section I provide a fairly detailed look at the TCP/IP Bootstrap Protocol. I begin with

an overview and history of the protocol and a look at the standards that define it. I then

discuss the general client/server nature of BOOTP and how addressing is done in commu-

nication between the client and the server. I describe the operation of BOOTP step by step,

and illustrate the format of BOOTP messages. I conclude with a description of BOOTP

vendor extensions, which are used to allow the information sent in BOOTP messages to be

customized, and a discussion of BOOTP relay agents, which allow the protocol to operate

even when the BOOTP server and client are on different networks.

Related Information: BOOTP was the predecessor of the Dynamic Host Configu-

ration Protocol. DHCP was built to be substantially compatible with BOOTP and

so the two protocols have a fair degree of commonality. To avoid duplication,

certain information has been included only in the DHCP section, with links provided from

the BOOTP topics where appropriate. On the other hand, some of the historical background

information behind features like vendor information extensions and relay agents, which

were first developed for BOOTP and adopted by DHCP, is in this section and linked from

the DHCP topics. Why structure the sections this way? DHCP is far more popular than

BOOTP today, so I wanted its description to be complete, but some features only really

make sense if initially explained in the context of BOOTP’s operation.

If you plan to read about DHCP as well as BOOTP, I recommend reading this section first. If

you don't plan to read up on DHCP, you may wish to check the topic in the DHCP topic on

DHCP/BOOTP interoperability.

BOOTP Overview, History and Standards

The TCP/IP protocol suite has been with us for over two decades, and the problem of how

to automate the configuration of parameters on IP hosts has been around almost as long.

Back in the early 1980s, networks were small and relatively simple. Automated host config-

uration wasn't considered an important capability so much because of the difficulty of

manual configuration. It was needed because there is no other way to configure devices

like diskless workstations.

As I discussed in the overview topic on host configuration, without a form of internal

storage, a device must rely on someone or something to tell it “who it is” (its address) and

how to function each time it is powered up. When a device like this is turned on, it is in a

difficult position: it needs to use IP to communicate with another device that will tell it how to

communicate using IP! This process, called bootstrapping or booting, comes from an

analogy to a person “pulling himself up using his own bootstraps”. You've likely encountered

this term before, if at no other time then at least when some tech support person has told

you to “reboot” your computer.

BOOTP: Correcting the Weaknesses of RARP

The Reverse Address Resolution Protocol (RARP) was the first attempt to resolve this

“bootstrap problem”. Created in 1984, RARP is a direct adaptation of the low-level Address

Resolution Protocol (ARP) that binds IP addresses to link-layer hardware addresses. RARP

is capable of providing a diskless device with its IP address, using a simple client/server

exchange of a request and reply between a host and an RARP server.

The difficulty with RARP is that it has so many limitations. It operates at a fairly low level

using hardware broadcasts, so it requires adjustments for different hardware types. An

RARP server is also required on every physical network to respond to layer-two broadcasts.

Each RARP server must have address assignments manually provided by an administrator.

And perhaps worst of all, RARP only provides an IP address to a host and none of the other

information a host may need. (I describe these issues in detail in the topic on RARP.)

RARP clearly wasn't sufficient for the host configuration needs of TCP/IP. To support both

the needs of diskless hosts and other situations where the benefits of autoconfiguration

were required, the Bootstrap Protocol (BOOTP) was created. BOOTP was standardized in

RFC 951, published September 1985. This relatively straight-forward protocol was

designed specifically to address the shortcomings of RARP:

☯ It is still based on a client/server exchange, but is implemented as a higher-layer

software protocol, using UDP for message transport. It is not dependent on the

particular hardware of the network like RARP.

☯ It supports sending additional configuration information to a client beyond just an IP

address. This extra information can usually all be sent in one message for efficiency.

☯ It can handle having the client and server on different networks of an internetwork.

This allows the administration of the server providing IP addresses to be more

centralized, saving money as well as administrative time and hassle.

BOOTP Deals With the First Phase of Bootstrapping

It should be noted that even though the name of BOOTP implies that it defines everything

needed for a storageless device to “boot”, this isn't really the case. As the BOOTP standard

itself describes, “bootstrapping” generally requires two phases. In the first, the client is

provided with an address and other parameters. In the second, the client downloads

software, such as an operating system and drivers, that let it function on the network and

perform whatever tasks it is charged with. BOOTP really only deals with the first of these

phases: address assignment and configuration. The second is assumed to take place using

a simple file transfer protocol like the Trivial File Transfer Protocol (TFTP).

Key Concept: The first widely-used host configuration protocol for TCP/IP was the

Boot Protocol (BOOTP). It was created specifically to enable host configuration while

addressing many of the weaknesses of RARP. BOOTP is intended to be used as the

first phase of a two-phase boot procedure for storageless devices—after obtaining an IP

address and other configuration parameters using BOOTP, the device employs a protocol

such as TFTP to download software necessary to function on the network.

Vendor-Specific Parameters

One smart decision made when BOOTP was created was the inclusion of a vendor-specific

area. This was intended to provide a place where hardware vendors could define param-

eters relevant to their own products. As the complexity of TCP/IP increased, it was realized

that this field could be used to define a method of communicating certain parameters that

were commonly needed by IP hosts, and were in fact vendor-independent. This was first

proposed in RFC 1048, BOOTP Vendor Information Extensions, published February 1988.

The fact that BOOTP can be used to provide information to a client beyond just an IP

address makes it useful even in cases where a device already knows its address. BOOTP

can be used to send parameters that the administrator wants all hosts to have, to ensure

that they use the network in a consistent manner. Also, in the case of devices that do have

local storage (and therefore do not need BOOTP to get an IP address), BOOTP can still be

used to let these devices get the name of a boot file for the “phase two” of bootstrapping

described above.

Changes to BOOTP and the Development of DHCP

BOOTP was the TCP/IP host configuration of choice from the mid-1980s through the end of

the 1990s. The vendor extensions introduced in RFC 1048 were popular, and over the

years, additional vendor extensions were defined; RFC 1048 was replaced by RFCs 1084,

1395 and 1497 in succession. Some confusion also resulted over the years in how some

sections of RFC 951 should be interpreted, and how certain features of BOOTP work.

RFC 1542, Clarifications and Extensions for the Bootstrap Protocol

, was published in

October 1993 to address this, and also made some slight changes to the protocol's

operation. (RFC 1542 is actually a correction of the nearly-identical RFC 1532 that had

some small errors in it.)

While BOOTP was obviously quite successful, it also had certain weaknesses of its own.

One of the most important of these is lack of support for dynamic address assignment. The

need for dynamic assignment became much more pronounced when the Internet really

started to take off in the late 90s. This led directly to the development of the Dynamic Host

Configuration Protocol (DHCP).

While DHCP replaced BOOTP as the TCP/IP host configuration protocol of choice, it would

be inaccurate to say that BOOTP is “gone”. It is still used to this day in various networks.

Furthermore, DHCP was based directly on BOOTP, and they share many attributes,

including a common message format. BOOTP vendor extensions were used as the basis

for DHCP options, which work in the same way but include extra capabilities. In fact, the

successor to RFC 1497 is RFC 1533, which officially merges BOOTP vendor extensions

and BOOTP options into the same standard.

BOOTP Client/Server Messaging and Addressing

While BOOTP can be used for a variety of devices, one of the prime motives behind its

creation was to provide a way to automatically configure “dumb” devices that have no

storage. Most of these devices are relatively limited in their capabilities, and so requiring

them to support a fancy boot protocol would not make sense. BOOTP is thus an uncompli-

cated protocol, which accomplishes host configuration without a lot of fancy concepts or

implementation requirements.

BOOTP Clients and Servers

Like so many other TCP/IP protocols, BOOTP is client/server in nature. The operation of

the protocol consists of a single exchange of messages between a BOOTP client and a

BOOTP server. A BOOTP client can be any type of device that needs to be configured. A

BOOTP server is a network device that has been specially set up to respond to BOOTP

client requests, and has been programmed with addressing and other information it can

provide to clients when required.

The BOOTP server maintains a special set of information about the clients it serves. One

key part of this is a table that maps the hardware (layer two, data link layer) addresses of

each client to an assigned IP address for that device. The client specifies its hardware

address in its request, and the server uses that address to look up the client's IP address

and return it to the client. (Other techniques can also be used, but a mapping table is most

common.)

Messaging and Transport

BOOTP messaging uses the User Datagram Protocol (UDP) as its layer four transport

protocol, for a couple of reasons. First, UDP is a lot less complex than the other layer-four

transport protocol (TCP) and is ideal for simple “request/reply” protocols like BOOTP.

Second, since the client obviously doesn't know the address of a BOOTP server, the

request is broadcast on its local network; UDP supports broadcasts while TCP does not.

UDP uses a special well-known (reserved) port number for BOOTP servers: UDP port 67.

BOOTP servers “listen” on port 67 for these broadcast BOOTP requests sent by clients.

After processing the request, the server sends a reply back to the client. How this is

handled depends on whether the client knows its own address or not:

☯ Client Knows Its Address: There are some cases where the BOOTP client already

knows its own address. In this case, the address can be used by the BOOTP server to

send back its reply directly.

☯ Client Does Not Know Its Own Address: BOOTP is of course often used to provide

an IP address to a client that doesn't know its address. This is sometimes called a

“chicken and egg” problem, because it represents a “loop” of sorts like the old

conundrum of “which came first, the chicken or the egg”. To resolve this dilemma, the

BOOTP server has two choices. If the operating system supports it, the server can use

the client's hardware address to create an ARP entry for the device, and then use a

layer-two unicast to deliver the reply. Otherwise, it must send the reply as a broadcast

as well on the local network.

Use of Broadcasts and Ports

The fact that BOOTP servers may need to broadcast back to the client necessitates a bit of

a change from the way most TCP/IP protocols use client ports. Recall that normally, the

client in a client/server transaction using UDP or TCP generates a temporary, or ephemeral

port number that it uses as the source port in its request. The server sends the reply back to

the client's IP address using that ephemeral port number. Ephemeral port numbers must be

unique for a particular IP address, but may not necessarily be unique across all the devices

on a network. For example, device A may be using ephemeral port number 1,248 for an

HTTP request to a Web server, while device B may be using port number 1,248 on its TCP/

IP stack to send a DNS request.

Since the server in BOOTP is broadcasting, it is not targeting a particular device with a

unicast transmission. This means it cannot safely send to an ephemeral port number: some

other device on the network may have selected the same ephemeral port number for some

other transaction and may mistake the BOOTP server's response as being intended for

itself. To avoid this problem, another well-known port number is used just for BOOTP

clients: UDP port 68. Clients listen on this port for broadcast or unicast transmissions, while

of course devices that have not sent a BOOTP request will ignore it. This “dual broadcast”

BOOTP communication process is illustrated in Figure 254.

Key Concept: A BOOTP client use broadcasts to send its requests to any listening

BOOTP server. In most cases, the BOOTP client device does not know its own IP

address when it uses the protocol. For this reason, a BOOTP server will also

typically use broadcast in sending its reply, to be sure it reaches the client.

Retransmission of Lost Messages

The drawback of the simplicity of using UDP for BOOTP messaging is that we get no

transport quality features. UDP is unreliable, which means a BOOTP request might be lost

before it gets to the server, or the server's response may similarly not get back to the client.

Like many other protocols using UDP, BOOTP clients take care of this by using a retrans-

mission timer. If after a certain period of time the client has not received a response, it re-

sends its request.