Droms R. The DHCP handbook

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

CHAPTER 16 Client Identification and Fixed-Address Allocation276

Each of these ways of identifying a client has advantages and disadvantages, which

are discussed in the remainder of this section.

Using the dhcp-client-identifier Option

DHCP specifies the dhcp-client-identifier option, which is used to uniquely iden-

tify clients. DHCP clients are expected to send this identifier whenever they commu-

nicate with the server. DHCP allows a client to send this option when it first

contacts a server and requires that if it uses the option once, it must continue to use

it thereafter. If a client chooses to send this option, the server can use the data from

the option to differentiate between clients.

There are some problems with client identifiers. Although the protocol requires that

client identifiers be unique on any given network segment, no mechanism is defined

for ensuring that they actually are unique. RFC 2132 recommends that the DHCP

client identifier consist of a network hardware type and the client’s link-layer address

but permits it to have any value. Many DHCP clients allow users to configure the

client identifier themselves. If a user chooses an identifier that is already in use by

another client, a collision (that is, the use of the same identifier for two or more

different clients) can occur—and the DHCP server treats both clients as if they are

the same. DHCP provides no mechanism for preventing collisions. It is simply up to

the user to ensure that collisions do not occur.

PROBLEMS WITH USING THE LINK-LAYER ADDRESS AS A UNIQUE IDENTIFIER

Most DHCP clients follow RFC 2132’s recommendation with respect to choosing client identi-

fiers. Choosing a client identifier based on a link-layer address can have some negative conse-

quences, however. Consider a typical laptop computer with an Ethernet interface and an

802.11 wireless Ethernet interface; this is an increasingly common configuration because

many laptops come with built-in Ethernet cards and many laptop users want wireless service.

When this computer connects to the network using the wireless interface, the client identifier

is based on the wireless Ethernet adapter’s link-layer address. When the computer connects to

the network via the Ethernet interface, the Ethernet interface’s identifier is used.

This is a problem if the user of the laptop wants a consistent IP address, and it’s also a

problem for sites where the DHCP server is configured to update the DNS (see Chapter 11,

“DHCP–DNS Interaction”). Both the IP address assignment and the DNS information are

based on the client identifier. So when the computer connects to the network, it gets a differ-

ent IP address for its wireless interface than for its Ethernet interface. If the DHCP client or

server is doing DNS updates, the client is not able to have a consistent domain name.

Sites can avoid this problem by configuring their DHCP clients to send a client identifier that

is not based on the link-layer address. To do this, the user must manually configure a client

identifier. Unfortunately, Microsoft DHCP clients prior to Windows 2000 do not provide this

capability. To work around this missing feature, some sites have made nonstandard modifica-

tions to their DHCP servers, to use the host name option as a client identifier. These modifica-

tions are discussed in detail later in this chapter, in the section “Specifying Client Identification

in a DHCP Server.”

020 3273 CH16 10/3/02 4:58 PM Page 276

Example 16.1 shows how to specify the client identifier for a particular client, when

that client uses its network hardware type and link-layer address to construct the

dhcp-client-identifier option it sends. Most DHCP clients generate their client

identifiers from their link-layer addresses. In Example 16.1, the hardware type is 1,

for Ethernet, and the remaining six hexadecimal numbers following the 1 are the

Ethernet address.

Example 16.1

option dhcp-client-identifier 1:8:0:2b:4c:72:17;

Example 16.2 shows how to configure a DHCP server with a client identifier when

the client identifier is an ASCII text string. RFC 2132 recommends that clients that

send text strings as identifiers place an identifier byte with a value of zero in front of

the text string. In Example 16.2, the zero byte is specified with a special escape

sequence,

\0, in the string that defines the identifier. Not all DHCP clients follow

this convention, so you might have to try to configure the identifier with and

without the leading zero byte.

Example 16.2

option dhcp-client-identifier “\0joe’s computer”;

Using the Link-Layer Address as an Identifier

RFC 2131 does not require that the client send a dhcp-client-identifier option,

and some DHCP clients do not send the

dhcp-client-identifier option. When the

server does not find a

dhcp-client-identifier option in a request from a client, it

uses the client’s network hardware type and link-layer address instead.

Example 16.3 shows how you can configure a DHCP server with a client’s link-layer

address and network hardware type when the client is identified through its link-

layer address. For comparison, Example 16.3 illustrates the identification of the same

