Droms R. The DHCP handbook

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

process is complete, the client chooses the lease that was acquired most recently and

enters the

INIT-REBOOT state. In this state, the client broadcasts a DHCPREQUEST

message to ensure that the address in the selected lease is still valid for the network

segment to which the host is connected. If the client gets no response, it re-sends

the

DHCPREQUEST message. If the client receives no response after a certain period of

time elapses, it tries to use the IP address in the lease.

When they fail to confirm their lease during the

INIT-REBOOT state, most DHCP

clients simply use the IP address they tried to confirm. If the ISC DHCP client fails to

confirm its lease by using a broadcast

DHCPREQUEST message, it tries to confirm that

the address is appropriate for the subnet to which it is attached. It does this by

configuring its network connection with that address and sending an ICMP echo

request to its default router. If it gets a response, it uses the old address; otherwise, it

tries to determine whether any of the other unexpired addresses work on the current

subnet. If the client can’t contact the default router with any of its unexpired

addresses, the client reverts to the

TIMEOUT state.

As DHCP is specified in RFC 2131, a client is expected to start in the INIT state if it

has no unexpired leases. Many clients implement this behavior and immediately

broadcast a

DHCPDISCOVER message when starting with no unexpired leases. Some

implementors have interpreted the text in RFC 2131 to permit a client to first try to

renew an expired lease and then revert to the

INIT state if the renewal fails. This

behavior is widely agreed to be incorrect, but some older clients do operate this way.

If the ISC client receives no response to its broadcast message in the

INIT state, it

continues retransmitting

DHCPDISCOVER messages for some configurable period of

time (usually 60 seconds). If it doesn’t find a valid lease within that time period, it

reverts to the

TIMEOUT state.

When the Client Fails to Get an Address

The TIMEOUT state mentioned in the preceding section is not included in the protocol

specification, but many DHCP client implementors added it (or something like it) to

their state machines. The purpose of the

TIMEOUT state is to enable the client to “give

up” and notify the user in some way that it failed to acquire an IP address.

When the ISC DHCP client is started, it runs in the foreground until it has either

found an IP address or entered the

TIMEOUT state. This enables daemons that are

started after the client is started to assume that the network is configured before they

begin, but it prevents the client from holding up the system startup indefinitely.

After the purpose of the

TIMEOUT state is fulfilled, the client waits for a configurable

interval and then reverts to the

INIT state.

If the Microsoft or Apple DHCP client reaches the TIMEOUT state, it uses Automated

Private IP Addressing (APIPA) to assign an address to the interface that is being

configured. When using APIPA, the DHCP client chooses an IP address out of the

CHAPTER 21 DHCP Clients356

025 3273 CH21 10/3/02 4:57 PM Page 356

65,534 possible IP addresses in the 169.254.0.0/16 subnet. It then sends an ARP

request to see whether the address is in use; if the address is in use, the client

chooses a different address from the same subnet at random. It continues to do this

until it finds an address that isn’t in use, and then it configures that address. After

the client selects an APIPA address, it periodically attempts to use DHCP to get an IP

address. If it finally contacts a DHCP server, it stops using the autoconfigured IP

address.

NOTE

IANA has reserved the 169.254.0.0/16 subnet for host autoconfiguration. APIPA is one

example of an autoconfiguration mechanism that uses the 169.254.0.0/16 subnet.

Autoconfiguration addresses are restricted in scope to a single physical network; routers are

never allowed to forward IP datagrams with a source address from the 169.254.0.0/16 subnet

to a different network. Autoconfiguration addresses are intended to automate IP address

assignment without coordination by a central authority such as a network administrator in a

network with no DHCP server.

Using an IP Address After It Is Acquired

After the DHCP client acquires an IP address, it enters the BOUND state. When the

client initially enters this state, it configures the network interface with the new IP

address. If the server provides a default route, the client installs that route. The ISC

DHCP client also uses the

domain-name option (if the server provides one) and the

domain-name-servers option to create an /etc/resolv.conf file. This is a standard

configuration file on most Unix and Unix-like systems that is used to configure

domain name service.

In addition to configuring the network interface, when the DHCP client enters the

BOUND state, it also makes a persistent record in a disk file of the lease it acquired.

This record includes any DHCP options the server sends; you can use that lease

information later if the client is restarted.

Maintaining a Lease on an IP Address

After the DHCP client acquires a lease, it must maintain it. When half of the dura-

tion of the lease expires, the client enters the

RENEWING state. In this state, it periodi-

cally unicasts a

DHCPREQUEST message to the server that assigned it its lease,

