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.
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 in order 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. While 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 fleets 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 the Address Resolution Protocol (ARP). While 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. A RARP server then responds by transmitting the IP address assigned to that client computer. While RARP was suitable for use with diskless workstations on early TCP/IP networks, it isn't sufficient for today's needs, because it supplies the computer with an IP address only. It provides none of the other settings needed by a typical workstation today, such as a subnet mask and a default gateway.
The next attempt at an automatic TCP/IP configuration was called the Bootstrap Protocol (BOOTP). BOOTP does more than RARP, which is why it is still used today, while 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 while it is capable of performing all of 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.
The Dynamic Host Configuration Protocol (DHCP) was developed by Microsoft 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 ever being assigned duplicate IP addresses and enables administrators to move computers around between subnets without having to manually reconfigure 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 98 system, for example, when you select the Obtain An IP Address Automatically radio button in the TCP/IP Properties dialog box, 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 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 itself published as an open TCP/IP standard.
The core function of DHCP is to assign IP addresses. This is the most complicated part of the service, because an IP address must be unique for each client computer. The DHCP standard defines three types of IP address allocation, which are as follows:
Manual allocation is the functional equivalent of BOOTP address assignment. This option saves the least amount of 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 around 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, and enables 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 IANA-established well-known port numbers 67 at the server and 68 at the client.
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.
The functions of the option subfields are as follows:
Although it sounds like a contradiction in terms, there is one DHCP option which is, in fact, 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. This initial exchange of messages is 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 broadcasted 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 whose offer it is accepting 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.
Upon 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. After broadcasting an ARP message containing its new IP address, the client hopes not to receive any response. 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 one 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 in order 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 (as 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.
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 Windows Me, Windows 98, or Windows 95. For more information about these utilities, see Lesson 2: TCP/IP Utilities, later in this chapter.
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 whose drives or printers you want to access. To make TCP/IP more user-friendly, the TCP/IP 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. In order 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 in order to bypass the more elaborate name resolution methods used today.
When the Internet outgrew the HOSTS file, it also outgrew the flat name space the file used. There were too many systems to assign them 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. Then, the client can 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, however, and requires you to understand how DNS names are structured and assigned. The primary element of the DNS is its hierarchical name space, 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 organization, 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 computer in the domain microsoft.com.
Domain names on the Internet must be registered with an organization that is responsible for making sure that 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 other 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 has also been talk about the introduction of other, special-purpose top-level domains for years, but these have yet to appear in popular use.
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 gov and mil are restricted to the government and military organizations they describe, 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.
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, as well. 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.
Splitting the administrative chores between a central body and the individual registrant is part of what makes it possible to keep the DNS name space up to date. There are thousands of domains on the Internet today, and millions of hosts in those domains. To try and create a central registry for all of this information would require enormous resources of manpower and technology. Instead, the responsibility for maintaining the DNS name space 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 name space, 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 must 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. Since 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.
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 name space 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 name space 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 name space for any possible IP address. For example, the IP address 192.168.2.6 would be found in the domain name 6.2.168.192.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, while in a domain name, the top-level domain comes last.
Despite the complexity of the distributed name space, 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:
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 name space that Windows uses to provide friendly names for computers is not hierarchical like that of the 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.
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.
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.