Droms R. The DHCP handbook

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

NOTE

To protect against misconfiguration by naive users, the ISC DHCP server does not send

DHCPNAK messages to DHCP clients that send DHCPREQUEST messages for IP addresses on the

wrong network unless it is positively configured to do so, using the authoritative option.

The Microsoft DHCP server should always send a DHCPNAK message in this situation, so this

isn’t a problem for installations in which the Microsoft server is used. If you are using the ISC

DHCP server, you should make sure to include authoritative; at the top of the configura-

tion file.

Incorrect Option Values

Sometimes a client receives incorrect option values from the server when it gets a

lease for an IP address. Most frequently, this is the result of a configuration error in

the server and the association of the various option values with the different subnets

and DHCP clients.

If the server doesn’t provide some way to report the option values that it sends, you

can use a network analyzer to display the option values in the DHCP messages and

diagnose the problem. The DHCP client may also send a

parameter request list

option, specifying the parameters it is expecting. The treatment of this list varies

from server to server, and the server and client may not always agree on what this

list means. In such a situation, the server might not send the client all the options

that it needs in order to operate.

If you use a network analyzer and determine that the server is not sending all

the options that the client is requesting, you might have to override the DHCP

parameter-request-list option on the server.

The Uniqueness of Client Identifiers

For DHCP to operate correctly, DHCP client identifiers must be unique within each

administrative domain. If two clients choose the same client identifier, the server

cannot differentiate between the two clients. In many cases, the user does not have

control over the identifier the DHCP client chooses to send. In many of those cases,

the client identifier is based in some way on the client’s link-layer address, which

should guarantee uniqueness.

However, for cases in which the user can configure the client identifier, it is impor-

tant that he or she be very sure that it is unique because it is the identity, or key,

that the DHCP server uses to tell one client from another. This problem is discussed

in detail in Chapter 16.

CHAPTER 24 Debugging Problems with DHCP426

028 3273 CH24 10/3/02 4:57 PM Page 426

Dual-Boot Client Systems

A dual-boot client system is a computer on which a user is switching between two

different operating systems. For example, you might have an Intel-based system with

a partitioned disk that has Windows loaded in one partition and Linux loaded in

another partition. You can choose which operating system to use when the system

first starts up. Because the two operating systems are completely independent of one

another, they use two separate DHCP clients, each with its own state.

In some cases, those two different operating systems generate an identical client

identifier (typically from the link-layer address); the DHCP server is then unable to

distinguish one operating system from the other. Each operating system may,

however, have a different expiration time for the lease, even though they share the

same IP address.

Sometimes the operating systems on dual-boot systems have different DHCP client

identifiers. Most commonly, one operating system generates a client identifier from

the link-layer address and the other does not use a client identifier at all. In this case,

many DHCP servers see these two operating systems as fundamentally different

DHCP clients and give each of them a different IP address. Treating a dual-boot

system as two different DHCP clients may be an advantage if, for example, one of

the operating systems provides services that the other does not provide. However,

because each operating system has its own IP address, each dual-boot system

consumes two addresses, which might exhaust the pool of available addresses.

Chapter 23, “Updating the DNS with DHCP,” describes problems with dual-boot

machines that take advantage of DHCP–DNS dynamic updates. Briefly, if you are

using dual boot with dynamic DNS updates, you should be sure that either the two

operating systems use different client identifiers and different hostnames, or that

they use the same client identifier and the same hostname.

Duplicate IP Addresses

When two network interfaces are configured with the same IP address, problems

result. A DHCP server does not give one client a lease on an IP address while some

other client still holds a valid lease on that same address. However, a network user

could misappropriate an IP address without using DHCP by knowing the network

number and subnet mask and testing each valid IP address on the subnet until he or

she found one that is not in use. If the DHCP server subsequently assigned that IP

address to a DHCP client, both the client and the manually configured computer

would be using the same IP address simultaneously.

Some DHCP servers try to avoid allocating duplicate IP addresses by sending an

ICMP echo message to the address before allocating it to a client. If the server

receives a response, the address is already in use. The server marks the address as

Duplicate IP Addresses 427

028 3273 CH24 10/3/02 4:57 PM Page 427

unusable and tries another address for the client. This check works only if the other

computer using that IP address is operational at the time that the DHCP server

checks the address. If the rogue user’s machine is active when the server checks, the

server notifies the system administrator through a log message that a conflict exists.

