The TCPIP Protocol Suite

Whole books have been written about TCP/IP, and justifiably so. Although most administrators don't need to know every detail of programming a TCP connection or what to expect as a return value from a gethostbyname() call, they do need to understand enough to configure the protocol and make it work properly.

The important fact to remember about TCP/IP is that it isn't a single entity. TCP/IP is short for Transmission Control Protocol/Internet Protocol, but these are only two of the protocols included in the TCP/IP suite. There are a variety of other protocols, each with its own specialized area of importance and use.

Another important aspect of TCP/IP is that it isn't controlled by any one company or vendor, unlike other protocols such as Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX) and the now nearly obsolete NetBIOS Extended User Interface (NetBEUI) protocol. TCP/IP is an open standard controlled by the Internet Engineering Task Force (IETF) and by the users of the Internet itself in the form of RFCs (requests for comments). Anyone can submit an RFC for consideration and inclusion into the written definitions of the protocols and policies of the Internet and TCP/IP.

Internet Protocol

IP is the core protocol of the TCP/IP suite. To quote from RFC 791, "The Internet Protocol is designed for use in interconnected systems of packet-switched computer communication networks." IP performs only one basic function: to deliver a packet of bits (called a datagram) from point A to point B over any network "wire" it happens to encounter along the way.

The term wire is used very loosely here and elsewhere to indicate the actual—usually physical—network connection between two points. In fact, that wire can just as easily be a piece of optical fiber or even a radio or infrared signal. In all cases it functions as the transmission medium through which the packets travel.

IP doesn't in and of itself know anything about the information in the datagram it carries, nor does it have any provision beyond a simple checksum to ensure that the data is intact or that it has reached its destination. That is left to the other protocols in the TCP/IP suite.

Transmission Control Protocol

According to RFC 793 (the defining RFC for the protocol), TCP is "a connection-oriented, end-to-end reliable protocol designed to fit into a layered hierarchy of protocols which support multinetwork applications." The following list elaborates on some of those terms:

• Connection-oriented TCP provides for the communication of packets between two points, sending the datagram specifically from one computer or device to another, and sending an acknowledgment back to the sending computer on receipt of intact packets.
• End-to-end Each TCP packet designates a specific endpoint as its destination. Packets are passed along the wire and ignored except by the actual endpoint of the packet and any device that needs to direct it.
• Reliable This is the key point of TCP. When a program such as FTP uses TCP for its protocol, TCP takes responsibility for the reliability of the communications. The protocol itself provides for interprocess communication to ensure that packets that are sent out not only get there, but also that they get there in the order in which they were sent. If a packet is missed, the protocol communicates with the sending device to ensure a resend of the packet.

  Because TCP has to create a reliable connection between two devices or processes, each packet involves substantially more overhead than is needed with other, less reliable protocols within the suite. But by the same token, the programmer writing the application that uses TCP doesn't have to include a lot of error checking and handshaking in the application itself.

User Datagram Protocol

The User Datagram Protocol (UDP), another protocol in the TCP/IP suite, is a connectionless, transaction-oriented protocol designed to send packets with a minimum of protocol overhead. It provides no guarantee that its intended recipient received the packet, or that packets were received in the order in which they were sent. UDP is frequently used in broadcast messages where there is no specific intended recipient, such as Boot Protocol (BOOTP) and Dynamic Host Configuration Protocol (DHCP) requests, but it can also be used by applications that prefer to ensure reliable delivery internally rather than in an underlying protocol. UDP is defined in RFC 768.

Windows Sockets

Windows Sockets (commonly referred to as Winsock) provides a standard way for application programs to communicate with a TCP/IP stack without having to consider any underlying variations in the TCP/IP stack implementation.

In the past there were many different vendors of TCP/IP protocol and applications suites for MS-DOS-based computers, each slightly different from the others. This situation made it extremely difficult to write an application that required TCP/IP and yet worked with all the TCP/IP implementations that existed. Winsock was designed to get around this problem by providing a uniform set of application programming interface (API) calls that would be the same regardless of the underlying differences in the actual implementation of TCP/IP.

