The core protocols that TCP/IP uses to provide communication between computers—the Internet Protocol (IP), the Transmission Control Protocol (TCP), and the User Datagram Protocol (UDP)—rely on several other services to perform their functions. Some of these services take the form of independent protocols, such as the Address Resolution Protocol (ARP), which runs on every TCP/IP computer and enables IP to discover the hardware address of a computer using a particular IP address. Other services, such as the Dynamic Host Configuration Protocol (DHCP) and the Domain Name System (DNS), are both protocols and applications that run on their own servers.
In Chapter 6, "Network Layer Protocols," and Chapter 8, "TCP/IP Fundamentals," you learned about the advantages of TCP/IP's self-contained addressing system and about the nature of IP addresses themselves. Although there are many advantages of IP addressing, there are several significant problems with it, including that every computer on the network must have a unique IP address. This requirement complicates the process of configuring the TCP/IP client. The administrators of a TCP/IP network must be sure that every computer is configured properly, which means keeping track of the IP address assignments so that no duplication occurs. On a small network, configuring the individual TCP/IP workstations and keeping track of their IP addresses is relatively painless, but on a large corporate internetwork, it can be a monumental task.
Over the years, the developers of the TCP/IP protocols have worked out several solutions that address the problem of configuring the TCP/IP settings for large numbers of workstations. The first of these was the Reverse Address Resolution Protocol (RARP), which was designed for diskless workstations that had no means of permanently storing their TCP/IP settings. RARP is essentially the opposite of ARP. Whereas ARP broadcasts an IP address in an effort to discover its equivalent hardware address, RARP broadcasts the hardware address, as shown in Figure 10.1. An RARP server then responds by transmitting the IP address assigned to that client computer. RARP was suitable for use with diskless workstations on early TCP/IP networks, but it isn't sufficient for today's needs because it supplies the computer with only an IP address. It provides none of the other settings needed by a typical workstation today, such as a subnet mask and a default gateway.
Figure 10.1 A workstation that uses RARP receives an IP address from a RARP server in response to a broadcast message containing the client's hardware address
For more information about ARP, including its message format, which is the same as that used by RARP, see Lesson 1: TCP/IP Protocols, in Chapter 8, "TCP/IP Fundamentals."
The next attempt at an automatic TCP/IP configuration mechanism was called the Bootstrap Protocol (BOOTP). BOOTP does more than RARP, which is why it is still used today, whereas RARP is not. BOOTP enables a TCP/IP workstation to retrieve settings for all of the configuration parameters it needs to run, including an IP address, subnet mask, default gateway, and DNS server addresses. A workstation can also download an executable boot file from a BOOTP server, using the Trivial File Transfer Protocol (TFTP), which makes it clear that BOOTP, like RARP, was designed for diskless workstations. The drawback of BOOTP is that although it is capable of performing all the TCP/IP client communication tasks required by today's computers, an administrator must still specify the settings for each workstation on the BOOTP server. There is no mechanism for automatically assigning a unique IP address to each computer, nor is there any means of preventing two computers from receiving the same IP address due to administrator error.
Microsoft developed DHCP for the express purpose of addressing the shortcomings in RARP and BOOTP. DHCP is based on BOOTP to a great extent, but instead of simply feeding predetermined configuration parameters to TCP/IP clients, DHCP can dynamically allocate IP addresses from a pool and reclaim them when they are no longer in use. This prevents workstations from being assigned duplicate IP addresses and enables administrators to move computers around between subnets without manually reconfiguring them. In addition, DHCP can deliver a wide range of configuration parameters to TCP/IP clients, including platform-specific parameters added by third-party developers.
DHCP consists of three components: a client, a server, and the protocol that they use to communicate with each other. Most TCP/IP implementations these days have DHCP integrated into the networking client, even if the operating system doesn't specifically refer to it as such. On a Microsoft Windows 2000 system, for example, in the Internet Protocol (TCP/IP) Properties dialog box, when you select Obtain An IP Address Automatically, you are actually activating the DHCP client. The DHCP server is an application that runs on a computer and exists to service requests from DHCP clients. The Windows 2000 Server and Microsoft Windows NT Server operating systems both include the DHCP server application, but there are many other implementations available for other platforms as well. DHCP is widely used on UNIX, Novell NetWare, and Microsoft networks. Any DHCP client can retrieve configuration settings from a DHCP server running on any platform. Despite having been developed largely by Microsoft, DHCP is based on public BOOTP standards and is published as an open TCP/IP standard.
The basic components of DHCP are defined in Request for Comments (RFC) 2131, published by the Internet Engineering Task Force (IETF). RFC 2132 defines additional DHCP options and vendor extensions that can supply other types of information to client computers.
The core function of DHCP is to assign IP addresses. This is the most complicated part of the service, because the IP address must be unique for each client computer. The DHCP standard defines three types of IP address allocation, as follows:
Manual allocation is the functional equivalent of BOOTP address assignment. This option saves the least administrative labor, but it is necessary for systems that require permanently assigned IP addresses, such as Internet servers that have DNS names associated with specific addresses. Administrators could conceivably configure the TCP/IP clients of these computers directly, but using the DHCP server for the assignment prevents IP addresses from being accidentally duplicated.
Automatic allocation is a fitting solution for networks on which administrators rarely move workstations between subnets. Assigning IP addresses from a pool (called a scope) eliminates the need to furnish a specific address for each computer and prevents address duplication. Permanently assigning those addresses minimizes the network traffic generated by DHCP client/server communications.
Once the server is configured, dynamic allocation completely automates the TCP/IP client configuration process, enabling administrators to add, remove, and relocate computers as needed. When a computer boots, the server leases an address to the computer for a given period of time, renews the lease if the computer remains active, reclaims the address when it is no longer in use, and returns the address to the pool.
Communications between DHCP clients and servers use a single message format, which is illustrated in Figure 10.2. All DHCP messages are carried within UDP datagrams, using the well-known port numbers 67 at the server and 68 at the client, as established by the Internet Assigned Numbers Authority (IANA).
Figure 10.2 The DHCP message format
The functions of the fields in the DHCP message are as follows:
The options field is where the DHCP message carries all of the TCP/IP parameters assigned to a client, except for the IP address. Each option consists of three subfields, as shown in Figure 10.3.
Figure 10.3 The DHCP option format
The functions of the option subfields are as follows:
Although it sounds like a contradiction in terms, there is one DHCP option that is required. This is the DHCP Message Type option, which contains a code that specifies the function of each message. There are eight possible values for this option, as follows:
DHCP clients initiate communication with servers when they boot for the first time, as illustrated in Figure 10.4. The client generates a series of DHCPDISCOVER messages, which it transmits as broadcasts. At this point, the client has no IP address, and is said to be in the init state. Like all broadcasts, these transmissions are limited to the client's local network, but administrators can install a DHCP Relay Agent service on a computer on the local area network (LAN), which relays the messages to DHCP servers on other networks. This enables a single DHCP server to service clients on multiple LANs.
When a DHCP server receives a DHCPDISCOVER message from a client, it generates a DHCPOFFER message containing an IP address and whatever other optional parameters the server is configured to supply. In most cases, the server transmits this as a unicast message directly to the client. Because the client broadcasts its DHCPDISCOVER messages, it may receive DHCPOFFER responses from multiple servers. After a specified period of time, the client stops its broadcasting and accepts one of the offered IP addresses. To signal its acceptance, the client generates a DHCPREQUEST message containing the address of the server from which it is accepting the offer along with the offered IP address. Because the client has not yet configured itself with the offered parameters, it transmits the DHCPREQUEST message as a broadcast. This broadcast notifies the server that the client is accepting the offered address and also notifies the other servers on the network that the client is rejecting their offers.
Figure 10.4 DHCP client/server communications
On receipt of the DHCPREQUEST message, the server commits the offered IP address and other settings to its database using a combination of the client's hardware address and the offered IP address as a unique identifier for the assignment. This is known as the lease identification cookie. To conclude its part of the transaction, the server sends a DHCPACK message to the client, acknowledging the completion of the process. If the server cannot complete the assignment (because it has already assigned the offered IP address to another system, for example), it transmits a DHCPNAK message to the client and the whole process begins again.
As a final test, the client performs an ARP test to ensure that no other system on the network is using the assigned IP address. If no response is received, the DHCP transaction is completed and the client enters what is known as the bound state. If another system does respond, the client can't use the IP address and transmits a DHCPDECLINE message to the server, nullifying the transaction. The client can then reissue a series of DHCPDISCOVER messages, restarting the whole process.
The process by which a DHCP server assigns configuration parameters to a client is the same whether the server uses manual, automatic, or dynamic allocation. With manual and automatic allocation, this process is the end of the DHCP client/server communications. The client retains the settings assigned to it by the server until someone explicitly changes them or forces a reassignment. However, when the server dynamically allocates settings, the client leases its IP address for a certain period of time (configured at the server) and must renew the lease to continue using it.
The length of an IP address lease is typically measured in days and is generally based on whether computers are frequently moved around the network or whether IP addresses are in short supply. Shorter leases generate more network traffic but enable servers to reclaim unused addresses faster. For a relatively stable network, longer leases reduce the amount of traffic that DHCP generates.
The lease renewal process, illustrated in Figure 10.5, begins when a bound client reaches what is known as the renewal time value, or T1 value, of its lease. By default, the renewal time value is 50 percent of the lease period. When a client reaches this point, it enters the renewing state and begins generating DHCPREQUEST messages. The client transmits the messages to the server that holds the lease as unicasts, unlike the broadcast DHCPREQUEST messages the client generates while in the init state. If the server is available to receive the message, it responds with either a DHCPACK message, which renews the lease and restarts the lease time clock, or a DHCPNAK message, which terminates the lease and forces the client to begin the address assignment process again from the beginning.
Figure 10.5 The DHCP lease renewal process
If the server does not respond to the DHCPREQUEST unicast message, the client continues to send them until it reaches the rebinding time value or T2 value, which defaults to 87.5 percent of the lease period. At this point, the client enters the rebinding state and begins transmitting DHCPREQUEST messages as broadcasts, soliciting an address assignment from any DHCP server on the network. Again, a server can respond with either a DHCPACK or DHCPNAK message. If the lease time expires with no response from any DHCP server, the client's IP address is released and all of its TCP/IP communication ceases, except for the transmission of DHCPDISCOVER broadcasts.
It is also possible for a client to terminate an IP address lease at any time by transmitting a DHCPRELEASE message containing the lease identification cookie to the server. On a Microsoft Windows system, for example, you can do this manually, using the IPCONFIG.EXE utility in Windows 2000 and Windows NT or the WINIPCFG.EXE utility in Microsoft Windows Me, Microsoft Windows 98, or Microsoft Windows 95. For more information about these utilities, see Lesson 2: TCP/IP Utilities, later in this chapter.
Run the DHCP video located in the Demos folder on the CD-ROM accompanying this book for a demonstration of DHCP address assignment.
IP addresses may be an excellent way for computers to recognize and communicate with each other, but they are not exactly user-friendly. Imagine having to remember the IP address for every site that you visit while surfing the Web or for every computer on the local network that has drives or printers you want to access. To make TCP/IP more user-friendly, its developers created host names, which enable administrators to assign friendly names to the computers on a network and resolve them into IP addresses as needed.
A host name is simply a name used to represent a computer. The names of the hosts on a network are stored in a text file called HOSTS on each computer. The HOSTS file also contains the IP address of the computer associated with each of those names. To communicate with another computer on the network by specifying its host name, your computer must first resolve that name into its IP address by looking it up in the HOSTS file. Name resolution is the process of converting a name into its equivalent IP address. The name resolution process is essential, because an IP datagram must use an IP address, and not a name, to identify its destination.
Every computer must have its own HOSTS file, which is why this name resolution method is not widely used today. In the early days of the Internet, when the entire network consisted of a few dozen computers, administrators regularly downloaded updated HOSTS files containing entries for all of the computers on the Internet. Today a HOSTS file for the entire Internet would be enormous, even if you could compile one, and requiring every computer to download it would bring the entire network to its knees. However, if there are computers on the network that you visit frequently, you can put them in a HOSTS file on your computer to bypass the more elaborate name resolution methods used today.
When the Internet outgrew the HOSTS file, it also outgrew the flat namespace the file used. There were too many systems to assign each a unique single name. To address these problems, the TCP/IP developers created the Domain Name System (DNS), which enables administrators to assign hierarchical names to the computers on a network and resolve them into IP addresses as needed. The DNS is defined in two primary IETF documents: RFC 1034, "Domain Names: Concepts and Facilities," and RFC 1035, "Domain Names: Implementation and Specification." There are many additional RFCs that provide updates and augmentations to the DNS.
Whenever you use a DNS name to refer to a TCP/IP computer, such as when you type www.microsoft.com into your Web browser, your workstation performs a name resolution process before it sends any traffic to the destination server. If you look quickly, you might see your browser display a status message for a fraction of a second, indicating that it is resolving the name. To perform a name resolution, the client computer transmits a message containing the name to a DNS server, the address of which is specified as part of its TCP/IP client configuration. The DNS client implementation found in every computer running TCP/IP is called a resolver. The DNS server determines the IP address associated with the name requested by the resolver and returns it to the client. The client can then send its original message to the desired destination using its IP address.
Understanding how your local DNS server obtains the IP addresses for the names sent to it by your computer can be complicated and requires you to understand how DNS names are structured and assigned. The primary element of the DNS is its hierarchical namespace, which identifies computers using names composed of three or more words, separated by periods. The DNS name of a computer consists of a host name and a domain name. The domain name, which consists of two or more words, identifies a network or an organization running a network, and the host name identifies a specific computer on that network or in that organization. In the name www.microsoft.com, for example, www is the name of a particular host in the domain microsoft.com.
Domain names on the Internet must be registered with an organization that is responsible for ensuring there is no duplication of names. DNS names are read from right to left, with the word furthest to the right representing the top of the domain hierarchy. Therefore, the com in www.microsoft.com is known as a top-level domain. The original DNS standards defined eight top-level domains: com, edu, gov, mil, net, org, int, and arpa. All of these top-level domains are intended to be used for computers belonging to different types of organizations, with edu being for educational institutions, mil for the military, and so on. The term arpa is a special case used for reverse—that is, address-to-name—mapping.
Today, in addition to these eight, there are numerous additional top-level domains that represent various countries around the world. These international top-level domain names have only two letters, and are often abbreviations for the country name in its own language. For example, de is the top-level domain for Germany (Deutschland) and fr for France. There are also other, special-purpose, top-level domains that have only recently been introduced, but these have yet to have a major impact in the business world.
By contacting a registrar who is responsible for one or more top-level domains, any individual or organization can register a second-level domain within that top-level domain for a nominal fee. Top-level domains like edu, gov, and mil are restricted to the educational, government, and military organizations they describe, respectively, but the registrars of the com, org, and net top-level domains allow anyone to register names in those domains, as do many of the international domain registrars.
Once an individual or organization has registered a domain name, the owner is free to create as many hosts or subdomains in that domain as they wish. The word furthest to the left in a full DNS name is the host, and any names to the right of the host identify the domain. Thus, as shown in Figure 10.6, the owner of the microsoft.com domain can create any number of subdomains, such as msn.microsoft.com, and any number of hosts in each of those subdomains, such as www.msn.microsoft.com. This two-tiered administrative arrangement is the same as that for IP addresses. An administrative body is responsible for registering the network addresses assigned to various organizations, and the administrators of the organizations themselves then create the host address assignments.
Figure 10.6 A DNS name can include several domain levels, or as few as two, plus a host name
With the increasing commercialization of the Internet, domain name registration has become a lucrative business and a point of legal contention as well. In some cases, popular domain names are being sold for millions of dollars, either by failed companies that no longer need them or by forward-thinking entrepreneurs who registered them before the Internet boom. In other cases, large corporations have filed legal suits to have certain domain names stripped from their legal registrants simply because they have the same name as the corporation. Creative domain registration is also being used for unscrupulous business practices. For example, the owners of a corporation might register domains using the names of its competitors, so that potential customers are directed to the corporation's Web site when they look for a Web site using a competitor's name. At this time, the courts are still mulling over the legal issues pertaining to Internet rights.
Although they use the same basic administrative model, IP address registrations and domain name registrations are completely separate. You can have computers on many different IP networks using the same domain name, or you can have multiple domain names used by computers on the same network.
Splitting the administrative chores between a central body and the individual registrant is part of what makes it possible to keep the DNS namespace up to date. There are thousands of domains on the Internet today, and millions of hosts in those domains. To create a central registry for all of this information would require enormous manpower and technology resources. Instead, the responsibility for maintaining the DNS namespace is distributed among servers and administrators all over the Internet. It's remarkable that a system designed when the Internet wasn't a hundredth of its current size still functions well, even though it has grown far beyond the wildest dreams of its conceivers.
The relationship of the various domain levels becomes apparent when you examine the process by which DNS servers resolve names into IP addresses. Because of the distributed nature of the DNS namespace, there is no single server that contains a complete listing of all the domains on the Internet and all of the hosts on those domains. Therefore, when a client system sends a name to its DNS server for resolution, the server must have some means of locating the information it needs. The server does this by parsing the DNS name it receives from the client and working with one domain level at a time.
Every DNS server has the IP addresses of several root-name servers. These servers are responsible for maintaining a list of the top-level domains and the IP addresses of the DNS servers that are authoritative for those domains. An authoritative server is the computer that is the final source of information about a particular domain. Usually this is a server run by the administrators of the domain, on which they make changes when they modify their network configuration. The root-name servers are, in fact, the authoritative servers for most of the original eight top-level domains, but they also contain the addresses of the authoritative servers for the many international domains. These servers handle only a small part of the name resolution process, but they still process hundreds of requests per second.
A DNS server trying to resolve a name sends a message to one of the root-name servers requesting the address of the authoritative server for the top-level domain in the name (see Figure 10.7). Thus, a server trying to resolve the name www.microsoft.com sends a request to a root-name server, asking for the address of the authoritative server for the com domain. Because that server is authoritative for the com domain, it skips a step and supplies the address for the microsoft.com domain's authoritative server. Otherwise, the root-name server would respond with the address of the top-level domain server, and the original server would send a new request to the top-level domain server for the address of the second-level domain's authoritative server. Once the original server knows the address of the microsoft.com domain's authoritative server, it generates a request for the IP address of the host www. The microsoft.com server responds with the requested IP address, and the original server passes that address to the client.
In this way, any DNS server on the Internet can locate the IP address for a computer in any domain. However, in many cases, the servers can bypass part of this process because they can usually cache information about the names they resolve. For a popular DNS name like www.microsoft.com, for example, it is very possible that the client's DNS server already has the required IP address in its cache and can furnish it directly to the client without communicating with other servers.
Run the DNSNameResolution video located in the Demos folder on the CD-ROM accompanying this book for a demonstration of the DNS name resolution process.
Figure 10.7 The DNS name resolution process
DNS is designed to resolve names into IP addresses, but there are cases in which TCP/IP computers require the opposite service, the conversion of an IP address into a name. Because the DNS namespace is distributed based on the domain names, however, this task is almost impossible when using the system's standard capabilities. Finding a specific IP address in the namespace would require a search of all of the authoritative DNS servers on the Internet, which obviously is not practical.
To address this problem, the DNS name space includes a special domain called in-addr.arpa, which reverses the name/address relationship by containing domains that are named using IP addresses. In other words, in-addr is a second-level domain beneath arpa, and beneath in-addr there are 256 possible third-level domains, which are named using the numbers 0 to 255. These third-level domains represent the first byte of an IP address. Each of the third-level domains has 256 possible fourth-level domains, representing the second byte of an IP address. The fifth- and sixth-level domains work in the same way, enabling you to search in the DNS namespace for any possible IP address. For example, the IP address 192.168.2.6 would be found in the domain name 220.127.116.11.in-addr.arpa. This domain would contain a resource record that specifies the DNS name of the computer using this IP address. The bytes of the IP address are reversed in the domain name because, in an IP address, the most significant identifier is first, and in a domain name, the top-level domain comes last.
Despite the complexity of the distributed namespace, DNS servers themselves are actually relatively simple. DNS servers store their information in units called resource records, which administrators of authoritative servers must create manually, in most cases. In response to a request from a resolver or another server, the DNS server transmits a message containing the resource record for the requested name. There are many different types of resource records, the most important of which are as follows:
The need to manually create resource records is one of the long-standing shortcomings of DNS. Now that Windows 2000 relies heavily on DNS for its Active Directory service, the IETF has published additional documents that define new server features, such as RFC 2136, "Dynamic Updates in the Domain Name System," which specifies a method for automatically creating and updating DNS resource records.
Windows Internet Naming Service (WINS) is similar to DNS in that it is designed to resolve computer names into IP addresses. However, WINS is designed specifically for Windows networks and resolves the NetBIOS names used by Windows systems, rather than the DNS names used on the Internet. The NetBIOS namespace that Windows uses to provide friendly names for computers is not hierarchical like that of DNS, but the problem of using TCP/IP with these names is the same. A computer must resolve the name of the computer it wants to communicate with into an IP address before it can send IP datagrams to it.
WINS is included with the Windows NT Server and Windows 2000 Server operating systems. However, the Active Directory technology in Windows 2000 uses DNS instead of NetBIOS names, so the WINS server is included only to service downlevel clients, that is, workstations running earlier versions of Windows.
Windows has several ways of resolving NetBIOS names into IP addresses, so WINS is not an essential part of a Windows network. Without WINS, a computer resolves NetBIOS names either by looking them up in a text file similar to HOSTS, called LMHOSTS, or by transmitting broadcast messages containing the desired name on the LAN, and then waiting for the computer using that name to respond with its IP address. WINS is designed to increase the efficiency of the network by reducing the amount of broadcast traffic. Instead of broadcasting a request, a WINS client transmits a request to its designated WINS server as a unicast message, and the server responds with the IP address associated with the requested name.
For more information about NetBIOS names, see Lesson 3: NetBEUI, in Chapter 6, "Network Layer Protocols."
Unlike DNS, which requires administrators to create resource records manually, WINS automatically registers clients as they boot, then adds their names and IP addresses to its database. WINS is also designed for use on large internetworks. You can run multiple WINS servers to provide fault tolerance and service thousands of clients. WINS servers can also communicate with each other to replicate their database information, enabling you to maintain a composite picture of the entire network on all of your servers.