Export (0) Print
Expand All

DHCP Protocols

Applies To: Windows Server 2008

In Windows Server® 2008, the DHCP Server service includes support for the Dynamic Host Configuration Protocol for IP version 4 (DHCP), the Dynamic Host Configuration Protocol for IP version 6 (DHCPv6), the Multicast Address Dynamic Client Allocation Protocol (MADCAP), and the Bootstrap Protocol (BOOTP).

DHCP servers communicate with DHCP clients by using a series of DHCP messages. The format of DHCP messages is based on the message format used with BOOTP.

RFC 2131 defines the format for each message sent between a DHCP client and a DHCP server. The following table shows the possible fields in the DHCP messages.

DHCP message fields

 

Field Name Friendly Name Field Length (Octets) Description

op

Message Type

1

Message type.

htype

Hardware Address Type

1

Hardware address type defined at Internet Assigned Numbers Authority (IANA).

hlen

Hardware Address Length

1

Hardware address length, in octets.

hops

Hops

1

Value set to zero by DHCP clients. Optionally used to count the number of relay agents that forwarded the message.

xid

Transaction ID

4

A random number used to associate messages and responses between a client and a server.

secs

Seconds

2

Seconds elapsed since client began address acquisition or renewal process.

flags

Flags

2

Flags set by client. The Broadcast flag is set if the client cannot receive unicast IP datagrams (for example, before it is configured with an IP address).

ciaddr

Client IP Address

4

Used if the client has an IP address and can respond to Address Resolution Protocol (ARP) requests.

yiaddr

Your IP Address

4

Address given to the DHCP client by the DHCP server.

siaddr

DHCP Server IP Address

4

IP address of the server that is offering a lease.

giaddr

Gateway IP Address

4

DHCP relay agent IP address.

chaddr

Client Hardware Address

16

Client hardware address.

sname

Server Host Name

64

Optional server host name. Not used in Windows Server 2008.

file

Boot File Name

128

The name of the file containing the boot image for a BOOTP client.

options

Options

variable

Optional parameters field. In the DHCP protocol packet, each option begins with a single octet tag, which holds the option code, and a second octet, which describes the option data length, in bytes. For a complete list of the DHCP options available by default on a DHCP server running on Windows Server 2008, see DHCP Tools and Options.

For more information about how these fields are used in each DHCP message, see RFC 2131 or use a network monitoring tool, such as Netmon, to view the DHCP messages.

Although DHCP was designed to assign IP addresses and other networking information to computers so they can communicate on the network automatically, with an Internet Protocol version 6 (IPv6) network you do not need DHCP to configure addresses. You might have a network configuration, however, that will benefit from using DHCP. DHCP for IPv6 (DHCPv6) can provide stateful address configuration or stateless configuration settings to IPv6 hosts. IPv6 hosts can use several methods to configure addresses:

  • Stateless address autoconfiguration, which is used to configure both link-local addresses and additional non-link-local addresses by exchanging Router Solicitation and Router Advertisement messages with neighboring routers.

  • Stateful address autoconfiguration, which is used to configure non-link-local addresses through the use of a configuration protocol such as DHCP. An IPv6 host performs stateless address autoconfiguration automatically and uses a configuration protocol such as DHCPv6 based on the following flags in the Router Advertisement message sent by a neighboring router:

    • Managed Address Configuration flag, also known as the M flag. When set to 1, this flag instructs the host to use a configuration protocol to obtain stateful addresses.

    • Other Stateful Configuration flag, also known as the O flag. When set to 1, this flag instructs the host to use a configuration protocol to obtain other configuration settings.

      Combining the values of the M and O flags can yield the following:

      • Both M and O flags are set to 0. This combination corresponds to a network without a DHCPv6 infrastructure. Hosts use router advertisements for non-link-local addresses and other methods (such as manual configuration) to configure other settings.

      • Both M and O flags are set to 1. DHCPv6 is used for both addresses and other configuration settings. This combination is known as DHCPv6 stateful, in which DHCPv6 is assigning stateful addresses to IPv6 hosts.

      • The M flag is set to 0 and the O flag is set to 1. DHCPv6 is not used to assign addresses, only to assign other configuration settings. Neighboring routers are configured to advertise non-link-local address prefixes from which IPv6 hosts derive stateless addresses. This combination is known as DHCPv6 stateless: DHCPv6 is not assigning stateful addresses, but stateless configuration settings, to IPv6 hosts.

      • The M flag is set to 1 and the O flag is set to 0. DHCPv6 is used for address configuration, but not for other settings. Because IPv6 hosts typically need to be configured with other settings, such as the IPv6 addresses of Domain Name System (DNS) servers, this is an unlikely combination.