client as in Example 16.1.

Example 16.3

hardware ethernet 8:0:2b:4c:72:17;

Notice that in Example 16.1, the network hardware type is specified with the

number 1, but in Example 16.3, it is specified as the name of the type of network

hardware (

ethernet).

Identifying Clients 277

020 3273 CH16 10/3/02 4:58 PM Page 277

How the DHCP Server Identifies Clients

Because all clients send their link-layer addresses and network hardware types but

not all clients send a

dhcp-client-identifier option, the server must choose one of

the forms of identification. There are several schools of thought on how to handle

this. The ISC DHCP server simply records both identifiers but uses the client identi-

fier if it is there. The Microsoft DHCP server looks to see if there is a client identifier,

and if there is not, it makes one up, using the client’s link-layer address.

When a server initially allocates an address to the client, it creates an entry in its

database for the client. The entry includes the

dhcp-client-identifier option, if

supplied, and on the ISC server, it uses the link-layer address. If a lease is recorded

that has a link-layer address and a client identifier, the ISC server ignores the link-

layer address.

Because the DHCP server prefers the client identifier to the link-layer address, a

DHCP client can acquire more than one IP address.

This can happen when a user’s computer is configured to start up two or more differ-

ent operating systems, both of which obtain their IP addresses by using a DHCP

client. If both DHCP clients send the same identification information, the computer

has the same IP address, regardless of the operating system it is running. This can be

advantageous in some cases and disadvantageous in others.

Consider a system that is configured so that it can boot two operating sysems, such

as Linux and Windows 2000. When the system is running Linux, it is configured to

provide some network services, but those services are unavailable when the system

runs Windows. Some network services react badly if the server is reachable but refus-

ing connections. To avoid having this happen, you might want to arrange for the

Linux DHCP client to get a different IP address than the Windows 2000 DHCP client.

To prevent both DHCP clients from getting the same IP address, you configure either

the Linux or Windows 2000 client to send a different client identifier. For example, if

the computer uses the ISC DHCP client to get its IP address when it runs Linux, the

statement in Example 16.4 configures the Linux client with a different client identi-

fier.

Example 16.4

send dhcp-client-identifier “my-linux-box”;

Specifying Client Identification in a DHCP Server

The preceding section describes how to configure the DHCP clients so that the server

will allocate addresses dynamically and assign a different IP address, depending on

which operating system is running on the computer. However, if static address

CHAPTER 16 Client Identification and Fixed-Address Allocation278

020 3273 CH16 10/3/02 4:58 PM Page 278

allocation is performed, the network administrator must also configure the DHCP

server to work with the identification information that the user configured into the

DHCP clients.

The Microsoft DHCP client chooses a client identifier that consists of the network

hardware type followed by the link-layer address. If the link-layer address is

0:a0:4c:2b:e9:ac and the network hardware type is ethernet (that is, 1), and if the

Linux client is configured to send the text string

my-linux-box as its client identifier,

the two host declarations given in Example 16.5 match the Windows and Linux

clients, respectively.

Example 16.5

host ardmore-win2k {

option dhcp-client-identifier 1:a0:4c:2b:e9:ac;

}

host ardmore-linux {

option dhcp-client-identifier “my-linux-box”;

}

Problems that occur when DHCP users choose their own client identifiers are

discussed in the next section.

NONSTANDARD MEANS OF IDENTIFYING CLIENTS

Administrators at a number of sites have decided that neither the link-layer address nor the

client identifier option is a viable way of identifying clients. Instead, they have chosen to

implement nonstandard solutions based on the known behavior of the Microsoft DHCP

clients.

Users cannot easily configure Microsoft DHCP clients to send a client identifier other than one

formed from the link-layer address. Microsoft DHCP clients do send a host name option (that

is, 12) in every request, however, and users can configure this easily, by using the

Identification section of the Network Setup dialog box.

To avoid collisions, the host name the user supplies must be unique on networks on which the

client is used. As with the client identifier, no protocol exists to ensure that the name chosen

is unique—it is necessary to trust the user to arrange for this.

Some sites that use nonstandard client identification use the host name the client supplies in

preference to the client identifier. This involves customizing the DHCP server. Several sites

have customized the ISC DHCP server in this way.

This does to some extent solve the problem described earlier, in which a laptop has one wired

