RFCs: The Internet Standards Process
Anyone studying the Internet, or developing applications for it, must understand the RFC system. RFC stands for Request For Comments. These are the documents that define the Internet Protocol Suite (the official name for TCP/IP) and many related topics. Anyone can submit an RFC. Ones that are part of the Standards Track are usually produced by IETF (Internet Engineering Task Force) working groups. Anyone can start or participate in a working group. Submitted RFCs begin life as a series of Internet Drafts, each of which has a lifespan of six months or less. Most drafts go through considerable peer review, and possibly quite a few revisions, before they are approved, are issued an official RFC number (e.g. 793) and become part of the official RFC collection. There are other kinds of documents in addition to the Standards Track, including information memos (FYI), humor (primarily ones issued on April 1) and even one obituary, for Jon Postel, the first RFC Editor and initial allocator of IP addresses, RFC 2468, “I Remember IANA”, October 1998. There is even an RFC about RFCs, RFC 2026, “The Internet Standards Process, Revision 3”, October 1996. That is a good place to start if you really want to learn how to read them.
The Internet standards process is quite different from the standards process of ISO (The International Standards Organization) that created the Open System Interconnect (OSI) network specification. ISO typically develops large, complex standards with multiple 4 year cycles, with hundreds of engineers and much political wrangling. This was adequate for creating the standards for the worldwide telephony system, but is far too slow and hidebound for something as freewheeling and rapidly evolving as the Internet. The unique standards process of the IETF is one of the main reasons that TCP/IP is now the dominant networking standard worldwide. By the time OSI was specified, TCP/IP was already created, deployed, and being revised and expanded. OSI never knew what hit it.
Learning to read RFCs is an acquired skill, one that anyone serious about understanding the Internet, and most developers creating things for it, should master. There are certain “terms of art” (terms that have precise and very specific meanings), like the usage of MUST, SHOULD, MAY and NOT RECOMMENDED. As an example, the IPv6 Ready Silver (Phase 1) tests examine only the MUST (mandatory) items from relevant RFCs, but the IPv6 Ready Gold (Phase 2) tests also examine all of the SHOULD (optional) items.
RFCs are readily available to anyone for free. Compare this to the ISO standards, which can cost over $1000 for a complete set of “fascicles” for something like X.500. Today you can obtain RFCs easily in various formats by use of a search engine such as Google or Yahoo. The “official” source is the URL:
(where XXXX is the RFC number)
There is also an official RFC search page, where you can search for phrases (like “TCP”) in different tracks, such as RFC, STD, BCP or FYI, or all tracks. You can retrieve the ASCII or PDF versions. It is at:
There are over 8,000 RFCs today. I have included many references to the relevant RFCs in this book. If you want to see all the gory details on any subject, go right to the source and read it. You may find it somewhat tough going until you learn to read “RFC-ese”. A number of books on Internet technology are either just a collection of RFCs, or RFCs make up a large part of the content. There is no reason today to do that – anyone can download all the RFCs you want, and have them in soft (searchable) form. I have not included the text of even a single RFC in this book (warning – if you try to read this book somewhere without Internet access like on a plane, you may want to look ahead and download any relevant RFCs while you have Internet access). The casual reader should not need to reference the actual RFCs. The complete set of RFCs is probably tens of thousands of pages, and growing daily.
Most of the topics covered in this book also have considerable coverage on the Internet outside of the RFCs, such as in Wikipedia. Again, if you want to drill deeper in any of these topics, crank up your favorite search engine and have at it. The information is out there. What I’ve done is to try to collect together the essential information in a logical sequence, with a lot of explanations and examples, plus all the references you need to drill as deep as you like. I taught cryptography and Public Key Infrastructure for VeriSign for two years, so I have a lot of experience trying to explain complex technical concepts in ways that reasonably intelligent people can easily follow. Hopefully you will find my efforts worthwhile.