If the machine is not active, the user of the DHCP client notices the problem when

the rogue machine is again powered on.

DHCP clients are expected to use ARP to check a newly assigned IP address prior to

using it. If a client finds some other system using the address it was assigned, it

sends the DHCP server a

DHCPDECLINE

message and then goes back to the

INIT

state to

acquire a different IP address. If a client doesn’t support

DHCPDECLINE

messages, you

might need to manually mark the IP address as unusable through the server configu-

ration and then restart the client that experienced difficulty.

Duplicate-address situations can result from a variety of reasons with DHCP, and

they are, in general, completely preventable. Keep in mind the following:

•Do not configure a DHCP server to dynamically allocate an IP address that has

been manually assigned to a computer on the network.

•When using redundant DHCP servers (as described in Chapter 17), do not

supply the same IP address to two different servers to be dynamically allocated.

•When using the DHCP failover protocol, make sure that any address pools that

you configure with the same addresses on two servers are actually configured as

shared pools.

• Do not lose your DHCP server’s database of active leases.

If you keep these things in mind, you should have problems with duplicate IP

address allocation only if you have users who refuse to follow your address manage-

ment policy.

When a Client Fails to Get a Reserved IP Address

Most DHCP servers enable you to reserve a particular IP address for a particular

client. The DHCP server does not offer that IP address to any other client, and if the

client appears on the network segment where the reservation exists, it should get

that IP address.

For cases in which redundant DHCP servers are used, as described in Chapter 17,

both DHCP servers must be aware of the static allocation. Otherwise, the DHCP

server that is not configured with the static allocation might make a dynamic IP

address assignment to the client. This can be a problem if the client depends on

having a consistent IP address because the dynamically allocated address is almost

certainly different. Therefore, when you’re configuring redundant DHCP servers, the

CHAPTER 24 Debugging Problems with DHCP428

028 3273 CH24 10/3/02 4:57 PM Page 428

dynamic IP addresses must be different on the two DHCP servers, and the static IP

address allocations must be the same.

Summary

Successful DHCP client configuration requires that several parts of a network work

correctly. Specific characteristics of clients and servers, failure or incorrect configura-

tion of network components, and even uncooperative users may all cause DHCP to

fail. If you suspect a problem with DHCP, you should first examine your server’s log

files to see whether you can find some clues about the problem there.

When working on problems with DHCP, you should first ensure that the DHCP

client and DHCP server can communicate with each other. If the client and server

are on different network segments, you must ensure that a correctly configured

DHCP relay agent is supporting the client’s network. You can use a network analyzer

on the client’s network segment to confirm that the client is sending DHCP messages

and that the server’s responses are reaching the client. You can also check whether

the replies from the server are being delivered to the correct IP address.

Configuration problems on DHCP servers can often cause difficulties. A DHCP server

must be configured with information about the network segments to which clients

may be attached. The server must also have addresses available to assign to clients on

those network segments.

Redundant DHCP servers are especially prone to configuration problems. You should

be very careful to ensure that all servers are configured with the same list of subnets,

that the dynamic address pools are separate, and that the reservations for IP

addresses are identical. Only one server should support dynamic BOOTP for any

subnet.

Although no one can anticipate every failure scenario possible with a DHCP service,

this chapter describes several common problems. If you follow the strategies

described here, you should be able to diagnose and fix any DHCP problem.

Summary 429

028 3273 CH24 10/3/02 4:57 PM Page 429

028 3273 CH24 10/3/02 4:57 PM Page 430

IN THIS CHAPTER

• An Introduction to IPv6

• The Motivations for DHCPv6

• The Design of DHCPv6

DHCP for IPv6

The IETF has developed a new version of IP, which is

intended to replace the current version of IP, version 4,

with as few changes as possible to the rest of the TCP/IP

suite. This new version, called IPv6, is named after the

version number stored in the

version field of the IP

header. Version 4 of IP (defined in RFC 791), is sometimes

referred to as IPv4 to differentiate it from IPv6. Early

versions of IPv6 were called IP next generation (IPng) after

the popular television show Star Trek: The Next Generation.

NOTE

IP version numbers 0, 1, 2, and 3 are unassigned. IP version

number 5 was assigned to Internet Stream Protocol Version 2

(ST II; see RFC 1819) before IPng was developed. Thus, when

the IETF settled on the preliminary design of its new version of

IP, IANA assigned it version number 6.

Several motivations exist for the development of IPv6. One