requesting an extension. If it gets a response to this request that extends its lease, it

reenters the

BOUND state until half of the duration of the new lease once again

expires. The client need not reconfigure the network interface when it renews its

lease, but it does make use of any changes in the options that the server sends—for

example, the default route and the DNS configuration. The new lease is also recorded

on disk for later use.

The Theory of DHCP Client Operation 357

025 3273 CH21 10/3/02 4:57 PM Page 357

NOTE

Some older DHCP clients do not notice changes to parameters in DHCPACK messages when

they are in the RENEWING state. This is not correct behavior, but if you are having trouble

getting a DHCP client to obtain new configuration parameters, it might have this problem.

Telling the client to release and then renew its lease often clears up the problem, although in

some very old DHCP clients, even that does not work; in some versions of Windows 95, you

actually have to reinstall TCP/IP in order to clear out the old parameters.

If seven-eighths of the lease time expires and the client still receives no response, the

client enters the

REBINDING state and begins broadcasting DHCPREQUEST messages to

locate some other DHCP server that will renew its lease. If it receives a

DHCPACK

message in the REBINDING state, the client handles the DHCPACK message just as it

would in the

RENEWING state.

When the Lease Expires

If for some reason the client is unable to renew its lease before the entire duration of

the lease expires, the client must stop using the IP address it has leased. The client

deletes the IP address from its interface configuration and goes back to the

INIT state

to try to get a new address.

Multiple Network Interfaces

The discussion in the preceding sections assumes that the client can operate on only

one network interface. This is not far from the truth; if more than one network inter-

face must be configured, the DHCP client program sets up a separate state machine

for each interface. These state machines operate independently from one another;

one interface can be in the

BOUND state, while another interface is in the INIT state,

for example.

As far as IP address configurations go, this state of affairs works perfectly well; each

interface is configured with an IP address as soon as a server provides one.

Unfortunately, with respect to DHCP options, if two interfaces get different configu-

rations, no standard mechanism exists that says how a client should decide which

set of options to use. For options that are specific to an interface, such as a subnet

mask, this is not a problem, but for other options, such as the

routers option and

the

domain-name-servers option, there simply is no way to choose. Most DHCP

clients simply use the value they received most recently. MacOS 9 solves this

problem by not permitting you to use two interfaces at the same time.

More Than One IP Address Per Interface

Occasionally, users ask for a mechanism for obtaining more than one IP address for a

single network interface. The ISC DHCP client included in Version 3.0 of the ISC

CHAPTER 21 DHCP Clients358

025 3273 CH21 10/3/02 4:57 PM Page 358

DHCP distribution supports this capability. A pseudo-interface can be declared and

associated with a real interface, and the DHCP client allocates a separate state

machine for that pseudo-interface.

You must give the pseudo-interface a different DHCP client identifier than is sent for

the primary interface, or the DHCP server cannot differentiate between the two

requests, and it assigns the same IP address to both interfaces. The standard DHCP

client does not provide any way to actually use the second IP address.

The Microsoft DHCP Client

Microsoft has included a DHCP client with Windows since it released Windows for

Workgroups. DHCP clients are included with Windows 98, Windows 2000, and

Windows XP. All these DHCP clients are quite similar to each other. This section

describes the Microsoft DHCP client and points out the differences among the

various implementations. More information on the Microsoft DHCP client is avail-

able in Chapter 4, “Dynamic Host Configuration Protocol,” of The Microsoft Windows

2000 Server TCP/IP Core Networking Guide, which can be found on the Microsoft Web

site,

www.microsoft.com.

Installing and Enabling the Microsoft DHCP Client

The DHCP client in Microsoft Windows is part of the IP protocol suite. Windows 98

and Windows 2000 may not automatically install the IP protocol suite. Depending

on your system configuration, you might need to install it yourself. In some versions

of Windows, you do not need to install the IP protocol suite; it is installed automati-

cally.

To use the DHCP client in Windows 98, you must install IP networking. You can do

this by right-clicking the Network Neighborhood icon on the Windows desktop and

selecting Properties. Windows then displays the Network dialog box. If you select the

Configuration tab, you see a window within the dialog box that lists a series of

protocols and the network interfaces to which these protocols are bound. If the

TCP/IP protocol is already bound to the interface you intend to use, you don’t need

to install it again. If it is not, click Add.

Windows 98 then displays the Select Network Component Type dialog box. Click the

line that reads Protocol, and then click the Add button. This opens the Select

Network Protocol dialog box, which contains two windows: The one on the left

displays a list of manufacturers, and the one on the right displays a list of protocols.

