FYI Q/A (Experienced): FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions
The questions experienced operators kept asking, and the answers they had worked out.
Malkin, G.S., Marine, A.N., and J.K. Reynolds, "FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions", FYI 7, RFC 1207, DOI 10.17487/RFC1207, February 1991, <https://www.rfc-editor.org/info/rfc1207>.
@misc{rfc1207,
series = {Request for Comments},
number = 1207,
howpublished = {RFC 1207},
publisher = {RFC Editor},
doi = {10.17487/RFC1207},
url = {https://www.rfc-editor.org/info/rfc1207},
author = {G.S. Malkin and A.N. Marine and J.K. Reynolds},
title = {{FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions}},
pagetotal = 15,
year = 1991,
month = feb,
} RFC text
Contents
Network Working Group G. Malkin
Request for Comments: 1207 FTP Software, Inc.
FYI: 7 A. Marine
SRI
J. Reynolds
ISI
February 1991
FYI on Questions and Answers
Answers to Commonly asked "Experienced Internet User" Questions
Status of this Memo
This FYI RFC is one of two FYI's called, "Questions and Answers"
(Q/A), produced by the User Services Working Group of the Internet
Engineering Task Force (IETF). The goal is to document the most
commonly asked questions and answers in the Internet.
This memo provides information for the Internet community. It does
not specify any standard. Distribution of this memo is unlimited.
Table of Contents
1. Introduction.................................................. 1
2. Acknowledgements.............................................. 3
3. Questions about the Internet.................................. 3
4. Questions About Other Networks and Internets.................. 3
5. Questions About Internet Documentation........................ 4
6. Questions About the Domain Name System (DNS).................. 4
7. Questions About Network Management............................ 7
8. Questions about Serial Line Internet Protocol (SLIP) and
Point-to-Point Protocol (PPP) Implementations................. 9
9. Questions About Routing....................................... 11
10. Other Protocol and Standards Implementation Questions........ 11
11. Suggested Reading............................................ 12
12. References................................................... 13
13. Security Considerations...................................... 14
14. Authors' Addresses........................................... 15
1. Introduction
During the last few months, several people have monitored various
major mailing lists and have extracted questions that are important
or commonly asked. This FYI RFC is one of two in a series of FYI's
which present the questions and their answers. The first FYI, FYI 4,
presented questions new Internet users commonly ask and their
answers.
The goal of this FYI is to codify the Internet lore so that network
operations staff, especially for networks just joining the Internet,
will have an accurate and up to date set of references from which to
work. Also, redundancies are moved away from the electronic mailing
lists so that the lists' subscribers do not have to read the same
queries and answers over and over again.
Although the questions and their responses are taken from various
mailing lists, they are presented here loosely grouped by related
topic for ease of reading. First the question is presented, then the
answer (or answers) as it appeared on the mailing list.
Sometimes the answers are abridged for better use of space. If a
question was not answered on the mailing list, the editors provide an
answer. These answers are not distinguished from the answers found
on the lists. Sometimes, in order to be as complete as possible, the
editors provide additional information that was not present in the
original answer. If so, that information falls under the heading
"Additional Information".
The answers are as correct as the reviewers can make them. However,
much of this information changes with time. As the FYI is updated,
temporal errors will be corrected.
Many of the questions are in first person, and the answers were
directed to the originator of the question. These phrasings have not
been changed except where necessary for clarity. References to the
correspondents' names have been removed.
The Q/A mailing lists are maintained by Gary Malkin at FTP.COM. They
are used by a subgroup of the User Services Working Group to discuss
the Q/A FYIs. They include:
quail@ftp.com This is a discussion mailing list. Its
primary use is for pre-release review of
the Q/A FYIs.
quail-request@ftp.com This is how you join the quail mailing list.
quail-box@ftp.com This is where the questions and answers
will be forwarded-and-stored. It is
not necessary to be on the quail mailing
list to forward to the quail-box.
2. Acknowledgments
The following people deserve thanks for their help and contributions
to this FYI Q/A: Jim Conklin (EDUCOM), John C. Klensin (MIT),
Professor Kynikos (Special Consultant), Jon Postel (ISI),
Marshall Rose (PSI, Inc.), David Sitman (Tel Aviv University),
Patricia Smith (Merit), Gene Spafford (Purdue), and
James Van Bokkelen (FTP Software, Inc.).
3. Questions about the Internet
3.1. How do I get statistics regarding the traffic on NSFNET?
Merit/NSFNET Information Services maintains a variety of
statistical data at 'nis.nsf.net' (35.1.1.48) in the 'stats'
directory. Information includes packet counts by NSS and byte
counts for type of use (ftp, smtp, telnet, etc.). Filenames are
of the form 'NSFyy-mm.type'.
Files are available for anonymous ftp; use 'guest' as the
password.
The data in these files represent only traffic which traverses the
highest level of the NSFNET, not traffic within a campus or
regional network. Send questions/comments to nsfnet-
info@merit.edu.
4. Questions About Other Networks and Internets
4.1. We have a user who would like to access a machine on
"EARN/BITNET". I can't find anything on this in the domain
name tables. Please, what is this, and how do I connect to it?
There are several machines on the Internet that act as gateways
between the Internet and BITNET. Two examples are UICVM.UIC.EDU
and CUNYVM.CUNY.EDU. You can address a mail message to
user%nodename.bitnet@uicvm.uic.edu where the message will be
passed from the Internet to BITNET.
Additional Information:
These same gateways, known as INTERBIT on the BITNET/EARN side,
transfer mail from computers on that network which support SMTP
mail headers, onto the Internet. (Many BITNET/EARN computers
still do not support SMTP, which is not a part of the IBM
protocol used, and it is not possible to send mail from those
computers across the gateways into the Internet, in general.)
BITNET and EARN are the two largest of several cooperating
networks which use the IBM RSCS/NJE protocol suite, but are not
limited to IBM systems. These independently administered,
interconnected networks function as a single, worldwide network
directly connecting more than 3,300 computers in about 1,400,
mostly higher-education, organizations worldwide. This
worldwide network supports electronic mail, including mailing
lists, sender-initiated file transfer, and short "interactive"
messages.
BITNET, frequently used (outside of Europe) to refer to the
whole worldwide network, technically refers to that portion in
the United States, plus sites in other countries which are
connected through the United States and do not have their own
separately administered cooperating networks. More than 550
organizations in the U.S. participate in BITNET.
EARN is the European Academic Research Network. EARN links
more than 500 institutions in Europe and several surrounding
countries.
BITNET and CSNET merged organizationally on October 1, 1990, to
form CREN, the Corporation for Research and Educational
Networking. The two networks remain separate at the
operational level level, however. (EARN and the other
Cooperating Networks were not involved in this merger.)
5. Questions About Internet Documentation
5.1. Where do I get information regarding ordering documents
related to GOSIP?
The complete information as issued by NIST is available online on
the NIC.DDN.MIL host as PROTOCOLS:GOSIP-ORDER-INFO.TXT. The file
contains pointers to contact people, ordering addresses, prices,
and, in some cases, online pathnames, for various GOSIP related
documents. In addition, the information as of August 1990 was
published as an appendix to RFC 1169, "Explaining the Role of
GOSIP" [1].
6. Questions About Domain Name System (DNS)
6.1. Is there a DNS Query server?
Actually, what you are looking for is the service that host
128.218.1.109 provides on port 5555 - you simply connect to that
host at that port, type in a fully qualified domain name and it
responds with an internet address and closes the connection. I
used it when I had a host that still only had /etc/hosts and it
did just what I needed - which was basically a manual nslookup.
However, the vast majority of users will find it simpler to just
use a DNS query tool and ask the DNS directly. This doesn't
require much sophistication, and does allow the user to see how
short names are expanded at the user's site rather than at
128.218.1.109 (wherever that is). For example, suppose a user
wants to find out the address of a fully-qualified domain name
"X.MISKATONIC.EDU", and also see what host and address are used
when "Z" is typed as a host name.
Assuming the user is on a UNIX host and has a copy of the dig
program, type:
dig x.miskatonic.edu
and
dig z
and the answers will appear. You are now on your way to
becoming a DNS expert. There are other UNIX alternatives,
e.g., nslookup, and similar programs for non-UNIX systems.
Your local DNS guru certainly has one or more of these tools,
and although they are often kept from the public, they are
really quite easy to use for simple cases.
6.2. We have been having a frequent BIND failure on both our VAX
and Solbourne that is traced to TCP domain queries from an
IBM NSMAIN nameserver running in cache mode (UDP queries do
not cause this problem, though it is usually a UDP
resolution that is active upon the crash -- this resolution
is an innocent victim).
I have discovered that something is trashing the hash areas
(sometimes even as it is being recursively used in a
resolution). Also, occasionally the socket/file descriptor
for the TCP connection is changed to invalid entries causing
a reply write fail (though this is not necessarily fatal,
and the rest of the structure is not apparently altered).
Has any one else had frequent BIND failures (especially
major domain sites that have heavy TCP domain loads)?
In both the case of BIND and the IBM implementation, often called
FAL, there are multiple versions, with older versions being truly
bad. Upgrade to recent version before exploring further.
BIND has always had a problem with polluting its own database.
These problems have been related to TCP connections, NS RRs with
small TTLs, and several other causes. Experience suggests that
the style of bug fixing has often been that of reducing the
problem by 90% rather than eliminating it.
IBM's support for the DNS (outside of UNIX systems) is interesting
in its techniques, encouraging in its improvement, but still
somewhat depressing when compared to most other DNS software. IBM
also uses terminology that varies somewhat from the usual DNS
usage and preserves some archaic syntax, e.g., "..".
The combination of an old BIND and an old IBM server is just plain
unpleasant.
6.3. Is the model used by the domain name system for host names
that the owner of a name gets to choose its case?
The model used by the DNS is that you get to control at a specific
point in the name space, and are hence free to select case as you
choose, until points where you in turn give away control. As a
practical matter, there are several implementations that don't do
the right thing. IBM implementations often map everything into a
single case.
6.4. According to RFC 1034 [2], section 4.2.1, one should not have
to code glue RR's for name server's names unless they are below
the cut. When I don't put glue RR's in, and do a query for
NS records, the "additional" field is left blank. As far as I
can tell, all other zones I query for NS records have this
filled with the IP addresses of the NS hosts. Is this required
or should I not be concerned that the additional field is empty?
The protocol says that an empty additional field is not a problem
when the name server's name is not "below" the cut.
In practice, putting in the glue where it is not required can
cause problems if the servers named in the glue are used for
several zones. This is broken behavior in BIND. Not putting in
glue can cause other problems in BIND, usually when the server
name is difficult to resolve. So, the bottom line is to put glue
in only when required, and don't use aliases or anything else
tricky when it comes to identifying name servers.
7. Questions About Network Management Implementations
7.1. In reading the SNMP RFCs [3,4,5,6] I find mention of
authentication of PDUs. Are there any standards for
authentication mechanisms?
There is a working group of the IETF that is working on this
problem. They are close to a solution, but nothing has yet
reached RFC publication yet. Expect something solid and
implementable by October of 1991.
7.2. Can vendors make their enterprise-specific variables available
to users through a standard distribution mechanism?
Yes. But before someone submits a MIB, they should check it out
themselves.
On uu.psi.com in pilot/snmp-wg/, there are two files
mosy-sparc-4.0.3.c
mosy-sun3-3.5
The first will run on a Sun-Sparc, the second will run on a Sun-3.
After retrieving one of these files in BINARY mode via anonymous FTP,
the submittor can run their MIB through it, e.g.,
% mosy mymib.my
Once your MIB passes, send it to:
mib-checker@isi.edu
If everything is OK, the mib-checker will arrange to have it
installed in the /share/ftp/mib directory on venera.isi.edu.
Note: This processing does not offer an official endorsement. The
documents submitted must not be marked proprietary, confidential,
or the like.
7.3. I have a question regarding those pesky octet strings again.
I use the variable-type field of the Response pdu to determine
how the result should be displayed to the user. For example,
I convert NetworkAddresses to their dotted decimal format
("132.243.50.4"). I convert Object Identifiers into strings
("1.3.6.1.2....").
I would LIKE to just print Octet Strings as strings. But,
this causes a problem in such cases as atPhysAddress in
which the Octet string contains the 6 byte address instead
of a printable ASCII string. In this case, I would want to
display the 6 bytes instead of just trying to print the
string.
MY QUESTION IS: Does anyone have a suggestion as to how I
can determine whether I can just print the string or whether
I should display the octet bytes. * Remember: I want to
support enterprise specific variables too.
In general, there is no way that you can tell what is inside an
OCTET STRING without knowing something about the object that the
OCTET STRING comes from. In MIB-II [6], some objects are marked
as DisplayString which has the syntax of OCTET STRING but is
restricted to characters from the NVT ASCII character set (see the
TELNET Specification, RFC 854 [7], for further information).
These objects are:
sysDescr
sysContact
sysName
sysLocation
ifDescr
If you want to be able to arbitrarily decide how to display the
strings, without knowing anything about the object, then you can
scan the octets, looking for any octet which is not printable
ASCII. If you find at least one, you can print the entire string,
octet by octet, in "%02x:" notation. If all of the octets are
printable ASCII, then you can just printf the string.
7.4. If archived MIBs must be 1155-compatible [3], it would be nice
if those who submit them check them first. Where are these
MIB tools available for public FTP? Ideally, a simple
syntax checker (that didn't actually generate code) would be
nice.
In the ISODE 6.0 release there is a tool called MOSY which
recognizes the 1155 syntax and produces a flat ASCII file. If you
can run it through MOSY without problems then you are OK.
7.5. Suppose I want to create a private MIB object for causing
some action to happen, say, do a reset. Should the syntax
or this object specify a value such as:
Syntax:
INTEGER {
perform reset (1),
}
even though there is only a single value? Or, is it ok to
just allow a Set on this object with any value to perform
the desired action? If the later, how is this specified?
For our SNMP manageable gizmos and doohickies with similar
"action" type MIB variables, I've defined two values
Syntax:
INTEGER {
reset(1)
not-reset(2)
}
And defined behavior so that the only valid value that the
variable may be set to is "reset" (which is returned in the get
response PDU) and at all other times a get/getnext will respond
with "not-reset".
8. Questions about Serial Line Internet Protocol (SLIP) and
Point-to-Point Protocol (PPP) Implementations
8.1. I seem to recall hearing that SLIP [8] will only run on
synchronous serial lines. Is this true? ... is there
something about SLIP which precludes it's being implemented
over async lines?
Other way around: SLIP is designed for async lines and is not a
good fit on sync lines. PPP [9, 10] works on either, and is what
you should be implementing if you're implementing something.
8.2. Since we are very interested in standards in this area,
could someone tell me were I can find more information on PPP?
Also, can this protocol be used in other fields than for the
Internet (i.e., telecontrol, telemetering) where we see a
profusion of proprietary incompatible and hard to maintain
Point-to-Point Protocols?
PPP was designed to be useful for many protocols besides just IP.
Whether it would be useful for your particular application should
probably be discussed with the IETF's Point-to-Point Protocol
Working Group discussion list. For general discussion: ietf-
ppp@ucdavis.edu. To subscribe: ietf-ppp-request@ucdavis.edu
The PPP specification is available as RFC 1171 [9], and a PPP
options specification is available as RFC 1172 [10].
In UnixWorld of April 1990 (Vol. VII, No. 4, Pg. 85), Howard
Baldwin writes:
"Point-to-Point Protocol (PPP) has just been submitted to the
CCITT from the Internet Engineering Task Force. It specifies a
standard for encapsulating Internet Protocol data and other
network layer (level three on ISO's OSI Model) protocol
information over point-to-point links; it also provides ways to
test and configure lines and the upper level protocols on the
OSI Model. The only requirement is a provision of a duplex
circuit either dedicated or switched, that can operate in
either an asynchronous or synchronous mode, transparent to the
data-linklayer frame.
"According to Michael Ballard, director of network systems for
Telebit, PPP is a direct improvement upon Serial Line Internet
Protocol (SLIP), which had neither error correction nor a way
to exchange network address."
8.3. Does anyone know if there is a way to run a SLIP program on
a IBM computer running SCO Xenix/Unix, with a multi-port
serial board?
SCO TCP/IP for Xenix supports SLIP. It works. However, be
warned: SCO SLIP works *only* with SCO serial drivers, so it will
*not* work with intelligent boards that come with their own
drivers. If you want lots of SLIP ports, you'll need lots of dumb
ports, perhaps with a multi-dumb-port board.
Here's the setup -- SunOS 3.5, with the 4.3BSD TCP, IP & SLIP
distributions installed. Slip is running between the "ttya" ports
of two Sun 3/60's. "ping", "rlogin", etc., works fine, but a NFS
mount results in "server not responding: RPC Timed Out".
SunOS 3.5 turns the UDP checksum off, which is legal and works
okay over interfaces such as ethernet which has link- level
checksumming. On the other hand, SLIP doesn't perform checksums
thus running NFS over SLIP requires you to turn the UDP checksum
on. Otherwise, you'll experience erratic behavior such as the one
described above.
Save the older kernel and try,
% adb -k -w /vmunix /dev/kmem udpcksum?w 1
to patch up the kernel.
9. Questions About Routing
9.1. Some postings mentioned "maximum entropy routing". Could
someone please provide a pointer to on-line or off-line
references to this topic?
Try NYU CSD Technical Report 371: "Some Comments on Highly Dynamic
Network Routing," by Herbert J. Bernstein, May 1988.
10. Other Protocol and Standards Implementation Questions
10.1. Does anyone recognize ethernet type "80F3"? I don't see it
in RFC 1010, but I am seeing it on our net.
Ethernet type 0x80F3 is used by AppleTalk for address resolution.
You must have Macs on your network which are directly connected to
Ethernet. These packets are used by the Mac (generally at
startup) to determine a valid AppleTalk node number.
Additional Information:
RFC 1010 is obsolete. Please consult RFC 1060 [11], the current
"Assigned Numbers" (issued March 1990), which does list "80F3":
Ethernet Exp. Ethernet Description References
------------- ------------- ----------- ----------
decimal Hex decimal octal
33011 80F3 - - AppleTalk AARP (Kinetics)[XEROX]
10.2. Does anyone know the significance of a high value for
"Bad proto" in the output from netstat on Unix machines using
ethernet? We're seeing values in the tens of thousands out of
a few hundred thousand packets sent/received in all. Some
"Bad proto" values are negative, too. (Off the scale?) Any
help would be appreciated.
This probably indicates that you are getting tens of thousands of
broadcast packets from some host or hosts on your network. You
might want to buy or rent a LAN monitor, or install one of the
public-domain packages to see what private protocol is guilty.
"FYI on a Network Management Tool Catalog: Tools for Monitoring
and Debugging TCP/IP Internets and Interconnected Devices" (RFC
1147, FYI 2), [12] contains pointers to tools that may help you
zero in on the problem.
10.3. Which RFC would explain the proper way to configure broadcast
addresses when using subnets?
Consult RFC 1122, "Requirements for Internet Hosts --
Communication Layer" [13].
10.4. Can anyone tell me what .TAR files exactly are? Is it like
ZIP or LZH for the IBM PC's? IF so, how do I go about getting
a compressor/decompressor for .TAR files and what computer
does this run on?
TAR stands for "Tape ARchive". It is a Unix utility which takes
files, and directories of files, and creates a single large file.
Originally intended to back up directory trees onto tape (hence
the name), TAR is also used to combine files for easier electronic
file transfer.
11. Suggested Reading
For further information about the Internet and its protocols in
general, you may choose to obtain copies of the following works:
Bowers, K., T. LaQuey, J. Reynolds, K. Roubicek, M. Stahl, and A.
Yuan, "Where to Start - A Bibliography of General Internetworking
Information", RFC 1175, FYI 3, CNRI, U Texas, ISI, BBN, SRI,
Mitre, August 1990.
Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layer", RFC 1122, Internet Engineering Task Force,
October 1989.
Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", RFC 1123, Internet Engineering Task
Force, October 1989.
Comer, D., "Internetworking with TCP/IP: Principles, Protocols,
and Architecture", Prentice Hall, New Jersey, 1989.
Frey, D. and R. Adams, "!%@:: A Directory of Electronic Mail
Addressing and Networks", O'Reilly and Associates, Newton, MA,
August 1989.
Krol, E., "The Hitchhikers Guide to the Internet", RFC 1118,
University of Illinois Urbana, September 1989.
LaQuey, T, Editor, "Users' Directory of Computer Networks",
Digital Press, Bedford, MA, 1990.
Malkin, G., and A. Marine, "FYI on Questions and Answers - Answers
to Commonly asked "New Internet User" Questions", RFC 1206, FYI 4,
FTP Software, Inc., SRI, February 1991.
Postel, J., Editor, "IAB Official Protocol Standards", RFC 1140,
Internet Activities Board, May 1990.
Quarterman, J., "Matrix: Computer Networks and Conferencing
Systems Worldwide", Digital Press, Bedford, MA, 1989.
Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.
Socolofsky, T., and C. Kale, "A TCP/IP Tutorial", RFC 1180, Spider
Systems Limited, January 1991.
Stevens, W., "UNIX Network Programming", ISBN 0-13-949876-1,
Prentice Hall, Englewood Cliffs, NJ, 1990.
Stine, R., Editor, "FYI on a Network Management Tool Catalog:
Tools for Monitoring and Debugging TCP/IP Internets and
Interconnected Devices" RFC 1147, FYI 2, Sparta, Inc., April 1990.
12. References
[1] Cerf, V., and K. Mills, "Explaining the Role of GOSIP", RFC 1169,
IAB, NIST, August 1990.
[2] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
1034, USC/Information Sciences Institute, November 1987.
[3] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.
[4] McCloghrie, K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC 1156, Hughes
LAN Systems, Performance Systems International, May 1990.
[5] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple
Network Management Protocol (SNMP)", RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[6] Rose, M., Editor, "Management Information Base for Network
Management of TCP/IP-based internets: MIB-II", RFC 1158,
Performance Systems International, May 1990.
[7] Postel, J., and J. Reynolds, "TELNET Protocol Specification", RFC
854, USC/Information Sciences Institute, May 1983.
[8] Romkey, J., "A Nonstandard for Transmission of IP Datagrams over
Serial Lines: SLIP", RFC 1055, June 1988.
[9] Perkins, D., "The Point-to-Point Protocol: A Proposal for Multi-
Protocol Transmission of Datagrams Over Point-to-Point Links",
RFC 1171, CMU, July 1990.
[10] Perkins, D., and R. Hobby, "The Point-to-Point Protocol (PPP)
Initial Configuration Options", CMU, UC Davis, July 1990.
[11] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.
[12] Stine, R., Editor, "FYI on a Network Management Tool Catalog:
Tools for Monitoring and Debugging TCP/IP Internets and
Interconnected Devices" RFC 1147, FYI 2, Sparta, Inc., April
1990.
[13] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layer", RFC 1122, Internet Engineering Task Force,
October 1989.
13. Security Considerations
Security issues are not discussed in this memo.
14. Authors' Addresses
Gary Scott Malkin
FTP Software, Inc.
26 Princess Street
Wakefield, MA 01880
Phone: (617) 246-0900
EMail: gmalkin@ftp.com
April N. Marine
SRI International
Network Information Systems Center
333 Ravenswood Avenue, EJ294
Menlo Park, CA 94025
Phone: (415) 859-5318
EMail: APRIL@nic.ddn.mil
Joyce K. Reynolds
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
Phone: (213) 822-1511
EMail: jkrey@isi.edu
ISO Plain Language
On this page
§1Why This Collection of Answers Exists
RFC 1207 is FYI 7, one of two FYI documents on questions and answers produced by the User Services Working Group of the Internet Engineering Task Force. The stated goal is to document the most commonly asked questions and answers in the Internet, and the memo says it provides information for the Internet community and specifies no standard.
The reason for collecting them is stated plainly. The goal is to codify the Internet lore so that network operations staff, especially those running networks that had just joined the Internet, would have an accurate and up to date set of references to work from. It would also take the redundancy off the electronic mailing lists, so subscribers would not have to read the same queries and answers over and over again.
Several people monitored the major mailing lists over the preceding months and extracted the questions that mattered or came up most often. The answers come from those lists as well, presented loosely grouped by related topic for ease of reading, with the question first and then the answer as it appeared on the list. Sometimes an answer is abridged for space. When a question went unanswered on the list, the editors supply an answer themselves, and these are not marked apart from the others; when they add material that was not in the original answer, it appears under the heading Additional Information. Many questions are in the first person and the answers are addressed to whoever asked, and the phrasing was left alone apart from necessary clarifications, with the correspondents' names removed.
The editors warn that the answers are as correct as the reviewers can make them, but that much of the information changes with time, and that temporal errors will be corrected as the FYI is updated. A subgroup of the working group used three mailing lists to work on the document: quail@ftp.com for discussion and pre-release review, quail-request@ftp.com to join, and quail-box@ftp.com, where questions and answers were forwarded and stored.
This memo gathers the questions network operators asked most often and the answers that worked in practice. It saves people from asking the same things on mailing lists again and again.
- FYI 7 questions The subject areas of the memo
- The Internet
- Other networks and internets
- Internet documentation
- The Domain Name System
- Network management
- SLIP and PPP implementations
- Routing
- Other protocol and standards questions
- Suggested reading
§2The Internet and the Networks Beside It
The first question is where to get traffic statistics for NSFNET, the National Science Foundation Network. Merit/NSFNET Information Services kept statistical data at nis.nsf.net (35.1.1.48) in a stats directory, including packet counts by NSS and byte counts for each type of use such as ftp, smtp and telnet, in files named NSFyy-mm.type. The files were available over anonymous FTP with guest as the password. The answer is careful about what the numbers mean: they cover only traffic that traverses the highest level of the NSFNET, not traffic inside a campus or regional network.
The second question asks how to reach a machine on EARN/BITNET, and the answer explains that several Internet machines act as gateways between the Internet and BITNET, two examples being UICVM.UIC.EDU and CUNYVM.CUNY.EDU. Mail can be addressed to user%nodename.bitnet@uicvm.uic.edu and will be passed from the Internet to BITNET. The same gateways, known as INTERBIT on the BITNET and EARN side, carry mail back the other way, but only from computers that support SMTP mail headers, because many BITNET and EARN computers still do not support SMTP, which is not part of the IBM protocol used.
BITNET and EARN are the two largest of several cooperating networks that use the IBM RSCS/NJE protocol suite, and are not limited to IBM systems. Together with the other cooperating networks they function as a single worldwide network connecting more than 3,300 computers in about 1,400, mostly higher-education, organizations worldwide, and they support electronic mail including mailing lists, sender-initiated file transfer and short interactive messages. BITNET is the United States portion, with more than 550 organizations participating, and EARN is the European Academic Research Network, linking more than 500 institutions in Europe and several surrounding countries.
One date is worth noting: BITNET and CSNET merged organisationally on October 1, 1990, to form CREN, the Corporation for Research and Educational Networking. The two networks remain separate at the operational level, and EARN and the other cooperating networks were not part of that merger. A third question, about ordering documents related to GOSIP, points to PROTOCOLS:GOSIP-ORDER-INFO.TXT on NIC.DDN.MIL and to an appendix to RFC 1169.
The memo says where to find traffic statistics, and how to send mail to the academic networks that ran alongside the Internet. Those networks used different protocols, so gateways did the translation, and only some of their computers could send mail back out.
| Aspect | The Internet | BITNET and EARN |
|---|---|---|
| Protocol suite | TCP/IP | IBM RSCS/NJE |
| Mail sent back out | SMTP throughout | Only from computers that support SMTP mail headers |
| Reached from the Internet | Directly | Through a gateway, for example UICVM.UIC.EDU |
§3Domain Name System Questions
The longest run of questions concerns the Domain Name System (DNS). The first asks whether there is a DNS query server, and the answer describes a service on host 128.218.1.109 port 5555: connect to it, type a fully qualified domain name, and it replies with an internet address and closes the connection, which the writer describes as a manual nslookup. The answer then says that most users will find it simpler to use a DNS query tool and ask the DNS directly, because that also shows how short names are expanded at the user's own site rather than elsewhere. On a UNIX host with the dig program the answer shows dig x.miskatonic.edu and dig z, and mentions nslookup and similar programs for other systems.
The next question reports frequent BIND failures on VAX and Solbourne machines, traced to TCP domain queries from an IBM NSMAIN nameserver running in cache mode, with UDP queries not causing the problem even though a UDP resolution is usually what is running when the crash happens. Something appears to trash the hash areas, sometimes even during a recursive resolution, and the socket or file descriptor for the TCP connection is occasionally changed to invalid entries, which makes a reply write fail. The answer is that both BIND and the IBM implementation, often called FAL, come in many versions and the older ones are truly bad, so upgrade before investigating further. It adds that BIND has always had a problem with polluting its own database, that the problems have been related to TCP connections and NS resource records with small time-to-live values, and that the style of bug fixing has often been to reduce the problem by 90 per cent rather than eliminate it. The plain conclusion is that the combination of an old BIND and an old IBM server is unpleasant.
Two smaller DNS questions follow. On letter case, the model is that whoever controls a point in the name space is free to choose the case there, until control is handed on, though several implementations get it wrong and IBM implementations often map everything into one case. On glue records, the protocol says an empty additional field is not a problem when the name server's name is not below the cut; putting in glue that is not required can cause problems when the servers named are used for several zones, which the answer calls broken behaviour in BIND, and leaving glue out can cause other BIND problems, usually when the server name is hard to resolve. The advice is to put glue in only when it is required, and not to use aliases when identifying name servers.
Most of the DNS questions are about practical trouble: a name server that crashes, software that changes the case of names, and records that are missing or in the wrong place. The answers are blunt advice to upgrade the software and to fill in only what the rules require.
dig x.miskatonic.edu
dig z§4Network Management and Serial Lines
The network management questions start with SNMP authentication. The answer reports that an IETF working group was close to a solution, that nothing had yet reached RFC publication, and that something solid and implementable was expected by October of 1991.
The next question asks how vendors can make their own variables available, and the answer says yes, but that a MIB should be checked first. Two programs are named for the job: mosy-sparc-4.0.3.c, which runs on a Sun-Sparc, and mosy-sun3-3.5, which runs on a Sun-3. Both are retrieved in BINARY mode over anonymous FTP and run over a MIB, for example % mosy mymib.my. A MIB that passes is sent to mib-checker@isi.edu, and if everything is in order the checker arranges for it to be installed in the /share/ftp/mib directory on venera.isi.edu. The answer notes that this processing offers no official endorsement and that submitted documents must not be marked proprietary or confidential. A related question names MOSY in the ISODE 6.0 release as the tool that recognises the 1155 syntax and produces a flat ASCII file.
Another question asks how to decide whether an OCTET STRING should be printed as text or as bytes. The answer is that in general there is no way to tell without knowing something about the object the string came from. Some objects in MIB-II are marked as DisplayString, which has the syntax of OCTET STRING but is restricted to characters from the NVT ASCII character set, and the answer lists them: sysDescr, sysContact, sysName, sysLocation and ifDescr. If arbitrary display is wanted, scan the octets for any that are not printable ASCII; if there is at least one, print the whole string octet by octet in %02x: notation, and if all of them are printable, print the string.
A private MIB object that triggers an action, such as a reset, is handled by defining two values, reset(1) and not-reset(2), with behaviour defined so that reset is the only valid value to set, and any other get or getnext returns not-reset.
The serial line questions correct a common belief: SLIP is designed for asynchronous lines and is not a good fit on synchronous ones, while PPP works on either and is what the answer says to implement. PPP was designed to be useful for many protocols besides IP, and a quotation from UnixWorld of April 1990 records that it had been submitted to the CCITT from the IETF, specifies a standard for encapsulating IP data and other network layer information over point-to-point links, provides ways to test and configure lines and the upper level protocols, and requires only a duplex circuit, dedicated or switched, that can operate in either an asynchronous or synchronous mode and is transparent to the data-link layer frame. The same quotation records PPP as a direct improvement on SLIP, which had neither error correction nor a way to exchange network address. The specification is RFC 1171 and the options specification RFC 1172.
Two practical warnings close the section. SCO's TCP/IP for Xenix supports SLIP, but only with SCO serial drivers, so it will not work with intelligent boards that bring their own drivers. And SunOS 3.5 turns the UDP checksum off, which is legal and works over interfaces such as Ethernet that have link-level checksumming, whereas SLIP performs no checksums, so running NFS over SLIP requires the UDP checksum to be turned on. Without it the result is erratic behaviour such as server not responding: RPC Timed Out.
The management answers are practical: check a MIB with a tool before submitting it, decide how to print a string by looking at its bytes, and give an action object two values so that reading it is safe. The serial line answers correct a common mistake about SLIP and explain why PPP is the better choice.
§5Routing, Assigned Numbers and Other Practical Questions
Section 9 asks about maximum entropy routing and gets a single pointer: NYU CSD Technical Report 371, Some Comments on Highly Dynamic Network Routing, by Herbert J. Bernstein, May 1988.
Section 10 collects four short answers about protocol and standards implementation. The first asks whether anyone recognises the Ethernet type 80F3, which is not listed in RFC 1010. The answer identifies it as AppleTalk for address resolution, says that Macs directly connected to Ethernet must be present on the network, and explains that these packets are used by the Mac, generally at startup, to determine a valid AppleTalk node number. It adds that RFC 1010 is obsolete and that RFC 1060, the current Assigned Numbers document issued in March 1990, does list 80F3, with the entry AppleTalk AARP.
The second question asks what a high value for Bad proto in netstat output on UNIX machines with Ethernet means, with values in the tens of thousands against a few hundred thousand packets sent and received, and some negative values. The answer says this probably indicates tens of thousands of broadcast packets from some host or hosts on the network, and suggests buying or renting a LAN monitor or installing one of the public-domain packages to find the private protocol that is guilty. It points to RFC 1147, FYI 2, a network management tool catalog.
The third answer, on configuring broadcast addresses when using subnets, says to consult RFC 1122, Requirements for Internet Hosts -- Communication Layer. The fourth explains that .TAR files stand for Tape ARchive: a Unix utility that takes files and directories of files and creates a single large file, originally intended to back up directory trees onto tape, and also used to combine files for easier electronic file transfer.
The last questions are short lookups. The memo identifies an unfamiliar Ethernet type, explains a puzzling counter in netstat, points to the right RFC for subnets, and says what a .TAR file actually is.
§6Suggested Reading and Security
The memo ends with a reading list for anyone who wants to go further on the Internet and its protocols in general. It includes RFC 1175, the Where to Start bibliography, RFC 1122 and RFC 1123 on requirements for Internet hosts, Doug Comer's textbook, Frey and Adams' !%@:: A Directory of Electronic Mail Addressing and Networks, Ed Krol's Hitchhiker's Guide published as RFC 1118, Tracy LaQuey's Users' Directory of Computer Networks, the companion FYI 4 (RFC 1206) of questions from new users, RFC 1140 on the IAB Official Protocol Standards, John Quarterman's Matrix, RFC 1060 on Assigned Numbers, RFC 1180, the TCP/IP Tutorial, W. Stevens' UNIX Network Programming, and RFC 1147, the network management tool catalog.
The Security Considerations section is one sentence: security issues are not discussed in this memo. The answers deal with availability and configuration rather than with the threats themselves, and the topics of authentication and privacy are not treated here.
The memo closes with a reading list and one line about security: it says security issues are not discussed. Nothing here treats the threats themselves, only the operational questions people were asking.