home *** CD-ROM | disk | FTP | other *** search
/ CD-ROM Today - The Disc! 2 / CD-ROM_Today_-_The_Disc_2_June-July_1994.iso / inetinfo / rfc1207 < prev    next >
Text File  |  1991-04-20  |  33KB  |  843 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          G. Malkin
  8. Request for Comments: 1207                            FTP Software, Inc.
  9. FYI: 7                                                         A. Marine
  10.                                                                      SRI
  11.                                                              J. Reynolds
  12.                                                                      ISI
  13.                                                            February 1991
  14.  
  15.  
  16.                       FYI on Questions and Answers
  17.     Answers to Commonly asked "Experienced Internet User" Questions
  18.  
  19. Status of this Memo
  20.  
  21.    This FYI RFC is one of two FYI's called, "Questions and Answers"
  22.    (Q/A), produced by the User Services Working Group of the Internet
  23.    Engineering Task Force (IETF).  The goal is to document the most
  24.    commonly asked questions and answers in the Internet.
  25.  
  26.    This memo provides information for the Internet community.  It does
  27.    not specify any standard.  Distribution of this memo is unlimited.
  28.  
  29. Table of Contents
  30.  
  31.    1. Introduction..................................................  1
  32.    2. Acknowledgements..............................................  3
  33.    3. Questions about the Internet..................................  3
  34.    4. Questions About Other Networks and Internets..................  3
  35.    5. Questions About Internet Documentation........................  4
  36.    6. Questions About the Domain Name System (DNS)..................  4
  37.    7. Questions About Network Management............................  7
  38.    8. Questions about Serial Line Internet Protocol (SLIP) and
  39.       Point-to-Point Protocol (PPP) Implementations.................  9
  40.    9. Questions About Routing....................................... 11
  41.    10. Other Protocol and Standards Implementation Questions........ 11
  42.    11. Suggested Reading............................................ 12
  43.    12. References................................................... 13
  44.    13. Security Considerations...................................... 14
  45.    14. Authors' Addresses........................................... 15
  46.  
  47. 1. Introduction
  48.  
  49.    During the last few months, several people have monitored various
  50.    major mailing lists and have extracted questions that are important
  51.    or commonly asked.  This FYI RFC is one of two in a series of FYI's
  52.    which present the questions and their answers.  The first FYI, FYI 4,
  53.    presented questions new Internet users commonly ask and their
  54.    answers.
  55.  
  56.  
  57.  
  58. User Services Working Group                                     [Page 1]
  59.  
  60. RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991
  61.  
  62.  
  63.    The goal of this FYI is to codify the Internet lore so that network
  64.    operations staff, especially for networks just joining the Internet,
  65.    will have an accurate and up to date set of references from which to
  66.    work.  Also, redundancies are moved away from the electronic mailing
  67.    lists so that the lists' subscribers do not have to read the same
  68.    queries and answers over and over again.
  69.  
  70.    Although the questions and their responses are taken from various
  71.    mailing lists, they are presented here loosely grouped by related
  72.    topic for ease of reading.  First the question is presented, then the
  73.    answer (or answers) as it appeared on the mailing list.
  74.  
  75.    Sometimes the answers are abridged for better use of space.  If a
  76.    question was not answered on the mailing list, the editors provide an
  77.    answer.  These answers are not distinguished from the answers found
  78.    on the lists.  Sometimes, in order to be as complete as possible, the
  79.    editors provide additional information that was not present in the
  80.    original answer.  If so, that information falls under the heading
  81.    "Additional Information".
  82.  
  83.    The answers are as correct as the reviewers can make them.  However,
  84.    much of this information changes with time.  As the FYI is updated,
  85.    temporal errors will be corrected.
  86.  
  87.    Many of the questions are in first person, and the answers were
  88.    directed to the originator of the question.  These phrasings have not
  89.    been changed except where necessary for clarity.  References to the
  90.    correspondents' names have been removed.
  91.  
  92.    The Q/A mailing lists are maintained by Gary Malkin at FTP.COM.  They
  93.    are used by a subgroup of the User Services Working Group to discuss
  94.    the Q/A FYIs.  They include:
  95.  
  96.    quail@ftp.com           This is a discussion mailing list.  Its
  97.                            primary use is for pre-release review of
  98.                            the Q/A FYIs.
  99.  
  100.    quail-request@ftp.com   This is how you join the quail mailing list.
  101.  
  102.    quail-box@ftp.com       This is where the questions and answers
  103.                            will be forwarded-and-stored.  It is
  104.                            not necessary to be on the quail mailing
  105.                            list to forward to the quail-box.
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. User Services Working Group                                     [Page 2]
  115.  
  116. RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991
  117.  
  118.  
  119. 2. Acknowledgments
  120.  
  121.    The following people deserve thanks for their help and contributions
  122.    to this FYI Q/A: Jim Conklin (EDUCOM), John C. Klensin (MIT),
  123.    Professor Kynikos (Special Consultant), Jon Postel (ISI),
  124.    Marshall Rose (PSI, Inc.), David Sitman (Tel Aviv University),
  125.    Patricia Smith (Merit), Gene Spafford (Purdue), and
  126.    James Van Bokkelen (FTP Software, Inc.).
  127.  
  128. 3. Questions about the Internet
  129.  
  130.    3.1. How do I get statistics regarding the traffic on NSFNET?
  131.  
  132.       Merit/NSFNET Information Services maintains a variety of
  133.       statistical data at 'nis.nsf.net' (35.1.1.48) in the 'stats'
  134.       directory.  Information includes packet counts by NSS and byte
  135.       counts for type of use (ftp, smtp, telnet, etc.).  Filenames are
  136.       of the form 'NSFyy-mm.type'.
  137.  
  138.       Files are available for anonymous ftp; use 'guest' as the
  139.       password.
  140.  
  141.       The data in these files represent only traffic which traverses the
  142.       highest level of the NSFNET, not traffic within a campus or
  143.       regional network.  Send questions/comments to nsfnet-
  144.       info@merit.edu.
  145.  
  146. 4. Questions About Other Networks and Internets
  147.  
  148.    4.1. We have a user who would like to access a machine on
  149.         "EARN/BITNET".  I can't find anything on this in the domain
  150.         name tables.  Please, what is this, and how do I connect to it?
  151.  
  152.       There are several machines on the Internet that act as gateways
  153.       between the Internet and BITNET.  Two examples are UICVM.UIC.EDU
  154.       and CUNYVM.CUNY.EDU.  You can address a mail message to
  155.       user%nodename.bitnet@uicvm.uic.edu where the message will be
  156.       passed from the Internet to BITNET.
  157.  
  158.       Additional Information:
  159.  
  160.          These same gateways, known as INTERBIT on the BITNET/EARN side,
  161.          transfer mail from computers on that network which support SMTP
  162.          mail headers, onto the Internet.  (Many BITNET/EARN computers
  163.          still do not support SMTP, which is not a part of the IBM
  164.          protocol used, and it is not possible to send mail from those
  165.          computers across the gateways into the Internet, in general.)
  166.  
  167.  
  168.  
  169.  
  170. User Services Working Group                                     [Page 3]
  171.  
  172. RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991
  173.  
  174.  
  175.          BITNET and EARN are the two largest of several cooperating
  176.          networks which use the IBM RSCS/NJE protocol suite, but are not
  177.          limited to IBM systems.  These independently administered,
  178.          interconnected networks function as a single, worldwide network
  179.          directly connecting more than 3,300 computers in about 1,400,
  180.          mostly higher-education, organizations worldwide.  This
  181.          worldwide network supports electronic mail, including mailing
  182.          lists, sender-initiated file transfer, and short "interactive"
  183.          messages.
  184.  
  185.          BITNET, frequently used (outside of Europe) to refer to the
  186.          whole worldwide network, technically refers to that portion in
  187.          the United States, plus sites in other countries which are
  188.          connected through the United States and do not have their own
  189.          separately administered cooperating networks.  More than 550
  190.          organizations in the U.S.  participate in BITNET.
  191.  
  192.          EARN is the European Academic Research Network.  EARN links
  193.          more than 500 institutions in Europe and several surrounding
  194.          countries.
  195.  
  196.          BITNET and CSNET merged organizationally on October 1, 1990, to
  197.          form CREN, the Corporation for Research and Educational
  198.          Networking.  The two networks remain separate at the
  199.          operational level level, however.  (EARN and the other
  200.          Cooperating Networks were not involved in this merger.)
  201.  
  202. 5. Questions About Internet Documentation
  203.  
  204.    5.1. Where do I get information regarding ordering documents
  205.         related to GOSIP?
  206.  
  207.       The complete information as issued by NIST is available online on
  208.       the NIC.DDN.MIL host as PROTOCOLS:GOSIP-ORDER-INFO.TXT.  The file
  209.       contains pointers to contact people, ordering addresses, prices,
  210.       and, in some cases, online pathnames, for various GOSIP related
  211.       documents.  In addition, the information as of August 1990 was
  212.       published as an appendix to RFC 1169, "Explaining the Role of
  213.       GOSIP" [1].
  214.  
  215. 6. Questions About Domain Name System (DNS)
  216.  
  217.    6.1. Is there a DNS Query server?
  218.  
  219.       Actually, what you are looking for is the service that host
  220.       128.218.1.109 provides on port 5555 - you simply connect to that
  221.       host at that port, type in a fully qualified domain name and it
  222.       responds with an internet address and closes the connection.  I
  223.  
  224.  
  225.  
  226. User Services Working Group                                     [Page 4]
  227.  
  228. RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991
  229.  
  230.  
  231.       used it when I had a host that still only had /etc/hosts and it
  232.       did just what I needed - which was basically a manual nslookup.
  233.  
  234.       However, the vast majority of users will find it simpler to just
  235.       use a DNS query tool and ask the DNS directly.  This doesn't
  236.       require much sophistication, and does allow the user to see how
  237.       short names are expanded at the user's site rather than at
  238.       128.218.1.109 (wherever that is).  For example, suppose a user
  239.       wants to find out the address of a fully-qualified domain name
  240.       "X.MISKATONIC.EDU", and also see what host and address are used
  241.       when "Z" is typed as a host name.
  242.  
  243.       Assuming the user is on a UNIX host and has a copy of the dig
  244.       program, type:
  245.  
  246.          dig x.miskatonic.edu
  247.       and
  248.          dig z
  249.  
  250.          and the answers will appear.  You are now on your way to
  251.          becoming a DNS expert.  There are other UNIX alternatives,
  252.          e.g., nslookup, and similar programs for non-UNIX systems.
  253.          Your local DNS guru certainly has one or more of these tools,
  254.          and although they are often kept from the public, they are
  255.          really quite easy to use for simple cases.
  256.  
  257.    6.2. We have been having a frequent BIND failure on both our VAX
  258.         and Solbourne that is traced to TCP domain queries from an
  259.         IBM NSMAIN nameserver running in cache mode (UDP queries do
  260.         not cause this problem, though it is usually a UDP
  261.         resolution that is active upon the crash -- this resolution
  262.         is an innocent victim).
  263.  
  264.         I have discovered that something is trashing the hash areas
  265.         (sometimes even as it is being recursively used in a
  266.         resolution).  Also, occasionally the socket/file descriptor
  267.         for the TCP connection is changed to invalid entries causing
  268.         a reply write fail (though this is not necessarily fatal,
  269.         and the rest of the structure is not apparently altered).
  270.  
  271.         Has any one else had frequent BIND failures (especially
  272.         major domain sites that have heavy TCP domain loads)?
  273.  
  274.       In both the case of BIND and the IBM implementation, often called
  275.       FAL, there are multiple versions, with older versions being truly
  276.       bad.  Upgrade to recent version before exploring further.
  277.  
  278.       BIND has always had a problem with polluting its own database.
  279.  
  280.  
  281.  
  282. User Services Working Group                                     [Page 5]
  283.  
  284. RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991
  285.  
  286.  
  287.       These problems have been related to TCP connections, NS RRs with
  288.       small TTLs, and several other causes.  Experience suggests that
  289.       the style of bug fixing has often been that of reducing the
  290.       problem by 90% rather than eliminating it.
  291.  
  292.       IBM's support for the DNS (outside of UNIX systems) is interesting
  293.       in its techniques, encouraging in its improvement, but still
  294.       somewhat depressing when compared to most other DNS software.  IBM
  295.       also uses terminology that varies somewhat from the usual DNS
  296.       usage and preserves some archaic syntax, e.g., "..".
  297.  
  298.       The combination of an old BIND and an old IBM server is just plain
  299.       unpleasant.
  300.  
  301.    6.3. Is the model used by the domain name system for host names
  302.         that the owner of a name gets to choose its case?
  303.  
  304.       The model used by the DNS is that you get to control at a specific
  305.       point in the name space, and are hence free to select case as you
  306.       choose, until points where you in turn give away control.  As a
  307.       practical matter, there are several implementations that don't do
  308.       the right thing.  IBM implementations often map everything into a
  309.       single case.
  310.  
  311.    6.4. According to RFC 1034 [2], section 4.2.1, one should not have
  312.         to code glue RR's for name server's names unless they are below
  313.         the cut.  When I don't put glue RR's in, and do a query for
  314.         NS records, the "additional" field is left blank.  As far as I
  315.         can tell, all other zones I query for NS records have this
  316.         filled with the IP addresses of the NS hosts.  Is this required
  317.         or should I not be concerned that the additional field is empty?
  318.  
  319.       The protocol says that an empty additional field is not a problem
  320.       when the name server's name is not "below" the cut.
  321.  
  322.       In practice, putting in the glue where it is not required can
  323.       cause problems if the servers named in the glue are used for
  324.       several zones.  This is broken behavior in BIND.  Not putting in
  325.       glue can cause other problems in BIND, usually when the server
  326.       name is difficult to resolve.  So, the bottom line is to put glue
  327.       in only when required, and don't use aliases or anything else
  328.       tricky when it comes to identifying name servers.
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. User Services Working Group                                     [Page 6]
  339.  
  340. RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991
  341.  
  342.  
  343. 7. Questions About Network Management Implementations
  344.  
  345.    7.1. In reading the SNMP RFCs [3,4,5,6] I find mention of
  346.         authentication of PDUs.  Are there any standards for
  347.         authentication mechanisms?
  348.  
  349.       There is a working group of the IETF that is working on this
  350.       problem.  They are close to a solution, but nothing has yet
  351.       reached RFC publication yet.  Expect something solid and
  352.       implementable by October of 1991.
  353.  
  354.    7.2. Can vendors make their enterprise-specific variables available
  355.         to users through a standard distribution mechanism?
  356.  
  357.       Yes.  But before someone submits a MIB, they should check it out
  358.       themselves.
  359.  
  360.       On uu.psi.com in pilot/snmp-wg/, there are two files
  361.  
  362.               mosy-sparc-4.0.3.c
  363.  
  364.               mosy-sun3-3.5
  365.  
  366.       The first will run on a Sun-Sparc, the second will run on a Sun-3.
  367.       After retrieving one of these files in BINARY mode via anonymous FTP,
  368.       the submittor can run their MIB through it, e.g.,
  369.  
  370.               % mosy mymib.my
  371.  
  372.       Once your MIB passes, send it to:
  373.  
  374.               mib-checker@isi.edu
  375.  
  376.       If everything is OK, the mib-checker will arrange to have it
  377.       installed in the /share/ftp/mib directory on venera.isi.edu.
  378.  
  379.       Note: This processing does not offer an official endorsement.  The
  380.       documents submitted must not be marked proprietary, confidential,
  381.       or the like.
  382.  
  383.    7.3. I have a question regarding those pesky octet strings again.
  384.         I use the variable-type field of the Response pdu to determine
  385.         how the result should be displayed to the user.  For example,
  386.         I convert NetworkAddresses to their dotted decimal format
  387.         ("132.243.50.4").  I convert Object Identifiers into strings
  388.         ("1.3.6.1.2....").
  389.  
  390.         I would LIKE to just print Octet Strings as strings.  But,
  391.  
  392.  
  393.  
  394. User Services Working Group                                     [Page 7]
  395.  
  396. RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991
  397.  
  398.  
  399.         this causes a problem in such cases as atPhysAddress in
  400.         which the Octet string contains the 6 byte address instead
  401.         of a printable ASCII string.  In this case, I would want to
  402.         display the 6 bytes instead of just trying to print the
  403.         string.
  404.  
  405.         MY QUESTION IS: Does anyone have a suggestion as to how I
  406.         can determine whether I can just print the string or whether
  407.         I should display the octet bytes.  * Remember: I want to
  408.         support enterprise specific variables too.
  409.  
  410.       In general, there is no way that you can tell what is inside an
  411.       OCTET STRING without knowing something about the object that the
  412.       OCTET STRING comes from.  In MIB-II [6], some objects are marked
  413.       as DisplayString which has the syntax of OCTET STRING but is
  414.       restricted to characters from the NVT ASCII character set (see the
  415.       TELNET Specification, RFC 854 [7], for further information).
  416.       These objects are:
  417.  
  418.          sysDescr
  419.          sysContact
  420.          sysName
  421.          sysLocation
  422.          ifDescr
  423.  
  424.       If you want to be able to arbitrarily decide how to display the
  425.       strings, without knowing anything about the object, then you can
  426.       scan the octets, looking for any octet which is not printable
  427.       ASCII.  If you find at least one, you can print the entire string,
  428.       octet by octet, in "%02x:" notation.  If all of the octets are
  429.       printable ASCII, then you can just printf the string.
  430.  
  431.    7.4. If archived MIBs must be 1155-compatible [3], it would be nice
  432.         if those who submit them check them first.  Where are these
  433.         MIB tools available for public FTP?  Ideally, a simple
  434.         syntax checker (that didn't actually generate code) would be
  435.         nice.
  436.  
  437.       In the ISODE 6.0 release there is a tool called MOSY which
  438.       recognizes the 1155 syntax and produces a flat ASCII file.  If you
  439.       can run it through MOSY without problems then you are OK.
  440.  
  441.    7.5. Suppose I want to create a private MIB object for causing
  442.         some action to happen, say, do a reset.  Should the syntax
  443.         or this object specify a value such as:
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. User Services Working Group                                     [Page 8]
  451.  
  452. RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991
  453.  
  454.  
  455.          Syntax:
  456.             INTEGER {
  457.                perform reset (1),
  458.             }
  459.  
  460.         even though there is only a single value?  Or, is it ok to
  461.         just allow a Set on this object with any value to perform
  462.         the desired action?  If the later, how is this specified?
  463.  
  464.       For our SNMP manageable gizmos and doohickies with similar
  465.       "action" type MIB variables, I've defined two values
  466.  
  467.             Syntax:
  468.                INTEGER {
  469.                   reset(1)
  470.                   not-reset(2)
  471.                }
  472.  
  473.       And defined behavior so that the only valid value that the
  474.       variable may be set to is "reset" (which is returned in the get
  475.       response PDU) and at all other times a get/getnext will respond
  476.       with "not-reset".
  477.  
  478. 8. Questions about Serial Line Internet Protocol (SLIP) and
  479.    Point-to-Point Protocol (PPP) Implementations
  480.  
  481.    8.1. I seem to recall hearing that SLIP [8] will only run on
  482.         synchronous serial lines.  Is this true?  ... is there
  483.         something about SLIP which precludes it's being implemented
  484.         over async lines?
  485.  
  486.       Other way around:  SLIP is designed for async lines and is not a
  487.       good fit on sync lines.  PPP [9, 10] works on either, and is what
  488.       you should be implementing if you're implementing something.
  489.  
  490.    8.2. Since we are very interested in standards in this area,
  491.         could someone tell me were I can find more information on PPP?
  492.  
  493.         Also, can this protocol be used in other fields than for the
  494.         Internet (i.e., telecontrol, telemetering) where we see a
  495.         profusion of proprietary incompatible and hard to maintain
  496.         Point-to-Point Protocols?
  497.  
  498.       PPP was designed to be useful for many protocols besides just IP.
  499.       Whether it would be useful for your particular application should
  500.       probably be discussed with the IETF's Point-to-Point Protocol
  501.       Working Group discussion list.  For general discussion: ietf-
  502.       ppp@ucdavis.edu.  To subscribe: ietf-ppp-request@ucdavis.edu
  503.  
  504.  
  505.  
  506. User Services Working Group                                     [Page 9]
  507.  
  508. RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991
  509.  
  510.  
  511.       The PPP specification is available as RFC 1171 [9], and a PPP
  512.       options specification is available as RFC 1172 [10].
  513.  
  514.       In UnixWorld of April 1990 (Vol. VII, No. 4, Pg. 85), Howard
  515.       Baldwin writes:
  516.  
  517.          "Point-to-Point Protocol (PPP) has just been submitted to the
  518.          CCITT from the Internet Engineering Task Force.  It specifies a
  519.          standard for encapsulating Internet Protocol data and other
  520.          network layer (level three on ISO's OSI Model) protocol
  521.          information over point-to-point links; it also provides ways to
  522.          test and configure lines and the upper level protocols on the
  523.          OSI Model.  The only requirement is a provision of a duplex
  524.          circuit either dedicated or switched, that can operate in
  525.          either an asynchronous or synchronous mode, transparent to the
  526.          data-linklayer frame.
  527.  
  528.          "According to Michael Ballard, director of network systems for
  529.          Telebit, PPP is a direct improvement upon Serial Line Internet
  530.          Protocol (SLIP), which had neither error correction nor a way
  531.          to exchange network address."
  532.  
  533.    8.3. Does anyone know if there is a way to run a SLIP program on
  534.         a IBM computer running SCO Xenix/Unix, with a multi-port
  535.         serial board?
  536.  
  537.       SCO TCP/IP for Xenix supports SLIP.  It works.  However, be
  538.       warned: SCO SLIP works *only* with SCO serial drivers, so it will
  539.       *not* work with intelligent boards that come with their own
  540.       drivers.  If you want lots of SLIP ports, you'll need lots of dumb
  541.       ports, perhaps with a multi-dumb-port board.
  542.  
  543.       Here's the setup -- SunOS 3.5, with the 4.3BSD TCP, IP & SLIP
  544.       distributions installed.  Slip is running between the "ttya" ports
  545.       of two Sun 3/60's.  "ping", "rlogin", etc., works fine, but a NFS
  546.       mount results in "server not responding: RPC Timed Out".
  547.  
  548.       SunOS 3.5 turns the UDP checksum off, which is legal and works
  549.       okay over interfaces such as ethernet which has link- level
  550.       checksumming.  On the other hand, SLIP doesn't perform checksums
  551.       thus running NFS over SLIP requires you to turn the UDP checksum
  552.       on.  Otherwise, you'll experience erratic behavior such as the one
  553.       described above.
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. User Services Working Group                                    [Page 10]
  563.  
  564. RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991
  565.  
  566.  
  567.          Save the older kernel and try,
  568.  
  569.             % adb -k -w /vmunix /dev/kmem udpcksum?w 1
  570.  
  571.          to patch up the kernel.
  572.  
  573. 9. Questions About Routing
  574.  
  575.    9.1. Some postings mentioned "maximum entropy routing".  Could
  576.         someone please provide a pointer to on-line or off-line
  577.         references to this topic?
  578.  
  579.       Try NYU CSD Technical Report 371: "Some Comments on Highly Dynamic
  580.       Network Routing," by Herbert J. Bernstein, May 1988.
  581.  
  582. 10. Other Protocol and Standards Implementation Questions
  583.  
  584.    10.1. Does anyone recognize ethernet type "80F3"?  I don't see it
  585.          in RFC 1010, but I am seeing it on our net.
  586.  
  587.       Ethernet type 0x80F3 is used by AppleTalk for address resolution.
  588.       You must have Macs on your network which are directly connected to
  589.       Ethernet.  These packets are used by the Mac (generally at
  590.       startup) to determine a valid AppleTalk node number.
  591.  
  592.       Additional Information:
  593.  
  594.       RFC 1010 is obsolete.  Please consult RFC 1060 [11], the current
  595.       "Assigned Numbers" (issued March 1990), which does list "80F3":
  596.  
  597.       Ethernet          Exp. Ethernet    Description          References
  598.       -------------     -------------   -----------           ----------
  599.       decimal  Hex      decimal  octal
  600.       33011   80F3        -      -     AppleTalk AARP (Kinetics)[XEROX]
  601.  
  602.    10.2. Does anyone know the significance of a high value for
  603.          "Bad proto" in the output from netstat on Unix machines using
  604.          ethernet?  We're seeing values in the tens of thousands out of
  605.          a few hundred thousand packets sent/received in all.  Some
  606.          "Bad proto" values are negative, too.  (Off the scale?)  Any
  607.          help would be appreciated.
  608.  
  609.       This probably indicates that you are getting tens of thousands of
  610.       broadcast packets from some host or hosts on your network.  You
  611.       might want to buy or rent a LAN monitor, or install one of the
  612.       public-domain packages to see what private protocol is guilty.
  613.       "FYI on a Network Management Tool Catalog: Tools for Monitoring
  614.       and Debugging TCP/IP Internets and Interconnected Devices" (RFC
  615.  
  616.  
  617.  
  618. User Services Working Group                                    [Page 11]
  619.  
  620. RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991
  621.  
  622.  
  623.       1147, FYI 2), [12] contains pointers to tools that may help you
  624.       zero in on the problem.
  625.  
  626.    10.3. Which RFC would explain the proper way to configure broadcast
  627.          addresses when using subnets?
  628.  
  629.       Consult RFC 1122, "Requirements for Internet Hosts --
  630.       Communication Layer" [13].
  631.  
  632.    10.4. Can anyone tell me what .TAR files exactly are?  Is it like
  633.          ZIP or LZH for the IBM PC's?  IF so, how do I go about getting
  634.          a compressor/decompressor for .TAR files and what computer
  635.          does this run on?
  636.  
  637.       TAR stands for "Tape ARchive".  It is a Unix utility which takes
  638.       files, and directories of files, and creates a single large file.
  639.       Originally intended to back up directory trees onto tape (hence
  640.       the name), TAR is also used to combine files for easier electronic
  641.       file transfer.
  642.  
  643. 11. Suggested Reading
  644.  
  645.    For further information about the Internet and its protocols in
  646.    general, you may choose to obtain copies of the following works:
  647.  
  648.       Bowers, K., T. LaQuey, J. Reynolds, K. Roubicek, M. Stahl, and A.
  649.       Yuan, "Where to Start - A Bibliography of General Internetworking
  650.       Information", RFC 1175, FYI 3, CNRI, U Texas, ISI, BBN, SRI,
  651.       Mitre, August 1990.
  652.  
  653.       Braden, R., Editor, "Requirements for Internet Hosts --
  654.       Communication Layer", RFC 1122, Internet Engineering Task Force,
  655.       October 1989.
  656.  
  657.       Braden, R., Editor, "Requirements for Internet Hosts --
  658.       Application and Support", RFC 1123, Internet Engineering Task
  659.       Force, October 1989.
  660.  
  661.       Comer, D., "Internetworking with TCP/IP: Principles, Protocols,
  662.       and Architecture", Prentice Hall, New Jersey, 1989.
  663.  
  664.       Frey, D. and R. Adams, "!%@:: A Directory of Electronic Mail
  665.       Addressing and Networks", O'Reilly and Associates, Newton, MA,
  666.       August 1989.
  667.  
  668.       Krol, E., "The Hitchhikers Guide to the Internet", RFC 1118,
  669.       University of Illinois Urbana, September 1989.
  670.  
  671.  
  672.  
  673.  
  674. User Services Working Group                                    [Page 12]
  675.  
  676. RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991
  677.  
  678.  
  679.       LaQuey, T, Editor, "Users' Directory of Computer Networks",
  680.       Digital Press, Bedford, MA, 1990.
  681.  
  682.       Malkin, G., and A. Marine, "FYI on Questions and Answers - Answers
  683.       to Commonly asked "New Internet User" Questions", RFC 1206, FYI 4,
  684.       FTP Software, Inc., SRI, February 1991.
  685.  
  686.       Postel, J., Editor, "IAB Official Protocol Standards", RFC 1140,
  687.       Internet Activities Board, May 1990.
  688.  
  689.       Quarterman, J., "Matrix: Computer Networks and Conferencing
  690.       Systems Worldwide", Digital Press, Bedford, MA, 1989.
  691.  
  692.       Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
  693.       USC/Information Sciences Institute, March 1990.
  694.  
  695.       Socolofsky, T., and C. Kale, "A TCP/IP Tutorial", RFC 1180, Spider
  696.       Systems Limited, January 1991.
  697.  
  698.       Stevens, W., "UNIX Network Programming", ISBN 0-13-949876-1,
  699.       Prentice Hall, Englewood Cliffs, NJ, 1990.
  700.  
  701.       Stine, R., Editor, "FYI on a Network Management Tool Catalog:
  702.       Tools for Monitoring and Debugging TCP/IP Internets and
  703.       Interconnected Devices" RFC 1147, FYI 2, Sparta, Inc., April 1990.
  704.  
  705. 12.  References
  706.  
  707.    [1] Cerf, V., and K. Mills, "Explaining the Role of GOSIP", RFC 1169,
  708.        IAB, NIST, August 1990.
  709.  
  710.    [2] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
  711.        1034, USC/Information Sciences Institute, November 1987.
  712.  
  713.    [3] Rose, M., and K. McCloghrie, "Structure and Identification of
  714.        Management Information for TCP/IP-based Internets", RFC 1155,
  715.        Performance Systems International, Hughes LAN Systems, May 1990.
  716.  
  717.    [4] McCloghrie, K., and M. Rose, "Management Information Base for
  718.        Network Management of TCP/IP-based internets", RFC 1156, Hughes
  719.        LAN Systems, Performance Systems International, May 1990.
  720.  
  721.    [5] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple
  722.        Network Management Protocol (SNMP)", RFC 1157, SNMP Research,
  723.        Performance Systems International, Performance Systems
  724.        International, MIT Laboratory for Computer Science, May 1990.
  725.  
  726.    [6] Rose, M., Editor, "Management Information Base for Network
  727.  
  728.  
  729.  
  730. User Services Working Group                                    [Page 13]
  731.  
  732. RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991
  733.  
  734.  
  735.        Management of TCP/IP-based internets: MIB-II", RFC 1158,
  736.        Performance Systems International, May 1990.
  737.  
  738.    [7] Postel, J., and J. Reynolds, "TELNET Protocol Specification", RFC
  739.        854, USC/Information Sciences Institute, May 1983.
  740.  
  741.    [8] Romkey, J., "A Nonstandard for Transmission of IP Datagrams over
  742.        Serial Lines: SLIP", RFC 1055, June 1988.
  743.  
  744.    [9] Perkins, D., "The Point-to-Point Protocol: A Proposal for Multi-
  745.        Protocol Transmission of Datagrams Over Point-to-Point Links",
  746.        RFC 1171, CMU, July 1990.
  747.  
  748.   [10] Perkins, D., and R. Hobby, "The Point-to-Point Protocol (PPP)
  749.        Initial Configuration Options", CMU, UC Davis, July 1990.
  750.  
  751.   [11] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
  752.        USC/Information Sciences Institute, March 1990.
  753.  
  754.   [12] Stine, R., Editor, "FYI on a Network Management Tool Catalog:
  755.        Tools for Monitoring and Debugging TCP/IP Internets and
  756.        Interconnected Devices" RFC 1147, FYI 2, Sparta, Inc., April
  757.        1990.
  758.  
  759.   [13] Braden, R., Editor, "Requirements for Internet Hosts --
  760.        Communication Layer", RFC 1122, Internet Engineering Task Force,
  761.        October 1989.
  762.  
  763. 13. Security Considerations
  764.  
  765.    Security issues are not discussed in this memo.
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. User Services Working Group                                    [Page 14]
  787.  
  788. RFC 1207        FYI Q/A - for Experienced Internet Users   February 1991
  789.  
  790.  
  791. 14. Authors' Addresses
  792.  
  793.    Gary Scott Malkin
  794.    FTP Software, Inc.
  795.    26 Princess Street
  796.    Wakefield, MA 01880
  797.  
  798.    Phone:  (617) 246-0900
  799.    EMail:  gmalkin@ftp.com
  800.  
  801.  
  802.    April N. Marine
  803.    SRI International
  804.    Network Information Systems Center
  805.    333 Ravenswood Avenue, EJ294
  806.    Menlo Park, CA 94025
  807.  
  808.    Phone:  (415) 859-5318
  809.    EMail:  APRIL@nic.ddn.mil
  810.  
  811.  
  812.    Joyce K. Reynolds
  813.    USC/Information Sciences Institute
  814.    4676 Admiralty Way
  815.    Marina del Rey, CA  90292-6695
  816.  
  817.    Phone:  (213) 822-1511
  818.    EMail:  jkrey@isi.edu
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. User Services Working Group                                    [Page 15]
  843.