and one wireless network interface. However, it works only with Microsoft DHCP clients;

clients that do not send a host name option are identified by their client identifier or possibly

not at all. In addition, with nonstandard identification methods, the potential for client name

collisions can be a major problem.

Identifying Clients 279

020 3273 CH16 10/3/02 4:58 PM Page 279

Client Identification Name Collisions

As previously discussed, two clients can have the same identification. If the identifi-

cation is a user-supplied text string (for example, a host name), a collision occurs

when two users choose the same name. For example, if The Lord of the Rings has a lot

of fans at any given site, several users might choose the name

gandalf for their

computers.

Using the client’s link-layer address as an identifier mitigates this name collision

problem; link-layer addresses are usually guaranteed to be unique, at least to a partic-

ular machine, if not to a particular network interface. Even if the link-layer address is

used, however, it is possible to run into trouble because you can change the link-

layer address on many network adapters. For instance, an Ethernet adapter that was

widely used at a particular site had a device driver bug that caused its link-layer

address to reset to all zeros. Whenever two cards entered this state at the same time,

serious confusion ensued.

When a collision occurs between the identification of two clients, the DHCP server

thinks the two different clients are a single client. If one client is connected to the

network and sends a

DHCPDISCOVER message with its identification, gandalf, the

DHCP server allocates an address (for example, 10.240.17.7) and sends a

DHCPOFFER

message, to which the client responds with a DHCPREQUEST message. The server then

sends a

DHCPACK message, and the client begins using its new address.

However, if a different client with the same identification tries to obtain an

address—by sending a

DHCPDISCOVER message with its identification gandalf—the

DHCP server looks up

gandalf, finds an entry for the first client that started up with

that identifier, and, not knowing any better, sends a

DHCPOFFER message with the

same address, 10.240.17.7. The client accepts the address, binds to it, and begins

using it, at which point both clients receive packets intended for each other, and the

users of the two computers begin experiencing seemingly random unreliability in

their network service.

When two DHCP clients are accidentally configured with the same client identifier,

you see one of two symptoms. Either you see the same two clients being assigned the

same IP address, or you see that two clients are always associated with abandoned

leases or

DHCPDECLINE messages. If you see these symptoms, look at the lease entries

for both DHCP clients. If they show the same client identifier, you need to configure

one of the clients so that it has a different client identifier.

Static Allocation

Now that you know how the DHCP server identifies clients and how you can iden-

tify clients to it, it is time to discuss static IP address allocation. (The Microsoft

DHCP server uses the term reservation instead of static IP address allocation.)

CHAPTER 16 Client Identification and Fixed-Address Allocation280

020 3273 CH16 10/3/02 4:58 PM Page 280

In static allocation with DHCP, the server administrator maintains a list of known

DHCP client identification information and assigns an IP address (or possibly more

than one IP address, if the client can roam from network to network) for each client

thus identified. Static IP address assignments are not permanent; the server leases the

IP address to the client for a limited time, which the network administrator can

specify. Chapter 19, “Tuning a DHCP Service,” discusses the use of static IP address

assignment in detail.

Completely static address allocation is surprisingly prevalent, considering how much

work it involves. The most common reason people give when asked why they use

static IP address allocation is that the network administrator (or, often, management)

at a site wants to control which clients have access to the network; this can seem

natural at sites that perform static IP address allocation without the help of a DHCP

server. Switching to the DHCP server can save quite a bit of work, even though the

protocol’s full labor-saving capabilities are still not exploited.

When a client tries to obtain a lease, the DHCP server looks it up in the list of clients

the administrator provides. If the server finds an entry for the client, it sees whether

any of the IP addresses reserved for the client are appropriate for the network to

which the client is connected. If it finds an appropriate address, it assigns it to the

client.

If you have configured the DHCP server to perform only static address assignment

and the server does not find an appropriate address for the client, it simply does not

respond to the client’s requests. Exceptions do exist, however; if the client sends a

DHCPREQUEST message for an address that the server knows is invalid for the network

segment to which the client is connected, the server always responds with a

DHCPNAK

message. The server also sends a DHCPNAK message if the requested address is known

to the DHCP server and is not available for the client. If the server finds an appropri-

ate address for the client, it offers that address to the client.

Mixing Static and Dynamic Allocation

It is common for a site to define fixed IP addresses for its DHCP clients that are not

mobile or that are otherwise known to the network administrator and still enable

