TCP/IP Administration
Chapter 2. TCP/IP Communications

To better understand the complexities of network communications, the processes involved are broken down into distinct function-based layers. This chapter provides a basic overview of computer networking using the TCP/IP protocols. The following subjects are covered:

• The operational layers of a network implementation, known as a protocol stack
• The encapsulation process by which multiple protocols package data for transmission over a network
• The addressing system by which the TCP/IP protocols identify specific computers on an internetwork
• The domain-based system by which TCP/IP hosts are assigned familiar names

When computers communicate using the TCP/IP protocols, they follow the client/server model, even if the operating system (OS) provides peer-to-peer functionality, such as Windows NT. A peer-to-peer OS is simply one that contains both client and server components to be used simultaneously. At any given time, the computer can act as a server by enabling access to its drives or application processes; or as a client, by accessing the resources of other systems.

On a system using TCP/IP, the networking protocols come into play when an application requests access to resources found elsewhere on the network. For transmittal over the network, this request must be packaged as a data structure suitable for the network medium, and delivered to the network interface adapter. In most cases, the adapter is a network interface card (NIC) in the computer, to which a network cable is attached. This packaging and delivery process is largely performed by a protocol suite like TCP/IP.

The application generating the request for access to resources on the network is said to reside at the top of what is called a protocol stack. The bottom of the protocol stack is the interface to the network medium, itself. The protocol stack is divided into several layers. Each of which represents a protocol that performs some of the tasks necessary for effective communication with another system. The request generated by the application at the top of the stack is passed downwards. Each successive layer provides a service to the layer above, until the message reaches the network medium, which is usually a cable.

During its journey downwards through the stack, the request is transformed, from an Application Programming Interface (API) call—such as a word processor's FileOpen command—into a coded signal, suitable for network transmission. Depending on the network type, the signal may be an electric current, pulses of light, radio waves, or any other viable medium.

In order to process the request, the receiving computer must have an identical networking stack, representing the same protocols. The request is passed up through the layers where the same process is performed in reverse, until the decoded signal reaches the application at the top (see Figure 2-1). The receiving application—in this case, the file system of another computer—processes the request and generates a response that is transmitted back to the source.

Figure 2-1: Client and server systems possess the same protocol stack, which can process incoming and outgoing data.

The activities that occur in the protocol stack are the primary subject of this book. TCP/IP is one of several protocol suites that operating systems can use to process application requests for transmission over a network. Some operating systems, like UNIX, are completely dependent on TCP/IP, while others like Windows NT provide an open networking architecture that can utilize various different stacks—even simultaneously.

The OSI Reference Model

When seen at a very high level, the act of generating a request, transmitting it over a network, and receiving a response is deceptively simple. It might be likened to dropping a letter into a mailbox and receiving a response a few days later. However, the actual process of packaging the request and assuring its intact, timely delivery, is quite complex. The process is divided into layers to make it more manageable and comprehensible, to both the designers of networking protocols and computer users.

In 1983, two standards bodies, the ISO (International Organization for Standardization) and the CCITT (which translates from the French as the International Telegraph and Telephone Consultative Committee) jointly published "The Basic Reference Model for Open Systems Interconnection." Based on research work performed by both bodies over the course of several years, this document, also called the OSI reference model, describes the network communications process. Using a seven-layer structure, the process has since become the standard reference and teaching tool for data networking.

The networking process within a computer's OS ranges from the application request (at the top of the protocol stack) to the network medium (at the bottom). The OSI reference model divides this functionality into seven discrete layers, as shown in figure 2-2.

The seven layers of the OSI model perform the following operations:

Figure 2-2: The OSI reference model contains seven layers that represent the entire networking functionality of the computer.

• Application—Consists not of the actual application running on the computer (such as a word processor), but of the APIs providing the application with access to network resources.
• Presentation—Performs any syntax translations that are needed when computers of different types communicate using the same protocol stack.
• Session—Initiates and maintains the dialog between two communicating computers. It also creates checkpoints, allowing transactions to be rolled back to a previous state, in the event of an interruption in the communications process.
• Transport—Provides the end-to-end communication between two systems. This layer ensures that the appropriate quality of service is achieved for the type of transmission being used.
• Network—Routes transmissions across internetworks to destinations on other network segments. It may also provide end-to-end services such as flow control and error detection.
• Data Link—Packages the transmitted data into packets suitable for transmission over the network. This layer also controls access to the network medium, allowing multiple systems to utilize the same cable.
• Physical—Consists of the actual interface between the computer and the network medium. It is responsible for the final coding of information into the electrical impulses, or other signals, used to transmit data over the network.

Originally, the OSI model was intended to be the basis for a protocol stack. After many years of development, there is now an OSI stack, but it is not used in business LAN environments. When you examine TCP/IP, or any of the other stacks used in commercial networking products, you find that they do not exactly conform to the stratification of the OSI model. The model has, instead, become more of a tool for learning about the processes involved in computer networking, and not the implementations found in specific products.

The functionality of the OSI model's seven layers has become the vernacular of the networking industry. Presented here, it makes understanding which services are provided by the TCP/IP protocols much easier. Development of the TCP/IP protocols began in 1975, long before the documents defining the OSI reference model were published. In fact, the first official TCP/IP standards were published in 1983, the same year as the OSI documents.

The TCP/IP Stack

The TCP/IP protocols are also divided into layers representing some of the same processes (and using some of the same names) as their counterparts in the OSI model. The TCP/IP stack contains four layers, as shown in figure 2-3.

The functions of the TCP/IP layers are as follows:

Figure 2-3: The TCP/IP protocol stack represents only part of a computer's networking system, and is designed to work with many other protocols.

• Application - Some TCP/IP application layer protocols are full-fledged user applications which generate network-service requests, such as TELNET and FTP. Other protocols provide support to applications in the form of services, such as the Domain Name System (DNS) and the Simple Network Management Protocol (SNMP).
• Transport - As in the OSI model, the transport layer provides end-to-end communications services in the form of two protocols: the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP).
• Internet - The internet layer contains IP (the Internet Protocol), which is responsible for the packaging, addressing, and routing of data to its destination. Also operating at this layer are the Internet Control Message Protocol (ICMP) and the Internet Group Management Protocol (IGMP).
• Link - The link layer contains protocols used to facilitate the transmission of IP data over the existing network medium. The TCP/IP standards do not define the functionality of the OSI data link and physical layers. Instead, the standards define protocols like the Address Resolution Protocol (ARP) that provide an interface between TCP/IP structures and the physical network as implemented by the OS.

NOTE:

The names of the four layers that comprise the TCP/IP protocol stack used here are those defined in RFC1122, "Requirements for Internet Hosts — Communication Layers." Many sources use alternative names, for instance, referring to the internet layer as the network layer. The link layer is sometimes called the network interface layer — or worse — the data link layer, giving rise to confusion with the OSI reference model layer of the same name. In this book, the link layer refers strictly to the protocols defined by the Internet standards. It does not include the functionality of OSI data link layer protocols such as Ethernet and Token Ring.

