What’s an RFC and what can they do for me?

No matter what book or manual you use to study for the CCNA examination, you will see various protocols and processes referencing an RFC. And, although frequently referenced, the RFCs are seldom actually included in the documentation. So, the logical question becomes, “What is an RFC and where can I find them?”

In the computer network engineering and design realm, a Request for Comments (RFC) is a memorandum published by the Internet Engineering Task Force (IETF) describing methods, behaviors, research, or innovations applicable to the working of the Internet, along with Internet-connected systems.

Through the organization known as the Internet Society, designers, engineers, and computer scientists can publish papers or discourses in the form of an RFC, either for peer review or simply to share new concepts, information, or (occasionally) engineering humor. Peer review is an important process of subjecting your work, research, or personal ideas to the scrutiny of others who are usually considered to be experts in the same field. The IETF will then adopt some of the proposals published as RFCs as “Internet Standards.”

The beginning of the RFC format and process occurred in 1969 as part of the original ARPANET project, which was a wide-area experimental network connecting hosts and terminal servers together. Procedures were set up to regulate the allocation of addresses, and to create voluntary standards for the network. The authors of the first RFCs actually used typewriters to create their work and passed hard copies among the ARPA researchers.

Unlike the modern RFCs, many of the early RFCs were actual requests for comments. The RFC left questions open and was written in a less formal style. This less formal style is now typical of Internet Draft documents, the precursor step before being approved as an RFC.

The RFCs turned out to provide a convenient, useful vehicle for documentation and distribution of the research performed by the developers of the Internet, and ended up becoming the official record of the Internet’s design decisions, architecture, and technical standards. Although they remained named “Request For Comments,” by consensus they are the Internet documents of record, and often include very detailed technical information.

Now, working groups of the IETF do most of the work on standardization of Internet protocols as they go through proposed standard, draft standard, and actual standard phases. A protocol published as a proposed standard is usually intended to become an actual standard, but is not promoted to draft standard for at least six months, to allow time for the Internet community to review and comment. A draft standard is not promoted to full standard for at least four months, after operational experience has been obtained, and when there is demonstrated interoperability between two or more independent implementations

There are a wide range of official Internet protocol standards. Fortunately, there is a complete list of official standards documented in the Request for Comments documents, with a recent version at RFC 3300 and an up-to-date list maintained at RFC-Editor. The first RFC explicitly declared an official standard was RFC 733. The official protocol standards are listed in the following categories:

  • Standard – Established as a standard protocol by the IESG.
  • Draft – On track, likely a future standard protocol.
  • Proposed – Early stage, proposed protocol.
  • Historic – Older protocols, usually superseded or unused.
  • Experimental – Research protocols, documented to provide a convenient reference for researchers.

The sixth type, Informational are protocols that were developed by other organizations, such as official standards organizations and commercial network companies. These were sometimes published as RFC’s to provide a standard reference for the IETF. The latest list of information protocols can be found in RFC 2500.

The RFC Editor assigns each RFC a unique serial number. Once assigned a number and published, an RFC is never rescinded or modified. If the document requires amendments, the authors publish a revised document. Therefore, some RFCs supersede others. The superseded RFCs are said to be deprecated, obsolete, or even obsoleted [sic]. Together, the serialized RFCs compose a continuous historical record of the evolution of Internet standards and practices.

The RFC production process differs from the standardization process of formal standards organizations such as the International Standards Organization (ISO). Internet technology experts may submit an Internet Draft without support from an external institution.

Standards-track RFCs are published with approval from the IETF, and are usually produced by experts participating in working groups, which first publish an Internet Draft. This approach facilitates initial rounds of peer review before documents mature into RFCs.

Each protocol is assigned a status of “Required,” “Recommended,” “Elective,” “Limited Use,” or “Not Recommended,” in descending order of priority. Only a very few essential protocols are ever labeled “Required,”

The official source for RFCs on the World Wide Web is the RFC Editor. One may retrieve almost any individual, published RFC (RFC 5000 for instance) via URL in the form of: http://www.rfc-editor.org/rfc/rfc5000.txt

And, finally, almost every April Fool’s Day (1 April) since 1989, the IETF has published one or more satirical or humorous RFC documents. These special offerings follow the tradition of the June 1973 RFC entitled ARPAWOCKY, which parodied Lewis Carroll’s nonsense poem Jabberwocky.

Author: David Stahl

In this article

Join the Conversation