6 Appendix A: Product Behavior

  • Article

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.

Windows Client

  • Windows 98 operating system

  • Windows 2000 Professional operating system

  • Windows Millennium Edition operating system

  • Windows XP operating system

  • Windows Vista operating system

  • Windows 7 operating system

  • Windows 8 operating system

  • Windows 8.1 operating system

  • Windows 10 operating system

  • Windows 11 operating system

Windows Server

  • Windows 2000 Server operating system

  • Windows Server 2003 operating system

  • Windows Server 2008 operating system

  • Windows Server 2008 R2 operating system

  • Windows Server 2012 operating system

  • Windows Server 2012 R2 operating system

  • Windows Server 2016 operating system

  • Windows Server operating system

  • Windows Server 2019 operating system

  • Windows Server 2022 operating system

  • Windows Server 2025 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 2.2.1: In Windows 98, Windows 2000 operating system, Windows Millennium Edition, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and in Windows Server 2008 R2, DHCP clients send the host name encoded using the original equipment manufacturer (OEM) code page that was installed as the current system code page at system boot time in Option 12. In Windows 2000 Server, Windows Server 2003, Windows Server 2008, and in Windows Server 2008 R2, DHCP servers treat the host name as being encoded using the OEM code page that was installed on the DHCP server as the current system code page at system boot time.

Otherwise, in applicable Windows releases, the DHCP client sends the Host Name Option in the OEM code page in the DHCPDISCOVER message (see section 3.1.4.1). In the DHCPREQUEST message (see section 3.1.4.1), if the FQDN Option is sent in canonical IDNA (see section 2.2.7), then the Host Name Option is sent in IDNA in the same message. If the FQDN Option is not sent in canonical IDNA encoding or if the FQDN Option is not sent in the DHCPREQUEST, then the host name is sent in the OEM code page in the same message.

<2> Section 2.2.2: The ANDROID_METERED option is not supported in Windows 10 v1909 operating system or Windows Server v1909 operating system or earlier.

<3> Section 2.2.2.1: Windows DHCPv4 servers send the Disable NetBIOS Option in the DHCPOFFER and DHCPACK messages, if configured to do so by the administrator.

<4> Section 2.2.2.1: Windows 98 and Windows Millennium Edition DHCPv4 clients do not support the Disable NetBIOS Option.

<5> Section 2.2.2.2: Windows 98 and Windows Millennium Edition DHCPv4 clients do not support the Release DHCP Lease on Shutdown Option.

<6> Section 2.2.2.3: Windows 98 and Windows Millennium Edition DHCPv4 clients do not support the Default Router Metric Base Option.

<7> Section 2.2.2.3: In Windows 98, Windows Millennium Edition, Windows 2000 Professional, Windows XP, and Windows XP operating system Service Pack 1 (SP1) clients by default (if not overridden by this Vendor-Specific Option), the TCP/IP stack instead computes the route metric based on link speed as follows.

Metric

 Link speed

0x0000000A (10)

Greater than 200 Mbps

0x00000014 (20)

Greater than 20 Mbps, and less than or equal to 200 Mbps

0x0000001E (30)

Greater than 4 Mbps, and less than or equal to 20 Mbps

0x00000028 (40)

Greater than 500 Kbps, and less than or equal to 4 Mbps

0x00000032 (50)

Less than or equal to 500 Kbps

<8> Section 2.2.2.6: The ANDROID_METERED option is not supported in Windows 10 v1909 or Windows Server v1909 or earlier.

<9> Section 2.2.3: The "MSFT 5.0 XBOX" value is not supported in Windows 10 v1909 or Windows Server v1909 or earlier.

<10> Section 2.2.4: In Windows Vista operating system with Service Pack 1 (SP1) and Windows Server 2008, DHCPv6 clients do not support the User Class Option. Otherwise, in applicable Windows releases, DHCPv6 clients request the User Classes defined on the Windows DHCPv6 server whenever a user tries to set the User Class for the DHCPv6 client by executing "Ipconfig /setclassid6" or whenever a user tries to see the User Classes defined on the DHCPv6 server by executing "Ipconfig /showclassid6".

