home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / internet / tcp-ip / tcp-ip-faq / part1 next >
Encoding:
Internet Message Format  |  1999-09-07  |  44.1 KB

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!howland.erols.net!news-out.digex.net.MISMATCH!dca1-hub1.news.digex.net!intermedia!hermes.visi.com!news-out.visi.com!cam-news-hub1.bbnplanet.com!denver-news-feed1.bbnplanet.com!news.gtei.net!namche.sun.com!news2me.EBay.Sun.COM!engnews3.Eng.Sun.COM!not-for-mail
  2. From: tcp-ip-faq@eng.sun.com (TCP/IP FAQ Maintainer)
  3. Newsgroups: comp.protocols.tcp-ip,comp.answers,news.answers
  4. Subject: TCP/IP FAQ; Frequently Asked Questions (1999-09) Part 1 of 2
  5. Supersedes: <tcp-ip-faq-1.1999-08@eng.sun.com>
  6. Followup-To: comp.protocols.tcp-ip
  7. Date: 7 Sep 1999 03:36:53 GMT
  8. Organization: Sun Microsystems Inc., Mountain View, CA
  9. Lines: 973
  10. Approved: news-answers-request@MIT.EDU
  11. Expires: Sat, 09 Oct 99 03:11:44 GMT
  12. Message-ID: <tcp-ip-faq-1.1999-09@eng.sun.com>
  13. NNTP-Posting-Host: rory.eng.sun.com
  14. Summary: Part 1 of a 2-part informational posting that contains
  15.      responses to common questions on basic TCP/IP network
  16.      protocols and applications.
  17. X-Disclaimer: Approval for postings in *.answers is based on form, not content.
  18. X-Newsreader: trn 4.0-test72 (19 April 1999)
  19. Xref: senator-bedfellow.mit.edu comp.protocols.tcp-ip:78107 comp.answers:37579 news.answers:166032
  20.  
  21. Archive-name:      internet/tcp-ip/tcp-ip-faq/part1
  22. Version:           5.15
  23. Last-modified:     1999-09-06 20:11:43
  24. Posting-Frequency: monthly (first Friday)
  25. Maintainer:        tcp-ip-faq@eng.sun.com (Mike Oliver)
  26. URL:               http://www.itprc.com/tcpipfaq/default.htm
  27.  
  28. TCP/IP Frequently Asked Questions
  29.  
  30. Part 1: Introduction and Fundamental Protocols
  31.  
  32. This is Part 1 of the Frequently Asked Questions (FAQ) list for the
  33. comp.protocols.tcp-ip Usenet newsgroup. The FAQ provides answers to a
  34. selection of common questions on the various protocols (IP, TCP, UDP,
  35. ICMP and others) that make up the TCP/IP protocol suite. It is posted
  36. to the news.answers, comp.answers and comp.protocols.tcp-ip newsgroups
  37. on or about the first Friday of every month.
  38.  
  39. The FAQ is posted in two parts. Part 1 contains answers to general
  40. questions and questions that concern the fundamental components of the
  41. suite. Part 2 contains answers to questions concerning common
  42. applications that depend on the TCP/IP suite for their network
  43. connectivity.
  44.  
  45. Comments on this document can be emailed to the FAQ maintainer at
  46. <tcp-ip-faq@eng.sun.com>.
  47.  
  48.   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  49.  
  50. Table of Contents
  51.  
  52. FAQ Part 1: Introduction and Fundamental Protocols
  53.  
  54. Administrivia
  55.  
  56.   1. Where can I find an up-to-date copy of this FAQ?
  57.   2. Who wrote this FAQ?
  58.  
  59. About TCP/IP
  60.  
  61.   1. What is TCP/IP?
  62.   2. How is TCP/IP defined?
  63.   3. Where can I find RFC's?
  64.   4. How do I find the right RFC?
  65.  
  66. About IP
  67.  
  68.   1. What is IP?
  69.   2. How is IP carried on a network?
  70.   3. Does IP Protect Data on the Network?
  71.   4. What is ARP?
  72.   5. What is IPv6?
  73.   6. What happened to IPv5?
  74.   7. What is the 6bone?
  75.   8. What is the MBONE?
  76.   9. What is IPsec?
  77.  
  78. About TCP
  79.  
  80.   1. What is TCP?
  81.   2. How does TCP try to avoid network meltdown?
  82.   3. How do applications coexist over TCP and UDP?
  83.   4. Where do I find assigned port numbers?
  84.  
  85. About UDP
  86.  
  87.   1. What is UDP?
  88.  
  89. About ICMP
  90.  
  91.   1. What is ICMP?
  92.  
  93. TCP/IP Network Operations
  94.  
  95.   1. How can I measure the performance of an IP link?
  96.   2. What IP addresses should I assign to machines on a private
  97.      internet?
  98.   3. Can I set up a gateway to the Internet that translates IP
  99.      addresses, so that I don't have to change all our internal
  100.      addresses to an official network?
  101.   4. Can I use a single bit subnet?
  102.  
  103. TCP/IP Protocol Implementations
  104.  
  105.   1. Where can I find TCP/IP source code?
  106.   2. Where can I find TCP/IP application source code?
  107.   3. Where can I find IPv6 source code?
  108.  
  109. Further Sources of Information
  110.  
  111.   1. What newsgroups deal with TCP/IP?
  112.   2. Are there any good books on TCP/IP?
  113.  
  114.   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  115.  
  116. Administrivia
  117.  
  118.   1. Where can I find an up-to-date copy of this FAQ?
  119.  
  120.      You can browse a hyperlinked version of this FAQ on the World Wide
  121.      Web at <http://www.itprc.com/tcpipfaq/default.htm> in the US
  122.      (thanks to Irwin Lazar) and at
  123.      <http://t2.technion.ac.il/~s2845543/tcpip-faq/default.htm> in
  124.      Israel (thanks to Uri Raz). Links to RFC's from Irwin's site refer
  125.      to the ISI RFC repository in the US, while links to RFC's from
  126.      Uri's site refer to the RFC repository at Imperial College in the
  127.      UK. Use whichever gives you better response time.
  128.  
  129.      The current version of this FAQ is posted on a monthly basis to
  130.      the news.answers, comp.answers and comp.protocols.tcp-ip
  131.      newsgroups.
  132.  
  133.      A plaintext copy of the most recently posted version of the FAQ is
  134.      available by anonymous FTP from
  135.      <ftp://rtfm.mit.edu/pub/faqs/internet/tcp-ip/tcp-ip-faq/>.
  136.  
  137.   2. Who wrote this FAQ?
  138.  
  139.      This FAQ was compiled from Usenet postings and email contributions
  140.      made by many people, including: Rui Duarte Tavares Bastos, Mark
  141.      Bergman, Stephane Bortzmeyer, Rodney Brown, Dr. Charles E.
  142.      Campbell Jr., James Carlson, Phill Conrad, Alan Cox, Michael
  143.      Hunter, Jay Kreibrich, William Manning, Barry Margolin, Vic
  144.      Metcalfe, Jim Muchow, George V. Neville-Neil, Dang Thanh Ngan,
  145.      Subu Rama, Uri Raz, and W. Richard Stevens.
  146.  
  147.      The FAQ is currently maintained by Mike Oliver. Comments,
  148.      criticisms and contributions should be mailed to
  149.      <tcp-ip-faq@eng.sun.com>. Please do not send TCP/IP questions to
  150.      this address; it is intended only for FAQ issues. If you have a
  151.      question that is not already answered by the material in this FAQ
  152.      you will get a much faster (and probably more accurate) response
  153.      by posting the question to the comp.protocols.tcp-ip newsgroup
  154.      than you will by sending it to the FAQ maintainer.
  155.  
  156.   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  157.  
  158. About TCP/IP
  159.  
  160.   1. What is TCP/IP?
  161.  
  162.      TCP/IP is a name given to the collection (or suite) of networking
  163.      protocols that have been used to construct the global Internet.
  164.      The protocols are also referred to as the DoD (dee-oh-dee) or
  165.      Arpanet protocol suite because their early development was funded
  166.      by the Advanced Research Projects Agency (ARPA) of the US
  167.      Department of Defense (DoD).
  168.  
  169.      The TCP/IP name is taken from two of the fundamental protocols in
  170.      the collection, IP and TCP. Other core protocols in the suite are
  171.      UDP and ICMP. These protocols work together to provide a basic
  172.      networking framework that is used by many different application
  173.      protocols, each tuned to achieving a particular goal.
  174.  
  175.      TCP/IP protocols are not used only on the Internet. They are also
  176.      widely used to build private networks, called internets (spelled
  177.      with a small 'i'), that may or may not be connected to the global
  178.      Internet (spelled with a capital 'I'). An internet that is used
  179.      exclusively by one organization is sometimes called an intranet.
  180.  
  181.   2. How is TCP/IP defined?
  182.  
  183.      All of the protocols in the TCP/IP suite are defined by documents
  184.      called Requests For Comments (RFC's). An important difference
  185.      between TCP/IP RFC's and other (say, IEEE or ITU) networking
  186.      standards is that RFC's are freely available online.
  187.  
  188.      RFC's can be composed and submitted for approval by anyone.
  189.      Standards RFC's are often the product of many weeks or months of
  190.      discussion between interested parties designated as working
  191.      groups, during which time drafts of the proposed RFC are
  192.      continually updated and made available for comment. These
  193.      discussions typically take place on open mailing lists which
  194.      welcome input from all quarters. The RFC approval process is
  195.      managed by the Internet Engineering Steering Group (IESG) based on
  196.      recommendations from the Internet Engineering Task Force (IETF)
  197.      which is a prime mover in the formation of working groups focused
  198.      on strategic TCP/IP issues. You can find out more about IESG and
  199.      IETF activities from the IETF home page at
  200.      <http://www.ietf.org/>.
  201.  
  202.      Not all RFC's specify TCP/IP standards. Some RFC's contain
  203.      background information, some provide hints for managing an
  204.      internet, some document protocol weaknesses in the hope that they
  205.      might be addressed by future standards, and some are entirely
  206.      humorous.
  207.  
  208.   3. Where can I find RFC's?
  209.  
  210.      The Definitive RFC Repository
  211.  
  212.      The official and definitive RFC repository is the anonymous FTP
  213.      archive maintained by the Information Sciences Institute of the
  214.      University of Southern California at <ftp://ftp.isi.edu/in-notes>.
  215.      It is reachable via the Web at <http://www.rfc-editor.org/>.
  216.  
  217.      RFC Repository Mirror Sites
  218.  
  219.      The RFC repository is mirrored at many sites on the Internet, and
  220.      you may get a faster response from a local archive than you would
  221.      from the often-overworked ISI site. Primary mirrors are updated at
  222.      the same time as the ISI site. Secondary mirrors may lag by a few
  223.      hours or days. The current primary mirror sites are:
  224.  
  225.           In the USA ...
  226.  
  227.           Missouri:
  228.                <ftp://wuarchive.wustl.edu/doc/rfc>
  229.           New Jersey:
  230.                <ftp://nisc.jvnc.net/rfc>
  231.           North Carolina:
  232.                <ftp://ftp.ncren.net/rfc>
  233.           Texas:
  234.                <ftp://ftp.sesqui.net/pub/rfc>
  235.  
  236.           In Europe ...
  237.  
  238.           France:
  239.                <ftp://ftp.imag.fr/pub/archive/IETF/rfc>
  240.           Italy:
  241.                <ftp://ftp.nic.it/rfc>
  242.           UK:
  243.                <ftp://src.doc.ic.ac.uk/rfc>
  244.  
  245.      Secondary mirror sites are listed in a document named
  246.      rfc-retrieval.txt which can be found alongside the RFC's
  247.      themselves at any of the above sites.
  248.  
  249.      RFC's by Email
  250.  
  251.      If you don't have direct access to the Internet but are able to
  252.      send and receive email then you can still get RFC's through
  253.      various email-to-ftp gateways. For instructions on how to do this,
  254.      send email containing the text:
  255.  
  256.           help: ways_to_get_rfcs
  257.  
  258.      to <rfc-info@isi.edu>.
  259.  
  260.   4. How do I find the right RFC?
  261.  
  262.      There are over 2500 RFC's. Each RFC is known by a number. For
  263.      instance, RFC 1180 presents a tutorial on TCP/IP, RFC 1920 lists
  264.      the current standards RFC's and explains the RFC standards
  265.      process, and RFC 1941 is a FAQ list on the topic of Internet
  266.      deployment in educational establishments. RFC numbers are assigned
  267.      in ascending order as each RFC is approved.
  268.  
  269.      The RFC files in the archive are named rfcNNNN.txt where NNNN is
  270.      the number of the RFC. For instance, the text of RFC 822 is
  271.      contained in the file named rfc822.txt. A small number of RFC's
  272.      are also available in PostScript format, in which case a file
  273.      named rfcNNNN.ps will exist in addition to the .txt file.
  274.  
  275.      Basic information (number, title, author, publication date and so
  276.      on) on all of the RFC's is contained in the RFC index document
  277.      named rfc-index.txt which you can find alongside the RFC's at any
  278.      of the RFC archive sites. If you don't know which RFC's you need,
  279.      the index is a good place to start. The index also indicates the
  280.      current status of each RFC. The content of an RFC does not change
  281.      once the RFC has been published, but since TCP/IP is in a constant
  282.      state of evolution the information in one RFC is often revised,
  283.      extended, clarified and in some cases completely superseded by
  284.      later RFC's. Annotations in the index indicate when this is the
  285.      case.
  286.  
  287.      If you find yourself using the index a lot then you might find it
  288.      convenient to create your own HTML version of the index. Wayne
  289.      Mesard has published a Perl script that takes the plaintext index
  290.      file as input and produces an HTML version with hyperlinks to your
  291.      chosen RFC FTP repository or to your own local RFC archive. The
  292.      script is available at
  293.      <ftp://ftp.ibnets.com/pub/wmesard/rfctxt2html.pl>.
  294.  
  295.      If you don't want to wade through the index, some sites provide
  296.      the ability to search the RFC catalogue by keyword:
  297.  
  298.      Keyword Searches on the Web
  299.           <http://www.faqs.org/rfcs/> lets you search on RFC content.
  300.           <http://web.nexor.co.uk/public/rfc/index/rfc.html> and
  301.           <http://www.csl.sony.co.jp/rfc/> let you search on words in the
  302.           RFC title.
  303.      Keyword Searches via gopher
  304.           <gopher://r2d2.jvnc.net/11/Internet%20Resources/RFC> or
  305.           <gopher://muspin.gsfc.nasa.gov:4320/1g2go4%20ds.internic.net%2070%201%201/.ds/.internetdocs>
  306.      RFC Keyword Searches via WAIS
  307.           <wais://wais.cnam.fr/RFC>
  308.  
  309.   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  310.  
  311. About IP
  312.  
  313.   1. What is IP?
  314.  
  315.      Internet Protocol (IP) is the central, unifying protocol in the
  316.      TCP/IP suite. It provides the basic delivery mechanism for packets
  317.      of data sent between all systems on an internet, regardless of
  318.      whether the systems are in the same room or on opposite sides of
  319.      the world. All other protocols in the TCP/IP suite depend on IP to
  320.      carry out the fundamental function of moving packets across the
  321.      internet.
  322.  
  323.      In terms of the OSI networking model, IP provides a Connectionless
  324.      Unacknowledged Network Service, which means that its attitude to
  325.      data packets can be characterised as "send and forget". IP does
  326.      not guarantee to actually deliver the data to the destination, nor
  327.      does it guarantee that the data will be delivered undamaged, nor
  328.      does it guarantee that data packets will be delivered to the
  329.      destination in the order in which they were sent by the source,
  330.      nor does it guarantee that only one copy of the data will be
  331.      delivered to the destination.
  332.  
  333.      Because it makes so few guarantees, IP is a very simple protocol.
  334.      This means that it can be implemented fairly easily and can run on
  335.      systems that have modest processing power and small amounts of
  336.      memory. It also means that IP demands only minimal functionality
  337.      from the underlying medium (the physical network that carries
  338.      packets on behalf of IP) and can be deployed on a wide variety of
  339.      networking technologies.
  340.  
  341.      The no-promises type of service offered by IP is not directly
  342.      useful to many applications. Applications usually depend on TCP or
  343.      UDP to provide assurances of of data integrity and (in TCP's case)
  344.      ordered and complete data delivery.
  345.  
  346.      The fundamentals of IP are defined in RFC 791. RFC 1122 summarises
  347.      the requirements that must be met by an IP implementation in an
  348.      Internet host, and RFC 1812 summarises the IP requirements for an
  349.      Internet router.
  350.  
  351.   2. How Is IP Carried On A Network?
  352.  
  353.      IP really isn't very fussy about how its packets are transported.
  354.      The details of how an IP packet is carried over a particular kind
  355.      of network are usually chosen to be convenient for the network
  356.      itself. As long as the transmitter and receiver observe some
  357.      convention that allows IP packets to be differentiated from any
  358.      other data that might be seen by the receiver, then IP can be used
  359.      to carry data between those stations.
  360.  
  361.      On a LAN, IP is carried in the data portion of the LAN frame and
  362.      the frame header contains additional information that identifies
  363.      the frame an an IP frame. Different LAN's have different
  364.      conventions for carrying that additional information. On an
  365.      Ethernet the Ethertype field is used; a value of 0x0800 identifies
  366.      a frame that contains IP data. FDDI and Token Ring use frames that
  367.      conform to IEEE 802 Logical Link Control, and on those LAN's IP is
  368.      carried in Unnumbered Information frames with Source and
  369.      Destination LSAP's of 0xAA and a SNAP header of 00-00-00-08-00.
  370.  
  371.      The only thing that IP cares strongly about is the maximum size of
  372.      a frame that can be carried on the medium. This controls whether,
  373.      and to what extent, IP must break down large data packets into a
  374.      train of smaller packets before arranging for them to be
  375.      transmitted on the medium. This activity is called "fragmentation"
  376.      and the resulting smaller and incomplete packets are called
  377.      "fragments". The final destination is responsible for rebuilding
  378.      the original IP packet from its fragments, an activity called
  379.      "fragment reassembly".
  380.  
  381.   3. Does IP Protect Data On The Network?
  382.  
  383.      IP itself does not guarantee to deliver data correctly. It leaves
  384.      all issues of data protection to the transport protocol. Both TCP
  385.      and UDP have mechanisms that guarantee that the data they deliver
  386.      to an application is correct.
  387.  
  388.      IP does try to protect the packet's IP header, the relatively
  389.      small part of each packet that controls how the packet is moved
  390.      through the network. It does this by calculating a checksum on the
  391.      header fields and including that checksum in the transmitted
  392.      packet. The receiver verifies the IP header checksum before
  393.      processing the packet. Packets whose checksums no longer match
  394.      have been damaged in some way and are simply discarded.
  395.  
  396.      The IP checksum is discussed in detail in RFC 1071, which also
  397.      includes sample code for calculating the checksum. RFC 1141 and
  398.      RFC 1624 describe incremental modification of an existing
  399.      checksum, which can be useful in machines such as routers which
  400.      modify fields in the IP header while forwarding a packet and
  401.      therefore need to compute a new header checksum.
  402.  
  403.      The same checksum algorithm is used by TCP and UDP, although they
  404.      include the data portion of the packet (not just the header) in
  405.      their calculations.
  406.  
  407.   4. What is ARP?
  408.  
  409.      Address Resolution Protocol (ARP) is a mechanism that can be used
  410.      by IP to find the link-layer station address that corresponds to a
  411.      particular IP address. It defines a method that is used to ask,
  412.      and answer, the question "what MAC address corresponds to a given
  413.      IP address?". ARP sends broadcast frames to obtain this
  414.      information dynamically, so it can only be used on media that
  415.      support broadcast frames. Most LAN's (including Ethernet, FDDI,
  416.      and Token Ring) have a broadcast capability and ARP is used when
  417.      IP is running on those media. ARP is defined in RFC 826. That
  418.      definition assumes an Ethernet LAN. Additional details for ARP on
  419.      networks that use IEEE 802.2 frame formats (IEEE 802.3 CSMA/CD,
  420.      IEEE 802.4, IEEE 802.5 Token Ring) are in RFC 1042. ARP on FDDI is
  421.      described in RFC 1390.
  422.  
  423.      When IP is runnning over non-broadcast media (say, X.25 or ATM)
  424.      some other mechanism is used to match IP addresses to media
  425.      addresses. IP really doesn't care how the media address is
  426.      obtained.
  427.  
  428.      RFC 903 defines Reverse ARP (RARP) which lets a station ask the
  429.      question "which IP address corresponds to a given MAC address?".
  430.      RARP is typically used to let a piece of diskless equipment
  431.      discover its own IP address as part of its boot procedure. RARP is
  432.      rarely used by modern equipment; it has been supplanted by the
  433.      Boot Protocol (BOOTP) defined in RFC 1542. BOOTP in turn is being
  434.      supplanted by the Dynamic Host Configuration Protocol (DHCP).
  435.  
  436.   5. What is IPv6?
  437.  
  438.      IP Version 6 (IPv6) is the newest version of IP, sometimes called
  439.      IPng for "IP, Next Generation". IPv6 is fairly well defined but is
  440.      not yet widely deployed. The main differences between IPv6 and the
  441.      current widely-deployed version of IP (which is IPv4) are:
  442.  
  443.     o IPv6 uses larger addresses (128 bits instead of 32 bits in
  444.       IPv4) and so can support many more devices on the network,
  445.       and
  446.  
  447.     o IPv6 includes features like authentication and multicasting
  448.       that had been bolted on to IPv4 in a piecemeal fashion over
  449.       the years.
  450.  
  451.      Information on IPv6 can be found on the IPv6 home page at
  452.      <http://playground.sun.com/pub/ipng/html/ipng-main.html>
  453.  
  454.   6. What happened to IPv5?
  455.  
  456.      Or, ""Why are we skipping from IPv4 to IPv6?"
  457.  
  458.      IPv5 never existed. The version number "5" in the IP header was
  459.      assigned to identify packets carrying an experimental non-IP
  460.      real-time stream protocol called ST. ST was never widely used, but
  461.      since the version number 5 had already been allocated the new
  462.      version of IP was given its own unique identifying number, 6. ST
  463.      is described in RFC 1819.
  464.  
  465.   7. What is the 6bone?
  466.  
  467.      The 6bone is the experimental IPv6 backbone being developed using
  468.      IPv6-in-IPv4 tunnels. This is intended for early experimentation
  469.      with IPv6 and is not a production service.
  470.  
  471.   8. What is the MBONE?
  472.  
  473.      The Multicast backBONE (MBONE) is a multicast-capable portion of
  474.      the Internet backbone. Multicast support over IP is provided by a
  475.      protocol called IGMP (Internet Group Management Protocol) which is
  476.      defined in RFC 1112. The MBONE is still a research prototype, but
  477.      it extends through most of the core of the Internet (including
  478.      North America, Europe, and Australia). It is typically used to
  479.      relay multimedia (audio and low bandwidth video) presentations
  480.      from a single source to multiple receiving sites dispersed over
  481.      the Internet.
  482.  
  483.      A slightly dated MBONE FAQ is available by anonymous FTP from
  484.      <ftp://ftp.isi.edu/mbone/faq.txt>.
  485.  
  486.   9. What is IPsec?
  487.  
  488.      IPsec stands for "IP Security". The IPsec working group of the
  489.      IETF is developing standards for cryptographic authentication and
  490.      for encryption within IP. The base specifications are defined in
  491.      RFC's 1825, 1826 and 1827. Products that implement these are
  492.      beginning to appear.
  493.  
  494.      A freely distributable implementation of IPsec for IPv4 and IPsec
  495.      for IPv6 is included in the NRL IPv6/IPsec distribution for
  496.      4.4-Lite BSD.  The NRL software is available from
  497.      <http://web.mit.edu/network/isakmp/> (for distribution within the
  498.      US only), from
  499.      <http://www.cisco.com/public/library/isakmp/ipsec.html> (for
  500.      distribution within the US and Canada), and from
  501.      <ftp://ftp.ripe.net/ipv6/nrl/> (for unrestricted distribution).
  502.  
  503.      (Some countries consider encryption software to have military
  504.      significance and so restrict the export and import of such
  505.      software, which is why there are geographical restrictions on the
  506.      areas served by the above sites.)
  507.  
  508.   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  509.  
  510. About TCP
  511.  
  512.   1. What is TCP?
  513.  
  514.      Transmission Control Protocol (TCP) provides a reliable
  515.      byte-stream transfer service between two endpoints on an internet.
  516.      TCP depends on IP to move packets around the network on its
  517.      behalf. IP is inherently unreliable, so TCP protects against data
  518.      loss, data corruption, packet reordering and data duplication by
  519.      adding checksums and sequence numbers to transmitted data and, on
  520.      the receiving side, sending back packets that acknowledge the
  521.      receipt of data.
  522.  
  523.      Before sending data across the network, TCP establishes a
  524.      connection with the destination via an exchange of management
  525.      packets. The connection is destroyed, again via an exchange of
  526.      management packets, when the application that was using TCP
  527.      indicates that no more data will be transferred. In OSI terms, TCP
  528.      is a Connection-Oriented Acknowledged Transport protocol.
  529.  
  530.      TCP has a multi-stage flow-control mechanism which continuously
  531.      adjusts the sender's data rate in an attempt to achieve maximum
  532.      data throughput while avoiding congestion and subsequent packet
  533.      losses in the network.  It also attempts to make the best use of
  534.      network resources by packing as much data as possible into a
  535.      single IP packet, although this behaviour can be overridden by
  536.      applications that demand immediate data transfer and don't care
  537.      about the inefficiencies of small network packets.
  538.  
  539.      The fundamentals of TCP are defined in RFC 793, and later RFC's
  540.      refine the protocol. RFC 1122 catalogues these refinements as of
  541.      October 1989 and summarises the requirements that a TCP
  542.      implementation must meet.
  543.  
  544.      TCP is still being developed. For instance, RFC 1323 introduces a
  545.      TCP option that can be useful when traffic is being carried over
  546.      high-capacity links. It is important that such developments are
  547.      backwards-compatible. That is, a TCP implementation that supports
  548.      a new feature must continue to work with older TCP implementations
  549.      that do not support that feature.
  550.  
  551.   2. How does TCP try to avoid network meltdown?
  552.  
  553.      TCP includes several mechanisms that attempt to sustain good data
  554.      transfer rates while avoiding placing excessive load on the
  555.      network.  TCP's "Slow Start", "Congestion Avoidance", "Fast
  556.      Retransmit" and "Fast Recovery" algorithms are summarised in RFC
  557.      2001. TCP also mandates an algorithm that avoids "Silly Window
  558.      Syndrome" (SWS), an undesirable condition that results in very
  559.      small chunks of data being transferred between sender and
  560.      receiver. SWS Avoidance is discussed in RFC 813. The "Nagle
  561.      Algorithm", which prevents the sending side of TCP from flooding
  562.      the network with a train of small frames, is described in RFC
  563.      896.
  564.  
  565.      Van Jacobson has done significant work on this aspect of TCP's
  566.      behaviour. The FAQ used to contain a couple of pieces of
  567.      historically interesting pieces of Van's email concerning an early
  568.      implementation of congestion avoidance, but in the interests of
  569.      saving space they've been removed and can instead be obtained by
  570.      anonymous FTP from the end-to-end mailing list archive at
  571.      <ftp://ftp.isi.edu/end2end/end2end-1990.mail>. PostScript slides
  572.      of a presentation on this implementation of congestion avoidance
  573.      can be obtained by anonymous FTP from
  574.      <ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z>.
  575.  
  576.      That directory contains several other interesting TCP-related
  577.      papers, including one
  578.      (<ftp://ftp.ee.lbl.gov/papers/fastretrans.ps>) by Sally Floyd that
  579.      discusses a algorithm that attempts to give TCP the ability to
  580.      recover quickly from packet loss in a network.
  581.  
  582.   3. How do applications coexist over TCP and UDP?
  583.  
  584.      Each application running over TCP or UDP distinguishes itself from
  585.      other applications using the service by reserving and using a
  586.      16-bit port number. Destination and source port numbers are placed
  587.      in the UDP and TCP headers by the originator of the packet before
  588.      it is given to IP, and the destination port number allows the
  589.      packet to be delivered to the intended recipient at the
  590.      destination system.
  591.  
  592.      So, a system may have a Telnet server listening for packets on TCP
  593.      port 23 while an FTP server listens for packets on TCP port 21 and
  594.      a DNS server listens for packets on port 53. TCP examines the port
  595.      number in each received frame and uses it to figure out which
  596.      server gets the data. UDP has its own similar set of port
  597.      numbers.
  598.  
  599.      Many servers, like the ones in this example, always listen on the
  600.      same well-known port number. The actual port number is arbitrary,
  601.      but is fixed by tradition and by an official allocation or
  602.      "assignment" of the number by the Internet Assigned Numbers
  603.      Authority (IANA).
  604.  
  605.   4. Where do I find assigned port numbers?
  606.  
  607.      The IANA allocates and keeps track of all kinds of arbitrary
  608.      numbers used by TCP/IP, including well-known port numbers. The
  609.      entire collection is published periodically in an RFC called the
  610.      Assigned Numbers RFC, each of which supersedes the previous one in
  611.      the series.  The current Assigned Numbers RFC is RFC 1700.
  612.  
  613.      The Assigned Numbers document can also be obtained directly by FTP
  614.      from the IANA at <ftp://ftp.isi.edu/in-notes/iana/assignments>.
  615.  
  616.   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  617.  
  618. About UDP
  619.  
  620.   1. What is UDP?
  621.  
  622.      User Datagram Protocol (UDP) provides an unreliable packetized
  623.      data transfer service between endpoints on an internet. UDP
  624.      depends on IP to move packets around the network on its behalf.
  625.  
  626.      UDP does not guarantee to actually deliver the data to the
  627.      destination, nor does it guarantee that data packets will be
  628.      delivered to the destination in the order in which they were sent
  629.      by the source, nor does it guarantee that only one copy of the
  630.      data will be delivered to the destination. UDP does guarantee data
  631.      integrity, and it does this by adding a checksum to the data
  632.      before transmission. (Some machines run with UDP checksum
  633.      generation disabled, in which case data corruption or truncation
  634.      can go undetected. Very few people think this is a good idea.)
  635.  
  636.      The fundamentals of UDP are defined in RFC 768. RFC 1122
  637.      summarises the requirements that a UDP implementation must meet.
  638.  
  639.   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  640.  
  641. About ICMP
  642.  
  643.   1. What is ICMP?
  644.  
  645.      Internet Control Message Protocol (ICMP) defines a small number of
  646.      messages used for diagnostic and management purposes. ICMP depends
  647.      on IP to move packets around the network on its behalf.
  648.  
  649.      The fundamentals of ICMP are defined in RFC 792. RFC 1122
  650.      summarises the requirements that must be met by an ICMP
  651.      implementation in an Internet host, and RFC 1812 summarises the
  652.      ICMP requirements for an Internet router.
  653.  
  654.      ICMP is basically IP's internal network management protocol and is
  655.      not intended for use by applications. Two well known exceptions
  656.      are the ping and traceroute diagnostic utilities:
  657.  
  658.     o ping sends and receives ICMP "ECHO" packets, where the
  659.       response packet can be taken as evidence that the target host
  660.       is at least minimally active on the network, and
  661.  
  662.     o traceroute sends UDP packets and infers the route taken to
  663.       the target from ICMP "TIME-TO-LIVE EXCEEDED" or "PORT
  664.       UNREACHABLE" packets returned by the network. (Microsoft's
  665.       TRACERT sends ICMP "ECHO" packets rather than UDP packets,
  666.       and so receives ICMP "TIME-TO-LIVE EXCEEDED" or "ECHO
  667.       RESPONSE" packets in return.)
  668.  
  669.   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  670.  
  671. TCP/IP Network Operations
  672.  
  673.   1. How can I measure the performance of an IP link?
  674.  
  675.      You can get a quick approximation by timing how long it takes to
  676.      FTP or RCP a large file over the link, but bear in mind that that
  677.      measurement will be skewed by the time spent in dealing with the
  678.      local and remote filesystems, not simply with the network itself.
  679.      And remember to measure the time it takes to receive a file, not
  680.      the time it takes to send it; the sender can report completion
  681.      even though large amounts of data are still buffered locally by
  682.      TCP and have not yet been delivered to the destination.
  683.  
  684.      Two well-known open-source programs that measure and report
  685.      throughput over an IP link without involving the filesystem are:
  686.  
  687.     o TTCP, available for anonymous ftp from the Silicon Graphics
  688.       FTP archive at <ftp://ftp.sgi.com/sgi/src/ttcp/>.
  689.  
  690.     o Rick Jones' NETPERF, available on the Web at
  691.       <http://www.cup.hp.com/netperf/NetperfPage.html>.
  692.  
  693.      If neither of those tools does what you want then you might find
  694.      something that meets your needs in CAIDA's measurement tools list
  695.      at <http://www.caida.org/Tools/meastools.html>.
  696.  
  697.   2. What IP addresses should I assign to machines on a private
  698.      internet?
  699.  
  700.      You shouldn't use IP addresses that have been assigned to some
  701.      other organisation, because if knowledge of your network ever gets
  702.      leaked onto the Internet they may disrupt that innocent
  703.      organisation's activity. RFC 1918 provides a solution for this
  704.      problem by allocating several IP address ranges specifically for
  705.      use on private networks.  These addresses will never be assigned
  706.      to any organisation and are never supposed to appear on the
  707.      Internet. The ranges are:
  708.  
  709.              Class A: 10.0.0.0    through 10.255.255.255
  710.              Class B: 172.16.0.0  through 172.31.255.255
  711.              Class C: 192.168.0.0 through 192.168.255.255
  712.  
  713.  
  714.   3. Can I set up a gateway to the Internet that translates IP
  715.      addresses, so that I don't have to change all our internal
  716.      addresses to an official network?
  717.  
  718.      This is called Network Address Translation, or NAT. In general it
  719.      is a difficult thing to do properly because many applications
  720.      embed IP addresses in the application-level data (FTP's "PORT"
  721.      command is a notable example) so NAT isn't simply a matter of
  722.      translating addresses in the IP header and recalculating header
  723.      checksums. Also, if the network number(s) you're using match those
  724.      assigned to another organisation, your gateway may not be able to
  725.      communicate with that organisation. As noted above, RFC 1918
  726.      proposes network numbers that are reserved for private use, to
  727.      avoid such conflicts, but if you're already using a different
  728.      network number this won't help you.
  729.  
  730.      However, there are several products that do attempt to provide
  731.      this kind of on-the-fly NAT. Linux provides NAT through its "IP
  732.      Masquerading" feature, and many firewall and router vendors offer
  733.      NAT capabilities in their products -- look for "Network Address
  734.      Translation" in your favourite Web search engine to get a list of
  735.      vendors. Proxy servers developed for firewalls can also sometimes
  736.      be used as a substitute for an address-translating gateway for
  737.      particular application protocols. This is discussed in more detail
  738.      in the FAQ for the comp.security.firewalls newsgroup. That FAQ can
  739.      be viewed on the Web at <http://www.clark.net/pub/mjr/pubs/fwfaq/>.
  740.  
  741.   4. Can I use a single bit subnet?
  742.  
  743.      The answer used to be a straightforward "no", because a 1-bit
  744.      subnet can only have a subnet part of all-ones or all-zeroes, both
  745.      of which were assigned special meanings when the subnetting
  746.      concept was originally defined. (All-ones meant "broadcast, all
  747.      subnets of this net" and all-zeroes meant "this subnet, regardless
  748.      of its actual subnet number".)
  749.  
  750.      However, the old definition of subnetting has been superseded by
  751.      the concept of Classless Inter-Domain Routing (CIDR, pronounced
  752.      'cider').  Under CIDR the subnet doesn't really have an existence
  753.      of its own and the subnet mask simply provides the mechanism for
  754.      isolating an arbitrarily-sized network portion of an IP address
  755.      from the remaining host part. As CIDR-aware equipment is deployed
  756.      it becomes increasingly like that you will be able to use a 1-bit
  757.      subnet with at least some particular combinations of networking
  758.      equipment. However, it's still not safe to assume that a 1-bit
  759.      subnet will work properly with all kinds of equipment.
  760.  
  761.      As Steinar Haug explains:
  762.  
  763.           From RFC 1122:
  764.  
  765.           > 3.3.6  Broadcasts
  766.           >
  767.           > Section 3.2.1.3 defined the four standard IP broadcast address
  768.           > forms:
  769.           >   Limited Broadcast:              {-1, -1}
  770.           >   Directed Broadcast:             {<Network-number>, -1}
  771.           >   Subnet Directed Broadcast:      {<Network-number>, <Subnet-number>, -1}
  772.           >   All-Subnets Directed Broadcast: {<Network-number>, -1, -1}
  773.  
  774.           All-Subnets Directed broadcasts are being deprecated in favor of IP
  775.           multicast, but were very much defined at the time RFC1122 was written.
  776.           Thus a Subnet Directed Broadcast to a subnet of all ones is not
  777.           distinguishable from an All-Subnets Directed Broadcast.
  778.  
  779.           For those old systems that used all zeros for broadcast in IP
  780.           addresses, a similar argument can be made against the subnet of all
  781.           zeros.
  782.  
  783.           Also, for old routing protocols like RIP, a route to subnet zero is not
  784.           distinguishable from the route to the entire network number (except
  785.           possibly by context).
  786.  
  787.           Most of today's systems don't support variable length subnet masks
  788.           (VLSM), and for such systems the above is true. However, all the major
  789.           router vendors and *some* Unix systems (BSD 4.4 based ones) support
  790.           VLSMs, and in that case the situation is more complicated :-)
  791.  
  792.           With VLSMs (necessary to support CIDR, see RFC 1519), you can utilize
  793.           the address space more efficiently. Routing lookups are based on
  794.           *longest* match, and this means that you can for instance subnet the
  795.           class C net with a mask of 255.255.255.224 (27 bits) in addition to the
  796.           subnet mask of 255.255.255.192 (26 bits) given above. You will then be
  797.           able to use the addresses x.x.x.33 through x.x.x.62 (first three bits
  798.           001) and the addresses x.x.x.193 through x.x.x.222 (first three bits
  799.           110) with this new subnet mask. And you can continue with a subnet mask
  800.           of 28 bits, etc.  (Note also, by the way, that non-contiguous subnet
  801.           masks are deprecated.)
  802.  
  803.           This is all very nicely covered in the paper by Havard Eidnes:
  804.  
  805.                Practical Considerations for Network Address using a
  806.                CIDR Block Allocation
  807.                Proceedings of INET '93
  808.  
  809.           This paper is available with anonymous FTP from
  810.           aun.uninett.no:pub/misc/eidnes-cidr.ps.
  811.  
  812.           The same paper, with minor revisions, is one of the articles in the
  813.           special Internetworking issue of Communications of the ACM (last month,
  814.           I believe).
  815.  
  816.           Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY
  817.           Email: Steinar.Haug@runit.sintef.no
  818.  
  819.   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  820.  
  821. TCP/IP Protocol Implementations
  822.  
  823.   1. Where can I find TCP/IP source code?
  824.  
  825.      Code used in the venerable Net-2 version of Berkeley Unix is
  826.      available by anonymous FTP from
  827.      <ftp://ftp.uu.net/systems/unix/bsd-sources/sys/netinet> (at UUNet
  828.      in Virginia, US) and
  829.      <ftp://gatekeeper.dec.com/pub/BSD/net2/sys/netinet> (at Compaq in
  830.      California, US).
  831.  
  832.      Source code for the TCP/IP implementations in the current dialects
  833.      of BSD Unix is available. Instructions on how to access the
  834.      sources through FTP and other methods is detailed on their
  835.      respective websites:  FreeBSD at <http://www.freebsd.org/>; NetBSD
  836.      at <http://www.netbsd.org/>; and OpenBSD at
  837.      <http://www.openbsd.org/>.
  838.  
  839.      Source for the Unix-like Linux operating system is at
  840.      <http://www.kernel.org/pub/linux/>.
  841.  
  842.      Source for the TCP/IP implementation of the Xinu operating system
  843.      discussed in Comer & D. L. Stevens' "Internetworking with TCP/IP
  844.      Volume II" is at <ftp://ftp.cs.purdue.edu/pub/Xinu/>.
  845.  
  846.      WATTCP is a DOS TCP/IP stack derived from the NCSA Telnet program
  847.      and much enhanced. It is available from many DOS software archive
  848.      sites as WATTCP.ZIP. This file includes some example programs and
  849.      complete source code. The interface isn't BSD sockets but is well
  850.      suited to PC type work.
  851.  
  852.      KA9Q is Phil Karn's network operating system for PC's. It includes
  853.      a TCP/IP implementation originally developed for use over packet
  854.      radio.  Source is available from Phil's website at
  855.      <http://people.qualcomm.com/karn/code/ka9qos/>.
  856.  
  857.   2. Where can I find TCP/IP application source code?
  858.  
  859.      Source code for the various TCP/IP applications delivered with the
  860.      current BSD Unix flavours is available through the FreeBSD, NetBSD
  861.      and OpenBSD websites noted in the previous section.
  862.  
  863.      Linux application source is at <http://www.kernel.org/pub/linux/>.
  864.      Much of the application source used by Linux was originally
  865.      developed by the GNU Project whose website is at
  866.      <http://www.gnu.org/>.
  867.  
  868.      Code from Comer & D. L. Stevens' "Internetworking with TCP/IP
  869.      Volume III" is available by anonymous FTP from
  870.      <ftp://ftp.cs.purdue.edu/pub/dls/>.
  871.  
  872.      Code from W. R. Stevens' "TCP/IP Illustrated, Volume 1" is
  873.      available from
  874.      <ftp://ftp.uu.net/published/books/stevens.tcpipiv1.tar.Z>.
  875.  
  876.      Source code for some well-known cross-system TCP/IP applications
  877.      (BIND, sendmail, Apache and so on) is available from the various
  878.      organisations that sponsor the applications. See Part 2 of the FAQ
  879.      for details.
  880.  
  881.   3. Where can I find IPv6 source code?
  882.  
  883.      There are several freely distributable implementations of IPv6,
  884.      particularly for BSD and Linux. You can find detailed information at
  885.      <http://playground.sun.com/pub/ipng/html/ipng-implementations.html>,
  886.      part of the IPv6 home site mentioned above.
  887.  
  888.   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  889.  
  890. Further Sources of Information
  891.  
  892.   1. TCP/IP-related newsgroups and FAQ lists
  893.  
  894.      Collections of newsgroup FAQ documents are archived at many
  895.      locations including <http://www.faqs.org/> and
  896.      <ftp://rtfm.mit.edu/pub/faqs/>.  The following newsgroups are
  897.      particularly relevant to TCP/IP:
  898.  
  899.           comp.protocols.tcp-ip covers all of the TCP/IP suite.
  900.  
  901.       comp.protocols.dns.bind covers the BIND suite, which contains
  902.       server and client implementations of DNS.
  903.  
  904.       comp.protocols.tcp-ip.domains discusses DNS global
  905.       administration and politics.
  906.  
  907.       comp.protocols.nfs covers NFS protocol, implementation, and
  908.       administration.
  909.  
  910.       comp.protocols.snmp covers SNMP definition, implementation,
  911.       and administration.
  912.  
  913.       comp.protocols.time.ntp covers NTP definition,
  914.       implementation, and administration.
  915.  
  916.       comp.protocols.tcp-ip.ibmpc discusses TCP/IP for IBM(-like)
  917.       personal computers. The group's FAQ is available at
  918.       <ftp://ftp.netcom.com/pub/ma/mailcom/IBMTCP/ibmtcp.zip>.
  919.  
  920.       comp.os.ms-windows.networking.tcp-ip discusses TCP/IP on
  921.       Microsoft Windows machines.
  922.  
  923.       comp.os.ms-windows.programmer.tools.winsock covers the
  924.       Winsock sockets API on Microsoft Windows machines. The
  925.       group's FAQ is available at
  926.       <http://www.cyberport.com/~tangent/programming/winsock/>.
  927.  
  928.           comp.os.os2.networking.tcp-ip discusses TCP/IP on OS/2.
  929.  
  930.       comp.dcom.lans.ethernet covers Ethernet and IEEE 802.3 LAN's.
  931.       The group's FAQ is available at
  932.       <ftp://dorm.rutgers.edu/pub/novell/info_and_docs/Ethernet.FAQ>.
  933.  
  934.           comp.dcom.lans.fddi covers FDDI LAN's.
  935.  
  936.       comp.dcom.lans.token-ring covers IBM Token Ring and IEEE
  937.       802.5 LAN's.
  938.  
  939.       comp.dcom.lans.misc covers all other types of LAN.
  940.  
  941.       comp.protocols.ppp covers PPP and SLIP. The group's FAQ is
  942.       available at <http://cs.uni-bonn.de/ppp/part1.html>.
  943.  
  944.       comp.dcom.sys.cisco discusses cisco products.
  945.  
  946.       comp.dcom.sys.wellfleet discusses Wellfleet (now Bay
  947.       Networks) products.
  948.  
  949.   2. Are there any good books on TCP/IP?
  950.  
  951.      Yes, lots of them, far too many to list here. Uri Raz maintains a
  952.      TCP/IP bibliography (the "TCP/IP Resources List") that is posted
  953.      to the comp.protocols.tcp-ip newsgroup on a monthly basis. It is
  954.      available on the Web at
  955.      <http://www.qnx.com/%7Emphunter/tcpip_resources.html> and
  956.      <http://www.faqs.org/faqs/internet/tcp-ip/resource-list/index.html>
  957.      or can be retrieved by anonymous FTP from
  958.      <ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/comp/protocols/tcp-ip/TCP_IP_Resources_List>.
  959.  
  960.      However, a couple of books that always head the list of
  961.      recommended reading are:
  962.  
  963.       "Internetworking with TCP/IP Volume I (Principles, Protocols,
  964.       and Architecture)" by Douglas E. Comer, published by Prentice
  965.       Hall, 1991 (ISBN 0-13-468505-9). This is an introductory book
  966.       which covers all of the fundamental protocols, including IP,
  967.       UDP, TCP, and the gateway protocols. It also discusses some
  968.       higher level protocols such as FTP, Telnet, and NFS.
  969.  
  970.       "TCP/IP Illustrated, Volume 1: The Protocols" by W. Richard
  971.       Stevens, published by Addison-Wesley, 1994 (ISBN
  972.       0-201-63346-9).  This book explains the TCP/IP protocols and
  973.       several application protocols in exquisite detail. It
  974.       contains many real-life traces of the protocols in action,
  975.       which is especially valuable for people who need to
  976.       understand the protocols in depth.
  977.  
  978.      If you're writing programs that use TCP/IP then the classic text
  979.      is "Unix Network Programming" by W. Richard Stevens, published by
  980.      Prentice Hall, 1990 (ISBN 0-13-949876-1). It's now being rewritten
  981.      as a three volume set. The first volume "Unix Network Programming:
  982.      Networking APIs: Sockets and Xti" published by Prentice Hall, 1997
  983.      (ISBN 013490012X), contains just about everything you need to know
  984.      about using TCP/IP and includes material on topics (eg IPv6,
  985.      multicasting, threads) that are not covered in the original UNP.
  986.  
  987.   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  988.  
  989. This compilation contains the opinions of the FAQ maintainer and the
  990. various FAQ contributors. Any resemblance to the opinions of the FAQ
  991. maintainer's employer is entirely coincidental.
  992.  
  993. Copyright (C) Mike Oliver 1997-1999. All Rights Reserved.
  994.