Like DHCP for Internet Protocol version 4 (IPv4), the components of a DHCPv6 infrastructure consist of DHCPv6 clients that request configuration, DHCPv6 servers that provide configuration, and DHCPv6 relay agents that convey messages between clients and servers when clients are on subnets that do not have a DHCPv6 server.

As with DHCP for IPv4, DHCPv6 uses User Datagram Protocol (UDP) messages. DHCPv6 clients listen for DHCP messages on UDP port 546. DHCPv6 servers and relay agents listen for DHCPv6 messages on UDP port 547. The structure for DHCPv6 messages is much simpler than for DHCP for IPv4, which had its origins in BOOTP to support diskless workstations. The following figure shows the structure of DHCPv6 messages sent between client and server.

ffab0fde-f7ed-4ee9-a743-416d0ef87fa1

The 1-byte Msg-Type field indicates the type of DHCPv6 message. The 3-byte Transaction-ID field is determined by a client and used to group the messages of a DHCPv6 message exchange together. Following the Transaction-ID field, DHCPv6 options are used to indicate client and server identification, addresses, and other configuration settings. For the list of defined DHCPv6 options, see RFC 3315.

DHCPv6 options are formatted with the type-length-value (TLV) format. The following figure shows the structure of DHCPv6 options.

8498c5e3-b333-48c4-82ca-ba90fb124b07

The 2-byte Option-Code field indicates a specific option. The 2-byte Option-Len field indicates the length of the Option-Data field in bytes. The Option-Data field contains the data for the option.

There is a separate message structure for the messages exchanged between relay agents and servers to record additional information. The following figure shows the structure of these kinds of messages.

aeb96fcd-1e42-4fd6-937b-00fa1f4cfa28

The 1-byte Hop-Count field indicates the number of relay agents that have received the message. A receiving relay agent can discard the message if it exceeds a configured maximum hop count. The 16-byte Link-Address field contains a non-link-local address that is assigned to an interface connected to the subnet on which the client is located. From the Link-Address field, the server can determine the correct address scope from which to assign an address. The 16-byte Peer-Address field contains the IPv6 address of the client that originally sent the message or the previous relay agent that relayed the message. Other DHCPv6 options that include the Relay Message option, which contains the message being relayed and other options. The Relay Message option provides an encapsulation of the messages being exchanged between the client and the server.

There are no broadcast addresses defined for IPv6. Therefore, the use of the limited broadcast address for some DHCPv4 messages has been replaced with the use of the All_DHCP_Relay_Agents_and_Servers address of FF02::1:2 for DHCPv6. For example, a DHCPv6 client attempting to discover the location of the DHCPv6 server on the network sends a Solicit message from its link-local address to FF02::1:2. If there is a DHCPv6 server on the host's subnet, it receives the Solicit message and sends an appropriate reply. More typically, a DHCPv6 relay agent on the host's subnet receives the Solicit message and forwards it to a DHCPv6 server.

A DHCPv6 stateful message exchange to obtain IPv6 addresses and configuration settings (that is, when both M and O flags in a received router advertisement are set to 1) typically consists of the following messages:

  • A Solicit message sent by the client to locate the servers.

  • An Advertise message sent by a server to indicate that it can provide addresses and configuration settings.

  • A Request message sent by the client to request addresses and configuration settings from a specific server.

  • A Reply message sent by the requested server that contains addresses and configuration settings.

If there is a relay agent between the client and the server, the relay agent sends the server Relay-Forward messages containing the encapsulated Solicit and Request messages from the client. The server sends the relay agent Relay-Reply messages containing the encapsulated Advertise and Reply messages for the client. For a complete list of DHCPv6 messages, see the following table.

DHCP options for BOOTP clients

 

DHCPv6 Message Description Equivalent DHCP for IPv4 Message