<11> Section 2.2.4: On Windows Server 2008, the DHCPv6 server does not support the User Class Option. Otherwise, in applicable Windows Server releases the server sends one or more User Class Options depending on whether one or more User Classes are configured on the DHCP server.

<12> Section 2.2.5: In Windows 98, Windows 2000 Professional, Windows Millennium Edition, and in Windows Server 2003, DHCPv6 client support is not implemented. In Windows 2000 Server and in Windows Server 2003, DHCPv6 server support is not available.

<13> Section 2.2.5: The "MSFT 5.0 XBOX" value is not supported in Windows 10 v1909 or Windows Server v1909 or earlier.

<14> Section 2.2.6.1: By default, Windows DHCPv4 clients do not send the User Class Option in the DHCPv4 messages. Users can configure any data string value to be sent as the User Class value by the DHCPv4 client to the server.

<15> Section 2.2.6.2: DHCPv4 clients request the User Classes defined on the Windows DHCP server whenever a user tries to set the User Class for the DHCPv4 client by executing "Ipconfig /setclassid" or whenever a user tries to see the User Classes defined on the DHCPv4 server by executing "Ipconfig /showclassid".

<16> Section 2.2.6.2: In applicable Windows Server releases the server sends one or more User Class Options depending on whether one or more User Classes are configured on the DHCPv4 server.

<17> Section 2.2.7: All Windows DHCPv4 clients send FQDNs in Option 81 with the E bit set to 0 by default but can be configured to send with the E bit set to 1.

<18> Section 2.2.7: On all Windows DHCPv4 clients, when sending with the E bit set to 0, the host name is encoded using the OEM code page that was installed as the current system code page at system boot time. On Windows 98, Windows 2000, Windows Millennium Edition, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, when sending with the E bit set to 1, the host name is encoded using UTF-8 encoding.

Otherwise, Windows, except Windows 98, Windows 2000, Windows Millennium Edition, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and on Windows Server 2008 R2, reads the registry value "DhcpUseE1" of type REG_DWORD under the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<GUID of the interface>. If the registry value has a zero value or if it does not exist, then the host name is sent with the E bit set to 0 using the OEM code page. If "DhcpUseE1" has a zero value or if the registry value does not exist, then the registry value "DhcpUseUTF8" of type REG_DWORD under the same registry key is read. If "DhcpUseUTF8" is nonzero, then the host name is encoded using UTF-8 encoding and is sent with the E bit set to 1. If "DhcpUseE1" has a nonzero value, the host name is encoded in canonical IDNA and is sent with the E bit set to 1.

<19> Section 2.2.7: Windows DHCPv4 servers treat FQDNs with the E bit set to 0 in Option 81 as being encoded using the OEM code page that was installed on the DHCPv4 server as the current system code page at system boot time. In Windows 2000 Server, Windows Server 2003, Windows Server 2008, and in Windows Server 2008 R2, DHCPv4 servers treat FQDNs with the E bit set to 1 as being encoded using UTF-8 encoding. Otherwise, in applicable Windows Server releases, the DHCPv4 servers check FQDNs with the E bit set to 1 to determine if the FQDN is encoded in canonical IDNA. If the FQDN is not encoded in that manner, the FQDN is treated as being encoded by using UTF-8 encoding.

<20> Section 2.2.8: Windows XP and Windows Server 2003 DHCPv4 clients and servers use Option Code 249 for requesting and sending Classless Static Routes (CSRs) instead of Option Code 121, as specified in [RFC3442]. These clients and servers ignore Option 121 if included in a DHCPv4 message. Otherwise, Windows DHCPv4 clients use both Option 121 and Option 249.

<21> Section 2.2.11: In Windows 2000 Server, Windows Server 2003, Windows Server 2008, and in Windows Server 2008 R2, the DHCP server sends the domain name encoded by using the original equipment manufacturer (OEM) code page that was installed as the current system code page at system boot time. In Windows 98, Windows 2000, Windows Millennium Edition, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and in Windows Server 2008 R2, the DHCP client treats the domain name as though it were encoded using the OEM code page that was installed on the DHCP client as the current system code page at system boot time.