Each of the TCP/IP stack's layers and its protocols are examined at length in the individual chapters that comprise Part II of this book.

It is important to understand that the TCP/IP protocols do not provide all of the functionality found in the seven layers of the OSI model—nor can they be exactly equated to OSI equivalents. Roughly speaking, the two networking models can be compared as shown in figure 2-4, in which the TCP/IP application layer is approximately equivalent to the application and presentation layers of the OSI model. The internet and transport layers of both stacks provide roughly the same functions, but the TCP/IP stack's link layer is a special case.

Figure 2-4: The layers of the TCP/IP stack do not correspond exactly to those of the OSI reference model.

The link layer is special because the TCP/IP standards are designed for use on a wide range of hardware platforms and network types. The protocols controlling access to the network, and the actual signaling used on the medium, are found in the data link and physical layers of the OSI model. On today's business LANs, these are almost always Ethernet or Token Ring—which are the colloquial names assigned to the IEEE (Institute of Electrical and Electronics Engineers) 802.3 and 802.5 standards, respectively.

Obviously, Ethernet and Token Ring are not TCP/IP protocols, since they were developed by another standards body. Instead, these protocols are implemented by the network interface hardware and by device drivers installed into the OS. The TCP/IP standards do not define data link and physical protocols of this type. Instead, the TCP/IP protocols are designed to work with networking technologies like Ethernet and Token Ring, as well as many other lower-layer protocols used on Internet systems. Therefore, the TCP/IP link layer provides important functionality to the region of the OSI data link layer, but it doesn't necessarily replace it.

Because the TCP/IP standards do not define physical and data-link protocols, the four TCP/IP layers do not represent the entire network protocol stack, as does the OSI reference model. To see how the TCP/IP protocols fit into the NetWare and Windows NT protocol stacks, see Chapter 3, "TCP/IP and Operating Systems."

Protocol Symmetry

Another way to understand the use of layered protocols is to envision the protocol stacks of the sending and receiving systems side by side, as shown in figure 2-5. Every protocol in use on the sending system must also be supported by the receiving system. In essence, each layer is directly communicating with its counterpart.

Figure 2-5: Each protocol layer in the networking stack communicates with its counterpart in the receiving system's stack.

As a message travels down through the layers of the transmitting system, the various protocols apply their own specialized control data (this consists of mechanisms designed to provide the level of service required for transmission). When the message reaches the destination system and passes up through the protocol stack, the IP control data is read at the internet layer. The message is then passed up to the transport layer, where the TCP or UDP control data is read. Thus, the protocol operating at each layer of the sending system is capable of conducting a separate dialog with its equivalent in the receiving system.

Quality of Service

One of the primary benefits of using a stack of multiple protocols for network communications (as opposed to a single monolithic protocol) is that a transmission can be provided with the exact services needed to accomplish its appointed task. Whenever you transmit data across a network, you incur an additional measure of network traffic for control purposes. For example, you may download 100KB file from an Internet FTP site, but the total amount of data actually traversing the cable during the transmission process is substantially more than 100KB. The additional traffic consists of control data needed to get the file to the correct location intact.

The ultimate goal in designing any networking protocol is to accomplish the required tasks with the least amount of additional control traffic. You could, for example, design a protocol that breaks every transmission down into 1K chunks, each of which is transmitted in a separate packet and requires a separate acknowledgment in return. This would get the job done, but would be wildly impractical because the amount of control data required would far exceed the size of the file being transmitted.

A protocol stack like TCP/IP is intended to service many different kinds of applications. The applications can also have different requirements of the protocol stack. A DNS transaction, for example, may consist of a very simple exchange. A workstation sends a single packet containing a host name to a DNS server, which then responds with a single packet containing the IP address that is the equivalent to that host name.

A transaction like this requires relatively little from the protocol stack. There is no need for the server to acknowledge the workstation's transmission because its response serves as an acknowledgment. If the workstation receives no response, it can simply resend the request—which would probably require less control traffic than an elaborate acknowledgment mechanism.

Transmitting a 100KB file from an FTP site requires considerably more from the protocol stack. Because the file must be broken up into multiple packets, it requires more elaborate mechanisms, such as, packet acknowledgment, fragmentation, and flow control. The more services required, the greater the amount of control traffic.

The protocol stack in a TCP/IP system provides alternative protocols for exactly this reason. Although the protocols may operate individually, communicating with their counterparts on the destination system, they also work together to provide the overall quality of service required for the transmission. The quality of service is the aggregate sum of the features provided by all of the protocols used for a given transmission. The protocols at the various layers of the TCP/IP stack work together by providing the features required in the most efficient manner possible.

The IP protocol, for example, operates at the internet layer, and is used to carry the traffic of both transport layer protocols, TCP and UDP. In order to minimize control traffic, IP provides only the services required by both of these upper-layer protocols. The extensive services required for an FTP transmission are implemented at the transport layer by TCP; UDP provides the simple basic service required for DNS transactions.

Each type of transmission receives the quality of service that it requires, and no more. A DNS exchange is not burdened with the additional control traffic incurred by services it doesn't need, and these same services are made available for FTP transfers, as needed. The TCP/IP protocols also factor other standards into the equation. Since data link layer protocols like Ethernet and Token Ring both provide an error-checking mechanism for the entire contents of the packet, an equivalent service need not be implemented by TCP/IP.

Understanding Data Encapsulation

When a request is prepared for transmission over the network, each protocol in the stack applies its own control data through a process known as data encapsulation. Data encapsulation is the process by which each protocol in the stack takes the data handed down to it from the layer above and packages it by applying a header. A header consists of several additional bytes worth of information used to implement the particular features of that protocol. Headers vary in size depending on the features of the individual protocol.

Every network transmission requires a certain amount of control data, in addition to the information being sent to the destination. Again, think of the mail analogy, you cannot mail a letter without first putting it into an envelope and addressing it. The control data adds to the size of the transmission, just as the envelope adds to the overall weight of the letter. The more features needed to reliably transmit the request, the more control data is required.

At the top of the protocol stack, therefore, the data structure consists only of the original request generated by the application. It is a letter without an envelope. When the request is passed down to the TCP/IP application-layer protocol, a header is affixed (containing the control data needed by the same protocol at the receiving system). Once the header is applied, the original request becomes the payload, the baggage carried by the protocol. Just as the post office doesn't care what's in the envelopes, a protocol doesn't care what it is carrying in its payload.

The protocol at application layer of the stack produces a structure, consisting of a header and a payload, which it passes down to the next layer (see Figure 2-6).

The structure produced by the application-layer protocol is then passed down to the transport layer, where a second protocol applies its own header. Together the application-layer header and payload become the payload of the transport-layer protocol (see Figure 2-7). The transport-layer protocol cares nothing about the contents of the application protocol header or the original request.