The original Winsock version 1 had a fair number of difficulties, and version 1.1 was released soon after its initial implementation. The current version of Winsock supported by the Windows 2000 Server family is version 2, which provides for full backward compatibility with earlier versions while offering improved functionality and support for additional features and expandability. Note that Winsock 2 has been around since Microsoft Windows NT 4, so applications are widely available that use this API, something that will become more important as IP version 6 (discussed later in the chapter) is rolled out.

Network Basic Input/Output System

NetBIOS is a networking API used by legacy applications and operating systems to communicate across a network using the NWLink (IPX/SPX compatible), NetBEUI, or TCP/IP protocols.

Until the advent of Windows 2000, NetBIOS was the primary networking API used by all Microsoft operating systems. NetBIOS names were used for name resolution within Windows-based networks. Any time a computer wanted to communicate with another computer on the network, the computer had to resolve the NetBIOS name for the other computer either by querying a Windows Internet Name Service (WINS) server, using a NetBIOS broadcast, or referring to the computer's local Lmhosts file.

With Windows 2000, Microsoft changed the Windows networking infrastructure to one based on TCP/IP, with no NetBIOS support required. Networks based on Windows 2000 can use DNS to resolve network names, and network applications can use the Winsock interface to communicate using a network.

Unfortunately, because earlier versions of Windows require NetBIOS support to function properly on a Windows-based network, many companies still need to support NetBIOS over TCP/IP and provide WINS services for downlevel (older) clients and servers.

If you have only a small number of downlevel computers, you might be able to make do without WINS by relying on NetBIOS broadcasts for name resolution—just keep in mind that broadcasts generally aren't routable, so downlevel computers will have access only to their local subnet.

Requests for Comments

RFCs come in many guises, but all of them have the same intent and a somewhat similar format. They are designed to provide a way for an extremely diverse group—the users of the Internet—to communicate and agree on the architecture and functionality of the Internet. Some RFCs are official documents of the IETF, defining the standards of TCP/IP and the Internet; others are simply proposals trying to become standards; and others fall somewhere in between. Some are tutorial in nature, others are quite technical, and some are even humorous (such as RFC 2324, "Hyper Text Coffee Pot Control Protocol"). But all are a way for the Internet, an essentially anarchic entity, to organize and communicate.

There's no need to list all the RFCs here, and you certainly don't need to read them all, but you should know where to find them and be aware of the most important ones. You can find listings of RFCs in a number of places; an excellent site is http://www.cis.ohio-state.edu/cs/Services/rfc/index.html. The RFCs at this location are organized and linked logically to make it easy to find the information you're looking for. This site, however, isn't nearly as up-to-date as the official RFC editor site, http://www.rfc-editor.org. If you want to be sure you have the most current information, use the latter site. Table 13-1 lists some important RFCs and their subject matter.

Table 13-1. Some key RFCs and what they cover

RFC Number	Subject
RFC 768	User Datagram Protocol (UDP)
RFC 791	Internet Protocol (IP)
RFC 792	Internet Control Message Protocol (ICMP)
RFC 793	Transmission Control Protocol (TCP)
RFC 821	Simple Mail Transfer Protocol (SMTP)
RFC 822	Standard for the Format of Advanced Research Project Agency (ARPA) Internet Text Messages
RFC 854	Telnet Protocol
RFC 959	File Transfer Protocol (FTP)
RFC 1001, 1002	Network Basic Input/Output Operating System (NetBIOS) over TCP/IP
RFC 1011	Official Internet Protocols
RFC 1034	DNS Concepts and Facilities
RFC 1035	DNS Implementation and Specification
RFC 1166	Internet Numbers
RFC 1542	Clarifications and Extensions for the Bootstrap Protocol
RFC 1886	DNS Extensions to Support IP version 6
RFC 1918	Address Allocation for Private Internets
RFC 2131	Dynamic Host Configuration Protocol (DHCP)
RFC 2136	Dynamic Updates in the DNS System (Dynamic DNS)
RFC 2251	Lightweight Directory Access Protocol (LDAP)
RFC 2460-2463	Internet Protocol version 6 (IPv6) Specifications
RFC 2492	IPv6 over Asynchronous Transfer Mode (ATM) networks
RFC 2661	Layer Two Tunneling Protocol (L2TP)
RFC 2782	A DNS Resource Record (RR) for Specifying the Location of Services (DNS SRV)
RFC 3007	Secure DNS