Solicit

Sent by a client to locate servers.

DHCPDiscover

Advertise

Sent by a server in response to a Solicit message to indicate availability.

DHCPOffer

Request

Sent by a client to request addresses or configuration settings from a server.

DHCPRequest

Confirm

Sent by a client to all servers to determine if a client's configuration is valid for the connected link.

DHCPRequest

Renew

Sent by a client to a server to extend the lifetime of assigned addresses and obtain updated configuration settings.

DHCPRequest

Rebind

Sent by a client to any server when a response to the Renew message is not received.

DHCPRequest

Reply

Sent by a server to a client in response to a Solicit, Request, Renew, Rebind, Information-Request, Confirm, Release, or Decline message.

DHCPAck

Release

Sent by a client to indicate that the client is no longer using an assigned address.

DHCPRelease

Decline

Sent by a client to a server to indicate that the assigned address is already in use.

DHCPDecline

Reconfigure

Sent by a server to a client to indicate that the server has new or updated configuration settings. The client then sends either a Renew or Information-Request message.

N/A

Information-Request

Sent by a client to request configuration settings (but not addresses).

DHCPInform

Relay-Forward

Sent by a relay agent to forward a message to a server. Contains a client message encapsulated as the DHCPv6 Relay-Message option.

N/A

Relay-Reply

Sent by a server to send a message to a client through a relay agent. Contains a server message encapsulated as the DHCPv6 Relay-Message option.

N/A

A DHCPv6 stateless message exchange to obtain only configuration settings (that is, when the M flag is set to 0 and the O flag is set to 1 in a received router advertisement) typically consists of the following messages: an Information-Request message sent by the DHCPv6 client to request configuration settings from a server and a Reply message sent by a server containing the requested configuration settings.

For an IPv6 network that has routers configured to assign stateless address prefixes to IPv6 hosts, the two-message DHCPv6 exchange can be used to assign DNS servers, DNS domain names, and other configuration settings that are not included in the router advertisement message.

Windows Vista and Windows Server 2008 include a DHCPv6 client. The DHCPv6 client attempts DHCPv6-based configuration, depending on the values of the M and O flags in received router advertisement messages. Therefore, to use DHCPv6, you must configure DHCPv6 servers and relay agents to service each IPv6 subnet and then configure your IPv6 routers to set these two flags to their appropriate values. If there are multiple advertising routers for a given subnet, they should be configured to advertise the same stateless address prefixes and values of the M and O flags. IPv6 hosts running Windows® XP or Windows Server 2003 do not include a DHCPv6 client and therefore ignore the values of the M and O flags in received router advertisements.

You can configure an IPv6 router that is running Windows Vista or Windows Server 2008 to set the M flag to 1 in router advertisements with the netsh interface ipv6 set interface InterfaceName managedaddress=enabled command. Similarly, you can set the O flag to 1 in router advertisements with the netsh interface ipv6 set interface InterfaceName otherstateful=enabled command.

Windows Server 2008 includes a MADCAP Server service to support dynamic assignment and configuration of IP multicast addresses on TCP/IP-based networks.

Whereas DHCP unicast scopes provide client configurations by allocating ranges of IP addresses for point-to-point communication between two networked computers, multicast scopes provide ranges for multicast IP addresses. These addresses are reserved for multicast operation using directed transmission from one point to multiple points.

A multicast address is shared by many computers. A group of TCP/IP computers can use a single multicast IP address to send directed communication to all computers with which they share the use of the group address. An IP datagram that is sent to the multicast address is forwarded to all members of that multicast group.

Multicast addresses support dynamic membership, allowing individual computers to join or leave the multicast group at any time. The size of the group is not limited, and computers can be members of multiple groups. In addition, any computer that uses TCP/IP can send datagrams to any multicast group.

You can permanently reserve multicast group addresses or you can temporarily assign and use them. A permanent group is made by permanently reserving a multicast IP address (224.0.0.0 to 239.255.255.255) with the IANA. The reserved address then becomes a well-known address, indicating a specific multicast group that exists regardless of whether group member computers are present on the network. Any multicast IP address that is not permanently reserved with the IANA can then be used dynamically to assign and form temporary multicast groups. These temporary groups can exist as long as one or more computers on the network are configured with the group’s address and actively share in its use.