This process continues at each successive layer of the protocol stack, until a structure called a packet is created. The packet consists of four or more headers attached to the original message (see Figure 2-8). Each header contains control data, solely intended for a specific protocol on the receiving system. As the packet is passed up through the layers of the stack at the destination, each header is read, in turn, by the appropriate protocol. This process that is known as demultiplexing. As in the transmitting system, each protocol is only concerned with the contents of the header intended for it, treating everything else as payload. This is how the protocols, at each layer, are able to maintain a dialog with their equivalents on other systems.

Figure 2-8: By the time a packet is transmitted, it has had multiple protocol headers applied to it.

The final header, added to the message before the originating system transmits it over the network, is the data-link protocol—typically Ethernet or Token Ring. Unlike the TCP/IP protocols, this final step in message packaging contains a footer as well as a header. It encloses the data structure in an envelope suitable for transmission over the network medium to which the sending system is connected.

Naming Data Structures

One of the most confusing aspects of data encapsulation is the nomenclature used to refer to each data structure, as it is passed down through the layers of the protocol stack. In most cases, the original payload generated by an application that uses the UDP protocol is referred to as a message. If the application uses TCP, the data is called a stream.

Once it reaches the transport layer, the name given to the message again depends on the protocol used. TCP transmissions nearly always involve large amounts of data, even entire files, which are split up and sent as multiple segments. The segments that make up the transmission are collectively referred to as a sequence. The structures produced by the UDP protocol are called packets.

At the internet layer, the IP protocol is used to transmit both TCP segments and UDP packets within structures known as datagrams. Below the internet layer of the protocol stack, TCP/IP can use many different protocols, which may have different names for the structures they transmit. Ethernet and Token Ring networks refer to their individual transmissions as frames, which has become the most commonly used term. Thus, an Ethernet frame can contain an IP datagram, which in turn contains a TCP segment of an application data stream, or a UDP packet with a message inside (see figure 2-9).

Figure 2-9: Nearly all of the TCP/IP protocols use a different name for the data structure formed by the protocol header and its payload.

Adding to the confusion of all of these terms is the fact that some of them are used interchangeably. Because all of the networks using TCP/IP can be defined as packet-switching networks, the term packet is often used generically when speaking of the fundamental unit transmitted across the network medium. This usage is not incorrect, even though this structure is more properly referred to as a frame, in most cases. The term datagram is also used to refer to UDP structures because, like IP datagrams, they are independent transmissions, as opposed to TCP segments—which are part of a greater whole, composed of many frames.

Applying Protocol Headers

The header that each protocol applies to the payload (received from the layer above it) can vary greatly depending on the features of the protocol. Each header consists of a number of discrete fields, of various sizes, that are used by the receiving protocol stack to implement the services required for the data being transmitted. The control data in the header fields can perform several tasks, including addressing, fragmenting, error checking, and flow control—all of which are outlined in the following sections.

ADDRESSING

One of the most important functions of the information in the protocol headers is to direct transmitted data to the exact place it must go in the destination system. When you mail a letter using a postal service, the address on the envelope describes the location of the intended recipient in increasingly specific terms. The letter is delivered first to the correct state, then to a city in that state, then to a street in that city, and finally to a house on that street.

In the same way an envelope bares an address, the destination of a TCP/IP transmission is specified by the information contained in the headers—which are provided by the successive protocol layers. Directing the data to the proper destination, however, consists of more than just locating the correct computer. Computers can be running many different processes simultaneously. As a result, data packets may arrive at a computer containing payloads intended for the TCP/IP protocol stack, or any one of several other possibilities. IP transmissions may be intended for either one of the two transport protocols, and TCP and UDP data can be directed to any one of several dozen application processes. This assortment of destinations within a single computer can be illustrated by a tree-like structure (see Figure 2-10).

Figure 2-10: Once a TCP/IP message is transmitted to its destination, it must be directed to the proper protocol at each layer to arrive at the proper application process.

For a transmission, directed at a specific application, to wend its way through this morass of protocols on the destination system, each layer of the stack must provide a sign to point the way. Each of the protocol headers contains a field dedicated to this purpose. A data-link protocol such as Ethernet contains a code in its header that identifies the protocol stack for which the packet is intended. When a packet is passed to the internet layer of the TCP/IP stack, a field in the IP header specifies the protocol used at the transport layer. The transport layer protocol header includes a port number that identifies the application process for which the message is intended.

NOTE:

The codes used by the TCP/IP stack to identify specific protocols and ports are defined in most operating systems by files called PROTOCOL and SERVICES, respectively. These are ASCII text files that contain lists of numerical codes and their equivalent protocols and ports. The values found in these files are published by the Internet Assigned Numbers Authority (IANA) in RFC1700, "Assigned Numbers."

FRAGMENTING

In many cases, a message that must be carried by a TCP/IP transmission is too large to be the payload of a single packet. TCP transmissions, for example, are designed to carry large amounts of data (such as FTP or HTTP file transfers) that must be split, or fragmented, into multiple segments. The IP protocol is also capable of fragmenting payloads that exceed the maximum packet size permitted on a given network segment. To execute transfers of large amounts of data, the protocol splits the payload into appropriately sized units , each of which is assigned a number and packaged for transmission in the usual manner. The number assigned to each fragment is stored in the protocol header and transmitted with the data.

Fragment numbers are needed because the packets that comprise the payload are transmitted individually. They may, conceivably, take different routes to the destination and arrive in a different order from that in which they were transmitted. At the receiving station, the numbers are used to reassemble the fragments in proper order (rather than relying solely on the sequence in which they are received).

The fragmentation process performed by IP and the segmenting of TCP transmissions are two entirely different mechanisms. However, they both rely on the data in their respective headers to provide the receiving system with the needed information to reassemble the pieces back into a whole.

ERROR CHECKING

A protocol stack uses several mechanisms to verify that the packets transmitted from a source to a destination have arrived undamaged. These mechanisms rely on the basic technique in which a value is calculated by the sending system, and stored in a protocol header field. When the destination system receives the transmission, it performs the same calculation and compares the results to the value provided in the header. If the values do not match, the data in that packet is assumed to be corrupted.

Error-checking mechanisms like these can be very simple and provide only marginal protection—such as when IP specifies the total length of the packet in its header. If the packet arriving at the destination is a different length, it is certainly damaged. Transmissions can, however, be damaged without their length being affected. A more thorough check is performed by the Ethernet protocol, which computes a cyclical redundancy check (CRC) value for its entire payload and delivers it in its header. When the CRC is recomputed at the destination, a different value results if even one bit of the payload is changed.

FLOW CONTROL

Flow control is the process by which a receiving system passes information to the transmitter regarding the speed at which it can receive data. This process is used in extended transmissions consisting of many packets (such as TCP sessions). Flow control is provided by a value in the header of each acknowledgment packet returned to the sender by the destination system. The value specifies the amount of data that the destination system is capable of receiving. If this value decreases during successive acknowledgments, the sender must decrease the rate at which it is transmitting data.

