August 19, 1994
The Microsoft® Windows NT™ Server 3.5 operating system includes key technologies that add value to both new and existing TCP/IP-based networks. In existing networks these new technologies simplify TCP/IP network administration, reduce administrative costs, and resolve common configuration problems. For new network installations they simplify the planning, configuration, and installation of the network, as well as server and client configurations. This paper begins with a review of TCP/IP and its benefits and shortcomings, and then introduces these two key technologies: Dynamic Host Configuration Protocol (DHCP) and Windows® Internet Naming Service (WINS).
The Transport Control Protocol and Internet Protocol (TCP/IP) is a wide-area network (WAN) protocol that provides:
Beyond the basic design features of TCP/IP, a network protocol needs to have broad-based support by both end-users and networking vendors. TCP/IP is the default protocol for the UNIX® environment, and therefore has gained wide acceptance among the UNIX community. Research on corporate bandwidth usage indicates that TCP/IP usage is on the rise, while IPX/SPX usage is on a slight decline.
Figure 1: Corporate Bandwidth Usage, Network World, Dec. 2, 1993
TCP/IP plays a critical role in today's enterprise networking environment. As a primary transport, TCP/IP is the clear choice over IPX/SPX, and is anticipated to become the primary transport protocol for corporate sites in 1994.
Figure 2: Primary Transport Protocol, Datamation, June 1, 1993
Perhaps the most significant indication of the widespread acceptance of TCP/IP is the rapid growth of the Internet. Based upon the TCP/IP protocol, the Internet has exploded to over 2,000,000 nodes and 16,000 networks!
Figure 3: Number of Total Nodes on the Internet by Year, Source: SRI International
However, with all of the success of TCP/IP, it has its shortcomings. In order to address all of the nodes than can participate in this large, scalable network, there is a price to pay.
Each computer running TCP/IP must have specific information to uniquely identify itself, the network that it is a member of, and the location for packets not bound for computers on the local network. This information is referred to as the TCP/IP address, subnet mask, and default gateway, respectively. Each of these addresses consists of a 32-bit number typically represented in dotted decimal format. For example, in a typical TCP/IP configuration, the TCP/IP address might be 101.200.42.101, the subnet mask 255.255.0.0, and the default gateway 101.200.42.1.
Such requirements can create serious administrative headaches in a large corporate environment. For example, a department orders a new computer and it comes pre-installed with all of the necessary software and hardware to connect to the corporate network. However, the computer cannot be attached to the network, nor can it access any TCP/IP-based networking resources until the network administrator provides the necessary client information. Furthermore, either a person from the "helpdesk" needs to physically go to the computer to enter the appropriate information, or the user needs to dig through documentation (written by MIS) on how to do it him/herself. The gating factor here is the ability of the user to correctly enter the necessary client information versus a technician entering the information at a high hourly rate.
Typical problems that occur in these environments are misconfigured computers, which cannot access the network due to incorrect addresses, and duplicate TCP/IP addresses. Duplicate addresses can occur when one user "assists" another by providing him/her with a configuration that "works," or when a computer is cloned and put on the network. Unfortunately, these types of problems are very difficult to detect, and require a resource-intensive analysis of network traffic in order to locate the computer with the duplicate TCP/IP address.
Consider the average user attempting to access information provided by a network resource. Typically, the user knows the name of the computer, such as ENGR_AIX, but not the computer's IP address. If the user is running an MS-DOS®-based computer with NFS client support or FTP'ing to the computer, the user will reference the computer by name, e.g. (ENGR_AI), and the system will access a host table containing a mapping between the computer name and the IP address.
Figure 4: Host Table Information for an NFS Client
The difficulty of the host table lies in its administration: who loads and maintains the information in these host tables? For typical NFS clients, the host table information resides on local computers, which means that either the users need to know enough about host files and TCP/IP addresses to update this information on their own, or someone from MIS needs to maintain the information on a server, and have the updated file downloaded periodically.
Some corporate environments implement the Domain Name System (DNS) that is server-based host table information, where the user needs only to specify the address of the DNS server. However, this does not alleviate the matter of updating the information; it simply pushes the responsibility to the MIS department. Although DNS is server-based, it is not dynamic, and must be manually updated whenever a computer name or IP address is changed.
The expense of administering a network is often considered a "fixed cost." To keep expenses down, companies must manage internal reorganization quickly and efficiently, minimizing the amount of time required by both the technician and the user who is waiting for his/her system to be part of the corporate network.
For example, with the typical naming structure, the DNS implementation of network addresses requires that each time a computer is renamed or physically moved to a new location, it must be reconfigured with both the new TCP/IP network address (to reflect its new subnet) and the DNS tables must be updated (to reflect the new client configurations).
Even a simple configuration change, such as a computer name, requires that the DNS tables be updated in order to locate the new computer on the network.
TCP/IP Limitations
There is a need to make TCP/IP administration easier and more flexible, both for the user and the network administrator.
Windows NT Advantages
In order to address the problem of dynamic addressing in a TCP/IP environment, Microsoft looked at the available technologies, focusing on dynamic and open solutions to this problem. As a founding member of the Internet Society, Microsoft worked with the Internet Engineering Task Force (IETF) and other vendors to propose an open standard that would address the dynamic addressing problems of TCP/IP-based networks. As a result of this effort, standards were proposed, as documented in the Internet Request For Comments (RFCs) #1533, #1534, #1541, and #1542. These proposed standards document the basis for the work being done at Microsoft to provide scaleable, dynamic TCP/IP addressing solutions in future versions of Microsoft systems products, both at the server and at the client level.
The goal of the TCP/IP projects at Microsoft is to provide 32-bit performance, the ease of configuration with TCP/IP that users have today with NetBEUI or AppleTalk®, and the ease of administration that can be provided with a dynamic and scaleable TCP/IP addressing capability. Additionally, no workstation configuration is necessary, and users do not need to know anything about the computer's TCP/IP address.
To explore how DHCP works we will consider "Exotic Excursions," a fictitious company with three Class C Internet addresses (200.192.0.x, 200.192.100.x, and 200.192.127.x). The following figure shows a simple network with one network server, and a single network client being added to the network.
Figure 5: DHCP Server and New Client
The Engineering department has a Windows NT Server Domain "ENGR" and a Windows NT Server-based computer, \\ENGR_AS1, with IP address of 200.192.0.2. The new client is a Windows NT-based computer with DHCP client support.
The Windows NT-based client computer starts Windows NT and issues a DHCPDISCOVER message (containing the MAC address and the computer name, which is picked up by the DHCP server. The DHCP server looks at the most recent table of available addresses, and, finding no references to that computer, offers an available address to the computer.
Figure 6: DHCP DISCOVER, DHCP OFFER Messages
Any DHCP server receiving the request (even across a BOOTP-relay router) and having a valid configuration setting for the requesting computer can then check to see if it has an address available. If there is an available address, the DHCP server will offer a DHCPOFFER response with the necessary configuration information and additional parameters; including the destination computer's network card address, the offered IP address, the appropriate subnet mask, the IP address of the offering DHCP server, the IP lease expiration date, and any other pertinent information specified in the additional parameters section of the original DHCPDISCOVER request.
Figure 7: DHCP REQUEST, DHCP ACK Messages
The DHCP client collects the offers presented by the responding DCHP servers and selects the most desirable configuration. The DHCP client then issues a DHCPREQUEST to the DHCP server accepting the offered address, and may request additional information (depending on the client's needs), including the default gateway, the WINS-based server IP address, and the DNS server IP address. The DHCP server responds with a DHCPACK message, assigning the IP lease and providing the requested information.
Figure 8: BOUND DHCP Client
When the DHCP client receives the DHCPACK (acknowledge), the DHCP client completes the initialization process of the TCP/IP stack and becomes a bound DHCP client, and is able to use the leased IP address until the lease requires renewal.
Now that the client computer has a valid IP address, let's turn to the process of registering the computer name on the network. In previous implementations of registering the network IP address and the computer name, the network administrator had to manually update the host's tables. Using the Windows Internet Naming Service (WINS), this process is handled at the system level by Windows NT Server.
WINS is designed to address the problem of locating network resources in a TCP/IP-based Microsoft network by automatically configuring and maintaining the computer name and IP-address mapping tables, while serving basic functions such as preventing duplicate network names. WINS is a complementary service to DHCP and has a complete, centralized tool for administration and configuration of the WINS servers, static name tables, and replication information.
Once the DHCP client is configured and bound, the client proceeds to register its name with the designated WINS server. The client issues a NAMEREGISTRATIONREQUEST message to the WINS-based server (a directed send) with the DHCP client's computer name and leased IP address.
Figure 9: Name Registration with WINS Server
The WINS-based server checks to see if the requesting computer name is unique on the network, and will respond with a positive or negative WINS name registration response message. If positive, the registration response will include the Time To Live (TTL) for the name registration. If negative, a duplicate name has been identified on the network (following an accepted challenge to the current owner), the name registration to the new DCHP client is declined, and the user is advised of the name conflict. We will discuss the renewal process for the IP address and the TTL for the name registration later. First, we want to expand our view of the Exotic Excursions computing environment, which now includes some additional hardware.
Figure 10: Expanded View of Exotic Excursions Computing Environment
Notice the changes from the initial configuration. The DNS server address that was passed back to the DHCP client is actually a UNIX server (ENGR_AIX) on the network. The Windows NT Server-based DCHP server is also a Remote Access Server with a dial-up (Point to Point) TCP/IP-based DHCP client (\\ENGR_NT2) that uses the same DHCP server as our newly-bound DHCP client.
DHCP and WINS are designed to be dynamic and scaleable in their implementations, addressing the needs of highly dynamic and mobile corporations while providing centralized configuration and administration of TCP/IP-based Microsoft networks. In order to meet these requirements, the configuration confirmation for the clients is time-limited (with some exceptions), which means that the clients typically need to update their information to the DHCP and WINS-based servers.
DHCP clients receive an IP address with a lease period. When that lease period expires, the clients may no longer use the given IP address. The goal for the client is to periodically negotiate the lease renewal with their DHCP servers with enough time remaining in the lease so the lease does not expire in the process. By default (although the network administrator can change the defaults), the client will begin the renewal process when 50% of the lease time has expired. It will send a directed message to the DHCP server requesting a lease renewal. If allowed, the DCHP server will automatically renew the lease.
However, if the DHCP server no longer exists, or the IP address of the DHCP server has changed, the client will broadcast a DHCPREQUEST when 87.5% of the lease has elapsed to look for any DHCP server. If no DHCP server can be located, the lease may expire, in which case the client will discontinue the use of the IP address and will begin the initialization process with a DHCPDISCOVER message.
When a DHCP client contacts a DHCP server, the server may determine that the client is misconfigured (the computer has moved to a different subnet) or that the server can no longer honor the client's IP address. The DHCP server can issue a DHCPNAK (negative acknowledgment), forcing the DHCP client to re-initialize itself and request a new IP address. This can happen when the client computer has been moved between docking stations, and therefore may be located on a different subnet. It will need a new IP address to successfully access the desired network resources.
The renewal process for a WINS-based client is less obvious, as the NetBIOS over TCP/IP support (NBT) automatically registers the computer name with the WINS-based server when an NBT client process is started. Therefore, in many cases the renewal process is automatic, with the WINS-based server automatically reissuing a new TTL with each NBT registration. With each new TTL, a timer is reset in the system to issue an NBT name registration with the WINS-based server, should the computer be in a state of inactivity and the timer expire.
Now let's look at the Exotic Excursions environment with routers and multiple subnets.
Figure 11: Network with Routers and Multiple Subnets
Notice that there are a number of changes in the environment. There are two routers, two DHCP servers, and two WINS-based servers (one \\RSDV_AS1 is both a DHCP and a WINS-based server). Later, we will review the capabilities of the DHCP and WINS administrative tools, and reflect on how the tools and capabilities address the needs of a larger, more heterogeneous corporate environment.
What happens when a computer in the R&D domain wants to locate a resource in the ENGR domain? For the purpose of this example, \\RSDV_WFW wants to find the resources available on \\ENGR_NT1. To locate the computer's IP address, \\RSDV_WFW sends a NAMEQUERYREQUEST to its primary WINS server, \\RSDV_AS1, which it knows to be at 200.192.100.3. It requests that the server look in the database to find the entry for \\ENGR_NT1 and respond with the IP address of the desired computer. The WINS-based server responds with a NAMEQUERYRESPONSE to \\RSDV_WFW with the computers IP address, at which time the entry is cached at the requesting client computer.
Figure 12: Name Query Request and Response
Now that \\RSDV_WFW has the necessary IP address, it establishes a TCP connection, followed by a session message (request) to \\ENGR_NT1 (at 200.192.0.6) and the resource connection is established.
Figure 13: TCP Connection
The DHCP administration tool is designed to organize the configuration of the network resources into logical groupings of computers on the same physical wire; the same as an Internet subnet or an equivalent network node on a private network. The administration tool allows the network administrator to define global and scope-specific configuration settings in order to identify routers.
In the example below, there are three scopes defined, 11.101.12.198, 11.101.13.53, and 127.0.0.1, which is the local computer. Focusing on the 11.101.0.0 scope, you can see the global default information.
Figure 14: Dynamic Host Protocol Configuration Admin Tool
Each scope is defined by specific properties, which are established by the DHCP administrator. The administrator defines the subnet ID, the subnet mask, and the primary DHCP server. He/she also defines the pool of available IP addresses in that specific scope and any exclusion ranges to avoid, therefore allowing legacy systems to retain their established IP addresses.
Figure 15: DHCP Administrator Scope Properties Dialog Box
Each scope definition receives a name so that it can be easily identified by any network administrator, along with additional comments or questions.
In some cases, computers outside of the Microsoft network may access computers that participate in the DHCP/WINS environment but do not have an easy way to inquire for the IP address of the server. Instead of forcing the user of the legacy computer to be manually updated with the dynamic address of the DHCP client, the DHCP administrator may elect to specify a reserved client. A reserved client is issued an infinite lease of the IP address; therefore, any legacy computer attempting to locate the DHCP client will be able to consistently access the computer via the now-static IP address.
Figure 16: DHCP Administrator Reserved Client
Another option with the DHCP Administrator tool is the ability to review the client lease information on a per-scope basis, allowing the administrator to review the outstanding leases and associate them with the client names and their MAC-layer addresses.
Figure 17: DCHP Administrator Client Lease Review Dialog
For each scope-member, options can be configured for the scope to provide additional configuration information to the scope members. The scope options contain an array of parameters that the DHCP administrator may configure. Note that this same information can be set globally as well, via a similar Global Option Settings dialog box.
Figure 18: DHCP Scope Options
The WINS administration tool is designed to assist the network administrator configure the WINS-based servers and monitor activity. Note that the information presented is very detailed in nature. Key pieces of information are: 1) the number of name queries received by the WINS-based server, and 2) the number of successful and less-than-successful responses. In the example below, the Windows NT development team is running WINS-based clients, but when they perform a name query for computers outside of the development team, the WINS-based server cannot locate the computer, resulting in a Query Failure. At the time this screen shot was taken, only about 1% of the total computers on the Microsoft network were WINS-based clients, hence the high number of failures.
Figure 19: WINS Administrator Tool
The WINS Administrator tool allows the configuration of various parameters for the WINS-based server, including which WINS-based server to focus on, the static mappings for the server, the replication information, and the database in use.
Figure 20: WINS Administration Options
The Static Mapping options allows the network administrator to manually configure WINS mapping information for non-WINS clients, similar to the old host table information.
Figure 21: Static Mappings (Local)
This static mapping information can be entered individually for each computer, or it can be array loaded from a file containing the necessary mappings. The latter minimizes the amount of work required to create an interoperative environment by importing the DNS host tables from the UNIX DNS server.
WINS-based servers specify the name registration TTL by specifying an Extinction Interval, which is defined by the administrator. Should an NBT client's re-registration not be received prior to the extinction time, the name will no longer be registered with the WINS server. Also, the replication process can be configured in this dialog, which will be discussed later.
Figure 22: WINS Server Configuration
Now let's take a look at how DHCP and WINS handle error conditions when the primary DHCP or WINS server is down.
The following configuration shows the expansion of the Exotic Excursions network to include the scope settings and the enterprise. Note that the range of IP addresses has been split for both the ENGR and R&D scopes.
Figure 23: Exotic Excursions Enterprise Backbone
In the table below, the IP address ranges have been configured given an address range for the fourth octet of 1-254 for each scope (which is typical for a Class C address).
| Type of Range | IP Address * | Lease Period | |
| Fixed address: routers, DHCP, WINS servers | 1-5 | n/a | |
| Primary DHCP server scope | 6-120 | 2 weeks | |
| Backup DHCP server scope | 121-235 | 1 week | |
| MIS tertiary DHCP server scope | 236-245 | 1 day | |
| Reserved for future use | 245-254 | n/a | |
| * IP address of the (200.192.x.y, where x {0,100,127}) | |||
For example, the DCHP Server \\ENGR_AS1 (the primary DHCP server for the ENGR scope) has available addresses 200.192.0.6 through 200.192.0.120 for DHCP clients in the ENGR scope. The backup DHCP server \\RSDV_AS1 has available addresses 200.192.0.121 through 200.192.0.235. Therefore, if one DCHP server fails, either controller can support at least 115 DHCP clients in the ENGR scope.
| DHCP Server //RSDV_AS1 |
DHCP Server //ENG_AS1 |
DHCP Server //MIS_AS1 |
|
| R&D Scope | R&D Scope | R&D Scope | |
| Primary WINS Server 200.192.100.3 Backup WINS Server 200.192.0.4 IP Address Pool Start: 200.192.100.6 End: 200.192.100.120 Exclusion Range Start: 200.192.100.101 End: 200.192.100.101 |
Primary WINS Server 200.192.100.3 Backup WINS Server 200.192.0.4 IP Address Pool Start: 200.192.100.121 End: 200.192.100.235 |
Primary WINS Server 200.192.100.3 Backup WINS Server 200.192.0.4 IP Address Pool Start: 200.192.100.236 End: 200.192.100.245 |
|
| R&D Scope | R&D Scope | R&D Scope | |
| Primary WINS Server 200.192.0.4 Backup WINS Server 200.192.100.3 IP Address Pool Start: 200.192.0.121 End: 200.192.0.235 |
Primary WINS Server 200.192.0.4 Backup WINS Server 200.192.100.3 IP Address Pool Start: 200.192.0.6 End: 200.192.10.120 |
Primary WINS Server 200.192.0.4 Backup WINS Server 200.192.100.3 IP Address Pool Start: 200.192.0.236 End: 200.192.0.245 |
|
However, in many cases, both servers will regularly be online, and one computer may only be offline for a short period of time (for example, one day). Depending on the length of the lease period (for example, 3 months), only a few computers would need renewal during the period that the computer was offline. Therefore, you could have a smaller lease pool configured on the backup DHCP server than the primary server, effectively providing better utilization of the IP address space available.
What if we are powering up \\ENGR_NT1, and our primary DHCP server (\\ENGR_AS1) is offline? If we remember that the DHCPREQUEST message can be relayed by BOOTP Relay routers, then the request is relayed across the router at 200.192.0.1 to \\RSDV_AS, which will respond, but with a different IP address. The scope for that subnet is different, so instead of \\ENGR_NT1 having the IP address of 200.192.0.6 that was provided by the R&D scope from the DHCP server \\ENGR_AS1, it now has the IP address 200.192.0.129, provided by the DHCP server \\RSDV_AS1.
Figure 24: Primary DHCP Serve Offline
In a situation where a WINS-based server is offline or otherwise unavailable, the DHCP client will contact the backup WINS-based server via the IP address that was returned during the DHCP REQUEST, DHCPACK process. WINS-based servers replicate their databases to the other known WINS-based servers on the network with the time interval specified by the network administrator.
WINS-based servers maintain current databases via replication partners. Each WINS-based server is a push partner or pull partner with at least one other WINS-based server. A pull partner is a WINS-based server that pulls in database replicates. A push partner is a WINS-based server that sends replicas to its pull partner upon receiving a request. When the server's pull partner replicates the information, it pulls replicates by asking for all records with a higher version number than the last record stored from the last replication for that server. All mapping changes converge within the replication period for the entire WINS system.
Replication is triggered when a WINS-based server polls another server to get a replica based on an interval or time set by the administrator. Replication is also triggered when a WINS-based server reaches a threshold set by the administrator, which is a specified time or an update count for registrations and changes. In this case, the server notifies other servers that it has reached its threshold, and the other servers pull replicates. Replication pairs also have the advantage of specifying replication interval, so if servers are connected via slow links—such as international connections—you can specify specific replication intervals.
Figure 25: Replication of WINS-based Server in U.S. and Australia
Therefore, in the above example, we would replicate WINS-based server data in the U.S. every fifteen minutes, and in Australia every 30 minutes, but only every 12 hours between the U.S. and Australia.
TCP/IP is a widely accepted, routable, WAN protocol that is unparalleled in its deployment worldwide as a defacto standard for wide-area networking. However, it has historically had high costs associated with the configuration and administration of network clients. Microsoft, as a member of the Internet Engineering Task Force (IETF), has been working with other IETF members to deploy dynamic IP addressing technology. The result is the Dynamic Host Configuration Protocol (DHCP), an open standard for TCP/IP-based networks.
Microsoft has also developed the Windows Internet Naming Service (WINS), which allows dynamic host table mapping from a computer's IP address to its respective NetBIOS name, thus eliminating the need to manually maintain the host tables in a network.
Microsoft networking, using DHCP and WINS functionality, provides easy administration on TCP/IP-based networks for computers running Windows for Workgroups 3.11 (and the future release, called Windows 95), Windows NT Workstation, and Windows NT Server.