Critical Client Services and Stack Components
Updated: July 6, 2005
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
The focus of this article is on core TCP/IP stack components, not on the many available services that use it. However, the stack itself relies upon a few services for configuration information and name and address resolution. A few of these critical client services are discussed here.
Automatic Client Configuration and Media Sense
One of the most important client services is the Dynamic Host Configuration Protocol (DHCP) client. The DHCP client has an expanded role in Windows Server 2003. Its primary new feature is the ability to automatically configure an IP address and subnet mask when the client is started on a small private network without a DHCP server available to assign addresses (such as a home network). Another new feature is support for Media Sense, which can improve the roaming experience for portable device users.
If the TCP/IP is configured to dynamically obtain TCP/IP protocol configuration information from a DHCP server (instead of being manually configured with an IP address and other parameters), the DHCP client service is engaged each time the computer is restarted. The DHCP client service now uses a two-step process to configure the client with an IP address and other configuration information.
When the client is installed, it attempts to locate a DHCP server and obtain a configuration from it. Many TCP/IP networks use DHCP servers that are administratively configured to allocate TCP/IP configuration information to clients on the network. If this attempt to locate a DHCP server fails, the Windows Server 2003 DHCP client uses one of the following:
If Automatic Private IP Addressing (APIPA) is selected, TCP/IP automatically selects an IP address from the IANA-reserved class B network 169.254.0.0 with the subnet mask 255.255.0.08. The DHCP client tests (using a gratuitous ARP) to make sure that the IP address that it has chosen is not already in use. If it is in use, it selects another IP address (it does this for up to 10 addresses). Once the DHCP client has selected an address that is verifiably not in use, it configures the interface with this address. APIPA allows single subnet home office or small office networks to use TCP/IP without static configuration or the administration of a DHCP server. Note that APIPA does not configure a default gateway. Therefore, only local subnet traffic is possible.
If an alternate configuration is selected, TCP/IP is configured with the alternate configuration settings. Alternate configuration is useful when a computer is used on more than one network, at least one of the networks does not have a DHCP server, and an APIPA configuration is not wanted. For example, if you have a laptop computer that you use both at the office and at home, it is useful to configure TCP/IP for an alternate configuration. At the office, the laptop uses a DHCP-allocated TCP/IP configuration. At home, where there is no DHCP server present, the laptop automatically uses the alternate configuration, which provides easy access to home network devices and the Internet and allows seamless operation on both networks, without the manual reconfiguration of TCP/IP settings.
You can select whether to use APIPA or an alternate configuration from the Alternate Configuration tab from the properties of the TCP/IP protocol in the Network Connections folder.
Once configured for either APIPA or an alternate configuration, TCP/IP continues to check for a DHCP server in the background every 5 minutes. If a DHCP server is found, the APIPA or alternate configuration information is abandoned, and the configuration offered by the DHCP server is used instead.
If the DHCP client has previously obtained a lease from a DHCP server, the following modified sequence of events occurs:
If the client’s lease is still valid (not expired) at boot time, the client tries to renew its lease with the DHCP server. If the client fails to locate a DHCP server during the renewal attempt, it tries to ping the default gateway that is listed in the lease. If pinging the default gateway succeeds, the DHCP client assumes that it is still located on the same network where it obtained its current lease and continues to use the lease. By default, the client attempts to renew its lease in the background when half of its assigned lease time has expired.
If the attempt to ping the default gateway fails, the client assumes that it has been moved to a network that has no DHCP services currently available (such as a home network), and autoconfigures itself as described above. Once autoconfigured, it continues to try to locate a DHCP server every 5 minutes, in the background.
Media Sense support was added in NDIS 5.0. It provides a mechanism for the network interface card to notify the protocol stack of media connect and media disconnect events. Windows Server 2003 TCP/IP utilizes these notifications to assist in automatic configuration. For instance, in Windows NT 4.0, when a portable computer was located and DHCP was configured on an Ethernet subnet, and then moved to another subnet without rebooting, the protocol stack received no indication of the move. This meant that the configuration parameters became stale, and not relevant to the new network. Additionally, if the computer was shut off, carried home and rebooted, the protocol stack was not aware that the network interface card was no longer connected to a network, and again stale configuration parameters remained. This could be problematic, as subnet routes, default gateways, and so on, could conflict with dial-up parameters.
Media Sense support allows the protocol stack to react to events and invalidate stale parameters. For instance, if a computer running Windows Server 2003 is unplugged from the network (assuming the network interface card supports Media Sense), after a damping period implemented in the stack (currently 3 seconds), TCP/IP will invalidate the parameters associated with the network which has been disconnected. The IP address(es) will no longer allow sends, and any routes associated with the interface are invalidated. You can make the network connection status when connected visible on the taskbar by selecting a connection, right-clicking it, clicking Properties, and then selecting the Show icon in taskbar when connected check box. The network connection icon will also appear automatically with a red “X” when the adapter is having a connectivity problem.
If an application is bound to a socket that is using an invalidated address, it should handle the event and recover in a graceful way, such as attempting to use another IP address on the system or notifying the user of the disconnect.
DNS Dynamic Update Client
Windows Server 2003 includes support for DNS dynamic updates as described in RFC 2136. Every time there is an address event (new address or renewal), the DHCP client sends option 81 and its fully qualified name to the DHCP server, and requests the DHCP server to register a DNS pointer (PTR) resource record (RR) on its behalf. The DHCP client handles the dynamic update of the address (A) RR on its own. This is done because only the client knows which IP addresses on the host map to that name. The DHCP server may not be able to properly do the A RR registration because it has incomplete knowledge. However, the DHCP server can be configured to instruct the client to allow the server to register both records with the DNS. Registry parameters associated with the DNS dynamic update client are documented in Appendix C.
The Windows Server 2003 DHCP server handles option 81 requests as specified in the Internet draft titled "The DHCP Client FQDN Option" (draft-ietf-dhc-fqdn-option-0x.txt). If a Windows Server 2003 DHCP client obtains an IP address configuration from a down-level DHCP server that does not handle option 81, it registers a PTR RR on its own. The Windows Server 2003 DNS server is capable of handling dynamic updates.
Statically configured (non-DHCP) clients register both the A and PTR RRs with the DNS server themselves.
DNS Resolver Cache Service
Windows Server 2003 includes a caching DNS resolver service, which is enabled by default. For troubleshooting purposes, this service can be viewed, stopped, and started like any other Windows service. The caching resolver reduces DNS network traffic and speeds name resolution by providing a local cache for DNS queries. Name query responses are cached for the TTL specified in the response (not to exceed the value specified in the MaxCacheEntryTtlLimit parameter), and future queries are answered from the cache, when possible. One interesting feature of the DNS Resolver Cache Service is that it supports negative caching. For example, if a query is made to a DNS server for a given host name and the response is negative, succeeding queries for the same name are answered (negatively) from the cache for NegativeCacheTime seconds (the default is 300). Another example of negative caching is that if all DNS servers are queried and none are available, for NetFailureCacheTime seconds (the default is 30) all succeeding name queries fail instantly, instead of timing out. This feature can save time for services that query the DNS during the boot process, especially when the client is booted from the network.
The DNS Resolver Cache Service has a number of other adjustable registry parameters, which are documented in Appendix C.