The functions of each field in the various protocol headers are examined in much greater detail in Part II of this book. They are discussed in the sections devoted to the individual TCP/IP protocols.

Diagramming Protocol Headers

The "Assigned Numbers" RFC (RFC1700) document defines a standard method for notating the headers and fields which make up a TCP/IP transmission. This book uses this method for diagramming the TCP/IP protocol headers examined in later chapters. The transmission is divided horizontally into 32-bit words, which are further divided into 8-bit bytes (see Figure 2-11). The most significant byte of each word is on the left side, and the least significant byte, on the right. This is known as big-endian order. The bytes of each word are transmitted from left to right, and the words from top to bottom.

Figure 2-11: The TCP/IP standards diagram structures data by breaking it up into 8-bit bytes and 32-bit words.

Understanding IP Addressing

Once a TCP/IP packet leaves the transmitting workstation, it travels to its destination, whether the system is on the local network segment, a nearby segment of a private internetwork, or half a world away on the Internet. In order to reach the destination system, however, the packet must be properly addressed. On a typical PC LAN, this is not a problem. Data link protocol standards such as Ethernet and Token Ring have their own addressing systems based on hexadecimal addresses hardcoded into the network interface adapters.

	NOTE:
The TCP/IP standards often use the term "internet" to refer to both private internetworks and the public network that grew out of the ARPANET. In this book, a capital "I" refers to the public Internet, and a lower case "i" is used to refer to a private internet or internetwork, that is, a network of networks.

Every Ethernet network interface card has a unique node address. Manufacturers are each assigned a prefix, to which they append sequential addresses for each device. The administrators of private networks are responsible for assigning a hexadecimal address to each network segment on an enterprise internetwork. The combination of the network address and the node address provide a unique identifier for each system—even on a huge internetwork containing thousands of nodes.

The TCP/IP protocols, however, were originally designed for use on the Internet. Following are two reasons this hardware addressing system is unsuitable for the Internet environment:

1. Although individual network interface cards have unique addresses, there is no mechanism in place to prevent the duplication of network addresses, assigned by individual administrators.
2. While the hardware used in today's PC LANs supplies a robust addressing system, this was not always the case. The TCP/IP protocols were specifically designed to be independent of any particular hardware platform, at a time when the majority of the computers on the Internet did not use Ethernet or Token Ring at the physical layer.

It was, therefore, necessary for the TCP/IP standards to define an independent, self-contained addressing system that could be used with any hardware platform. In practice, TCP/IP uses a two-tiered system of network and node addresses just like Ethernet, but the network addresses are registered to avoid duplication. Thus, every computer on the Internet has a unique network and node identifier; the two are combined in a 32-bit IP address.

The header applied to packets by the IP protocol is the last one in the TCP/IP protocol stack, and is responsible for specifying the ultimate destination of the transmission. Every IP packet header contains fields holding the IP addresses of both the source and destination systems. TCP/IP packets may travel across dozens of networks as they traverse the Internet, and consequently, be packaged and repackaged in many different frames as they pass through Ethernet, FDDI, PPP, X.25, and untold other network types. Through all of this the IP header remains unchanged, providing a continuous reference to the packet's ultimate destination.

Network and Node Addresses

Using separate network and node addresses creates a system that packets to be more easily directed to a specific computer, on any network segment. On a large internetwork, a single list of thousands of node addresses would be most unmanageable, causing delays as routers repeatedly search the list for addresses. On the Internet, a node address list would contain millions of entries, bogging down the entire network with enormous router tables. Grouping the addresses by network simplifies the process by allowing routers to maintain lists of networks, instead of nodes. A router is only responsible for maintaining a list of the nodes on the networks to which it is directly connected.

Thus, a packet transmitted to a system on another network is sent first to the router responsible for that network. Then, the router consults its node list and directs the packet to the specific host. This is the internetworking equivalent to obtaining travel directions to a town, then asking someone there for directions to a specific street address.

IP Addresses

IP addresses are 32-bit binary addresses. They are usually expressed as four decimal numbers, representing eight bits (or one byte) each, separated by periods. This is known as dotted decimal notation. An eight-bit binary number, when expressed in decimal form, can have a value from 0 to 255. Valid IP addresses, therefore, range from 0.0.0.0 to 255.255.255.255. Originally, the TCP/IP standards used the word octet to refer to each of these 8-bit values, and this term is occasionally still seen today. The more common word byte was avoided because some of the systems on which the protocols were developed (such as the DEC-10) did not use 8-bit bytes. Today, however, a byte is understood to be the equivalent 8 bits on nearly every computer system made; it is the preferred term.

Thus, an IP address is four bytes long, and represents the addresses both of the network on which the computer is located, and the network interface within the computer itself. In TCP/IP parlance, a computer system is referred to as a host. A host can have more than one network interface in it, in which case it must have multiple IP addresses. A host equipped with two or more network adapters is said to be multihomed. If a multihomed host is configured to pass traffic from one network to the other, it is said to be a router. Usually, a system must be specifically configured to act as a router, and can conceivably maintain connections to two separate networks without routing packets between them.

NOTE:

In this book, the term "router" is used to describe any system propagating traffic between network segments—whether it is a dedicated hardware device or a PC on which routing is a software or OS function. The term "gateway" is often used in the RFC documents to refer to the same types of routing devices. Traditional networking terminology defines a gateway as a system that routes traffic between networks using different protocols.

IP ADDRESS CLASSES

Because an IP address identifies both the network and the host, there is always a dividing line between the network portion of the address and the host portion. Some of the 32 bits are used to represent the network, and the rest identify the individual host. The dividing line, however, is not located in the same place for all IP addresses. The TCP/IP standards identify several address classes that split the IP address in different ways to accommodate individual network sizes being serviced (see Figure 2-12). The address classes are identified as follows:

• Class A - In a class A IP address, the first bit is always 0. By default the first eight bits (or one byte) identify the network, and the remaining 24 bits identify the host.
• Class B - In a class B IP address, the first two bits are always 1 and 0. By default the first 16 bits (or two bytes) identify the network, and the remaining 16 bits identify the host.
• Class C - In a class C IP address, the first three bits are always 1, 1, and 0. By default the first 24 bits (or three bytes) identify the network, and the remaining 8 bits identify the host.

Classes A, B, and C are all used for unicast addresses, that is, addresses that identify a single host. Two additional classes, not officially used yet, are as follows:

• Class D - In a class D address, the first four bits are always 1, 1, 1, and 0. Class D addresses are not intended to identify individual hosts. Instead they identify multicast groups—logical groups of computers receiving identical transmissions—not necessarily located on the same network.
• Class E - In a class E address, the first four bits are always 1, 1, 1 and 1. These addresses have been reserved for future use.

Figure 2-12: The TCP/IP standards define three classes of IP addresses to support different sized networks.