of these motivations—to improve several aspects of IP

addressing—is directly related to DHCP. The changes to

IPv6 are significant enough to warrant the development of

a new version of DHCP for IPv6, called DHCPv6.

NOTE

For clarity, this chapter explicitly refers to IP version 4 as IPv4

and to DHCP for IPv4 as DHCPv4. Elsewhere in the book, these

protocols are referred to simply as IP and DHCP.

This chapter discusses the differences between IPv4 and

IPv6 that affect DHCP, as well as the details of DHCPv6.

029 3273 CH25 10/3/02 5:04 PM Page 431

CHAPTER 25 DHCP for IPv6432

NOTE

As this book was being written, the DHCPv6 specification was documented in an Internet

Draft. The details of the protocol might change before they are accepted as an Internet

Standard. Check www.dhcp.org for the latest details about DHCPv6.

An Introduction to IPv6

This section presents a brief introduction to IPv6, including features of IPv6 that are

directly connected to DHCP functions. The IPv6 documents define several terms that

describe components of an IPv6 internet. Some of those definitions are included

here because they are used in some of the IPv6 mechanisms discussed in this

chapter:

• Node—Any device that implements IPv6

• Router—A node that forwards IPv6 datagrams

• Host—A node that is not a router

• Link—A mechanism (for example, Ethernet) through which nodes can

exchange datagrams at the link layer

• Interface—A node’s connection to a link

• Address—An IPv6 identifier for an interface

• Prefix—The initial bits of an IPv6 address that identify a link; equivalent to a

network number in IPv4

IPv6 Addressing

Each IPv6 address contains 128 bits and, unlike the Class A, B, and C addresses in

IPv4, an IPv6 address has no inherent structure. Instead, IPv6 addresses are organized

into types by prefix. The prefix is identified, when necessary, by a 1-byte prefix length,

which gives the number of bits in the prefix.

At present, most of the IPv6 address space is reserved for future use. Prefixes are allo-

cated for unicast addresses, addresses with limited scope (described in more detail in

the section “Address Types and Scoping”), and multicast addresses. Also, a compati-

bility mode exists in which IPv4 addresses can be represented in the IPv6 address

space.

Because of their length, IPv6 addresses use a different format than IPv4 for textual

representation. IPv6 addresses are written in hexadecimal notation, in 16-bit groups

separated by colons. This notation is known as colon hexadecimal, or colon hex. The

029 3273 CH25 10/3/02 5:04 PM Page 432

colon hex format includes two additional notational shortcuts: Any leading zeros

from the hexadecimal representation of each 16-bit group can be dropped, and a pair

of colons can indicate a string of groups that contain zeros (

::). The following is an

example of an IPv6 address:

2000:0:0:122:C34:3F:54CA:B

Several addressing mechanisms in IPv4 are formalized in IPv6. In IPv4, the address

0.0.0.0 can be used as a source address during initialization when the computer is

not assigned an address, and the address 127.0.0.1 is used as the loopback address.

IPv6 also defines an address that consists of all zeros, 0:0:0:0:0:0:0:0, for use during

initialization, but in IPv6 the loopback address is 0:0:0:0:0:0:0:1. In IPv6, an interface

can have multiple addresses. Finally, the private addressing scheme for IPv4 that was

introduced in RFC 1918 is extended in RFC 2373 for IPv6 to define scoped addresses

that are restricted to a node’s local link or site.

NOTE

RFC 1918 reserves several IP addresses for use in private internets. Organizations can use these

addresses for any internal networks, and computers attached to these networks can use IP

addresses from the IP addresses without coordinating with any number assignment authority,

such as IANA. The addresses reserved in RFC 1918 include one Class A IP address, 10.0.0.0;

16 Class B addresses, 172.16.0.0–172.31.0.0; and 256 Class C addresses,

192.168.0.0–192.168.255.0.

Use of these private addresses postpones the imminent shortage of unique IP addresses by

allowing organizations to reuse parts of the IP address space on their internal networks. The

primary drawback is that a computer using a private address cannot exchange packets with a

computer outside its own internal network.

Address Types and Scoping

In IPv6, an address has three possible scopes:

• Global—A global address is unique among all addresses on the Internet and is

deliverable (that is, can be routed) to any Internet destination.

• Site-local—A site-local address is unique among all addresses within a site and

is deliverable to any destination within the site. A site is defined as an internet

that has a boundary defined by routers that will not forward IPv6 datagrams to

