The RFCs selected for this list were chosen in a highly subjective and arbitrary fashion. Note, for example, that entire topics— such as the Simple Network Management Protocol (SNMP) and the Post Office Protocol (POP3)—have been omitted. Clearly, some topics had to be left out. Otherwise, this appendix would have been a rewrite of the index itself. RFCs that would help you build a solid technical foundation, as well as the RFCs that explained the inner workings of the Internet standards bodies, are included.
Note
Consult the RFC index for the latest versions of these RFCs before you start studying those listed here. These numbers become outdated very quickly.
This RFC provides a history of the major events that shaped the Internet into what it is today.
This RFC covers some of the processes involved in creating RFCs. It also explains some of the terms found in RFCs and their usage. This is a "must read" for anyone involved in supporting IP networks.
This name is pretty self-explanatory. RFC 2151 is an introduction to some of the fundamental tools and utilities available. Traceroute, PING, Finger, and others are covered. This is another "must read."
This RFC clarifies the current interpretation of the IP V4 32-bit IP address space. It also provides some background on IP V6.
This RFC explains the relationship between the IETF and the Internet Society.
This is pretty much what it says it is—an explanation of the organizations involved in the IETF standards process.
Again, this is pretty self-explanatory; it's an introduction to the process of selecting members for, and managing the membership of, the IAB and IESG.
This is another RFC that explains RFC processes and other background information.
This RFC discusses some of the older policies for allocating IP address space. It suggests ways they can be changed to reflect the Internet changes that have occurred since they were originally drafted.
An informational RFC discussing the Internet and what it means to different people and organizations.
This is a humorous RFC about life and networking.
This RFC discusses the current status of RIP V1 (RFC 1058) and some of its limitations. Anyone running a network with RIP V1 should read this.
This RFC provides background on the allocation of IP addresses for private Internets. It also provides implementation guidelines for companies that want to implement IP but do not want full connectivity to the Internet. This is a "must read" for anyone involved in supporting an IP network.
This RFC discusses the limited amount of IP addresses available for allocation. It also explains how companies that have addresses they no longer require can return them.
This is a useful table of the various subnets that can be derived from the 32-bit IP address space.
This RFC explains some of the functions that routers must perform when routing IP V4. This is a "must read" for anyone involved in supporting an IP network that uses routers.
This RFC explains the function of IP address translation and some of the requirements that must be met by a device implementing NAT. This is a "must read" for anyone involved in supporting an IP network that uses NAT when accessing the Internet.
This is pretty self-explanatory; it is the charter of the IAB. Useful reading for anyone interested in the function of the IAB.
Similar to RFC 2151 in intent but not in content. This is more focused on information-finding tools, such as Gopher, WAIS, and USENET. This is a "must read" for anyone using the Internet to find or disseminate information.
This RFC provides background on the Traceroute utility. It also suggests some enhancements. This is useful reading for those responsible for troubleshooting IP network problems.
This RFC explains IRDP and discusses how IP systems can use it to find and use IP gateways (routers) off of their local network. Some third-party TCP/IP stacks for Windows 95 and Windows NT support IRDP. SUN Solaris 2.5 does as well. Those exploring how to enable hosts to use multiple local gateways should read this.
This RFC is a solid introduction to the TCP/IP protocol suite. It discusses the multiplexing of various applications over TCP and UDP. It also explains some related applications, such as Telnet and FTP. This is a "must read" for anybody just getting started in implementing an IP-based network. Experienced IP support engineers may find some new information as well.
This RFC covers some of the pitfalls of using inappropriate computer names and suggests some naming strategies.
This is another humorous RFC.
This is "the" RFC for RIP V1. It is a "must read" for supporters of IP networks with routers because this is where it all started.
This is the RFC on ARP. This is a "must read" for those involved in supporting IP networks.
This RFC contains references to the registered numbers that are assigned for various functions—such as TCP Port numbers for applications such as Telnet (23). Those involved in internetworking to any degree should be familiar with the material contained in this RFC.
This RFC explains how certain TCP/IP configuration parameters, such as IP addresses, default gateways, and DNS servers, are passed from servers to workstations while the workstations are booting up. This allows network administrators to centralize the administration of this information. BOOTP has been superseded by the Dynamic Host Configuration Protocol (DHCP), which is referenced later in this appendix.
BGP4 is the latest version of this protocol. It specifies how routing information is passed between autonomous systems. Autonomous systems are groups of networks (which are typically very large) under the control of a single organization or a group of cooperating organizations. Internet Service Providers (ISPs) that control the backbone of the Internet typically have their own autonomous systems. ISPs use BGP to link these autonomous systems to other ISPs' autonomous systems.
For more information on this subject, see Internet Routing Architectures by Bassam Halabi, published by Cisco Press (ISBN 1-56205-652-2).
CIDR replaces the standard network masks applied to classes of IP addresses. For example, instead of using a mask such as 255.255.0.0 for network 171.68.0.0, a mask of 255.0.0.0 could be applied. This would shorten the prefix of 171.68.0.0 to 171.0.0.0. If all of the networks that have 171 as their first octet were under the control of a single autonomous system, the autonomous system managers could limit their advertisements to other autonomous systems to an 8-bit prefix.
Instead of sending 16-bit prefixes, such as 171.1.0.0, 171.2.0.0, 171.2.0.0, and 171.253.0.0, to an adjacent autonomous system, the manager can just send 171.0.0.0. Because there are 254 possible 16-bit prefixes starting with 171.0.0.0, advertising can be saved on up to 253 networks (you still have to advertise 171.0.0.0), depending on how many of the available 171.0.0.0 networks are actually assigned.
The application of CIDR in the Internet has greatly reduced the numbers or routes (networks) that need to be advertised between and within autonomous systems.
This RFC explains how certain TCP/IP configuration parameters, such as IP addresses, default gateways, and DNS servers, are passed from servers to workstations while the workstations are booting up. This allows network administrators to centralize the administration of this information. DHCP supersedes BOOTP, which was referenced previously.
This is the application that allows IP hosts to be referenced by names instead of explicit IP addresses. For instance, instead of entering c:ftp 192.31.7.130 to start a Windows FTP session to Cisco's FTP site, you can enter c:ftp ftp.cisco.com.
If your PC's DNS server(s) is configured properly, your PC sends a DNS query to its DNS server(s) (it can have more than one in case one fails) requesting the IP address associated with the system name ftp.cisco.com. After the reply is received, the FTP application uses the IP address it contains (192.31.7.130) to establish an FTP session.
These are the latest RFCs containing information on OSPF. OSPF is an open (not proprietary) standard. It is what is commonly known as an Interior Gateway Protocol (IGP). IGPs are typically used within autonomous systems. IGP was created to overcome some of the significant limitations of the Routing Information Protocol V1 (RIP), such as lack of VLSM support and lack of discontiguous network support.
These protocols perform the opposite function of the Address Resolution Protocol (ARP). ARP maps layer three IP addresses to layer two MAC addresses. RARP, on the other hand, maps layer two MAC addresses to layer three IP addresses.
RIP V1 was one of the original IP routing protocols. RIP V2, which is now available on many TCP/IP systems, overcomes some of the significant limitations of RIPV1, such as lack of VLSM support and lack of discontiguous network support. The RIP V1 protocol specification (RFC 1058) is provided in the previous section. The other RFCs refer to RIP V2 and other RIP enhancements.
These informational RFCs explain the concept of renumbering IP networks and indicate when this may be necessary.
TCP is the connection-oriented transport layer protocol in the TCP/IP protocol suite. It has flow control and error correction built in. It is used by TCP/IP applications, such as Telnet and FTP.
The TCP Slow Start algorithm forces a new TCP session to assume there is congestion on the network. This results in using a smaller packet size, a smaller window size (number of outstanding, unacknowledged packets), and a longer timeout (how long TCP will wait for acknowledgments before assuming a packet has been lost).
After the session is established, TCP starts increasing the packet size and the window size, while decreasing the timeout period. When TCP determines that the maximum values have been reached (the timeout period starts to expire for some packets), it reduces the packet sizes and the window, while increasing the timeout period. However, these numbers are not immediately dropped to their original Slow Start values.
This RFC has valuable information on many tools and techniques for troubleshooting TCP/IP networking problems.