archive-name: internet/tcp-ip/tcp-ip-faq Version: 5.12 Last-modified: 1999-06-04 18:09:24 Posting-Frequency: monthly (first Friday) Maintainer: tcp-ip-faq@eng.sun.com (Mike Oliver) URL: http://www.itprc.com/tcpipfaq/default.htm TCP/IP Frequently Asked Questions Part 1: Introduction and Fundamental Protocols This is Part 1 of the Frequently Asked Questions (FAQ) list for the comp.protocols.tcp-ip Usenet newsgroup. The FAQ provides answers to a selection of common questions on the various protocols (IP, TCP, UDP, ICMP and others) that make up the TCP/IP protocol suite. It is posted to the news.answers, comp.answers and comp.protocols.tcp-ip newsgroups on or about the first Friday of every month. The FAQ is posted in two parts. Part 1 contains answers to general questions and questions that concern the fundamental components of the suite. Part 2 contains answers to questions concerning common applications that depend on the TCP/IP suite for their network connectivity. Comments on this document can be emailed to the FAQ maintainer at . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Table of Contents FAQ Part 1: Introduction and Fundamental Protocols Administrivia 1. Where can I find an up-to-date copy of this FAQ? 2. Who wrote this FAQ? About TCP/IP 1. What is TCP/IP? 2. How is TCP/IP defined? 3. Where can I find RFC's? 4. How do I find the right RFC? About IP 1. What is IP? 2. How is IP carried on a network? 3. Does IP Protect Data on the Network? 4. What is ARP? 5. What is IPng? 6. What is the MBONE? 7. What is the 6bone? 8. What is IPsec? About TCP 1. What is TCP? 2. How does TCP try to avoid network meltdown? 3. How do applications coexist over TCP and UDP? 4. Where do I find assigned port numbers? About UDP 1. What is UDP? About ICMP 1. What is ICMP? TCP/IP Network Operations 1. How can I measure the performance of an IP link? 2. What IP addresses should I assign to machines on a private internet? 3. Can I set up a gateway to the Internet that translates IP addresses, so that I don't have to change all our internal addresses to an official network? 4. Can I use a single bit subnet? TCP/IP Protocol Implementations 1. Where can I find TCP/IP source code? 2. Where can I find TCP/IP application source code? 3. Where can I find IPng source code? Further Sources of Information 1. What newsgroups deal with TCP/IP? 2. Are there any good books on TCP/IP? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Administrivia 1. Where can I find an up-to-date copy of this FAQ? You can browse a hyperlinked version of this FAQ on the World Wide Web at in the US (thanks to Irwin Lazar) and at in Israel (thanks to Uri Raz). Links to RFC's from Irwin's site refer to the ISI RFC repository in the US, while links to RFC's from Uri's site refer to the RFC repository at Imperial College in the UK. Use whichever gives you better response time. The current version of this FAQ is posted on a monthly basis to the news.answers, comp.answers and comp.protocols.tcp-ip newsgroups. A plaintext copy of the most recently posted version of the FAQ is available by anonymous FTP from . 2. Who wrote this FAQ? This FAQ was compiled from Usenet postings and email contributions made by many people, including: Rui Duarte Tavares Bastos, Mark Bergman, Stephane Bortzmeyer, Rodney Brown, Dr. Charles E. Campbell Jr., James Carlson, Phill Conrad, Alan Cox, Michael Hunter, Jay Kreibrich, William Manning, Barry Margolin, Vic Metcalfe, Jim Muchow, George V. Neville-Neil, Dang Thanh Ngan, Subu Rama, Uri Raz, and W. Richard Stevens. This FAQ is currently being maintained by Mike Oliver. Comments, complaints and contributions should be mailed to . Please do not send TCP/IP questions to this address; it is intended only for FAQ issues. If you have a question that is not already answered by the material in this FAQ you will get a much faster (and probably more accurate) response by posting the question to the comp.protocols.tcp-ip newsgroup than you will by sending it to the FAQ maintainer. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - About TCP/IP 1. 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. 2. 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 . 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. 3. Where can I find RFC's? The Definitive RFC Repository The official and definitive RFC repository is the anonymous FTP archive maintained by the Information Sciences Institute of the University of Southern California at . It is reachable via the Web at . RFC Repository Mirror Sites The RFC repository is mirrored at many sites on the Internet, and you may get a faster response from a local archive than you would from the often-overworked ISI site. Primary mirrors are updated at the same time as the InterNIC. Secondary mirrors may lag by a few hours or days. The current primary mirror sites are: In the USA ... Missouri: New Jersey: North Carolina: Texas: In Europe ... France: Italy: UK: Secondary mirror sites are listed in a document named rfc-retrieval.txt which can be found alongside the RFC's themselves at any of the above sites. RFC's by Email If you don't have direct access to the Internet but are able to send and receive email then you can still get RFC's through various email-to-ftp gateways. For instructions on how to do this, send email containing the text: help: ways_to_get_rfcs to . 4. How do I find the right RFC? There are over 2500 RFC's. Each RFC is known by a number. For instance, RFC 1180 presents a tutorial on TCP/IP, RFC 1920 lists the current standards RFC's and explains the RFC standards process, and RFC 1941 is a FAQ list on the topic of Internet deployment in educational establishments. RFC numbers are assigned in ascending order as each RFC is approved. The RFC files in the archive are named rfcNNNN.txt where NNNN is the number of the RFC. For instance, the text of RFC 822 is contained in the file named rfc822.txt. A small number of RFC's are also available in PostScript format, in which case a file named rfcNNNN.ps will exist in addition to the .txt file. Basic information (number, title, author, publication date and so on) on all of the RFC's is contained in the RFC index document named rfc-index.txt which you can find alongside the RFC's at any of the RFC archive sites. If you don't know which RFC's you need, the index is a good place to start. The index also indicates the current status of each RFC. The content of an RFC does not change once the RFC has been published, but since TCP/IP is in a constant state of evolution the information in one RFC is often revised, extended, clarified and in some cases completely superseded by later RFC's. Annotations in the index indicate when this is the case. If you find yourself using the index a lot then you might find it convenient to create your own HTML version of the index. Wayne Mesard has published a Perl script that takes the plaintext index file as input and produces an HTML version with hyperlinks to your chosen RFC FTP repository or to your own local RFC archive. The script is available at . If you don't want to wade through the index, some sites provide the ability to search the RFC catalogue by keyword: Keyword Searches on the Web , or Keyword Searches via gopher or RFC Keyword Searches via WAIS - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - About IP 1. 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. 2. 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". 3. 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 packet. 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 describes 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. 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. 4. 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). 5. What is IPng? Information on IPng can be found on the IPng home page at 6. 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 . 7. 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. 8. 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 (for distribution within the US only), from (for distribution within the US and Canada), and from (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.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - About TCP 1. 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. 2. 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 . PostScript slides of a presentation on this implementation of congestion avoidance can be obtained by anonymous FTP from . That directory contains several other interesting TCP-related papers, including one () by Sally Floyd that discusses a algorithm that attempts to give TCP the ability to recover quickly from packet loss in a network. 3. 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). 4. 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 . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - About UDP 1. 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 the destination, 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - About ICMP 1. 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 an 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: o 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 o 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.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TCP/IP Network Operations 1. How can I measure the performance of an IP link? You can get a quick approximation by timing how long it takes to FTP or RCP a large file over the link, but bear in mind that that measurement will be skewed by the time spent in dealing with the local and remote filesystems, not simply with the network itself. And remember to measure the time it takes to receive a file, not the time it takes to send it; the sender can report completion even though large amounts of data are still buffered locally by TCP and have not yet been delivered to the destination. There are a couple of well-known programs that measure and report throughput over an IP link without involving the filesystem. They are: o TTCP, available for anonymous ftp from the Silicon Graphics FTP archive at . o Rick Jones' NETPERF, available on the Web at . 2. What IP addresses should I assign to machines on a private internet? You shouldn't use IP addresses that have been assigned to some other organisation, because if knowledge of your network ever gets leaked onto the Internet they may disrupt that innocent organisation's activity. RFC 1918 provides a solution for this problem by allocating several IP address ranges specifically for use on private networks. These addresses will never be assigned to any organisation and are never supposed to appear on the Internet. The ranges are: Class A: 10.0.0.0 through 10.255.255.255 Class B: 172.16.0.0 through 172.31.255.255 Class C: 192.168.0.0 through 192.168.255.255 3. Can I set up a gateway to the Internet that translates IP addresses, so that I don't have to change all our internal addresses to an official network? This is called Network Address Translation, or NAT. In general it is a difficult thing to do properly because many applications embed IP addresses in the application-level data (FTP's "PORT" command is a notable example) so NAT isn't simply a matter of translating addresses in the IP header and recalculating header checksums. Also, if the network number(s) you're using match those assigned to another organisation, your gateway may not be able to communicate with that organisation. As noted above, RFC 1918 proposes network numbers that are reserved for private use, to avoid such conflicts, but if you're already using a different network number this won't help you. However, there are several products that do attempt to provide this kind of on-the-fly NAT. Linux provides NAT through its "IP Masquerading" feature, and many firewall and router vendors offer NAT capabilities in their products -- look for "Network Address Translation" in your favourite Web search engine to get a list of vendors. Proxy servers developed for firewalls can also sometimes be used as a substitute for an address-translating gateway for particular application protocols. This is discussed in more detail in the FAQ for the comp.security.firewalls newsgroup. That FAQ can be viewed on the Web at . 4. Can I use a single bit subnet? The answer used to be a straightforward "no", because a 1-bit subnet can only have a subnet part of all-ones or all-zeroes, both of which were assigned special meanings when the subnetting concept was originally defined. (All-ones meant "broadcast, all subnets of this net" and all-zeroes meant "this subnet, regardless of its actual subnet number".) However, the old definition of subnetting has been superseded by the concept of Classless Inter-Domain Routing (CIDR, pronounced 'cider'). Under CIDR the subnet doesn't really have an existence of its own and the subnet mask simply provides the mechanism for isolating an arbitrarily-sized network portion of an IP address from the remaining host part. As CIDR-aware equipment is deployed it becomes increasingly like that you will be able to use a 1-bit subnet with at least some particular combinations of networking equipment. However, it's still not safe to assume that a 1-bit subnet will work properly with all kinds of equipment. As Steinar Haug explains: From RFC 1122: > 3.3.6 Broadcasts > > Section 3.2.1.3 defined the four standard IP broadcast address > forms: > Limited Broadcast: {-1, -1} > Directed Broadcast: {, -1} > Subnet Directed Broadcast: {, , -1} > All-Subnets Directed Broadcast: {, -1, -1} All-Subnets Directed broadcasts are being deprecated in favor of IP multicast, but were very much defined at the time RFC1122 was written. Thus a Subnet Directed Broadcast to a subnet of all ones is not distinguishable from an All-Subnets Directed Broadcast. For those old systems that used all zeros for broadcast in IP addresses, a similar argument can be made against the subnet of all zeros. Also, for old routing protocols like RIP, a route to subnet zero is not distinguishable from the route to the entire network number (except possibly by context). Most of today's systems don't support variable length subnet masks (VLSM), and for such systems the above is true. However, all the major router vendors and *some* Unix systems (BSD 4.4 based ones) support VLSMs, and in that case the situation is more complicated :-) With VLSMs (necessary to support CIDR, see RFC 1519), you can utilize the address space more efficiently. Routing lookups are based on *longest* match, and this means that you can for instance subnet the class C net with a mask of 255.255.255.224 (27 bits) in addition to the subnet mask of 255.255.255.192 (26 bits) given above. You will then be able to use the addresses x.x.x.33 through x.x.x.62 (first three bits 001) and the addresses x.x.x.193 through x.x.x.222 (first three bits 110) with this new subnet mask. And you can continue with a subnet mask of 28 bits, etc. (Note also, by the way, that non-contiguous subnet masks are deprecated.) This is all very nicely covered in the paper by Havard Eidnes: Practical Considerations for Network Address using a CIDR Block Allocation Proceedings of INET '93 This paper is available with anonymous FTP from aun.uninett.no:pub/misc/eidnes-cidr.ps. The same paper, with minor revisions, is one of the articles in the special Internetworking issue of Communications of the ACM (last month, I believe). Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY Email: Steinar.Haug@runit.sintef.no - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TCP/IP Protocol Implementations 1. Where can I find TCP/IP source code? Code used in the venerable Net-2 version of Berkeley Unix is available by anonymous FTP from (at UUNet in Virginia, US) and (at Compaq in California, US). Source code for the TCP/IP implementations in the current dialects of BSD Unix is available. Instructions on how to access the sources through FTP and other methods is detailed on their respective websites: FreeBSD at ; NetBSD at ; and OpenBSD at . WATTCP is a DOS TCP/IP stack derived from the NCSA Telnet program and much enhanced. It is available from many DOS software archive sites as WATTCP.ZIP. This file includes some example programs and complete source code. The interface isn't BSD sockets but is well suited to PC type work. KA9Q is Phil Karn's network operating system for PC's. It includes a TCP/IP implementation originally developed for use over packet radio. Source is available from Phil's website at . 2. Where can I find TCP/IP application source code? Source code for the various TCP/IP applications delivered with the current BSD Unix flavours is available through the FreeBSD, NetBSD and OpenBSD websites noted in the previous section. Code from Comer's "Internetworking with TCP/IP Volume III" is available by anonymous FTP from . Code from Stevens' "TCP/IP Illustrated, Volume 1" is available from . Source code for some well-known cross-system TCP/IP applications (BIND, sendmail, Apache and so on) is available from the various organisations that sponsor the applications. See Part 2 of the FAQ for details. 3. Where can I find IPng Code? There are several freely distributable implementations of IPng, particularly for BSD and Linux. You can find detailed information at , part of the IPng home site mentioned above. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Further Sources of Information 1. TCP/IP-related newsgroups and FAQ lists: comp.protocols.tcp-ip covers all of the TCP/IP suite. comp.protocols.dns.bind covers the BIND suite, which contains server and client implementations of DNS. comp.protocols.tcp-ip.domains discusses DNS global administration and politics. comp.protocols.nfs covers NFS protocol, implementation, and administration. comp.protocols.snmp covers SNMP definition, implementation, and administration. comp.protocols.time.ntp covers NTP definition, implementation, and administration. comp.protocols.tcp-ip.ibmpc discusses TCP/IP for IBM(-like) personal computers. The group's FAQ is available at . comp.os.ms-windows.networking.tcp-ip discusses TCP/IP on Microsoft Windows machines. comp.os.ms-windows.programmer.tools.winsock covers the Winsock sockets API on Microsoft Windows machines. The group's FAQ is available at . comp.os.os2.networking.tcp-ip discusses TCP/IP on OS/2. comp.dcom.lans.ethernet covers Ethernet and IEEE 802.3 LAN's. The group's FAQ is available at . comp.dcom.lans.fddi covers FDDI LAN's. comp.dcom.lans.token-ring covers IBM Token Ring and IEEE 802.5 LAN's. comp.dcom.lans.misc covers all other types of LAN. comp.protocols.ppp covers PPP and SLIP. The group's FAQ is available at . comp.dcom.sys.cisco discusses cisco products. The group's FAQ is available at . comp.dcom.sys.wellfleet discusses Wellfleet (now Bay Networks) products. 2. Are there any good books on TCP/IP? Yes, lots of them, far too many to list here. Uri Raz maintains a TCP/IP bibliography (the "TCP/IP Resources List") that is posted to the comp.protocols.tcp-ip newsgroup on a monthly basis. It is available on the Web at and or can be retrieved by anonymous FTP from . However, a couple of books that always head the list of recommended reading are: "Internetworking with TCP/IP Volume I (Principles, Protocols, and Architecture)" by Douglas E. Comer, published by Prentice Hall 1991 (ISBN 0-13-468505-9). This is an introductory book which covers all of the fundamental protocols, including IP, UDP, TCP, and the gateway protocols. It also discusses some higher level protocols such as FTP, Telnet, and NFS. "TCP/IP Illustrated, Volume 1: The Protocols" by W. Richard Stevens, published by Addison-Wesley 1994 (ISBN 0-201-63346-9). This book explains the TCP/IP protocols and several application protocols in exquisite detail. It contains many real-life traces of the protocols in action, which is especially valuable for people who need to understand the protocols in depth. Part 2: Applications and Application Programming This is Part 2 of the Frequently Asked Questions (FAQ) list for the comp.protocols.tcp-ip Usenet newsgroup. The FAQ provides answers to a selection of common questions on the various protocols (IP, TCP, UDP, ICMP and others) that make up the TCP/IP protocol suite. It is posted to the news.answers, comp.answers and comp.protocols.tcp-ip newsgroups on or about the first Friday of every month. The FAQ is posted in two parts. Part 1 contains answers to general questions and questions that concern the fundamental components of the suite. Part 2 contains answers to questions concerning common applications that depend on the TCP/IP suite for their network connectivity. Comments on this document can be emailed to the FAQ maintainer at . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Table of Contents FAQ Part 2 -- Applications and Application Programming What Are The Common TCP/IP Application Protocols? 1. DHCP 2. DNS 3. FTP 4. HTTP 5. IMAP 6. NFS 7. NNTP 8. NTP 9. POP 10. Rlogin 11. Rsh 12. SMTP 13. SNMP 14. Telnet 15. X Window System TCP/IP Programming 1. What are sockets? 2. How can I detect that the other end of a TCP connection has crashed? 3. Can TCP keepalive timeouts be configured? 4. Are there object-oriented network programming tools? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - What Are The Common TCP/IP Application Protocols? 1. DHCP Dynamic Host Configuration Protocol (DHCP) allows IP addresses to be allocated to hosts on an as-needed basis. The conventional scheme of allocating a permanent fixed IP address to every host is wasteful of addresses in situations where only a relatively small number of hosts are active at any given time, and DHCP addresses this problem by allowing a small number of IP addresses to shared between the active hosts. DHCP also allows a host to retrieve a variety of boot-time configuration information at the same time as it acquires an IP address. DCHP depends on UDP to carry packets between the client and server tasks. DHCP is defined by RFC's 2131 and 2132. A widely-used implementation of DHCP can be downloaded from . 2. DNS The Domain Name System (DNS) provides dynamic on-demand translation between human-readable names (like www.pizzahut.com) and the numeric addresses actually used by IP (like 192.112.170.243). The basics of DNS operation are defined in RFC's 1034, 1101, 1876, 1982 and 2065. DNS uses both UDP and TCP. It used UDP to carry simple queries and responses but depends on TCP to guarantee the correct and orderly delivery of large amounts of bulk data (eg transfers of entire zone configurations) across the network. DNS standards are discussed in the comp.protocols.dns.std newsgroup. A very widely-used implementation of DNS called BIND (Berkeley Internet Name Domain) is discussed in the comp.protocols.dns.bind newsgroup, and the BIND software itself can be downloaded from . The politics and organization of DNS are discussed in the comp.protocols.tcp-ip.domains newsgroup. 3. FTP File Transfer Protocol (FTP) provides a mechanism for moving data files between systems. In addition to the fundamental PUT and GET operations, FTP provides a small number of file management and user authentication facilities. The protocol is defined in RFC 959. FTP depends on TCP to guarantee the correct and orderly delivery of data across the network. 4. HTTP Hyper Text Transfer Protocol (HTTP) is the protocol used to move Web pages across an internet. Version 1.0 of HTTP is defined by RFC 1945. Version 1.1 makes more efficient use of TCP and is defined by RFC 2068. HTTP depends on TCP to guarantee the correct and orderly delivery of data across the network. 5. IMAP Internet Message Access Protocol (IMAP) allows clients to manipulate email messages and mailboxes that reside on some server machine. The current version of IMAP is Version 4, usually referred to as IMAP4. IMAP4 is described by RFC 2060. IMAP provides no way of sending email; client programs that use IMAP to read mail usually use SMTP to send messages. IMAP is more powerful and more complex than the other widely-used mail-reading protocol POP. IMAP depends on TCP to guarantee the correct and orderly delivery of data across the network. IMAP is discussed in the comp.mail.imap newsgroup. 6. NFS Network File System (NFS) allows files stored on one machine (the "server") to be accessed by other machines (the "clients") as though the files were actually present on the client systems. NFS is defined in terms of a Remote Procedure Call (RPC) abstraction which in turn formats its packets according to a processor-independent eXternal Data Representation (XDR). Version 2 of NFS is defined in RFC 1094 and Version 3 is defined in RFC 1813. The RPC mechanism most often used with NFS, ONC/RPC, is defined by RFC 1831. The XDR conventions used by ONC/RPC are defined by RFC 1832. The ONC/RPC binding mechanism (a minimal directory service which allows RPC clients to rendezvous with RPC servers) is defined by RFC 1833. NFS can run over any kind of transport, but is most often used over UDP. UDP does not guarantee packet delivery or ordering, so when NFS runs over UDP the RPC implementation must provide its own guarantees of correctness. When NFS runs over TCP, the RPC layer can depend on TCP to provide this kind of correctness. NFS is discussed in the comp.protocols.nfs newsgroup. 7. NNTP Network News Transfer Protocol (NNTP) is used to propagate netnews postings (including Usenet postings) between systems. It is defined in RFC 977. (The format of netnews messages is defined in RFC 1023.) NNTP depends on TCP to guarantee the correct and orderly delivery of data across the network. NNTP is discussed in the news.software.nntp newsgroup. A very widely-used implementation of NNTP called INN (InterNet News) can be downloaded from . 8. NTP Network Time Protocol (NTP) is used to synchronise time-of-day clocks between various computer systems. The current version of NTP is Version 3, defined in RFC 1305. Earlier versions (2 and 1 respectively) of the protocol are defined in RFC's 1119 and 1059. David Mills maintains a publically-available implementation of NTP server and clients along with a comprehensive collection of NTP documentation on the web at . NTP depends on UDP to carry packets between server and client tasks. NTP is discussed in the comp.protocols.time.ntp newsgroup. 9. POP Post Office Protocol (POP) allows clients to read and remove email from a mailbox that resides on some server machine. The current version of POP is Version 3, usually referred to as POP3. It is described by RFC 1939. POP provides no way of sending email; client programs that use POP to read mail usually use SMTP to send messages. POP is simpler and less powerful than the other widely-used mail-reading protocol IMAP. POP depends on TCP to guarantee the correct and orderly delivery of data across the network. POP doesn't have its own dedicated newsgroup. It is sometimes discussed in client-specific newsgroups in the comp.mail.* hierarchy. 10. Rlogin Remote Login (rlogin) provides a network terminal or "remote login" capability. Rlogin is similar to Telnet but it adds a couple of features that make it a little more convenient than Telnet. Rlogin is one of the so-called Berkeley r-commands, (where the "r" stands for "remote") a family of commands created at UC Berkeley during the development of BSD Unix to provide access to remote systems in ways that are more convenient than the original TCP/IP commands. The most obvious convenience is that rlogin, like other r-commands, examines a .rhosts (pronounced "dot ar hosts") file on the server side to authenticate logins based on the client host address. The .rhosts file can be constructed to allow remote access without requiring you to enter a password. If used improperly this feature can be a security threat, but if used correctly it can actually enhance security by not requiring a password to be sent over the network where it might be read by a packet sniffer. The r-commands depend on TCP to guarantee the correct and orderly delivery of data across the network. 11. Rsh Remote Shell (rsh) is an r-command that provides for remote execution of arbitrary commands. It allows you to run a command on a server without having to actually log in on the server. More importantly it allows you to feed data to the remote command and retrieve the command's output without having to stage the data through temporary files on the server. Like other Berkeley r-commands, rsh uses the .rhosts file on the server side to authenticate access based on the client's host address. On some non-BSD systems the Remote Shell command is named remsh because by the time the command was delivered on those systems the usual rsh name had been used for a "restricted shell" application, a command line interpreter intended to boost security by preventing its users from performing certain activities. 12. SMTP Simple Mail Transfer Protocol (SMTP) is used to deliver email from one system to another. The basic SMTP is defined in RFC 821 and the format of Internet mail messages is described in RFC 822. SMTP depends on TCP to guarantee the correct and orderly delivery of data across the network. A very widely-used implementation of SMTP called sendmail can be downloaded from . 13. SNMP Simple Network Management Protocol (SNMP) provides a means of monitoring and managing systems over a network. SNMP defines a method of sending queries (the GET and GET-NEXT primitives) and commands (the SET primitive) from a management station client to an agent server running on the target system, and collecting responses and unsolicited event notifications (the TRAP primitive). Version 1 of SNMP is defined by RFC's 1098 and 1157. SNMP Version 2 is defined by RFC's 1441, 1445, 1446, 1447 and 1901 through 1909. The various things that can be monitored and managed by SNMP, collectively called the Management Information Base (MIB) are defined in dozens of additional RFC's. SNMP sends traffic through UDP because of its relative simplicity and low overhead. SNMP is discussed in the comp.protocols.snmp newsgroup. 14. Telnet Telnet provides a network terminal or "remote login" capability. The Telnet server accepts data from the telnet client and forwards them to the operating system in such a way that the received characters are treated as though they had been typed at a terminal keyboard. Responses generated by the server operating system are passed back to the Telnet client for display. The Telnet protocol provides the ability to negotiate many kinds of terminal-related behaviour (local vs. remote echoing, line mode vs. character mode and others) between the client and server. The basic Telnet protocol is defined in RFC's 818 and 854 and the option negotiation mechanism is described in RFC 855. Specific Telnet options, implementation issues and protocol quirks are discussed in several dozen RFC's dating back to 1971. (That's RFC's 97, 137, 139, 206, 215, 216, 318, 328, 340, 393, 435, 466, 495, 513, 559, 560, 562, 563, 581, 587, 595, 596, 652, 653, 654, 655, 656, 657, 658, 698, 726, 727, 728, 732, 735, 736, 748, 749, 779, 856, 857, 858, 859, 860, 861, 885, 927, 933, 946, 1041, 1043, 1053, 1073, 1079, 1091, 1096, 1097, 1143, 1184, 1205, 1372, 1408, 1411, 1412, 1416, 1571, 1572 and 2066, and that's not counting obsolete ones. A couple of these are not entirely serious.) As you might infer from this pedigree, Telnet is a widely-deployed and well-used protocol. Telnet depends on TCP to guarantee the correct and orderly delivery of data between the client and server. 15. X Window System The X Window System (X11R6 is the most recent incarnation) allows client programs running on one machine to control the graphic display, keyboard and mouse of some other machine or of a dedicated X display terminal. X depends on TCP to guarantee the correct and orderly delivery of data across the network. The X Window System is discussed in the comp.windows.x newsgroup. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TCP/IP Programming 1. What are sockets? A socket is an abstraction that represents an endpoint of communication. Most applications that consciously use TCP and UDP do so by creating a socket of the appropriate type and then performing a series of operations on that socket. The operations that can be performed on a socket include control operations (such as associating a port number with the socket, initiating or accepting a connection on the socket, or destroying the socket) data transfer operations (such as writing data through the socket to some other application, or reading data from some other application through the socket) and status operations (such as finding the IP address associated with the socket). The complete set of operations that can be performed on a socket constitutes the Sockets API (Application Programming Interface). If you are interested in writing programs that use TCP/IP then you'll probably need to use and understand the sockets API. Your system manuals may have a description of the API (try `man socket' if you're using a Unix system) and many books devote chapters to it. A FAQ list for sockets programming is available on the Web from its Canadian home at , from a UK mirror at or by anonymous FTP from . The TLI (Transport Layer Interface) API provides an alternative programming interface to TCP/IP on some systems, notably those based on AT&T's System V Unix. The Open Group, a Unix standards body, defines a variation of TLI called XTI (X/Open Transport Interface). Note that both sockets and TLI (and XTI) are general-purpose facilities and are defined to be completely independent of TCP/IP. TCP/IP is just one of the protocol families that can be accessed through these API's. 2. How can I detect that the other end of a TCP connection has crashed? Can I use "keepalives" for this? Detecting crashed systems over TCP/IP is difficult. TCP doesn't require any transmission over a connection if the application isn't sending anything, and many of the media over which TCP/IP is used (e.g. Ethernet) don't provide a reliable way to determine whether a particular host is up. If a server doesn't hear from a client, it could be because it has nothing to say, some network between the server and client may be down, the server or client's network interface may be disconnected, or the client may have crashed. Network failures are often temporary (a thin Ethernet will appear down while someone is adding a link to the daisy chain, and it often takes a few minutes for new routes to stabilize when a router goes down) and TCP connections shouldn't be dropped as a result. Keepalives are a feature of the sockets API that requests that an empty packet be sent periodically over an idle connection; this should evoke an acknowledgement from the remote system if it is still up, a reset if it has rebooted, and a timeout if it is down. These are not normally sent until the connection has been idle for a few hours. The purpose isn't to detect a crash immediately, but to keep unnecessary resources from being allocated forever. If more rapid detection of remote failures is required, this should be implemented in the application protocol. There is no standard mechanism for this, but an example is requiring clients to send a "no-op" message every minute or two. An example protocol that uses this is X Display Manager Control Protocol (XDMCP), part of the X Window System, Version 11; the XDM server managing a session periodically sends a Sync command to the display server, which should evoke an application-level response, and resets the session if it doesn't get a response (this is actually an example of a poor implementation, as a timeout can occur if another client "grabs" the server for too long). 3. Can the TCP keepalive timeouts be configured? This varies by operating system. There is a program that works on many Unices (though not Linux or Solaris), called netconfig, that allows one to do this and documents many of the variables. It is available by anonymous FTP from . In addition, Richard Stevens' TCP/IP Illustrated, Volume 1 includes a good discussion of setting the most useful variables on many platforms. 4. Are there object-oriented network programming tools? Yes. One such system is the ADAPTIVE Communication Environment (ACE). The README file for ACE is available on the Web at . All software and documentation is available via both anonymous ftp and the Web. ACE is available for anonymous ftp from . That's a compressed tar archive approximately 500KB in size. This release contains contains the source code, documentation, and example test drivers for C++ wrapper libraries. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This compilation contains the opinions of the FAQ maintainer and the various FAQ contributors. Any resemblance to the opinions of the FAQ maintainer's employer is entirely coincidental. Copyright (C) Mike Oliver 1997-1999. All Rights Reserved.