The manufacturer for the TCP/IP protocol is Microsoft; if you click Microsoft in the

left window, you should see TCP/IP as one of the choices in the right window. You

can click TCP/IP, and then click OK to install it. Windows might prompt you to

insert a floppy disk or CD-ROM from which it can install the TCP/IP software.

The Microsoft DHCP Client 359

025 3273 CH21 10/3/02 4:57 PM Page 359

Figure 21.1 shows the Network dialog box, the Select Network Component Type

dialog box, and the Select Network Protocol dialog box, as they look if you follow

the instructions in this section to the point just before you click OK.

CHAPTER 21 DHCP Clients360

FIGURE 21.1 Dialog boxes used when installing TCP/IP on Windows 98.

After you install TCP/IP protocol support, you can configure it by selecting a TCP/IP

binding from the Network dialog box; you should select the binding for the network

card on which you want to enable DHCP. Then click Properties. Windows will then

display the TCP/IP Properties dialog box. Select the IP Address tab, as shown in

Figure 21.2, and click the radio button Obtain an IP Address Automatically to enable

DHCP.

You can configure the Windows 98 DHCP client to obtain its IP address from DHCP

but still use a statically configured DNS configuration. If you do not want it to do

this, you should go back to the TCP/IP Properties dialog box and select the DNS

Configuration tab. Then click the Disable DNS radio button. If DNS is enabled, even

if you didn’t provide configuration information, Windows 98 does not use the DNS

configuration that the DHCP server provides.

025 3273 CH21 10/3/02 4:57 PM Page 360

FIGURE 21.2 The TCP/IP Properties dialog box.

The Microsoft DHCP Client on Windows 2000

To install TCP/IP in Windows 2000, first open the connection configuration dialog

box. Select Start and then click Settings. Then select Network and Dial-up

Connections. Select the connection (usually Local Area Network) from the Network

and Dial-up Connections entry. Click the Properties button to display the current

protocols installed on the interface, and then click Install to install TCP/IP (see

Figure 21.3).

The Microsoft DHCP Client 361

FIGURE 21.3 The Windows 2000 TCP/IP Installation dialog box.

025 3273 CH21 10/3/02 4:57 PM Page 361

After you install the TCP/IP software, you can select the Internet Protocol (TCP/IP)

entry from the Properties dialog box and click Properties. To enable DHCP, click

Obtain an IP Address Automatically, as shown in Figure 21.4.

CHAPTER 21 DHCP Clients362

FIGURE 21.4 The Windows 2000 TCP/IP Properties dialog box.

The Windows DHCP Client User Interface

The Microsoft Windows DHCP client for Windows 95, Windows 98, and Windows

Me has a user interface program called

winipcfg. To use winipcfg, choose Start, click

Run, and then type

winipcfg in the Open dialog box and click OK.

winipcfg then pops up its own dialog box, displaying the status of the DHCP client.

To see the complete status, click the More Info button. Figure 21.4 shows

winipcfg

after More Info has been selected.

FIGURE 21.5 The winipcfg dialog box.

025 3273 CH21 10/3/02 4:57 PM Page 362

You can use the winipcfg dialog box to see what options the DHCP server sends, to

see what IP address the server provides, and to display various other details of the

DHCP client’s state. If the client is configuring more than one network adapter, you

can change the adapter whose state is being displayed or affected by selecting the

network adapter from the drop-down list box below the Ethernet Adapter

Information label.

You can also use

winipcfg to release and renew the DHCP client’s lease; to release

the lease, click the Release button or the Release All button. To renew the lease, click

the Renew button or the Renew All button. Release and Renew affect only the

configuration for the network interface whose state is currently displayed, whereas

Release All and Renew All affect the state of all network adapters.

Behavior Specific to the Microsoft DHCP Client

This section describes some of the unique behavior of the Microsoft DHCP client.

Although this behavior is, by and large, unique to the Microsoft DHCP client, these

differences are due to interpretation of the protocol specification. Nothing that the

Microsoft DHCP client does that is documented here is specifically forbidden by the

protocol specification.

Use of the

host-name Option

The DHCP protocol standard, and indeed the documentation for many DHCP

servers, leads you to believe that if you define a

host-name option for a particular

DHCP client, that client will use the defined

host-name option. Unfortunately, the

Microsoft DHCP client does not use the

host-name option in this way. Indeed, it

ignores the

host-name option in any DHCP packets it receives.

Instead, it uses the host-name option to tell the DHCP server what it thinks its name

is. It does this by sending its NBNS name in the

host-name option whenever it sends