dynamic addressing for clients that are mobile or that are not known to the network

administrator. To allow dynamic address assignment for other clients on a subnet

with static allocations for some clients, the network administrator simply supplies a

range of IP addresses in each subnet declaration for subnets on which IP addresses

will be allocated.

Chapter 3, “Configuring the DHCP Server,” describes the internal network at Generic

Startup, Inc. (GSI). The DHCP server for the network was configured with a pool of

available addresses for each subnet. Example 16.6 shows the configuration file for

Mixing Static and Dynamic Allocation 281

020 3273 CH16 10/3/02 4:58 PM Page 281

the server subnet, with two static allocation definitions for the DHCP and DNS

servers on that subnet. With those definitions in place, the computers on which the

DHCP and DNS servers run can use DHCP and be guaranteed to receive a consistent,

well-known IP address.

Example 16.6

# Server subnet

subnet 192.168.11.0 netmask 255.255.255.0 {

range 192.168.11.1 192.168.11.251;

# 192.168.11.252 reserved for DHCP server

# 192.168.11.253 reserved for DNS server

# 192.168.11.254 reserved for router interface

option routers 192.168.11.254;

option subnet-mask 255.255.255.0;

option domain-name-servers 192.168.11.253;

}

host dhcp-server.genericstartup.com {

fixed-address 192.168.11.252;

hardware ethernet 00:20:78:11:F9:14;

}

host dns-server.generic-startup.com {

fixed-address 192.168.11.253;

hardware ethernet 00:C0:6D:16:68:A2;

}

When a client broadcasts a DHCPDISCOVER packet on the server subnet, the DHCP

server there first tries to match the client identification information to one of the

host entries defined in the configuration file in Example 16.6. If the client’s identifi-

cation matches one of these entries, the DHCP server uses that entry to determine

what address to send to the client.

If the client’s identification does not match one of these entries, the DHCP server

allocates an IP address from the list of available leases on the network and offers that

IP address to the client.

Moving a Client from Dynamic to Static Address Allocation

Some sites may want to register clients by enabling them to obtain dynamic leases,

extracting the client identification information from the lease database, and creating

a static address allocation for each client. This chapter uses a simple case to describe

how to convert a client from dynamic to static allocation by simply hand-editing the

configuration file.

CHAPTER 16 Client Identification and Fixed-Address Allocation282

020 3273 CH16 10/3/02 4:58 PM Page 282

The ISC DHCP server stores leases in an unstructured text file that provides a history

of all lease assignments during server operation.

Each lease is stored as a

lease statement, and the last lease statement in the file for

any given IP address is the most current lease for that IP address. Consider what

happens when an employee of GSI buys a new computer and plugs it in to the

network for the first time. When the computer receives an address, the lease is

logged in the

dhcpd.leases file. (Chapter 14 explains how to find out where the ISC

DHCP server stores the

dhcpd.leases file.) Example 16.7 shows what the client’s

lease statement might look like.

Example 16.7

lease 192.168.11.11 {

starts 3 1999/03/10 00:34:38;

ends 3 1999/03/10 00:40:38;

hardware ethernet 08:00:2b:81:65:56;

uid “ntp-server”;

}

In a lease statement, the dhcp-client-identifier option is stored by using the uid

keyword. In Example 16.7, the DHCP client sends a client identifier option that is

not derived from the client’s link-layer address. The network administrator wants to

turn this

lease statement into a fixed allocation, so she writes a host declaration

such as the one in Example 16.8.

Example 16.8

host ntp-server.genericstartup.com {

option dhcp-client-identifier “ntp-server”;

fixed-address 192.168.11.11;

}

Notice that the network administrator does not include a hardware statement

because the

dhcp-client-identifier option statement supersedes it. The client

identifier that the client sent is an ASCII text string, and the network administrator

can enter it into the

host declaration either as a text string or as a list of hexadeci-

mal numbers.

The network administrator could have followed his usual policy of using the link-

layer address as a client identifier. In this case, because the

client identifier

option always supersedes the hardware statement, she would have to delete the

client’s lease from the lease database file. Example 16.9 shows what the

host declara-

tion looks like when it uses the

hardware statement.

Mixing Static and Dynamic Allocation 283

020 3273 CH16 10/3/02 4:58 PM Page 283

Example 16.9