These class definitions, because of the enforced values for their initial bits, impose limitations on the decimal values used to represent them. For example, the highest possible value for an 8-bit binary number beginning with 0 is 01111111, which in decimal form is 127. Thus, you can always recognize a class A IP address, because its first byte is 127 or less. In the same way, the division between the network address and the host address imposed by the class definitions specifies the maximum number of possible networks that can belong to a particular class, and the maximum number of hosts that can be addressed on a particular network. Since a class A IP address devotes 24 bits to the host address, there can be a maximum of 16,777,214 hosts on any one of 127 possible networks. Table 2-1 displays the number of networks and hosts available in each class.

Because of these class definitions, you can tell that an IP address of 201.72.101.47, for example, identifies a class C network with an address of 201.72.101. The remaining number, 47, identifies the host on that network. For clarity's sake, this network itself would be referred to as 201.72.101.0 in routing tables or other documents.

Different sized IP address classes were developed primarily to facilitate the efficient routing of IP traffic while maximizing the number of addresses available for use. If all IP addresses split the network and host identifiers in the same place, there would always be a certain number of networks poorly served. If all IP addresses took the class C form, with three bytes devoted to the network address and one byte to the host, large organizations would be forced to maintain many different networks—each of which would require an entry in the routing tables on every system.

Conversely, if the class B division became the standard rule, with two bytes each devoted to the network and host addresses, a great many small organizations would be assigned a single network address supporting over 65,000 hosts (far more than would actually be used). Thus, any universal division of the IP address space into network and host segments would result either in excessively large routing tables, or a great many wasted host addresses.

At the time the class system was developed, the 32-bit IP address space seemed so vast, that routing efficiency was favored over conservation of host addresses. By now, virtually all of the class A and B addresses have been assigned and few, if any, of the organizations that own them are using all of their available host addresses. As the Internet approaches address saturation—the point at which all of the available IP network addresses have been registered—the IETF's Routing and Addressing (ROAD) working group is considering various strategies to remedy the problem, including classless addressing and the expansion of the 32-bit address space.

REGISTERING IP ADDRESSES

Because any computer on the Internet can send data to any other computer, it is vitally important that every system have a unique IP address. IP addresses cannot be assigned at the factory like those of Ethernet adapters because they are not associated with any particular hardware platform. In fact, there is no physical mechanism to stop users from specifying any IP address they wish in a workstation's TCP/IP configuration.

The developers of the TCP/IP protocols realized, early on, that in order to avoid duplication of IP addresses, there had to be an address registration system. This was a major problem because the thought of being the person whose phone would ring whenever a new system was added to the Internet was terrifying, even in 1983.

Using the same two-tiered network and node addressing procedure found on the network provided the solution to this problem. The authorities delegated the responsibility for maintaining the IP addresses of networks all over the Internet to an organization called InterNIC (the Internet Network Information Center). By registering only the network addresses, InterNIC became responsible for a much more manageable collection of listings. Today, the list numbers in the thousands, rather than the millions of entries that would be required to list every node address.

Once an organization registers their network with InterNIC, the administrators of the network are responsible for assigning unique host addresses to each computer. This distributed management philosophy is one of the basic tenets of TCP/IP and the Internet. It is largely responsible for the scalability that has allowed the Internet to grow to enormous proportions. You will see it demonstrated again when you read about the Domain Name System (DNS) later in this chapter, that uses a similar method to maintain a distributed database of Internet host names.

The IP address class definitions are intended to allow organizations to register network addresses supporting varying numbers of hosts. A relatively small company could register a class C address that would support up to 254 computers, while large corporations might need class B or class A addresses.

This is not, however, exactly how the system works in practice. There is no single organization that has the 16 million nodes to justify a class A address. Nearly all of the class A and B addresses have already been registered by Internet service providers, who divide the network address into many different subnets and lease them to their clients.

PRIVATE NETWORK ADDRESSES

The IP address classification and registration systems are, of course, designed for use on the Internet. On a private TCP/IP network, addresses need not be registered and classifications can be ignored. As long as each system's host address is unique, and located on the same subnet, the network will function properly.

Using unregistered IP addresses for computers on private networks is a practice that is being encouraged as the number of available IP addresses dwindles. The massive growth of the Internet in recent years has led to a situation that was not anticipated by the TCP/IP protocols' developers. There may soon come a time when all available addresses are exhausted. Authorities are trying to forestall this situation by urging network administrators to assign registered IP addresses only to the systems that require them.

There are two types of systems that do not require registered IP addresses: those that do not require access to other organizations' networks or the Internet, and those that connect to the Internet using a firewall or other application-layer gateway. In both cases, however, simply selecting IP addresses at random can later cause problems. A company merger or a connection to the Internet that was not planned when the network was designed, can result in address conflicts requiring a huge administrative effort to resolve.

If, for example, you select 199.99.99 as the address for your private network, and designate your workstation as 199.99.99.3, you will have trouble connecting to an Internet site with a registered network address of 199.99.99.0. Renumbering every network and node on your network to remedy problems like this is no one's idea of a good time.

To avoid this situation, the IETF (Internet Engineering Task Force) designated three blocks of IP addresses for use on private networks. These addresses will not be assigned to any Internet network, thus avoiding the address conflicts that may result from routing between the private network and the Internet. These private network address blocks are outlined in Table 2-2.

SPECIAL IP ADDRESSES

Apart from the IP address blocks designated for use on private networks, there are other addresses that cannot be assigned to hosts because they have special uses, as shown in Table 2-3.

In "Address Classes," earlier in this chapter, you learned that a TCP/IP network is referenced by using zeroes in place of the host portion of the IP address. Thus, there can be no individual host on a class C network with the address 199.99.99.0. This address identifies the network itself, and is used in router tables for this purpose.

In the same way, a host identifier of all 1’s cannot be assigned to a network interface. This value is used as a broadcast address so a transmission can be sent to all of the hosts on a particular network. For example, on a class C network, you cannot create an IP address for a host in which the value of the last byte is 255.

To broadcast a transmission to all hosts on the local network, the address 255.255.255.255 is used. Transmissions using this address must not be propagated beyond the boundaries of the local network or subnet. For this reason, the 255.255.255.255 address is referred to as a limited broadcast.

To broadcast a transmission to all of the hosts on another network, only the host portion of the address is filled with ones. The 199.99.99.255 address would, therefore, be used to send a broadcast to all of the hosts on the class C network 199.99.99.0, from a location on another network. Because the transmission originates from a system on another network, this is called a directed broadcast. A directed broadcast can also be used to address the hosts on all of the subnets of a given network, by replacing the subnet portion of the address with ones. If a class B network with the address 162.14.0.0 uses the third byte of the IP address to identify multiple subnets, a broadcast address of 162.14.255.255 would cause identical transmissions to be sent to every host on every subnet.

	NOTE:
Subnetting is the process of breaking down a registered class A, B, or C network address into multiple, smaller networks by designating additional bits from the host portion of the IP address as subnet identifiers. For more information, see "Subnetting," later in this chapter.

