The focus of this paper 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 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 NIC 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 NIC 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 NIC 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 taskbarwhen 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.