Droms R. The DHCP handbook
Подождите немного. Документ загружается.
Fragmentation and Path MTU Discovery
One last difference between IPv4 and IPv6 is that routers do not perform fragmenta-
tion on IPv6 datagrams. Only the source of an IPv6 datagram can fragment that
datagram. Thus, a computer must know the smallest MTU of all the links along the
path to the destination, which it can determine by using path MTU discovery.
Conceptually similar to path MTU for TCP in IPv4, an IPv6 node must use path MTU
discovery for all destinations, including UDP and TCP, to avoid losing packets on
links with small MTUs. To minimize the need for fragmentation, hardware technolo-
gies must support an MTU of at least 1,280 bytes for use with IPv6.
The Motivations for DHCPv6
Some difference of opinion exists in the IPv6 community about the need for
DHCPv6. A rich set of auto-configuration mechanisms, along with the capability to
control network prefixes through router advertisements, means it is possible to have
auto-configured operation of IPv6 devices without a centralized address administra-
tion service.
Even though formal auto-configuration mechanisms exist in IPv6, some installations
still require centralized management and control of IPv6 address allocation and
protocol parameter configuration. Other sites might want to provide hosts with
configuration parameters such as a list of DNS servers through DHCP. Therefore, the
Dynamic Host Configuration Working Group (DHCWG) has developed a new
version of DHCP.
The Design of DHCPv6
DHCPv6 retains the client/server architecture of DHCPv4, and many of its server
functions are similar to those in DHCPv4. At the same time, some key differences
exist between DHCPv6 and DHCPv4.
Differences Between DHCPv6 and DHCPv4
The authors of DHCPv6 took advantage of the opportunity to start with a clean
design slate for DHCPv6 by adding new features to the DHCP service, using the new
IPv6 addressing features, and dropping backward compatibility with BOOTP.
Using Multiple Addresses for an Interface
One key difference between the two versions of DHCP is that DHCPv6 manages
multiple addresses for each interface. When DHCPv4 was designed, few (if any)
TCP/IP stacks could be configured with more than one IP address. As a simplifying
assumption, DHCPv4 was designed with the constraint that each managed interface
could be assigned only one IP address.
CHAPTER 25 DHCP for IPv6436
029 3273 CH25 10/3/02 5:05 PM Page 436
NOTE
The DHCPv4 specification allows only a single address for each separately identified interface.
Because clients can use distinct values in the client-id option, it is theoretically possible to
allocate more than one IP address to a single physical interface by using DHCPv4. In practice,
the DHCP specification does not define how to assign multiple IP addresses to a physical inter-
face, and most DHCPv4 clients cannot support more than a single DHCP address on an inter-
face.
IPv6 allows for multiple addresses on each interface. This feature enables the use of
link-local, site-local, and global addresses through the same interface as well as
virtual hosting, which provides for multiple copies of a service—for example, multiple
Web servers—through a single physical interface.
DHCPv6 enables a client to request multiple addresses for an interface. The address
requests might come as separate DHCPv6 messages, asking for the addresses as
required by individual application servers on the DHCPv6 client. The DHCPv6 server
implementation manages the addresses in sets called identity associations (IAs).
Using Link-Local Addresses
In DHCPv4, using UDP and IP before the client is assigned an address is accom-
plished by using the all-zeros source address and link-level broadcast. The IPv6 link-
local address auto-configuration mechanism provides a valid IPv6 address to the
client, which the client and server or relay agent use to exchange messages on the
link they share.
Managing Lifetime Addresses
Another difference between DHCPv4 and DHCPv6 is the mechanism through which
the assignment duration of addresses is managed. In IPv6, an address has an associ-
ated valid lifetime, which defines the time through which the address can be used.
This lifetime is related to the DHCPv4 lease, and the network administrator uses it to
control the length of time over which a client can use an address.
Using Fewer Protocol Configuration Parameters
At present, the DHCPv6 specification defines far fewer options than DHCPv4. IPv6
has fewer configurable parameters than IPv4, and SLP for IPv6 provides many of the
application service addresses defined as options in DHCPv4.
Using Multicast Addresses in DHCPv6
DHCPv6 defines two multicast addresses that are reserved for the use of clients,
servers, and relay agents:
Name Use
All-DHCP-Agents Clients to send messages to servers and relay agents
All-DHCP-Servers Relay agents to forward messages to servers
The Design of DHCPv6 437
029 3273 CH25 10/3/02 5:05 PM Page 437
Changes in Message Formats and Client Identification
DHCPv6 uses a new format for protocol messages. The new format has a fixed-
format header that is smaller than the DHCPv4 message header. DHCPv6 uses
options in which the option code and length fields are 16 bits long, which allows for
many more options and which accommodates more data in each option than in
DHCPv4.
A client is identified in DHCPv6 by a DHCP unique identifier (DUID). The client’s
DUID remains unchanged through the lifetime of the device (for example, even if
the interface hardware in the device is changed), so a DHCPv6 server can reliably
identify a DHCPv6 client. The DHCPv6 specification defines several techniques
through which a device can generate a DUID that guarantees that each DHCPv6
client has a unique DUID.
Client/Server Transactions in DHCPv6
This section describes the specific message exchanges that take place between
DHCPv6 clients and servers. These transactions are similar but not identical to the
transactions in DHCPv4.
Initial Assignment of Addresses
A DHCPv6 client obtains an initial address by exchanging messages that are similar
to the initial messages in DHCPv4. The client uses multicast to send a message that
locates available DHCP servers. This message corresponds to the
DHCPDISCOVER
message that is broadcast by a DHCPv4 client to the local broadcast address. A
DHCPv6 client locates only servers with the initial message. Any address assignment
is performed in the second transaction between the client and server.
The client begins by sending a
Solicit message to DHCPv6 servers or relay agents
on its local link, looking for an available server. This message is sent to the
All-
DHCP-Agents multicast address. Any servers that choose to respond to the initial
discovery message reply with an
Advertise message to the client, through a relay
agent if necessary. The client then selects a server and sends a
Request message,
asking for any addresses and other configuration information. Finally, the chosen
server responds with a
Reply message that contains the requested parameters.
When it does not have a valid site-local or global address, the DHCPv6 client uses its
link-local address as the source address. The DHCPv6 server or relay agent on the
same link as the client uses that link-local address to unicast reply messages to the
client.
Obtaining Additional Addresses
DHCPv6 defines the IA as a mechanism through which clients and servers manage
IPv6 addresses. An IA contains one or more IPv6 addresses that are managed as a
CHAPTER 25 DHCP for IPv6438
029 3273 CH25 10/3/02 5:05 PM Page 438
group. Individual addresses can be added to the IA over time, and an address is
deleted from the IA when the valid lifetime for the address expires.
A client can subsequently contact a server directly with requests for additional IPv6
addresses to be assigned to a particular IA. The server keeps a list of all the addresses
assigned to an IA. Each of these addresses has an independent valid lifetime.
Extending Leases
Similarly to IPv4, the client can send
Renew messages to the server to extend the life-
time of addresses in an IA. And, as in DHCPv4, if the server fails to respond within
some time, the client may send
Rebind messages to all servers to extend the life-
times. DHCPv6 defines T1 and T2 in the same way as DHCPv4 (see the section
“Extending a Lease” in Chapter 8, “DHCP Message Exchanges”), so the server can
control the times at which the client contacts the server to extend address lifetimes.
Duplicate Addresses
When a DHCPv6 client receives an address assigned by a server, the client uses the
IPv6 duplicate address detection mechanism, which is part of the Neighbor Discovery
Protocol (RFC 2461), to confirm that the address is not already in use by another
node on the same link. If the client does find that the address is already in use, it
sends a
Decline message to the server and discards the address.
Releasing Addresses
A DHCPv6 client can return to a server addresses that it no longer needs. The client
can choose to return all addresses at once or it can return some addresses and retain
others. In DHCPv6, the server acknowledges returned addresses to the client, using
the client’s link-local address either directly or through the relay agent on the client’s
link.
Configuring Clients Without Address Assignment
Because of stateless address auto-configuration, many IPv6 hosts do not require
explicit address assignment from a DHCP server. Those hosts need other information
such as the addresses of DNS servers. A DHCP client can obtain configuration infor-
mation without being assigned an address by sending an Information-request
message. A server responds with a Reply message that contains the configuration
information requested by the client.
Reconfiguring Clients
The DHCPv6 reconfiguration mechanism allows a server to force the client to
contact the server for new configuration information, including addresses, lifetimes
for addresses, and other parameters. The server sends a Reconfigure message to the
client, to which the client responds with either a Renew or an Information-request
message. The server then sends the client a Reply message that contains the new
information.
The Design of DHCPv6 439
029 3273 CH25 10/3/02 5:05 PM Page 439
Interaction with IPv6 Auto-Configuration
DHCPv6 address configuration complements IPv6 auto-configuration, and IPv6
nodes use one or both forms of configuration or the other. The IPv6 router advertise-
ment mechanism provides administrative control over that choice through flag bits
that indicate whether IPv6 nodes should use auto-configuration or DHCPv6 to deter-
mine their IPv6 addresses. The flag bits also control whether the clients use DHCPv6
to obtain other configuration parameters when using auto-configuration for
addresses.
Summary
The IETF is developing a new version of IP, called IPv6. IPv6 includes several features
for address management that either are not included in IPv4 or represent formaliza-
tion of current practice in IPv4. IPv6 includes scoped addresses, which are forwarded
only across a single network (link) or only within a single site. With IPv6, computers
can obtain information about network numbering and an auto-configuration mecha-
nism through which they can generate addresses based on the network numbering
information.
The DHCWG has developed a specification of DHCP for IPv6, called DHCPv6.
DHCPv6 explicitly allows for multiple addresses on each interface and allows clients
to request addresses in more than one transaction. DHCPv6 allows servers to initiate
interactions with clients so that servers can push new configuration information to
clients on demand. Network administrators can control whether IPv6 devices use
auto-configuration or DHCPv6 through the router advertisement mechanism.
DHCPv6 is published as an Internet Draft, and the details might change before the
specification is accepted as an Internet Standard. To obtain information about the
latest version of the DHCPv6 specification, refer to the DHCWG charter page,
www.ietf.org/html.charters/dhc-charter.html.
CHAPTER 25 DHCP for IPv6440
029 3273 CH25 10/3/02 5:05 PM Page 440
PART IV
Appendixes
IN THIS PART
A Microsoft DHCP Server Examples
B ISC DHCP Server Configuration File Reference
C The DHCP Message Format
D DHCP Options Summary
E Bibliography and Other DHCP Resources
F DHCP Server and Operating System Versions
G Glossary
030 3273 Part IV 10/3/02 4:58 PM Page 441
030 3273 Part IV 10/3/02 4:58 PM Page 442
A
Microsoft DHCP Server
Examples
The main text of this book provides examples that use
the configuration file language of the ISC DHCP server.
This appendix shows you how to use the Microsoft DHCP
server supplied with Windows 2000 for every example in
the main text that the Microsoft server supports.
This appendix is intended for use as a reference and should
not be read sequentially. As a result, some examples are
redundant, and in many cases the text illustrating one
example also refers to another example.
To use these examples, you must have the Microsoft DHCP
server installed, as described in Chapter 13, “The Microsoft
DHCP Server.” Before using the examples in this appendix,
you should read Chapter 13, which explains how to make
the Microsoft DHCP server work.
After you install the Microsoft DHCP server, you must start
the DHCP Manager and connect it to the DHCP server you
want to modify. Figure A.1 shows the DHCP Manager
window.
Examples 3.1, 3.2, 3.3, and 3.4
Subnets are called scopes in the Microsoft DHCP server. To
add a scope, select the server you want to update (gener-
ally
Local Machine) in the DHCP Manager window. The
server is then listed in the DHCP Manager window, as
shown in Figure A.1. Select Action, New Scope. The DHCP
Manager runs the New Scope Wizard, which prompts you
for information about the new scope. At a minimum, you
need to configure the addresses available for assignment in
the scope and the maximum lease time for the scope.
031 3273 App A 10/3/02 5:04 PM Page 443
APPENDIX A Microsoft DHCP Server Examples444
FIGURE A.1 The DHCP Manager window.
Example 3.2, in Chapter 3, “Configuring the DHCP Server,” shows examples of five
new subnets. Because Microsoft treats scopes as a concept independent of subnets, it
is impossible to show an example of an empty scope declaration, as in Example 3.2.
Instead, Examples 3.1, 3.2, 3.3, and 3.4 are combined. Figure A.2 shows the full defi-
nition of the first of the GSI subnets.
FIGURE A.2 The DHCP Manager window, showing subnets for the GSI network.
031 3273 App A 10/3/02 5:04 PM Page 444
Examples 3.5 and 3.6
Example 3.5 shows the format of an option declaration, and Example 3.6 shows a
simple subnet-specific option declaration. The Microsoft DHCP server enables you to
declare options that are specific to the scope, very much like the
routers option
shown in Example 3.6. To define an option that is local to a scope, highlight the
scope in the DHCP Manager window and select the Scope Options item. Select
Action, Configure Options and a dialog box for option configuration appears. Figure
A.3 shows the
routers option being defined.
Examples 3.5 and 3.6 445
FIGURE A.3 Entering a router’s IP address in the Array Editor dialog box.
You might notice that the names of the options are slightly different in the
Microsoft DHCP server than in the ISC DHCP server; for example, the ISC routers
option is equivalent to the Microsoft Router option. The subnet-mask option is set
up in the Create Scope dialog box, and it can’t be configured in the Scope Options
dialog box. The ISC
domain-name-servers option corresponds to the Microsoft DNS
Servers option, and it is defined in the same way as the Router option. Be careful
not to mistake the Microsoft
Name Servers option for the DNS Servers option—the
two are completely different. The Name Servers option refers to IEN116 name
service, which is now obsolete. If you define IEN116 name servers and don’t define
domain name servers, your DHCP clients can’t do DNS name resolution.
031 3273 App A 10/3/02 5:04 PM Page 445