Since a TCP/IP transmission must emanate from a single system, it is obvious that this broadcast notation can only be used for destination addresses. IP packets must always include the address of the source (or sending) workstation as well. It is possible to form source IP addresses that identify a host on the current network by specifying zeroes in place of the network portion of the address. A source address of 0.0.99.75, therefore, would represent the host possessing the address 99.75 on the class B network from which the transmission originated. The address 0.0.0.0 would represent the current host on the local network. These two address forms are only used by workstations that do not yet have an IP address, for obtaining address assignment from a server, using a protocol such as BOOTP.

Finally, any IP address with a value of 127 as its first byte (except those using the reserved values 0 and 255) can be used as the internal host loopback address. In other words, using a destination address of 127.0.0.1 is the equivalent of sending a message to yourself. Any system with a functioning TCP/IP protocol stack should be able to PING itself using the loopback address.

The problem with using the 127 address as a testing medium, however, is that loopback transmissions never leave the system, therefore, they do not test the operational ability of the network hardware. You can physically disconnect your system from the network by pulling the cable out of the wall, and still be able to successfully PING yourself using the loopback address.

The 127 address can be useful when testing and troubleshooting software. For example, if you are running a system that has both web server and web client software packages installed on it, you can use the client to connect to the server on the same system using the loopback address. This removes the physical network as a possible source of any problems being experiencing.

Subnetting

When an organization registers a class A or B network address (even if it has the number of systems needed to utilize all of the host addresses provided), these systems are certainly not all located on a single network segment. Instead, the organization operates its own internetwork, consisting of many network segments, connected by routers. Even if this is the case, only the largest corporations could have internetworks that require all of the 65,534 hosts provided by a class B address.

More realistically, the A and B addresses have been registered by Internet Service Providers (ISPs) who are in the business of providing individuals or businesses with Internet connectivity and IP addresses. In either scenario, a class A or B network must be broken up into smaller units representing network segments or individual clients. These smaller units are called subnets.

Subnets are formed by "borrowing" some of the bits belonging to the host part of the address, and using them to identify the subnet. In its simplest form, this would be a matter of taking a class B address and using the third byte (originally intended to be part of the host address) and using it to identify the subnet (see Figure 2-13). This way, a class B network can be divided into as many as 254 subnets, each containing 254 hosts. Each subnet can be used to represent a network segment on a corporate internetwork, or be leased to a client at another location.

Figure 2-13: Subnetting involves taking some of the IP address bits allotted to the host identifier and using them to create a subnet identifier that functions as part of the network address.

NOTE:

The number of possible subnets provided by an 8-bit subnet identifier is computed using the formula 28, in which two are subtracted to account for the subnet ID values of all 0’s or all 1’s, which normally are not used. NetWare's TCP/IP stack, however, allows the creation of subnets using a 0 address. It is recommended that you not use 0 for a subnet address unless you know your routers support this practice.

Subnets are logical structures applied only within the bounds of the private internetwork. To the Internet, the borrowed bits are seen as the part of the host identifier that they originally were, just like any other address of that class. This is because the systems on the rest of the Internet need only be concerned with getting traffic to the router providing access to the private internetwork. From there, the borrowed bits are used by the network's internal routers to direct the traffic to the proper subnet, and then to the proper host.

A subnetted class B address allows Internet routers to maintain a record of that entire private internetwork with just one routing table entry. The alternative, which is a separate class C address for each network segment, would require Internet routers to maintain a routing table entry for each of those class C addresses. Multiply these additional routing table entries by the thousands of registered networks, and the result is an enormous additional burden on the Internet infrastructure.

Although it is not essential that IP addresses be subnetted to conform to the physical layout of an internetwork, it is beneficial to the routing process. If all of the systems on a large internetwork are assigned consecutive IP addresses irrespective of network segments (an arrangement called transparent subnetting), it becomes necessary to implement a system by which routers can determine the segment where a particular host is located.

Overall, the primary benefit to subnetting an internetwork is administrative. Individual host address assignments have to be made by the administrators of the registered network—and the assignments must be unique. Without subnets, the IP address list for an entire class B network would have to be maintained in one place. For an organization with many different offices, this would be most impractical. By creating subnets, individual branch offices or departments can be given the responsibility of maintaining their own individual IP address assignment lists.

SUBNET MASKING

This subnetting technique does present a problem. In previous sections, you read about IP address classes and the various ways to split the 32 bits of an IP address to identify a network and a host. Now, the logical question arises concerning how a computer determines where the dividing line between the network address and host address lies. The answer, when you are dealing with the standard address classes, is by the value of the first byte (128 to 191 representing class C networks, for example).

When you create subnets, however, this relationship is no longer reliable. A registered class B address can be subnetted using the third byte of the address as the subnet identifier. The addresses, therefore, function like class C’s, but the first byte still indicates class B. When subnetting was made a required feature of all TCP/IP hosts (in RFC950), a new mechanism was implemented to locate the dividing line between the network/subnet address and the host address. This mechanism is called a subnet mask. It is now a required element of all TCP/IP host configurations, along with the IP addresses. A subnet mask is simply a 32-bit binary figure that functions like a template for the IP address. Each bit with a value of one indicates that the bit is part of the network address. Bits with a value of zero represent host address bits. Thus, the subnet mask for an ordinary, unsubnetted class B address is:

In decimal notation, this subnet mask is 255.255.0.0.

When you subnet the class B network, you can modify the mask by extending the network address to include the third byte, as follows:

The new subnet mask in decimal form is 255.255.255.0. This is the same mask that would be used for a naturally occurring class C address.

Technically, subnetted IP addresses can be said to be broken into three parts, instead of two. Those are a network address, a subnet address, and a host address, as shown in figure 2-13. For masking and routing purposes, however, the network and subnet addresses are combined into a single explicit network address.

SUBNET MASK ORIENTATION

The previous example, of a class B address that is subnetted by using the third byte for a subnet identifier, demonstrates byte-orient masking. This is the simplest form of subnetting because masks are traditionally supplied in decimal form, and the binary figures 00000000 and 11111111 are easily converted into 0 and 255, respectively. You can, however, subnet any class of IP address by borrowing any number of bits from the host. When the boundary between the network and host addresses does not fall between bytes, however, the decimal values become much more difficult to understand. At these times, it is much simpler to think of the subnet mask in binary terms.

If, for example, you take a registered class C address and subnet it by borrowing four bits from the host address, your original subnet mask of:

becomes

This mask allows you to create 14 subnets (2⁴-2) containing 14 hosts each.

When a byte is used partly for a subnet identifier and partly for the host, you must also consider the binary values of the byte in assigning IP addresses to each workstation. The first subnet in the given example would have the binary value 0001, and the hosts would be numbered from 0001 to 1110 (the values 0000 and 1111 being invalid). This means that the hosts in that subnet would be assigned IP addresses with fourth-byte values ranging from 00010001 to 00011110, which translate into decimal form as 17 through 30.

