Export (0) Print
Expand All

6 Appendix A: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include released service packs:

  • Microsoft Windows 98 operating system

  • Windows 2000 operating system

  • Windows Millennium Edition operating system

  • Windows XP operating system

  • Windows Server 2003 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product 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 all versions of Windows, except Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 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 all versions of Windows, except Windows Server 2012 and Windows Server 2012 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.

In Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2, 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.1: Windows DHCPv4 servers send this option in the DHCPOFFER and DHCPACK messages, if configured to do so by the administrator.

<3> Section 2.2.2.1: Windows 98 and Windows Millennium Edition DHCPv4 clients do not support this option.

<4> Section 2.2.2.2: Windows 98 and Windows Millennium Edition DHCPv4 clients do not support this option.

<5> Section 2.2.2.3: Windows 98 and Windows Millennium Edition DHCPv4 clients do not support this option.

<6> Section 2.2.2.3: By default (if not overridden by this option), the TCP/IP stack instead computes the route metric based on link speed as follows for Windows 98, Windows Millennium Edition, Windows 2000, Windows XP, and Windows XP SP1 clients.

Link speed

Metric

Greater than 200 Mbps

0x0000000A (10)

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

0x00000014 (20)

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

0x0000001E (30)

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

0x00000028 (40)

Less than or equal to 500 Kbps

0x00000032 (50)

<7> Section 2.2.4: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 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". DHCPv6 clients on Windows Vista SP1 and Windows Server 2008 do not support the User Class Option.

<8> Section 2.2.4: Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 send one or more User Class Options depending on whether one or more User Classes are configured on the DHCP server. DHCPv6 server on Windows Server 2008 does not support User Class Option.

<9> Section 2.2.5: DHCPv6 Client support is implemented in Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. DHCPv6 server support is available in Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

<10> 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.

<11> 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".

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

<13> 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.

<14> Section 2.2.7: When sending with the E bit set to 0, all Windows DHCPv4 clients encode the host name using the OEM code page that was installed as the current system code page at system boot time. In all versions of Windows, except Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2, when sending with the E bit set to 1, the host name is encoded using UTF-8 encoding.

In Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2, 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> is read. If "DhcpUseE1" has a nonzero value, the host name is encoded in canonical IDNA and is sent with the E bit set to 1. 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 the registry value has a zero value or if it doesn’t exist, then the host name is sent with the E bit set to 0 using the OEM code page.

<15> 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 all versions of Windows Server except Windows Server 2012 and Windows Server 2012 R2, DHCPv4 servers treat FQDNs with the E bit set to 1 as being encoded using UTF-8 encoding. In Windows Server 2012 and Windows Server 2012 R2, 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.

<16> 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.

Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 DHCPv4 clients use both Option 121 and Option 249.

<17> Section 2.2.11: In all versions of Windows Server except Windows Server 2012 and Windows Server 2012 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 all versions of Windows except Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 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 Windows Server 2012 and Windows Server 2012 R2, the DHCP server sends the DHCPv4 Option Code 15 in the IDNA encoding in the DHCPOFFER message (see 3.1.5.1). If the client FQDN option (see 2.2.7) was sent in the canonical IDNA encoding by the DHCP client in the DHCPREQUEST message (see 3.1.4.1), then DHCPv4 Option Code 15 is sent in the IDNA encoding in the DHCPACK message (see 3.1.5.2). If the client FQDN option was not sent in the canonical IDNA encoding by the client in the DHCPREQUEST, then the domain name is sent in the OEM code page in the DHCPACK.

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

<19> 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.

<20> 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".

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

<22> Section 3.1.4.2: Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 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". DHCPv6 clients on Windows Vista and Windows Server 2008 do not support the User Class Option.

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

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

<25> 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.

<26> Section 3.1.5.1: Windows XP and Windows Server 2003 DHCPv4 clients request only option code 249 in the Parameter Request List. Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 DHCPv4 clients request both option code 121 and option code 249 in the Parameter Request List.

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

<28> Section 3.2.5.1: Administrative controls are implemented only by Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 DHCPv4 servers.

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

<30> Section 3.2.5.2: Administrative controls are implemented only by Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 DHCPv4 servers.

<31> 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.

<32> Section 3.2.5.2: Windows 2000 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. Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 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.

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

<34> Section 3.2.5.4: Administrative controls are implemented by Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

<35> Section 3.2.5.4: Windows Server sends one or more User Class Options depending on whether one or more User Classes are configured on the DHCPv4 server.

<36> Section 3.2.5.4: For Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2, a DHCPv4 server can be administratively authorized using the mechanism specified in Appendix B.

<37> Section 3.2.5.4: DHCPv4 servers on Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 do not reply if no subnets are configured on the DHCPv4 server.

<38> Section 3.2.5.4: DHCPv4 servers on Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 do not reply if no subnets are configured on the DHCPv4 server.

<39> Section 3.2.5.5: Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 DHCPv6 servers send one or more User Class Options depending on whether one or more User Classes are configured on the DHCPv6 server. DHCPv6 server on Windows Server 2008 does not support User Class Option.

<40> Section 3.2.5.5: Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 DHCPv6 servers send one or more User Class Options depending on whether one or more User Classes are configured on the DHCPv6 server. DHCPv6 server on Windows Server 2008 does not support User Class Option.

<41> Section 3.2.5.5: A DHCP server can be administratively authorized using the mechanism specified in Appendix B for Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

<42> Section 3.2.5.5: Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 DHCP servers reply even if no subnets are configured on the DHCPv6 server.

<43> Section 3.2.5.5: Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 DHCP servers reply even if no subnets are configured on the DHCPv6 server.

<44> Section 3.3: DHCP server on Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 implement Rogue Detection.

<45> Section 3.3: An authorization check is performed after every one hour by default by DHCP server on Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. The time interval after which the authorization check should be done is configurable and the minimum time interval is 5 minutes.

<46> Section 3.3: The time interval after which the authorization check is done does not vary based on the authorization state of a DHCP server on Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

<47> Section 3.3.5.1: The maximum number of retries for sending the DHCPINFORM message in the Rogue Detection mechanism is 4 for DHCP servers on Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

<48> 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. DHCP servers on Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 continue validation using the DHCPv6 Information-Request message.

<49> Section 3.3.5.2: The maximum number of retries for sending DHCPv6 Information-Request messages in Rogue Detection is 4 for Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 DHCP servers.

<50> Section 3.3.6: The maximum number of retries is 4 for DHCP servers on Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

<51> Section 3.3.6: Implementations on Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 wait 2 seconds after sending a DHCPINFORM message to receive DHCPACK messages when validating DHCP server authorization using Rogue Detection.

<52> 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. DHCP servers on Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 continue validation using DHCPv6 Information-Request messages.

<53> Section 3.3.6: The maximum number of retries for sending DHCPv6 Information-Request messages in Rogue Detection is 4 for Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 DHCP servers.

<54> Section 3.3.6: Implementations on Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 wait 2 seconds after sending an Information-Request message to receive Reply messages when validating DHCP server authorization using Rogue Detection.

 
Show:
© 2014 Microsoft