In applicable Windows Server releases, except Windows 2000 Server, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2, the DHCP server sends the DHCPv4 Option Code 15 in the IDNA encoding in the DHCPOFFER message (section 3.1.5.1). If the client FQDN Option (section 2.2.7) was not sent in the canonical IDNA encoding by the DHCP client in the DHCPREQUEST message (section 3.1.4.1), then the domain name is sent in the OEM code page in the DHCPACK. If the client FQDN Option was sent in the canonical IDNA encoding by the DHCP client in the DHCPREQUEST message, then DHCPv4 Option Code 15 is sent in the IDNA encoding in the DHCPACK message (section 3.1.5.2).

<22> Section 3.1.4.1: All Windows DHCPv4 clients include Vendor Class Identifier Option (Option 60) in DHCPDISCOVER, DHCPREQUEST, and DHCPINFORM messages.

<23> Section 3.1.4.1: By default, Windows DHCPv4 clients do not send the User Class Option in the DHCPv4 messages. Users can configure any data string value to be sent as the User Class value by the DHCPv4 client to the server.

Windows DHCPv4 clients using BOOTP to boot from the network send the Default BOOTP class (as defined in section 2.2.6) as their User Class.

<24> Section 3.1.4.1: DHCPv4 clients request the User Classes defined on the Windows DHCPv4 server whenever a user tries to set the User Class for the DHCPv4 client by executing "Ipconfig /setclassid" or whenever a user tries to see the User Classes defined on the DHCPv4 server by executing "Ipconfig /showclassid".

<25> Section 3.1.4.2: All Windows DHCPv6 clients include a Vendor Class Option (Option 16) in DHCPv6 Solicit, Request, and Information-request messages.

<26> Section 3.1.4.2: DHCPv6 clients on Windows Vista and Windows Server 2008 do not support the User Class Option. Otherwise, in Windows except Windows 98, Windows 2000, Windows Millennium Edition, Windows Server 2003, Windows Vista, and Windows Server 2008, DHCPv6 clients request the User Classes defined on the Windows DHCPv6 server whenever a user tries to set the User Class for the DHCPv6 client by executing "Ipconfig /setclassid6" or whenever a user tries to see the User Classes defined on the DHCPv6 server by executing "Ipconfig /showclassid6".

<27> Section 3.1.5.1: Windows DHCPv4 clients parse each of the options in the DHCPOFFER received and silently discard the message if any of the options do not conform to the syntax. If the DHCPv4 client has requested a specific IP Address, it chooses the DHCPOFFER which has an allocated IP address value that is the same as the requested IP address.

<28> Section 3.1.5.1: All Windows DHCPv4 clients include a Vendor Class Identifier Option (Option 60) in DHCPDISCOVER, DHCPREQUEST, and DHCPINFORM messages.

<29> Section 3.1.5.1: By default, Windows DHCPv4 clients do not send the User Class Option in the DHCPv4 messages. Users can configure any data string value to be sent as the User Class value by the DHCPv4 client to the server.

Windows DHCPv4 clients using BOOTP to boot from the network send the Default BOOTP class (as defined in section 2.2.6) as their User Class.

<30> Section 3.1.5.1: Windows XP and Windows Server 2003 DHCPv4 clients request only Option Code 249 in the Parameter Request List. Otherwise, Windows DHCPv4 clients request both Option Code 121 and Option Code 249 in the Parameter Request List.

<31> Section 3.1.5.2: All versions of Windows Vista and Windows Server 2008 and later will insert the last option in the message.

<32> Section 3.1.5.2: The ANDROID_METERED option is not supported in Windows 10 v1909 or Windows Server v1909 or earlier.

<33> Section 3.1.5.3: Windows DHCPv6 clients parse each of the options in the Advertise message received and silently discard the message if any of the options do not conform to the syntax.

<34> Section 3.2.5.1: Administrative controls were introduced in Windows Server 2008 R2 DHCPv4 servers.

<35> Section 3.2.5.1: Windows DHCPv4 servers includes all the standard and requested options in the reply.

<36> Section 3.2.5.2: Administrative controls were introduced in Windows Server 2008 R2 DHCPv4 servers.

<37> Section 3.2.5.2: Windows DHCPv4 servers interpret all unrecognized User Classes (including cases where the client sends a User Class option of length zero or where the client does not send the User Class option) to be the Default User Class.