DHCPDISCOVER or DHCPREQUEST message. Some DHCP servers take advantage of this

by using the NBNS name to do a DNS update. Also, as mentioned in Chapter 16,

“Client Identification and Fixed-Address Allocation,” you can configure some DHCP

servers to use the NBNS_name as a client identifier. Some problems occur with this,

but to understand them, you must know a bit about NBNS.

Microsoft historically has used NBNS, also known as WINS, to name Windows

network clients. NBNS is a distributed naming protocol that can function over IPX or

IP and can operate whether or not a centralized NBNS server is present. If no central-

ized NBNS server is present, the protocol operates by broadcasting NBNS queries to

the network and waiting for responses. NBNS is in the same class of protocol as Sun’s

Network Information Services protocol; it is easy to manage, and therefore advanta-

geous, on a small network, but it does not scale for use throughout the Internet.

The Microsoft DHCP Client 363

025 3273 CH21 10/3/02 4:57 PM Page 363

When Microsoft Windows is first installed, one of the questions it asks the person

installing it is the name of the system. This question is mandatory; you can’t finish

the installation without answering it. People tend to answer the question in a variety

of ways; if an individual is installing a single Windows workstation, he or she might

give it a name such as TEDSPC or SNEECH. A systems administrator who is installing

large numbers of Windows machines might have a standard way of choosing the

name of the PC—either the name of the person to whom it is delivered, or by using

some counting scheme, such as PC001, PC002, and so on. You can determine the

NBNS name of a Windows machine by right-clicking the Network Neighborhood

icon, selecting Properties from the menu, and then selecting the Identification tab,

as shown in Figure 21.5.

CHAPTER 21 DHCP Clients364

FIGURE 21.6 Finding the NBNS name of a Windows computer.

When the Windows machine first becomes active on the network, it uses the NBNS

protocol to ensure that its name is unique within its workgroup. If an NBNS server

is serving the administrative domain in which the workstation is installed, this

process succeeds; if the user chooses a name that is in use by some other user in the

same workgroup, Windows chooses a different name. If no NBNS server exists, you

cannot ensure that the name is unique. Note also that NBNS only ensures that a

name is unique within a workgroup, so if you have more than one active workgroup

on your network, the NBNS name alone is not guaranteed to be unique.

025 3273 CH21 10/3/02 4:57 PM Page 364

NOTE

You can control whether a client broadcasts WINS requests by configuring the DHCP server to

send a netbios-node-type option to indicate whether Windows should broadcast or contact

a WINS server. You can also configure the DHCP server to send the netbios-name-servers

option, which indicates which NBNS servers the DHCP client machine should use. Because a

response from the DHCP server can affect the conflict resolution process, the DHCP server

cannot assume that NBNS has checked the hostname for uniqueness before the DHCP client

starts.

As a consequence, although it would be handy to be able to count on the unique-

ness of the name that the Microsoft DHCP client sends in the

host-name option, it is

not possible to do so. If a DHCP server is going to use this name as a unique identi-

fier, this may result in an identifier conflict, as described in Chapter 14. If a DHCP

server wants to update the DNS server by using the

host-name option sent by the

Microsoft client, it must perform its own conflict resolution process prior to doing

so, and it must ensure that the name is not already claimed by some other client.

The Client Identifier Option

The Microsoft DHCP client does not provide a user interface with which the user can

choose the client identifier that it sends. Instead, it uses the format suggested in RFC

2132: The client identifier is a series of bytes beginning with a single byte containing

the network hardware type, followed by the link-layer address of the network inter-

face that the DHCP client is configuring.

The

DHCPINFORM Message

Some Windows applications may need information from the DHCP server that is not

requested or sent when the DHCP client acquires its lease. In that case, the applica-

tion can send a

DHCPINFORM message, requesting further information. For this reason,

recent versions of Windows frequently generate

DHCPINFORM requests, and it’s helpful

to have a DHCP server that supports

DHCPINFORM.

The dhcpcd DHCP Client

Yoichi Hariguchi of Fore Systems and Sergei Viznyuk of PhysTech have developed the

dhcpcd DHCP client for Unix and Unix-like operating systems. dhcpcd is a general-

purpose DHCP client that implements all the messages in RFC 2131 and many of the

options in RFC 2131.

dhcpcd passes configuration information through a file in the dhcpcd directory that

can be processed by a shell interpreter to set environment variables. System configu-

ration programs and other applications can look at the values of the environment

variables to get the configuration information obtained by dhcpcd.

The dhcpcd DHCP Client 365

025 3273 CH21 10/3/02 4:57 PM Page 365