site-local addresses.

• Link-local—A link-local address is unique among all addresses on the link

(that is, the local network) and is deliverable only to destinations on the same

link.

An Introduction to IPv6 433

029 3273 CH25 10/3/02 5:05 PM Page 433

IPv6 also introduces the interface identifier (RFC 2373), a 64-bit value that can be

generated from an interface link-layer address. For example, to construct an interface

identifier for Ethernet hardware, you insert fffe

(16 one bits) between the first 3

bytes and the last 3 bytes of a 48-bit Ethernet address to form an EUI-64 identifier.

Then, you form the interface identifier by complementing the universal/local bit,

which is the next-to-lowest order bit of the first octet of the EUI-64 identifier.

Interface identifiers are then used with a specific prefix to generate a 128-bit link-

local address. For example, the Ethernet address 0:80:3e:6d:31:ea:

00000000 10000000 00111100 01101101 00110001 11001010

is translated to the interface identifier 02:80:3e:ff:fe:6d:31:ea:

00000020 10000000 00111100 11111111 11111110 01101101 00110001 11001010

NOTE

The technique for creating the interface identifier for an interface is defined in the document

that specifies the techniques for transmission of IPv6 datagrams over the particular interface

hardware (for example, RFC 2464, “Transmission of IPv6 Packets over Ethernet Networks,” in

the case of Ethernet hardware).

RFC 2464 describes the use of the EUI-64 identifier in creating an interface identifier for an

Ethernet interface and the way in which an EUI-64 identifier is constructed from a 48-bit IEEE

802 address.

Scoping and Multicast Addresses

Scoping applies to multicast addresses as well as to unicast addresses. A 4-bit

scope

field defines several classes of increasing scope, including link-local and site-local

addresses. Thus, it is possible to define a multicast address that can be used at differ-

ent sites without conflict. For specific services or technologies using multicast, a

single multicast address can be defined for use at all sites.

IPv6 does not include a broadcast address like the 255.255.255.255 address in IPv4.

Instead, the address FF01:0:0:0:0:0:0:1 is reserved as a link-scoped multicast address

for all nodes on a link, and FF02:0:0:0:0:0:0:1 is reserved for all nodes within a site.

IPv6 Auto-Configuration

One of IPv6’s design goals is to enable the automated configuration of IPv6 devices.

Several specific mechanisms—some of which are formalizations of IPv4 practices and

others of which are new to IPv6—enable computers that use IPv6 to determine or

obtain an IP address without manual configuration or intervention by a network

server.

CHAPTER 25 DHCP for IPv6434

029 3273 CH25 10/3/02 5:05 PM Page 434

Link-Local Addresses

In simple network configurations with no routers, an IPv6 node can use a link-local

address with no knowledge of a local IP address. The node selects an address that is

not in use by other nodes on its network.

NOTE

The scenario of a single network with no connections to other networks is often called the

“dentist’s office” network. This describes an ad hoc network created by nonexpert users plug-

ging some computers into a hub. Why dentists were chosen as the canonical nonexpert users

is unclear, but the name has stuck.

The standard technique for a computer to generate an IPv6 link-local address is to

combine the link-local address prefix with the interface identifier. A dentist’s office

network need not be configured with a network number, and computers on that

network can use a link-local address to contact other computers on the network.

Of course, this automatic process does not configure DNS servers, DNS names, or

other services. It does, however, guarantee that computers on an isolated network

can communicate with each other and support other manually or automatically

configured services.

Although the link-local address generated according to these rules is quite likely to

be unique, a small chance exists that some other device on the same network is

already using the same address. To check the use of its generated link-local address, a

device using IPv6 transmits a request on its local network, asking whether other

devices are already using that address. If the device receives no responses to that

query, it can safely begin to use the new address.

Prefix Advertisements

Link-local addresses are useful only in communicating with other computers on the

same link. To exchange data with computers on other networks, a computer must

have a site-local address or a global address. A computer that uses IPv6 can pick a

site-local address or a global address for itself by combining the network number or

prefix assigned to the local network with the computer’s own interface identifier.

However, without other information, a computer does not know the prefix for its

local network. IPv6 router advertisement messages, transmitted by routers to announce

their availability on a link, carry prefix numbers for a link. Computers that receive

these messages can find out the prefix for a link and then generate an appropriate

address.

An Introduction to IPv6 435

029 3273 CH25 10/3/02 5:05 PM Page 435