TCP/IP FAQs

What is TCP/IP?

TCP/IP is a name given to the collection (or suite) of networking protocols that have been used to construct the global Internet. The protocols are also referred to as the DoD (dee-oh-dee) or Arpanet protocol suite because their early development was funded by the Advanced Research Projects Agency (ARPA) of the US Department of Defense (DoD).

The TCP/IP name is taken from two of the fundamental protocols in the collection, IP and TCP. Other core protocols in the suite are UDP and ICMP. These protocols work together to provide a basic networking framework that is used by many different application protocols, each tuned to achieving a particular goal.

TCP/IP protocols are not used only on the Internet. They are also widely used to build private networks, called internets (spelled with a small 'i'), that may or may not be connected to the global Internet (spelled with a capital 'I'). An internet that is used exclusively by one organization is sometimes called an intranet.

How is TCP/IP defined?

All of the protocols in the TCP/IP suite are defined by documents called Requests For Comments (RFC's). An important difference between TCP/IP RFC's and other (say, IEEE or ITU) networking standards is that RFC's are freely available online.

RFC's can be composed and submitted for approval by anyone. Standards RFC's are often the product of many weeks or months of discussion between interested parties designated as working groups, during which time drafts of the proposed RFC are continually updated and made available for comment. These discussions typically take place on open mailing lists which welcome input from all quarters. The RFC approval process is managed by the Internet Engineering Steering Group (IESG) based on recommendations from the Internet Engineering Task Force (IETF) which is a prime mover in the formation of working groups focused on strategic TCP/IP issues. You can find out more about IESG and IETF activities from the IETF home page at http://www.ietf.org/.

Not all RFC's specify TCP/IP standards. Some RFC's contain background information, some provide hints for managing an internet, some document protocol weaknesses in the hope that they might be addressed by future standards, and some are entirely humorous.

What is IP?

Internet Protocol (IP) is the central, unifying protocol in the TCP/IP suite. It provides the basic delivery mechanism for packets of data sent between all systems on an internet, regardless of whether the systems are in the same room or on opposite sides of the world. All other protocols in the TCP/IP suite depend on IP to carry out the fundamental function of moving packets across the internet.

In terms of the OSI networking model, IP provides a Connectionless Unacknowledged Network Service, which means that its attitude to data packets can be characterised as "send and forget". IP does not guarantee to actually deliver the data to the destination, nor does it guarantee that the data will be delivered undamaged, nor does it guarantee that data packets will be delivered to the destination in the order in which they were sent by the source, nor does it guarantee that only one copy of the data will be delivered to the destination.

Because it makes so few guarantees, IP is a very simple protocol. This means that it can be implemented fairly easily and can run on systems that have modest processing power and small amounts of memory. It also means that IP demands only minimal functionality from the underlying medium (the physical network that carries packets on behalf of IP) and can be deployed on a wide variety of networking technologies.

The no-promises type of service offered by IP is not directly useful to many applications. Applications usually depend on TCP or UDP to provide assurances of of data integrity and (in TCP's case) ordered and complete data delivery.

The fundamentals of IP are defined in RFC 791. RFC 1122 summarises the requirements that must be met by an IP implementation in an Internet host, and RFC 1812 summarises the IP requirements for an Internet router.

How Is IP Carried On A Network?

IP really isn't very fussy about how its packets are transported. The details of how an IP packet is carried over a particular kind of network are usually chosen to be convenient for the network itself. As long as the transmitter and receiver observe some convention that allows IP packets to be differentiated from any other data that might be seen by the receiver, then IP can be used to carry data between those stations.

On a LAN, IP is carried in the data portion of the LAN frame and the frame header contains additional information that identifies the frame an an IP frame. Different LAN's have different conventions for carrying that additional information. On an Ethernet the Ethertype field is used; a value of 0x0800 identifies a frame that contains IP data. FDDI and Token Ring use frames that conform to IEEE 802 Logical Link Control, and on those LAN's IP is carried in Unnumbered Information frames with Source and Destination LSAP's of 0xAA and a SNAP header of 00-00-00-08-00.

The only thing that IP cares strongly about is the maximum size of a frame that can be carried on the medium. This controls whether, and to what extent, IP must break down large data packets into a train of smaller packets before arranging for them to be transmitted on the medium. This activity is called "fragmentation" and the resulting smaller and incomplete packets are called "fragments". The final destination is responsible for rebuilding the original IP packet from its fragments, an activity called "fragment reassembly".

Does IP Protect Data On The Network?

IP itself does not guarantee to deliver data correctly. It leaves all issues of data protection to the transport protocol. Both TCP and UDP have mechanisms that guarantee that the data they deliver to an application is correct.

IP does try to protect the packet's IP header, the relatively small part of each packet that controls how the packet is moved through the network. It does this by calculating a checksum on the header fields and including that checksum in the transmitted acket. The receiver verifies the IP header checksum before processing the packet. Packets whose checksums no longer match have been damaged in some way and are simply discarded.

The IP checksum is discussed in detail in RFC 1071, which also includes sample code for calculating the checksum. RFC 1141 and RFC 1624 describe incremental modification of an existing checksum, which can be useful in machines such as routers which modify fields in the IP header while forwarding a packet and therefore need to compute a new header checksum.

The same checksum algorithm is used by TCP and UDP, although they include the data portion of the packet (not just the header) in their calculations.

What is ARP?

Address Resolution Protocol (ARP) is a mechanism that can be used by IP to find the link-layer station address that corresponds to a particular IP address. It defines a method that is used to ask, and answer, the question "what MAC address corresponds to a given IP address?". ARP sends broadcast frames to obtain this information dynamically, so it can only be used on media that support broadcast frames. Most LAN's (including Ethernet, FDDI, and Token Ring) have a broadcast capability and ARP is used when IP is running on those media. ARP is defined in RFC 826. That definition assumes an Ethernet LAN. Additional details for ARP on networks that use IEEE 802.2 frame formats (IEEE 802.3 CSMA/CD, IEEE 802.4, IEEE 802.5 Token Ring) are in RFC 1042. ARP on FDDI is described in RFC 1390.

When IP is runnning over non-broadcast media (say, X.25 or ATM) some other mechanism is used to match IP addresses to media addresses. IP really doesn't care how the media address is obtained.

RFC 903 defines Reverse ARP (RARP) which lets a station ask the question "which IP address corresponds to a given MAC address?". RARP is typically used to let a piece of diskless equipment discover its own IP address as part of its boot procedure. RARP is rarely used by modern equipment; it has been supplanted by the Boot Protocol (BOOTP) defined in RFC 1542. BOOTP in turn is being supplanted by the Dynamic Host Configuration Protocol (DHCP).

What is IPv6?

IP Version 6 (IPv6) is the newest version of IP, sometimes called IPng for "IP, Next Generation". IPv6 is fairly well defined but is not yet widely deployed. The main differences between IPv6 and the current widely-deployed version of IP (which is IPv4) are:

• IPv6 uses larger addresses (128 bits instead of 32 bits in IPv4) and so can support many more devices on the network,and
• IPv6 includes features like authentication and multicasting that had been bolted on to IPv4 in a piecemeal fashion over the years.

Information on IPv6 can be found on the IPv6 home page at http://playground.sun.com/pub/ipng/html/ipng-main.html

What happened to IPv5?

Or, ""Why are we skipping from IPv4 to IPv6?"

IPv5 never existed. The version number "5" in the IP header was assigned to identify packets carrying an experimental non-IP real-time stream protocol called ST. ST was never widely used, but since the version number 5 had already been allocated the new version of IP was given its own unique identifying number, 6. ST is described in RFC 1819.

What is the 6bone?

The 6bone is the experimental IPv6 backbone being developed using IPv6-in-IPv4 tunnels. This is intended for early experimentation with IPv6 and is not a production service.

What is the MBONE?

The Multicast backBONE (MBONE) is a multicast-capable portion of the Internet backbone. Multicast support over IP is provided by a protocol called IGMP (Internet Group Management Protocol) which is defined in RFC 1112. The MBONE is still a research prototype, but it extends through most of the core of the Internet (including North America, Europe, and Australia). It is typically used to relay multimedia (audio and low bandwidth video) presentations from a single source to multiple receiving sites dispersed over the Internet.

A slightly dated MBONE FAQ is available by anonymous FTP from ftp://ftp.isi.edu/mbone/faq.txt.

What is IPsec?

IPsec stands for "IP Security". The IPsec working group of the IETF is developing standards for cryptographic authentication and for encryption within IP. The base specifications are defined in RFC's 1825, 1826 and 1827. Products that implement these are beginning to appear.

A freely distributable implementation of IPsec for IPv4 and IPsec for IPv6 is included in the NRL IPv6/IPsec distribution for 4.4-Lite BSD. The NRL software is available from http://web.mit.edu/network/isakmp/ (for distribution within the US only), from http://www.cisco.com/public/library/isakmp/ipsec.html (for distribution within the US and Canada), and from ftp://ftp.ripe.net/ipv6/nrl/ (for unrestricted distribution).

(Some countries consider encryption software to have military significance and so restrict the export and import of such software, which is why there are geographical restrictions on the areas served by the above sites.)

What is TCP?

Transmission Control Protocol (TCP) provides a reliable byte-stream transfer service between two endpoints on an internet. TCP depends on IP to move packets around the network on its behalf. IP is inherently unreliable, so TCP protects against data loss, data corruption, packet reordering and data duplication by adding checksums and sequence numbers to transmitted data and, on the receiving side, sending back packets that acknowledge the receipt of data.

Before sending data across the network, TCP establishes a connection with the destination via an exchange of management packets. The connection is destroyed, again via an exchange of management packets, when the application that was using TCP indicates that no more data will be transferred. In OSI terms, TCP is a Connection-Oriented Acknowledged Transport protocol.

TCP has a multi-stage flow-control mechanism which continuously adjusts the sender's data rate in an attempt to achieve maximum data throughput while avoiding congestion and subsequent packet losses in the network. It also attempts to make the best use of network resources by packing as much data as possible into a single IP packet, although this behaviour can be overridden by applications that demand immediate data transfer and don't care about the inefficiencies of small network packets.

The fundamentals of TCP are defined in RFC 793, and later RFC's refine the protocol. RFC 1122 catalogues these refinements as of October 1989 and summarises the requirements that a TCP implementation must meet.

TCP is still being developed. For instance, RFC 1323 introduces a TCP option that can be useful when traffic is being carried over high-capacity links. It is important that such developments are backwards-compatible. That is, a TCP implementation that supports a new feature must continue to work with older TCP implementations that do not support that feature.

How does TCP try to avoid network meltdown?

TCP includes several mechanisms that attempt to sustain good data transfer rates while avoiding placing excessive load on the network. TCP's "Slow Start", "Congestion Avoidance", "Fast Retransmit" and "Fast Recovery" algorithms are summarised in RFC 2001. TCP also mandates an algorithm that avoids "Silly Window Syndrome" (SWS), an undesirable condition that results in very small chunks of data being transferred between sender and receiver. SWS Avoidance is discussed in RFC 813. The "Nagle Algorithm", which prevents the sending side of TCP from flooding the network with a train of small frames, is described in RFC 896.

Van Jacobson has done significant work on this aspect of TCP's behaviour. The FAQ used to contain a couple of pieces of historically interesting pieces of Van's email concerning an early implementation of congestion avoidance, but in the interests of saving space they've been removed and can instead be obtained by anonymous FTP from the end-to-end mailing list archive at ftp://ftp.isi.edu/end2end/end2end-1990.mail. PostScript slides of a presentation on this implementation of congestion avoidance can be obtained by anonymous FTP from ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

That directory contains several other interesting TCP-related papers, including one (ftp://ftp.ee.lbl.gov/papers/fastretrans.ps) by Sally Floyd that discusses a algorithm that attempts to give TCP the ability to recover quickly from packet loss in a network.

How do applications coexist over TCP and UDP?

Each application running over TCP or UDP distinguishes itself from other applications using the service by reserving and using a 16-bit port number. Destination and source port numbers are placed in the UDP and TCP headers by the originator of the packet before it is given to IP, and the destination port number allows the packet to be delivered to the intended recipient at the destination system.

So, a system may have a Telnet server listening for packets on TCP port 23 while an FTP server listens for packets on TCP port 21 and a DNS server listens for packets on port 53. TCP examines the port number in each received frame and uses it to figure out which server gets the data. UDP has its own similar set of port numbers.

Many servers, like the ones in this example, always listen on the same well-known port number. The actual port number is arbitrary, but is fixed by tradition and by an official allocation or "assignment" of the number by the Internet Assigned Numbers Authority (IANA).

Where do I find assigned port numbers?

The IANA allocates and keeps track of all kinds of arbitrary numbers used by TCP/IP, including well-known port numbers. The entire collection is published periodically in an RFC called the Assigned Numbers RFC, each of which supersedes the previous one in the series. The current Assigned Numbers RFC is RFC 1700.

The Assigned Numbers document can also be obtained directly by FTP from the IANA at ftp://ftp.isi.edu/in-notes/iana/assignments.

What is UDP?

User Datagram Protocol (UDP) provides an unreliable packetized data transfer service between endpoints on an internet. UDP depends on IP to move packets around the network on its behalf.

UDP does not guarantee to actually deliver the data to thedestination, nor does it guarantee that data packets will be delivered to the destination in the order in which they were sent by the source, nor does it guarantee that only one copy of the data will be delivered to the destination. UDP does guarantee data integrity, and it does this by adding a checksum to the data before transmission. (Some machines run with UDP checksum generation disabled, in which case data corruption or truncation can go undetected. Very few people think this is a good idea.)

The fundamentals of UDP are defined in RFC 768. RFC 1122 summarises the requirements that a UDP implementation must meet.

What is ICMP?

Internet Control Message Protocol (ICMP) defines a small number of messages used for diagnostic and management purposes. ICMP depends on IP to move packets around the network on its behalf.

The fundamentals of ICMP are defined in RFC 792. RFC 1122 summarises the requirements that must be met by an ICMP implementation in an Internet host, and RFC 1812 summarises the ICMP requirements for an Internet router.

ICMP is basically IP's internal network management protocol and is not intended for use by applications. Two well known exceptions are the ping and traceroute diagnostic utilities:

• ping sends and receives ICMP "ECHO" packets, where the response packet can be taken as evidence that the target host is at least minimally active on the network, and
• traceroute sends UDP packets and infers the route taken to the target from ICMP "TIME-TO-LIVE EXCEEDED" or "PORT UNREACHABLE" packets returned by the network. (Microsoft's TRACERT sends ICMP "ECHO" packets rather than UDP packets, and so receives ICMP "TIME-TO-LIVE EXCEEDED" or "ECHO RESPONSE" packets in return.)