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

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

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.

DHCPv6

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.

DHCPv6 messages

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.

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.

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.

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.

Stateful message exchange

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

Stateless message exchange

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.

DHCPv6 support in Windows

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.

MADCAP

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.

Dynamic membership

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.

Multicast address ranges

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

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.

DHCP options supported for BOOTP clients

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

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.

BOOTP table

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.