<38> Section 3.2.5.2: Windows 2000 Server and Windows Server 2003 DHCPv4 servers send the Classless Static Route information to clients in Option 249, even if the client requests both Option Code 121 and Option Code 249. Otherwise, in applicable Windows Server releases servers send the Classless Static Route information to clients in Option 121 if the client requests both Option Code 121 and Option Code 249 in the Parameter Request List.

<39> Section 3.2.5.3: Windows DHCP servers ignore the Vendor Class Option.

<40> Section 3.2.5.4: Administrative controls were introduced in Windows Server 2008 R2.

<41> Section 3.2.5.4: In applicable Windows Server releases the server sends one or more User Class options depending on whether one or more User Classes are configured on the DHCPv4 server.

<42> Section 3.2.5.4: In applicable Windows Server releases, a DHCPv4 server can be administratively authorized using the mechanism specified in Appendix B.

<43> Section 3.2.5.4: In applicable Windows Server releases, DHCPv4 servers do not reply if no subnets are configured on the DHCPv4 server.

<44> Section 3.2.5.4: In applicable Windows Server releases, DHCPv4 servers do not reply if no subnets are configured on the DHCPv4 server.

<45> Section 3.2.5.5: A DHCPv6 server in Windows Server 2008 does not support User Class Option. Otherwise, in applicable Windows Server releases, DHCPv6 servers send one or more User Class Options depending on whether one or more User Classes are configured on the DHCPv6 server.

<46> Section 3.2.5.5: A DHCPv6 server on Windows Server 2008 does not support User Class Option. Otherwise, in applicable Windows Server releases, DHCPv6 servers send one or more User Class Options depending on whether one or more User Classes are configured on the DHCPv6 server.

<47> Section 3.2.5.5: In applicable Windows Server releases, a DHCP server can be administratively authorized using the mechanism specified in Appendix B.

<48> Section 3.2.5.5: In applicable Windows Server releases, DHCP servers reply even if no subnets are configured on the DHCPv6 server.

<49> Section 3.2.5.5: In applicable Windows Server releases, DHCP servers reply even if no subnets are configured on the DHCPv6 server.

<50> Section 3.3: In applicable Windows Server releases, the DHCP server implements Rogue Detection.

<51> Section 3.3: In applicable Windows Server releases, an authorization check is performed after each hour by default by the DHCP server. The time interval is configurable, and the minimum time interval is 5 minutes.

<52> Section 3.3: In applicable Windows Server releases, the time interval after which the authorization check is done does not vary based on the authorization state of a DHCP server.

<53> Section 3.3.5.1: In applicable Windows Server releases, the maximum number of retries for sending the DHCPINFORM message in the Rogue Detection mechanism is 4 for DHCP servers.

<54> Section 3.3.5.1: In Rogue Detection, after all retry attempts to send the DHCPINFORM message are exhausted, DHCP servers on Windows 2000 Server and Windows Server 2003 consider themselves authorized. Otherwise, in applicable Windows Server releases, the DHCP servers continue validation using the DHCPv6 Information-request message.

<55> Section 3.3.5.2: In applicable Windows Server releases, the maximum number of retries for sending DHCPv6 Information-request messages in Rogue Detection is 4 for DHCP servers.

<56> Section 3.3.6: In applicable Windows Server releases, the maximum number of retries is 4 for DHCP servers.

<57> Section 3.3.6: In applicable Windows Server releases, the server waits 2 seconds after sending a DHCPINFORM message to receive DHCPACK messages when validating DHCP server authorization using Rogue Detection.

<58> Section 3.3.6: In Rogue Detection, after all retry attempts to send DHCPINFORM messages are exhausted, DHCP servers on Windows 2000 Server and Windows Server 2003 consider themselves authorized. Otherwise, in applicable Windows Server releases, the DHCP servers continue validation using DHCPv6 Information-request messages.

<59> Section 3.3.6: In applicable Windows Server releases, the maximum number of retries for sending DHCPv6 Information-request messages in Rogue Detection is 4 for DHCP servers.

<60> Section 3.3.6: In applicable Windows Server releases, the server waits 2 seconds after sending an Information-request message to receive Reply messages when validating DHCP server authorization using Rogue Detection.