The class C network 199.99.99.0 could therefore be subnetted as shown in Table 2-4.

The Windows Calculator program, in its Scientific mode, provides an easy means of converting binary numbers to decimals.

VARIABLE SIZE SUBNETTING

One of the problems that arises in the subnetting process is the difficulty in predicting the precise growth patterns of the network, in terms of how many hosts will be added to each subnet. As a result, administrators frequently waste IP addresses by planning for growth that never occurs, rather than risking modification of the entire subnetting strategy at a later date. NetWare supports a solution to this problem, defined in RFC1219, that calls for the creation of subnets of varying sizes.

Variable-sized subnets can be created by moving the dividing line between the subnet identifier and the host identifier. This results in hosts on different subnets with different subnet masks, depending on the number of host addresses needed for that subnet. Instead of borrowing a consistent number of bits from the host identifier and dividing a network address into a number of identical subnets (each containing the same number of hosts), the number of subnet bits is varied to allow as many host bits as are needed.

If a class B network address is to be subnetted, a subnet with a large number of hosts could have a mask in which the first four bits of the third byte form the subnet identifier. Following is an example:

Subnets containing a smaller number of hosts could use a standard byte-oriented mask in which the entire third byte identifies the subnet. An example of this looks like the following:

NOTE:

When you create variable-sized subnets, the subnet with the smaller number of hosts is a subset of the larger, and is sometimes referred to as a stub network. In order for the stub network to communicate properly with the rest of the host on the network, you must enable proxy ARP on the interface of the larger subnet. You do this by adding the proxyarp=yes parameter to the BIND command line, or by using the INETCFG.NLM utility in the NetWare implementation of TCP/IP. For more information, see "Proxy ARP" in Chapter 4.

In the latter case, the actual number of available subnets is limited. This is due to the last four bits of the third byte being used for host identifiers on the other subnet. These bits are being used to form IP addresses needed in the other, larger, subnet—rather than being squandered on another subnet with relatively few hosts.

A router connected to two network segments, one of which has many more workstations connected to it than the other, enables you to use different subnet masks for each interface. This accommodates the number of IP addresses needed for each.

This system of subnetting also provides a more flexible medium for network growth than the standard method. When administrators assign IP addresses, the values of the subnet and host identifiers are usually incremented from right to left, in binary notation. In other words, the progression of addresses (see Figure 2-14) shows the ones being added on the right and moving towards the left.

Figure 2-14: The numbering of subnets and hosts, when seen in binary notation, proceeds by adding 1 bit on the right side of the identifier, displacing the 0’s on the left.

Figure 2-15: By reversing the order of the bits in the subnet identifier, the zeroes or "growth bits" of the address can be used by either the host or the subnet. This is done by simply moving the location of the mask.

In this pattern, you can see that the "growth bits,"—the bits you use for expansion purposes—appear on the left on both sides of the mask, forming the dividing line between the subnet and host identifiers. RFC1219 proposes that the growth bits for the subnet identifier be reversed. That way they appear on the right side, so the zero bits on both sides of the mask can be pooled, as shown in figure 2-15.

With all of the growth bits pooled in between the subnet and host identifiers, you can move the subnet mask in either direction. This way you can provide additional bits to either identifier depending on the needs of your growing network. To change the orientation of the subnet identifiers growth bits however, you must assign subnet identifiers using a binary counting process that is the mirror image of the traditional method, with ones entering on the left and moving towards the right.

Adopting this subnetting method obviously makes the administrator's task of assigning IP addresses and subnet masks more arduous, and more dependent on an understanding of binary IP-address values. Variable-sized subnets are not supported by dynamic routing protocols that don’t carry subnet mask information—such as RIP—although the RIPII and OSPF protocols do carry subnet mask data.

Before creating variable-sized subnets, be sure that all of the technologies on your network support their use—including routers and other operating systems' TCP/IP implementations.

Naming TCP/IP Systems

IP addresses are one of the primary strengths of the TCP/IP protocols. They enable any computer on a network to identify and communicate with any other computer, regardless of their hardware and software platforms. When it comes to human interaction with TCP/IP applications, however, IP addresses are difficult to remember and use. For this reason, standards were developed to assign names to TCP/IP hosts.

On the Internet, host names are assigned to IP addresses and maintained in a distributed database, called the Domain Name System (DNS). Internet host names consist of multiple words, separated by periods, that define the location of a particular host in a hierarchy of domains. Another naming convention used by TCP/IP systems is that of the NetBIOS programming interface. IBM developed this for the purpose of creating one of the first PC networking systems. The NetBIOS names assigned to computers are up to 16 characters long, and are used on private networks to identify specific computers.

The Microsoft Windows operating systems use NetBIOS names to identify networked systems (no matter what protocols are used to carry the transmissions). When the NetBIOS Over TCP/IP (or NetBT) standards are used for Windows networking, NetBIOS names are equated with IP addresses, just like Internet host names. Thus a Windows 95 or Windows NT system on a corporate network must have an IP address, but it may also have a NetBIOS name and an Internet host name.

The TCP/IP protocols do not require (or even use) names to communicate with the other systems on a network. When a user supplies an Internet host name or a NetBIOS name in a TCP/IP client application such as a web browser, the first thing that the client software does, before any data is transmitted to the destination, is convert the host name into an IP address. This process is called name resolution. Then, the IP protocol uses only the address to identify the destination system. Names never appear in TCP/IP packet headers, only in the payload.

TCP/IP systems can use a number of different name resolution mechanisms, depending on the size and complexity of the network. These mechanisms, and their relationships to the TCP/IP protocols and standards, are examined in detail in chapter 11, "Name Registration and Resolution."

Hosts and Domains

An Internet host name, like an IP address, is divided into two distinct parts. One part identifies the domain in which the host is located and the other identifies the host, itself. The host identifier is a single word, while the domain name consists of at least two words. For example, in a common host name allotted to a web server, like www.mycorp.com, www identifies the host and mycorp.com the domain. Like IP addresses, Internet host names must be unique, and the responsibility for assigning and maintaining them is divided between the Internet authorities and the individual network administrators.

The multiple words of a domain name reflect the order formed by an Internet naming hierarchy. This is used to implement the DNS. A domain is a logical identifier for a collection of hosts, which may or may not be located on the same TCP/IP network. Organizations register their domain names with an Internet authority like InterNIC, just as they do their IP network addresses (but the two are completely separate). You need not register one in order to use the other.

Internet domains are hierarchical, and can be displayed in a tree diagram, much like a directory structure. At the top of the hierarchy is the root domain, which consists of a collection of root servers. Beneath the root are the top-level domains, which have been established by the Internet authorities to provide basic categories for organizations using the Internet. There are two basic principles used in the creation of the top-level domains: geographical and organizational.