BOOTP is a computer configuration protocol developed before DHCP. DHCP improves on BOOTP and resolves specific limitations that BOOTP had as a computer configuration service. RFC 951 defines BOOTP.

Whereas BOOTP configures diskless workstations with limited boot capabilities, DHCP configures networked computers that have local hard drives and full boot capabilities.

Likewise, although both BOOTP and DHCP allocate IP addresses to clients during startup, they use different methods of allocation. BOOTP typically provides fixed allocation of a single IP address for each client, permanently reserving this address in the BOOTP server database. DHCP typically provides dynamic, leased allocation of available IP addresses, reserving each DHCP client address temporarily in the DHCP database.

Because of the relationship between BOOTP and DHCP, both protocols share some defining characteristics. BOOTP and DHCP use nearly identical request messages and reply messages. Both protocols enclose each protocol message in a single UDP datagram of 576 bytes. Message headers are the same for both BOOTP and DHCP, except for the final message header field that carries optional data. For BOOTP, this optional field is called the vendor-specific area and is limited to 64 bytes. For DHCP, this optional field is called the options field and is at least 312 bytes long.

Both BOOTP and DHCP use the same reserved protocol ports for sending and receiving messages between servers and clients. Both BOOTP and DHCP servers use UDP port 67 to listen for and receive client request messages. BOOTP and DHCP clients typically reserve UDP port 68 for accepting message replies from either a BOOTP server or DHCP server.

Because DHCP and BOOTP messages use nearly identical format types and packet structures, and use the same well-known service ports, BOOTP or DHCP relay agent programs usually treat BOOTP and DHCP messages as the same message type and do not differentiate between them.

BOOTP clients do not rebind or renew configuration with the BOOTP server except when the system restarts, whereas DHCP clients do not require a system restart to rebind or renew configuration with the DHCP server. Instead, clients automatically enter the rebinding state at defined intervals to renew their leased address allocation with the DHCP server. This process occurs in the background and is transparent to the user.

BOOTP uses a two-phase bootstrap configuration process in which clients contact BOOTP servers to perform address determination and boot file name selection, and clients also contact Trivial File Transfer Protocol (TFTP) servers to perform file transfer of their boot image. DHCP uses a single-phase boot configuration process whereby a DHCP client negotiates with a DHCP server to determine its IP address and obtain any other initial configuration details it needs for network operation.

Because BOOTP clients contact TFTP servers to perform file transfer of their boot image and Windows Server 2008 does not provide a TFTP file service, you need a TFTP server to support BOOTP clients that must boot from an image file (usually diskless workstations). You also need to configure your DHCP server to provide supported BOOTP/DHCP options.

To obtain other options, BOOTP clients must specify DHCP option code 55 (the Options Request List parameter) in the BOOTP request. BOOTP clients that do not specify option 55 can still retrieve the options listed in the following table from DHCP servers running Windows NT Server 4.0 or later, if they are configured on the server.

DHCP options for BOOTP clients

 

Code Option Name

1

Subnet Mask

3

Router

4

Time Server

5

Name Server

9

LPR Server

12

Computer Name

15

Domain Name

17

Root Path

42

NTP Servers

44

WINS Server

45

NetBIOS over TCP/IP Datagram Distribution Server

46

NetBIOS over TCP/IP Node Type

47

NetBIOS over TCP/IP Scope

48

X Window System Font Server

49

X Window System Display Manager

69

SMTP Server

70

POP3 Server

DHCP servers running Windows Server 2008 return the options in the order listed above and return as many options as can fit in a single datagram response. For more information about individual DHCP options, see DHCP Tools and Options.

noteNote
When configuring client reservations for use with BOOTP clients, remember that DHCP options can apply equally to DHCP and BOOTP clients.

Each record in the BOOTP table has three fields of information that is returned to the BOOTP client:

  • Boot Image. Identifies the generic file name (such as “unix”) of the requested boot file, based on the BOOTP client’s hardware type.

  • File Name. Identifies the full path of the boot file (such as “/etc/vmunix”) that the BOOTP server returns to the client by using TFTP.

  • File Server. Identifies the name of the TFTP server used to store the boot file.

To add entries in the BOOTP table, use the DHCP snap-in.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft