E. Krol, University of Illinois Urbana
A few groups provide much of the information services on the Internet. Information Sciences Institute (ISI) does much of the standardization and allocation work of the Internet acting as the Internet Assigned Numbers Authority (IANA). SRI International provides the principal information services for the Internet by operating the Network Information Center (NIC). In fact, after you are connected to the Internet most of the information in this document can be retrieved from the SRI-NIC. Bolt Beranek and Newman (BBN) provides information services for CSNET (the CIC) and NSFNET (the NNSC), and Merit provides information services for NSFNET (the NIS).
There are two independent categorizations of protocols. The first is the state of standardization which is one of "standard", "draft standard", "proposed", "experimental", or "historic". The second is the status of this protocol which is one of "required", "recommended", "elective", or "not recommended". One could expect a particular protocol to move along the scale of status from elective to required at the same time as it moves along the scale of standardization from proposed to standard.
A Required Standard protocol (e.g., RFC-791, The Internet Protocol) must be implemented on any host connected to the Internet. Recommended Standard protocols are generally implemented by network hosts. Lack of them does not preclude access to the Internet, but may impact its usability. RFC-793 (Transmission Control Protocol) is a Recommended Standard protocol. Elective Proposed protocols were discussed and agreed to, but their application has never come into wide use. This may be due to the lack of wide need for the specific application (RFC-937, The Post Office Protocol) or that, although technically superior, ran against other pervasive approaches. It is suggested that should the facility be required by a particular site, an implementation be done in accordance with the RFC. This insures that, should the idea be one whose time has come, the implementation will be in accordance with some standard and will be generally usable.
Informational RFCs contain factual information about the Internet and its operation (RFC-1010, Assigned Numbers). Finally, as the Internet and technology have grown, some RFCs have become unnecessary. These obsolete RFCs cannot be ignored, however. Frequently when a change is made to some RFC that causes a new one to be issued obsoleting others, the new RFC may only contains explanations and motivations for the change. Understanding the model on which the whole facility is based may involve reading the original and subsequent RFCs on the topic. (Appendix B contains a list of what are considered to be the major RFCs necessary for understanding the Internet).
Only a few RFCs actually specify standards, most RFCs are for information or discussion purposes. To find out what the current standards are see the RFC titled "IAB Official Protocol Standards" (most recently published as RFC-1100).
%telnet nic.ddn.milon a BSD system, and following the directions provided by a user friendly prompter. From poking around in the databases provided, one might decide that a document named NETINFO:NUG.DOC (The Users Guide to the ARPANET) would be worth having. It could be retrieved via an anonymous FTP. An anonymous FTP would proceed something like the following. (The dialogue may vary slightly depending on the implementation of FTP you are using).
%ftp nic.ddn.mil Connected to nic.ddn.mil 220 NIC.DDN.MIL FTP Server 5Z(47)-6 at Wed 17-Jun-87 12:00 PDT Name (nic.ddn.mil:myname): anonymous 331 ANONYMOUS user ok, send real ident as password. Password: myname 230 User ANONYMOUS logged in at Wed 17-Jun-87 12:01 PDT, job 15. ftp> get netinfo:nug.doc 200 Port 18.144 at host 128.174.5.50 accepted. 150 ASCII retrieve of <NETINFO>NUG.DOC.11 started. 226 Transfer Completed 157675 (8) bytes transferred local: netinfo:nug.doc remote:netinfo:nug.doc 157675 bytes in 4.5e+02 seconds (0.34 Kbytes/s) ftp> quit 221 QUIT command received. Goodbye.(Another good initial document to fetch is NETINFO:WHAT-THE-NIC- DOES.TXT).
Questions of the NIC or problems with services can be asked of or reported to using electronic mail. The following addresses can be used:
NIC@NIC.DDN.MIL General user assistance, document requests REGISTRAR@NIC.DDN.MIL User registration and WHOIS updates HOSTMASTER@NIC.DDN.MIL Hostname and domain changes and updates ACTION@NIC.DDN.MIL SRI-NIC computer operations SUGGESTIONS@NIC.DDN.MIL Comments on NIC publications and servicesFor people without network access, or if the number of documents is large, many of the NIC documents are available in printed form for a small charge. One frequently ordered document for starting sites is a compendium of major RFCs. Telephone access is used primarily for questions or problems with network access. (See appendix B for mail/telephone contact numbers).
The NNSC, which has information and documents online and in printed form, distributes news through network mailing lists, bulletins, and online reports. NNSC publications include a hardcopy newsletter, the NSF Network News, which contains articles of interest to network users and the Internet Resource Guide, which lists facilities (such as supercomputer centers and on-line library catalogues) accessible from the Internet. The Resource Guide can be obtained via anonymous ftp to nnsc.nsf.net in the directory resource-guide, or by joining the resource guide mailing list (send a subscription request to Resource-Guide-Request@NNSC.NSF.NET.)
The general format to subscribe to a mail list is to find the address reflector and append the string -REQUEST to the mailbox name (not the host name). For example, if you wanted to take part in the mailing list for NSFNET reflected by NSFNET-INFO@MERIT.EDU, one sends a request to NSFNET-INFO-REQUEST@MERIT.EDU. This may be a wonderful scheme, but the problem is that you must know the list exists in the first place. It is suggested that, if you are interested, you read the mail from one list (like NSFNET-INFO) and you will probably become familiar with the existence of others. A registration service for mail reflectors is provided by the NIC in the files NETINFO:INTEREST-GROUPS-1.TXT, NETINFO:INTEREST-GROUPS-2.TXT, and NETINFO:INTEREST-GROUPS-3.TXT.
The NSFNET-INFO mail reflector is targeted at those people who have a day to day interest in the news of the NSFNET (the backbone, regional network, and Internet inter-connection site workers). The messages are reflected by a central location and are sent as separate messages to each subscriber. This creates hundreds of messages on the wide area networks where bandwidth is the scarcest.
There are two ways in which a campus could spread the news and not cause these messages to inundate the wide area networks. One is to re-reflect the message on the campus. That is, set up a reflector on a local machine which forwards the message to a campus distribution list. The other is to create an alias on a campus machine which places the messages into a notesfile on the topic. Campus users who want the information could access the notesfile and see the messages that have been sent since their last access. One might also elect to have the campus wide area network liaison screen the messages in either case and only forward those which are considered of merit. Either of these schemes allows one message to be sent to the campus, while allowing wide distribution within.
IP addresses are 32 bits long. It is usually written as four decimal numbers separated by periods (e.g., 192.17.5.100). Each number is the value of an octet of the 32 bits. Some networks might choose to organize themselves as very flat (one net with a lot of nodes) and some might organize hierarchically (many interconnected nets with fewer nodes each and a backbone). To provide for these cases, addresses were differentiated into class A, B, and C networks. This classification had to with the interpretation of the octets. Class A networks have the first octet as a network address and the remaining three as a host address on that network. Class C addresses have three octets of network address and one of host. Class B is split two and two. Therefore, there is an address space for a few large nets, a reasonable number of medium nets and a large number of small nets. The high order bits in the first octet are coded to tell the address format. There are very few unallocated class A nets, so a very good case must be made for them. So as a practical matter, one has to choose between Class B and Class C when placing an order. (There are also class D (Multicast) and E (Experimental) formats. Multicast addresses will likely come into greater use in the near future, but are not frequently used yet).
In the past, sites requiring multiple network addresses requested multiple discrete addresses (usually Class C). This was done because much of the software available (notably 4.2BSD) could not deal with subnetted addresses. Information on how to reach a particular network (routing information) must be stored in Internet gateways and packet switches. Some of these nodes have a limited capability to store and exchange routing information (limited to about 700 networks). Therefore, it is suggested that any campus announce (make known to the Internet) no more than two discrete network numbers.
If a campus expects to be constrained by this, it should consider subnetting. Subnetting (RFC-950) allows one to announce one address to the Internet and use a set of addresses on the campus. Basically, one defines a mask which allows the network to differentiate between the network portion and host portion of the address. By using a different mask on the Internet and the campus, the address can be interpreted in multiple ways. For example, if a campus requires two networks internally and has the 32,000 addresses beginning 128.174.X.X (a Class B address) allocated to it, the campus could allocate 128.174.5.X to one part of campus and 128.174.10.X to another. By advertising 128.174 to the Internet with a subnet mask of FF.FF.00.00, the Internet would treat these two addresses as one. Within the campus a mask of FF.FF.FF.00 would be used, allowing the campus to treat the addresses as separate entities. (In reality, you don't pass the subnet mask of FF.FF.00.00 to the Internet, the octet meaning is implicit in its being a class B address).
A word of warning is necessary. Not all systems know how to do subnetting. Some 4.2BSD systems require additional software. 4.3BSD systems subnet as released. Other devices and operating systems vary in the problems they have dealing with subnets. Frequently, these machines can be used as a leaf on a network but not as a gateway within the subnetted portion of the network. As time passes and more systems become 4.3BSD based, these problems should disappear.
There has been some confusion in the past over the format of an IP broadcast address. Some machines used an address of all zeros to mean broadcast and some all ones. This was confusing when machines of both type were connected to the same network. The broadcast address of all ones has been adopted to end the grief. Some systems (e.g., 4.3 BSD) allow one to choose the format of the broadcast address. If a system does allow this choice, care should be taken that the all ones format is chosen. (This is explained in RFC-1009 and RFC-1010).
Number of Networks
When the Internet was designed it was to have about 50 connected networks. With the explosion of networking, the number is now approaching 1000. The software in a group of critical gateways (called the core gateways) are not able to pass or store much more than that number. In the short term, core reallocation and recoding has raised the number slightly.
Routing Issues
Along with sheer mass of the data necessary to route packets to a large number of networks, there are many problems with the updating, stability, and optimality of the routing algorithms. Much research is being done in the area, but the optimal solution to these routing problems is still years away. In most cases, the the routing we have today works, but sub-optimally and sometimes unpredictably. The current best hope for a good routing protocol is something known as OSPFIGP which will be generally available from many router manufacturers within a year.
Trust Issues
Gateways exchange network routing information. Currently, most gateways accept on faith that the information provided about the state of the network is correct. In the past this was not a big problem since most of the gateways belonged to a single administrative entity (DARPA). Now, with multiple wide area networks under different administrations, a rogue gateway somewhere in the net could cripple the Internet. There is design work going on to solve both the problem of a gateway doing unreasonable things and providing enough information to reasonably route data between multiply connected networks (multi-homed networks).
Capacity & Congestion
Some portions of the Internet are very congested during the busy part of the day. Growth is dramatic with some networks experiencing growth in traffic in excess of 20% per month. Additional bandwidth is planned, but delivery and budgets might not allow supply to keep up.
The current IAB members are:
Vinton Cerf - Chairman David Clark - IRTF Chairman Phillip Gross - IETF Chairman Jon Postel - RFC Editor Robert Braden - Executive Director Hans-Werner Braun - NSFNET Liaison Barry Leiner - CCIRN Liaison Daniel Lynch - Vendor Liaison Stephen Kent - Internet SecurityThis board is supported by a Research Task Force (chaired by Dave Clark of MIT) and an Engineering Task Force (chaired by Phill Gross of NRI).
The Internet Research Task Force has the following Research Groups:
Autonomous Networks Deborah Estrin End-to-End Services Bob Braden Privacy Steve Kent User Interfaces Keith LantzThe Internet Engineering Task Force has the following technical areas:
Applications TBD Host Protocols Craig Partridge Internet Protocols Noel Chiappa Routing Robert Hinden Network Management David Crocker OSI Interoperability Ross Callon, Robert Hagen Operations TBD Security TBDThe Internet Engineering Task Force has the following Working Groups:
ALERTMAN Louis Steinberg Authentication Jeff Schiller CMIP over TCP Lee LaBarre Domain Names Paul Mockapetris Dynamic Host Config Ralph Droms Host Requirements Bob Braden Interconnectivity Guy Almes Internet MIB Craig Partridge Joint Management Susan Hares LAN Mgr MIB Amatzia Ben-Artzi NISI Karen Bowers NM Serial Interface Jeff Case NOC Tools Bob Enger OSPF Mike Petry Open Systems Routing Marianne Lepp OSI Interoperability Ross Callon PDN Routing Group CH Rokitansky Performance and CC Allison Mankin Point - Point IP Drew Perkins ST and CO-IP Claudio Topolcic Telnet Dave Borman User Documents Karen Roubicek User Services Karen Bowers
A little more background might be appropriate. IP gateways (more correctly routers) are boxes which have connections to multiple networks and pass traffic between these nets. They decide how the packet is to be sent based on the information in the IP header of the packet and the state of the network. Each interface on a router has an unique address appropriate to the network to which it is connected. The information in the IP header which is used is primarily the destination address. Other information (e.g., type of service) is largely ignored at this time. The state of the network is determined by the routers passing information among themselves. The distribution of the database (what each node knows), the form of the updates, and metrics used to measure the value of a connection, are the parameters which determine the characteristics of a routing protocol.
Under some algorithms, each node in the network has complete knowledge of the state of the network (the adult algorithm). This implies the nodes must have larger amounts of local storage and enough CPU to search the large tables in a short enough time (remember, this must be done for each packet). Also, routing updates usually contain only changes to the existing information (or you spend a large amount of the network capacity passing around megabyte routing updates). This type of algorithm has several problems. Since the only way the routing information can be passed around is across the network and the propagation time is non-trivial, the view of the network at each node is a correct historical view of the network at varying times in the past. (The adult algorithm, but rather than looking directly at the dining area, looking at a photograph of the dining room. One is likely to pick the optimal route and find a bus-cart has moved in to block the path after the photo was taken). These inconsistencies can cause circular routes (called routing loops) where once a packet enters it is routed in a closed path until its time to live (TTL) field expires and it is discarded.
Other algorithms may know about only a subset of the network. To prevent loops in these protocols, they are usually used in a hierarchical network. They know completely about their own area, but to leave that area they go to one particular place (the default gateway). Typically these are used in smaller networks (campus or regional).
Routing protocols in current use:
The other problem with hop-count metrics is that if links have different speeds, that difference is not reflected in the hop- count. So a one hop satellite link (with a .5 sec delay) at 56kb would be used instead of a two hop T1 connection. Congestion can be viewed as a decrease in the efficacy of a link. So, as a link gets more congested, RIP will still know it is the best hop-count route and congest it even more by throwing more packets on the queue for that link.
RIP was originally not well documented in the community and people read BSD code to find out how RIP really worked. Finally, it was documented in RFC-1058.
There are two ways to insert static routes into routed; the /etc/gateways file, and the "route add" command. Static routes are useful if you know how to reach a distant network, but you are not receiving that route using RIP. For the most part the "route add" command is preferable to use. The reason for this is that the command adds the route to that machine's routing table but does not export it through RIP. The /etc/gateways file takes precedence over any routing information received through a RIP update. It is also broadcast as fact in RIP updates produced by the host without question, so if a mistake is made in the /etc/gateways file, that mistake will soon permeate the RIP space and may bring the network to its knees.
One of the problems with routed is that you have very little control over what gets broadcast and what doesn't. Many times in larger networks where various parts of the network are under different administrative controls, you would like to pass on through RIP only nets which you receive from RIP and you know are reasonable. This prevents people from adding IP addresses to the network which may be illegal and you being responsible for passing them on to the Internet. This type of reasonability checks are not available with routed and leave it usable, but inadequate for large networks.
One of the most interesting side effects of Hello based networks is their great timekeeping ability. If you consider the problem of measuring delay on a link for the metric, you find that it is not an easy thing to do. You cannot measure round trip time since the return link may be more congested, of a different speed, or even not there. It is not really feasible for each node on the network to have a builtin WWV (nationwide radio time standard) receiver. So, you must design an algorithm to pass around time between nodes over the network links where the delay in transmission can only be approximated. Hello routers do this and in a nationwide network maintain synchronized time within milliseconds. (See also the Network Time Protocol, RFC-1059.)
Gated talks RIP to RIP speaking hosts, EGP to EGP speakers, and Hello to Hello'ers. These speakers frequently all live on one Ethernet, but luckily (or unluckily) cannot understand each others ruminations. In addition, under configuration file control it can filter the conversion. For example, one can produce a configuration saying announce RIP nets via Hello only if they are specified in a list and are reachable by way of a RIP broadcast as well. This means that if a rogue network appears in your local site's RIP space, it won't be passed through to the Hello side of the world. There are also configuration options to do static routing and name trusted gateways.
This may sound like the greatest thing since sliced bread, but there is a catch called metric conversion. You have RIP measuring in hops, Hello measuring in milliseconds, and EGP using arbitrary small numbers. The big questions is how many hops to a millisecond, how many milliseconds in the EGP number 3.... Also, remember that infinity (unreachability) is 16 to RIP, 30000 or so to Hello, and 8 to the DDN with EGP. Getting all these metrics to work well together is no small feat. If done incorrectly and you translate an RIP of 16 into an EGP of 6, everyone in the ARPANET will still think your gateway can reach the unreachable and will send every packet in the world your way. Gated is available via anonymous FTP from devvax.tn.cornell.edu in directory pub/gated.
We must look a little more closely into what's in a name. First, note that an address specifies a particular connection on a specific network. If the machine moves, the address changes. Second, a machine can have one or more names and one or more network addresses (connections) to different networks. Names point to a something which does useful work (i.e., the machine) and IP addresses point to an interface on that provider. A name is a purely symbolic representation of a list of addresses on the network. If a machine moves to a different network, the addresses will change but the name could remain the same.
Domain names are tree structured names with the root of the tree at the right. For example:
uxc.cso.uiuc.eduis a machine called "uxc" (purely arbitrary), within the subdomains of the U of I, and "uiuc" (the University of Illinois at Urbana), registered with "edu" (the set of educational institutions).
A simplified model of how a name is resolved is that on the user's machine there is a resolver. The resolver knows how to contact across the network a root name server. Root servers are the base of the tree structured data retrieval system. They know who is responsible for handling first level domains (e.g., 'edu'). What root servers to use is an installation parameter. From the root server the resolver finds out who provides 'edu' service. It contacts the 'edu' name server which supplies it with a list of addresses of servers for the subdomains (like 'uiuc'). This action is repeated with the sub-domain servers until the final subdomain returns a list of addresses of interfaces on the host in question. The user's machine then has its choice of which of these addresses to use for communication.
A group may apply for its own domain name (like 'uiuc' above). This is done in a manner similar to the IP address allocation. The only requirements are that the requestor have two machines reachable from the Internet, which will act as name servers for that domain. Those servers could also act as servers for subdomains or other servers could be designated as such. Note that the servers need not be located in any particular place, as long as they are reachable for name resolution. (U of I could ask Michigan State to act on its behalf and that would be fine.) The biggest problem is that someone must do maintenance on the database. If the machine is not convenient, that might not be done in a timely fashion. The other thing to note is that once the domain is allocated to an administrative entity, that entity can freely allocate subdomains using what ever manner it sees fit.
The Berkeley Internet Name Domain (BIND) Server implements the Internet name server for UNIX systems. The name server is a distributed data base system that allows clients to name resources and to share that information with other network hosts. BIND is integrated with 4.3BSD and is used to lookup and store host names, addresses, mail agents, host information, and more. It replaces the /etc/hosts file or host name lookup. BIND is still an evolving program. To keep up with reports on operational problems, future design decisions, etc., join the BIND mailing list by sending a request to Bind-Request@UCBARPA.BERKELEY.EDU. BIND can also be obtained via anonymous FTP from ucbarpa.berkeley.edu. There are several advantages in using BIND. One of the most important is that it frees a host from relying on /etc/hosts being up to date and complete. Within the .uiuc.edu domain, only a few hosts are included in the host table distributed by SRI. The remainder are listed locally within the BIND tables on uxc.cso.uiuc.edu (the server machine for most of the .uiuc.edu domain). All are equally reachable from any other Internet host running BIND, or any DNS resolver.
BIND can also provide mail forwarding information for interior hosts not directly reachable from the Internet. These hosts an either be on non-advertised networks, or not connected to an IP network at all, as in the case of UUCP-reachable hosts (see RFC-974). More information on BIND is available in the "Name Server Operations Guide for BIND" in UNIX System Manager's Manual, 4.3BSD release.
There are a few special domains on the network, like NIC.DDN.MIL. The hosts database at the NIC. There are others of the form NNSC.NSF.NET. These special domains are used sparingly, and require ample justification. They refer to servers under the administrative control of the network rather than any single organization. This allows for the actual server to be moved around the net while the user interface to that machine remains constant. That is, should BBN relinquish control of the NNSC, the new provider would be pointed to by that name.
In actuality, the domain system is a much more general and complex system than has been described. Resolvers and some servers cache information to allow steps in the resolution to be skipped. Information provided by the servers can be arbitrary, not merely IP addresses. This allows the system to be used both by non-IP networks and for mail, where it may be necessary to give information on intermediate mail bridges.
There is no correct algorithm but some are better than others, where worse is measured by the number of retransmissions done unnecessarily. BSD 4.2 had a retransmission algorithm which retransmitted quickly and often. This is exactly what you would want if you had a bunch of machines on an Ethernet (a low delay network of large bandwidth). If you have a network of relatively longer delay and scarce bandwidth (e.g., 56kb lines), it tends to retransmit too aggressively. Therefore, it makes the networks and gateways pass more traffic than is really necessary for a given conversation. Retransmission algorithms do adapt to the delay of the network after a few packets, but 4.2's adapts slowly in delay situations. BSD 4.3 does a lot better and tries to do the best for both worlds. It fires off a few retransmissions really quickly assuming it is on a low delay network, and then backs off very quickly. It also allows the delay to be about 4 minutes before it gives up and declares the connection broken.
Even better than the original 4.3 code is a version of TCP with a retransmission algorithm developed by Van Jacobson of LBL. He did a lot of research into how the algorithm works on real networks and modified it to get both better throughput and be friendlier to the network. This code has been integrated into the later releases of BSD 4.3 and can be fetched anonymously from ucbarpa.berkeley.edu in directory 4.3.
[1] Quarterman and Hoskins, "Notable Computer Networks",
Communications of the ACM, Vol. 29, No. 10, pp. 932-971,
October 1986.
[2] Tannenbaum, A., "Computer Networks", Prentice Hall, 1981.
[3] Hedrick, C., "Introduction to the Internet Protocols", Via
Anonymous FTP from topaz.rutgers.edu, directory pub/tcp-ip-docs,
file tcp-ip-intro.doc.
[4] Comer, D., "Internetworking with TCP/IP: Principles, Protocols,
and Architecture", Copyright 1988, by Prentice-Hall, Inc.,
Englewood Cliffs, NJ, 07632 ISBN 0-13-470154-2.
RFC-768 User Datagram Protocol (UDP)
RFC-791 Internet Protocol (IP)
RFC-792 Internet Control Message Protocol (ICMP)
RFC-793 Transmission Control Protocol (TCP)
RFC-821 Simple Mail Transfer Protocol (SMTP)
RFC-822 Standard for the Format of ARPA Internet Text Messages
RFC-826 Ethernet Address Resolution Protocol
RFC-854 Telnet Protocol
RFC-862 Echo Protocol
RFC-894 A Standard for the Transmission of IP
Datagrams over Ethernet Networks
RFC-904 Exterior Gateway Protocol
RFC-919 Broadcasting Internet Datagrams
RFC-922 Broadcasting Internet Datagrams in the Presence of Subnets
RFC-950 Internet Standard Subnetting Procedure
RFC-951 Bootstrap Protocol (BOOTP)
RFC-959 File Transfer Protocol (FTP)
RFC-966 Host Groups: A Multicast Extension to the Internet Protocol
RFC-974 Mail Routing and the Domain System
RFC-1000 The Request for Comments Reference Guide
RFC-1009 Requirements for Internet Gateways
RFC-1010 Assigned Numbers
RFC-1011 Official Internet Protocols
RFC-1012 Bibliography of Request for Comments 1 through 999
RFC-1034 Domain Names - Concepts and Facilities
RFC-1035 Domain Names - Implementation
RFC-1042 A Standard for the Transmission of IP
Datagrams over IEEE 802 Networks
RFC-1048 BOOTP Vendor Information Extensions
RFC-1058 Routing Information Protocol
RFC-1059 Network Time Protocol (NTP)
RFC-1065 Structure and Identification of
Management Information for TCP/IP-based internets
RFC-1066 Management Information Base for Network
Management of TCP/IP-based internets
RFC-1084 BOOTP Vendor Information Extensions
RFC-1087 Ethics and the Internet
RFC-1095 The Common Management Information
Services and Protocol over TCP/IP (CMOT)
RFC-1098 A Simple Network Management Protocol (SNMP)
RFC-1100 IAB Official Protocol Standards
RFC-1101 DNS Encoding of Network Names and Other Types
RFC-1112 Host Extensions for IP Multicasting
RFC-1117 Internet Numbers
Note: This list is a portion of a list of RFC's by topic that may be
retrieved from the NIC under NETINFO:RFC-SETS.TXT (anonymous FTP, of
course).
The following list is not necessary for connection to the Internet, but is useful in understanding the domain system, mail system, and gateways:
RFC-974 Mail Routing and the Domain System RFC-1009 Requirements for Internet Gateways RFC-1034 Domain Names - Concepts and Facilities RFC-1035 Domain Names - Implementation and Specification RFC-1101 DNS Encoding of Network Names and Other Types
Network Information Center (NIC) DDN Network Information Center SRI International, Room EJ291 333 Ravenswood Avenue Menlo Park, CA 94025 (800) 235-3155 or (415) 859-3695 NIC@NIC.DDN.MIL NSF Network Service Center (NNSC) NNSC BBN Systems and Technology Corporation 10 Moulton St. Cambridge, MA 02238 (617) 497-3400 NNSC@NNSC.NSF.NET NSF Network Information Service (NIS) NIS Merit Inc. University of Michigan 1075 Beal Avenue Ann Arbor, MI 48109 (313) 763-4897 INFO@NIS.NSF.NET CIC CSNET Coordination and Information Center Bolt Beranek and Newman Inc. 10 Moulton Street Cambridge, MA 02238 (617) 873-2777 INFO@SH.CS.NET
Ed Krol University of Illinois 195 DCL 1304 West Springfield Avenue Urbana, IL 61801-4399 Phone: (217) 333-7886 EMail: Krol@UXC.CSO.UIUC.EDU