host ntp-server.genericstartup.com {

hardware ethernet 08:00:2b:81:65:56;

fixed-address 10.152.204.75;

}

After the static entry for a host is set up, the DHCP server must be told about the

new information. Normally, you do this by terminating the DHCP server process and

restarting it. When the server restarts, it rereads the

dhcpd.conf file, and the

dhcpd.leases file and picks up the new host declaration. If the dhcpd.leases file

must be modified, you should stop the server before it is modified and not restart it

until the modification is complete.

At some point after the DHCP server reads the host declaration for the client, the

DHCP client will attempt to renew its lease. Remember that although the server was

told about the client’s fixed address, the client is still unaware that anything has

changed. So it sends a

DHCPREQUEST message to the server, asking for the renewal of

its old dynamically assigned address.

When the ISC DHCP server finds the host declaration for the client, it assumes that

the declared IP address is the one that the network administrator wants the client to

have. Therefore, it does not renew the client’s lease. Indeed, if it can, it sends a

DHCPNAK message, forcing the DHCP client to immediately try to obtain a new IP

address. If it cannot, the client runs to the end of its lease without getting a renewal.

After the lease expires, the client automatically obtains the new IP address.

No matter how the client gets to the

INIT (reinitializing) state, it broadcasts a

DHCPDISCOVER packet. The server looks for a matching host entry, finds it, and sends

the fixed IP address in that entry to the client, at which point the client has its

permanent address.

Converting a DHCP Server from Static to Dynamic Allocation

The ISC DHCP server assumes that statically allocated IP addresses are allocated

permanently, so it doesn’t actually record lease entries for such addresses. Instead, it

assumes that the static entry will be available the next time the client contacts the

server—when it must renew the lease. This can cause problems for sites that decide

they want to convert from static to dynamic address allocation.

People report two common problems in performing such a conversion:

•Moving formerly fixed addresses into a dynamic pool

•Getting clients to take dynamic address allocations after their static allocations

are deleted

CHAPTER 16 Client Identification and Fixed-Address Allocation284

020 3273 CH16 10/3/02 4:58 PM Page 284

Problems Moving Static Addresses to a Dynamic Pool

When you move statically assigned IP addresses into a dynamic pool, the server does

not know when statically assigned leases expire. When you delete the static assign-

ment from the server’s configuration file, it forgets that assignment existed. The

client, on the other hand, is probably still using the address. Therefore, there is

always a period of time when the client thinks it is entitled to use its static IP address

but the server is not aware of it.

It is not a problem if the client extends the lease on its address before the server tries

to assign it to another client. However, if the server tries to allocate the lease to

another client before the old client renews its lease, the server will most likely

abandon the lease. At a minimum, this generates an unexpected warning message to

the server administrator. In a worst-case scenario, one or both clients might have

trouble using the network until the conflict is resolved.

The easiest way to avoid this conflict is to remove the static IP address assignment

but not put that address back into the pool for allocation until you are certain that

any lease the client is holding has expired. After you are certain that the client lease

has expired, you can add the address to the pool of available addresses. You can

configure a default maximum lease length into the DHCP server; if you do not do

this, the default is one day on the ISC DHCP server and three days on the Microsoft

server. After you remove the entry, you can simply wait for that amount of time

before reusing that IP address. Of course, you can also contact the owner of the

machine and ask him or her to release the lease.

Problems Getting a Client to Accept a New Address

Some older DHCP clients do not accept a different address than the one they are

bound to unless the DHCP server tells them that the address they have is no longer

valid, by sending them a

DHCPNAK message. If the static IP address allocation is

deleted for a client, the server simply ignores renewal requests from the client until

the client goes back into the

INIT state, at which point the server offers the client a

new IP address. The client does not take this new address because it wants the old

address and has not received a

DHCPNAK message. Thus, it continues to send DHCPDIS-

COVER messages indefinitely.

The ISC DHCP server sends a DHCPNAK message to a client, trying to get an address

that belongs to a different client. To create a situation in which

DHCPNAK messages are

generated, you might want to modify the client identification information on static

assignments you are converting so that the identification does not match a real

client. When a client whose static assignment is doctored in this way tries to renew

its lease, the server sends it a

DHCPNAK message, at which point it always gives up that

IP address and returns to the

INIT state.

Mixing Static and Dynamic Allocation 285

020 3273 CH16 10/3/02 4:58 PM Page 285