IETF RFC documents


RFCs tend to be accurate and straightforward, although they can be dry reading. Different people have different tolerances: Most people would probably consider most of the reading to be very dry. RFCs also may assume some familiarity with the subject.

These are published by the “RFC Editor”, as noted by RFC Editor's Instructions to authors.

Not all are standards: RFC Editor's FAQ: Allstds

RFC Sub-Series

An RFC may be part of a “sub-series”. These may help to identify some of the more important RFC documents.

An entry in one of these series may contain more than one RFC document (e.g. STD 13: DNS has contained both RFC 1034 (DNS concepts) and RFC 1035 (DNS implementation), and BCP 79 has contained RFC 3979 and 4879). However, the text in these STDs is simply the text of the RFC documents. (There may be small modification, at least on the Tools IETF site, such as prepnding (meaning: adding to the beginning) a brief statement pointing out when a displayed STD or BCP document contains more than one RFC.)

[#ietfstd]: IETF STD

The term “STD”, when referring to an IETF document, is an abbrevation for “Standard”. (Granted, “standard” is usually abbreviated as “std.” or “Std.”, while “STD” in all capital letters generally refers to “sexually transmitted disease”. However, when referring to an IETF STD, the term “STD” officially means “Standard”. More specifically, this refers to one of IETF's standards.)

The term STD identifies an official Internet Standard. The full list of IETF STDs contains some of the most important Internet standards. For instance, the first baker's dozen contains information on how Internet hosts communicate, and important protocols like IPv4 (STD 5), ICMP for IPv4 (also part of STD 5), UDP (STD 6), TCP (STD 7), the historically significant FTP (STD 9), SMTP (E-Mail, STD 10), and DNS (STD 13).

RFC 1311: Introduction to the STD Notes is a source of official documentation.

STD1 (e.g. RFC5000) refers to http://www.rfc-editor.org/rfcxx00.html (Official Internet Protocol Standards). (Like many URLs, the “www.” portion of that name is optional, though redirection indicates it is canonical, meaning that it seems to be officially preferred by whoever runs the site)). Additional lists are at: See RFC Editor's STD Index or IETF's STD list.

Perhaps see: BCP9 : The Internet Standards Process, STD 1: Internet Official Protocol Standards.

Basically, an IETF STD has the behavior of a pointer. It points. The actual contents being pointed to may change. The IETF STD points at the latest version of one RFC document, or more than one RFC document. If a newer RFC marks an older RFC as obsolete, the IETF STD (which is a pointer) can be updated to point at the newer RFC instead of older RFC(s). So, unlike the contents of any actual RFC file, an IETF STD is allowed to change. The concept/topic of an IETF STD, however, is not anticipated to change.

The IETF STD documents tend to refer to processes that describe how machines operate, such as protocols.

[#ietfbcp]: BCP

The term “BCP” stands for “Best Current Practice”.

RFC BCP's index or IETF's BCP list. Note that BCP can contain more than one RFC (e.g. BCP79 has contained RFC 3979 and 4879).

(The following paragraph intentionally sounds very similar to the discussion about IETF STD.)

Basically, an IETF BCP has the behavior of a pointer. It points. The actual contents being pointed to may change. The IETF BCP points at the latest version of one RFC document, or more than one RFC document. If a newer RFC marks an older RFC as obsolete, the IETF BCP (which is a pointer) can be updated to point at the newer RFC instead of older RFC(s). So, unlike the contents of any actual RFC file, an IETF BCP is allowed to change. The concept/topic of an IETF BCP, however, is not anticipated to change.

An example of a BCP that has changed is BCP 153: “Special Use IPv4 Addresses”. At one time, it pointed at RFC 3330. Later, it pointed at RFC 5735. Later, it also pointed at RFC 6598.

When compared to the IETF documents, the BCP documents will tend to reflect processes such as methods of setting up a network. As an example, address reservations are covered by the BCP list.


Unlike the IETF STD series and the IETF BCP series, this series is not anticipated to have additional documents added in the future. This is documented by RFC 6360: Conclusion of FYI RFC Sub-Series. The reasons for discontinuing are not extremely abundantly clear: it appears that marking RFCs as FYI may have just been deemed a task with high overhead/work and little useful benefit. The last sentence of section 2 does note that the action isn't necessarily meant to be permanent. (Instead, the notice was likely just made to clearly communicate current practice, and to make sure that nobody creates undesired overhead (by surprising people) by trying to make a new FYI based on prior documented procedures.)

The list of documents that were marked as FYI are shown by: RFC Editor's FYI Index.

The FYI documents do not tend to be quite as demanding as, say, an IETF STD which should be adhered to (so that compatability may work). Instead, these documents were simply informational documents which the authors believed may be helpful. Actions that are contrary to what is stated in an FYI document, if done with care by a person knowledgeable about the situation, might commonly not be bad at all. These RFCs are not meant to be directions, or even standards; just information.

[#getrfc]: Retrieving

STD 1 (RFC 5000: “Internet Official Protocol Standards” Section 2: “RFC Resources and Retrieval” states “The RFC Editor maintains the official repository of all RFCs and indexes to them. The site also provides additional information” at http://www.rfc-editor.org.

RFC Editor home page notes “Funded by the Internet Society to edit and publish RFCs online. The RFC Editor maintains the master repository of RFCs as well as RFC meta-data”.

So, who exactly is the RFC Editor? At one point, a single person fulfilled the role of the RFC Editor. His name was Jon Postel. He stopped performing the role because, well, he died. (It does seem consistent that people who do that end up stopping any help they actively provide with Internet administration.) His death was noted by: RFC 2468: I Remember IANA. (This RFC refers to Jon as if he, himself, rather than any group of people, was the Internet “Assigned Numbers” Authority.) RFC Editor FAQ (about who is the RFC Editor) says the RFC Editor is now a group.

RFC Editor's RFC Database hyperlinks to RFC Index (in numeric order) and RFC Index (in reverse numeric order) and other lists. RFC Editor's list of RFC Repositories is a fairly small list. Surely others provide this information as well.

RFCs can also be searched based on their official Status Category: See RFC Editor: RFCs by Number within Status Category

[#rfcrules]: Rules of RFCs
Never updated

e.g. RFC 791 (IPv4) page 12 says “relibility”. That is a spelling error. However, despite clearly being an error, it will not be fixed.

RFC Editor FAQ on updating an RFC states, “Once an RFC is published, it cannot be changed. The RFCs form an archival series.” Once updates were allowed, but it has since been decided to not permit this. That way, there aren't multiple versions of an RFC, which could complicate things. Now, any time anyone refers to an RFC, there is not likely to be confusion regarding which version is being referred to. (The small number of older exceptions are likely to be so old that the problem doesn't tend to come up frequently.)

An an example, RFC 1718: “The Tao of IETF”: “A Guide for New Attendees of the Internet Engineering Task Force” has a section called “On-line Availability”, which contains a URL that is no longer valid. That RFC has been obsoleted, and eventually got moved; the latest version is now hosted on the IETF website. (“The Tao of IETF”, now hosted on the IETF website)

So people checking out the URL in that RFC document might not find the desired document. However, the URL in that RFC will not change. That RFC will not change.


BCP78 (Rights Contributors Provide to the IETF Trust) and BCP79: Intellectual Property Rights in IETF Technology. In summary: the technology in RFC documents is often donated to the IETF Trust and/or Internet Society. These organizations allow free re-distribution (and, presumably, implementation) of the technical documents. RFC Editor FAQ on Copyright says “All RFCs may be freely reproduced and translated (unmodified).”

[#rfcformt]: RFC Format

RFC 2223 section 3 indicates that the allowed formats are ASCII and PostScript. (PostScript allows graphics, and PostScript is the basis of the more well-known format called Portable Document Format (PDF)).

That PostScript option may be a bit old... RFC Editor FAQ: Question about having a document “enhanced” with images (which, at the time of this writing, is the second-to-the-last question on the page) notes, “After an RFC has been published, there is an option of posting a PDF with images; it contains the exact text of the RFC with diagrams added.”

RFC 2223 page 2 states, “RFCs have been traditionally published and continue to be published in ASCII text.” The document goes on to state that some common “practices are not yet practical with PostScript files.” “PostScript producing systems are less standard than is desirable and that several of the document production systems that claim to produce PostScript actually produce nonstandard results.” The recommendation of using PostScript as a secondary format may be updated by RFC Editor's Instructions to Author (a.k.a. draft-rfc-editor-rfc2223bis-08.txt : Internet Draft: RFC Editor (RFC 2223) Latest Revision (Revision 8)). For instance, Internet Draft: RFC Editor (RFC 2223) Revision 8, page 9 which refers to “The primacy of” ASCII.

Specifically, the Instructions to Authors section 2.4 (which is found on RFC Editor's Instructions to Authors Page 9) provides some brief reasons why ASCII text is preferred.

The fact that ASCII has become the preferred format sometimes leads to “ASCII art”, including:


Examples include: RFC 793 (TCP) section 3.1, RFC 791 (IPv4) section 3.1, RFC 2460 (IPv6) section 3

In each of these cases, the hyphens (“-”) represent columns that correspond to one bit, and the furthest left and right pipe (“|”) characters represent groups of 32-bits. The specific amount of 32-bits is not mandatory (but has often been sensible since IPv4 addresses are 32-bits in length), but many times tables are shown with spaces being proportional to the number of bits in each table field.

e.g. RFC 1034 (DNS concepts and facilities) section 3.4 (“Example name space”)) and other diagrams (RFC 1035 (DNS implementation/specification) page 6 which shows a 3D box. This document uses a capital A for an up arrow, rather than another obvious choice of a carot (^). RFC 5620: section 3 does use the carot character. Another example is RFC 793 (TCP) section 2.5, which is similar to RFC 791 (IPv4) section 2.1.
Other diagrams
e.g. the flowchart with RFC 793 (TCP) page 23

Such text, which is used to “graphically” present information, would often not look good with a proportional font, so mono-spaced is recommended for viewing at least some of the RFCs.

Other formatting rules, like the 72-character line width, are shown by RFC 2223 page 5. RFC 5741 may also discuss some general expectations, such as RFC 5741 section 3.1: “The Title Page Header” which shows what is expected to appear at the top of an RFC's text.

Key words
BCP14: Key words for use in RFCs to Indicate Requirement Levels discusses some requirement levels that are traditionally spelled out in all capital letters.
[#mkrfc]: Creating RFCs

Various references are provided in the section about the format of RFC files.

Some additional information for people interested in being an RFC author may be found at The “tao” (“way”) of the Internet: section 6.3.1 (section called “Recommended Reading for Writers”).

The “tao” (“way”) of the Internet: section called “RFCs and Internet Drafts”

Familiarity with existing standards are recommended, such as IETF BCP 22: Guide for Internet Standards Writers, and IETF BCP 26: Guidelines for Writing an IANA Considerations Section in RFCs, and IETF BCP 72: Guidelines for Writing RFC Text on Security Considerations, and some of the other documents that have been referenced (such as those related to intellectual property ownership).

Misc info

66 of the first 1,000 RFC numbers were RFC numbers that were never issued, and then 11 more numbers over the next 2,500 numbers were RFC numbers that were never issued.

There is another series of documents: IEN, which stands for “Internet Experimental Note”. For instance, RFC 791 (IPv4) section 2.4 cites reference number seven in that document, which is IEN 109. IEN are documents that pre-date at least most of the RFC documents. They are available at: IETF IEN documents (and, similar to RFC documents, are available via FTP at ftp://ftp.ietf.org/rfc/ien ). A listing of them may be at: Geoff Huston's potaroo.net : IEN list.