Most of the world outside the U.S. uses geographical domains. Based on the X.500 directory service structure, these top-level domains use two letter codes to represent countries. The domain name uk is used for the United Kingdom, for example, and fr for France. The domain name for Germany is de, for Deutschland, because the names are abbreviations of the country's name, in its native language. There is also a us domain name, which is coming into more popular use because of the serious depletion of effective names in the com domain.

Com is an organizational name, and is the prevalent system used in the U.S. There are six organizational top-level domain names. Used by various bodies according to their primary function, they are as follows:

• com - used by commercial organizations
• mil - used by military organizations
• gov - used by government agencies
• edu - used by educational institutions
• net - used by network support organizations, such as ISPs
• org - used by non-profit organizations, and other uncategorizable bodies

In addition, seven new generic top-level domains (gTLDs) have been approved by the Internet Ad Hoc Committee (IAHC). Currently in the process of being assigned official registrars, they are as follows:

• firm - used for businesses or firms
• store - used for businesses offering goods for purchase
• web - used for organizations emphasizing World Wide Web-related activities
• arts - used for organizations emphasizing cultural and entertainment activities
• rec - used for organizations emphasizing recreation/entertainment activities
• info - used for organizations providing information services
• nom - used for those wishing individual or personal nomenclature

The top-level domains are not registered or owned by particular organizations (but all of those below the top level are). A company, school, or other organization registers its selected name with the authority controlling the appropriate top-level domain. They are then assigned exclusive rights to that name. Domain names must be unique. In the past, failure to create unique names resulted in conflicts between companies seeking to obtain rights to the same name. As the primary contact mechanism used by Internet clients, domain names, possess a marketing value that far extends any technical considerations (particularly in the commercial arena).

Having registered a domain name, an organization can assign host names to individual systems, or they can choose to create subdomains. Like subnetting IP addresses, the responsibility of creating subdomains lies exclusively with the organization's network administrators. The owners of the mycorp.com domain can create subdomains for each of their branch offices, such as ny.mycorp.com and la.mycorp.com—or use any organizational principle they wish, without consulting InterNIC or registering the names.

Host names are always written in the reverse order of IP addresses. The least significant word, the host identifier, comes first and each name in the domain hierarchy follows. The hierarchy culminates in the name of the top-level domain. The host identifier is also assigned by the network administrator, and must be unique within the domain (or subdomain). Systems are often named for the services they provide, such as www for web servers and ftp for FTP servers. There is no official standard that controls host naming.

NetBIOS Names

NetBIOS is a software interface, developed by IBM in the early 1980s. It was created to be one of the first PC networking systems. NetBIOS provides unicast, multicast, and broadcast transmission capabilities using both session (connection-oriented) and datagram (connectionless) services. Originally designed for use with DOS operating systems, it is not based on any official standard. Other implementations were developed, based on IBM's documentation, that were not necessarily compatible with the original version.

The significance of NetBIOS in today's networking industry is that Microsoft used it as the foundation for the peer-to-peer networking functionality in its Windows NT, Windows 95, and Windows for Workgroups operating systems. The name that you assign to your computer when installing the networking modules in any of these OSs is, in fact, a NetBIOS name.

NetBIOS, therefore, provides a naming system but not a communications protocol. The Windows operating systems can use any one of several protocol standards with its NetBIOS interface. NetBEUI, the NetBIOS Extended User Interface, was the default protocol in the original Windows NT 3.1 release. NetBEUI strictly uses NetBIOS names to identify the other systems on the network. It does this by issuing name broadcasts and waiting for the appropriate system to respond. NetBEUI tends to flood networks with broadcasts; it also lacks a network layer and cannot be routed to other network segments. The TCP/IP protocols became the default in Windows NT 3.51, based on the RFC1001 and RFC1002 standards—which define a method for carrying NetBIOS data within normal TCP and UDP transmissions. Unlike NetBEUI, NetBIOS over TCP/IP (or NetBT), requires IP addresses for all communicating systems, just like any TCP/IP network. The standards, therefore, must define a means of resolving NetBIOS names into IP addresses (just as Internet host names are resolved into IP addresses by DNS). Because the NetBIOS interface, in the Windows OS, can use other networking protocols for its communication, NetBIOS names are a more integral part of the networking system than host names are to the Internet. It is quite possible to operate Internet services like web or FTP clients and servers without ever using a host name or the DNS, but to perform standard Windows networking functions, you must provide a NetBIOS name for your computer.

TCP/IP Routing

The vast majority of TCP/IP packet transmissions are not destined for systems on the same local network segment. Instead, they are routed to another network; therein lies the essential difference between IP addresses and hardware addresses coded into network adapters. When a packet is transmitted over an Ethernet network, the destination address stored in Ethernet header does not always identify the ultimate receiver of the packet. Instead, this header is designed only to get the packet to the next stop in its journey. When the next stop is a router providing access to another network segment, it changes the destination address in the Ethernet header to that of the next router in the journey.

If the router provides access to a different type of network, the Ethernet header is removed entirely and replaced with one appropriate for the new protocol. Through all of this, the destination address in the IP header identifies the system for which the packet's payload is intended. This does not change. In a TCP/IP transmission, the sending and receiving computers are referred to as end systems. All of the routers encountered during the journey are called intermediate systems.

In the OSI reference model, data link layer protocols are not involved in the delivery of packets to their final destination. They are only involved with the next system down the line. The network layer protocol handles the routing of packets through the internetwork to the destination system. In the TCP/IP protocol stack, the internet layer is the direct equivalent to the OSI network layer—which leaves the IP protocol responsible for internetwork routing.

When TCP/IP packets pass through intermediate systems on their way to a destination, they travel up the protocol stack. They do not, however, go any higher than the internet layer (see Figure 2-16). The IP protocol determines whether the destination system is located on the local network segment, or if the packets must be sent to another router. In the latter case, IP works in cooperation with ICMP, the system's internal routing tables, and specialized routing protocols like RIP (the Routing Information Protocol) to determine the most efficient route. Then, the hardware address of the next router is discovered and passed to the data link layer protocol for transmission over the network medium.

Figure 2-16: Incoming traffic travels no higher than the internet layer in an intermediate system.

On private internetworks, routing is a relatively limited exercise. The most commonly used data link protocol standards, Ethernet and Token Ring, impose strict limitations on the number of network segment packets may pass through on the way to a destination. The Internet, however, uses many different data link layer protocols, and imposes no such restrictions. It is not uncommon for packets to pass through up to twenty routers or more on their way to a destination. This phenomenon is easily demonstrated with a traceroute utility, like that found in UNIX and Windows operating systems.

Summary

This chapter described some basic structures and procedures involved in communicating over a network using the TCP/IP protocols. In this chapter, you learned:

• How multilayered networking stacks are used to organize communications processes
• How the data generated by one protocol is encapsulated by another protocol for transmission
• How the IP addressing system is used to identify TCP/IP hosts
• How the domain naming system is used to create friendly names for Internet hosts

The next chapter examines the ways TCP/IP protocols are integrated into the Windows NT and IntranetWare products.