RFC's (Requests For Comments)

RFC's Describe the Internet and it's Supported Technologies.
All RFC's are Internet-related !!!

- these RFC tables are Grouped by "Maturity Levels" (explained below). They include all RFC's that pertain to the "Official Internet Protocol Standards" - they DO NOT contain Informational RFC's (FYI's) because those RFC's are not Standards-related. <a href="yourpage.htm#yourbookmark">

"Thirty years ago today, the first Request for Comments document, RFC 1, was published at UCLA (ftp://ftp.isi.edu/in-notes/rfc1.txt). This was the first of a series that currently contains more than 2500 documents on computer networking, collected, archived, and edited by Jon Postel for 28 years. Jon has left us, but this 30th anniversary tribute to the RFC series is assembled in grateful admiration for his massive contribution . . . "

That is the first paragraph of RFC number 2555. RFC2555 describes the 30-year history of RFC's.

RFC's are the most ubiquitous set of telecom and engineering standards in the world - because the Internet has become the primary technology in the world !!! Virtually all telecom concepts are described by RFC's.

RFC's are Text documents - unfortunately, all RFC's are in ASCII text format only, and this has had a negative impact. People understand graphics better than text, and many people refuse to read long, complex text files. This is the main reason why so many actually "fear" reading RFC's - they view it as a tedious task. Some people have created PDF's of the RFC's but they are still text-based files, with no graphics. Even diagrams, which some RFC's have, are done in ASCII. They were done in text because at that time many computers had no graphics capabilities.

Are RFC's Difficult Reading?? Actually, most RFC's are written in a direct, easy-to-understand (for Techs and engineers, that is) format. They are dry reading to be sure . . . but they explain most concepts better than the many volumes of books that have been written on the subjects. In addition, they explain the true standard, instead of giving you someone else's version of the technology.

Why the odd Name, "Request For Comments" ?? yes it does seem strange that a "request for comments" could ever be viewed as a "standard". The name implies, that all they are doing is asking for some input from the industry on a particular technical topic. Well actually, the name is VERY misleading, because an RFC can, and often is - a standard - and NOT a request. In fact:

AN RFC IS NEVER A REQUEST FOR COMMENTS - at least, not in the literal sense !!!

RFC's are managed by the IETF (Internet Engineering Task Force - www.ietf.org ), and they are nothing more than a series of notes about the Internet and the many technologes that revolve arounf it. The forst RFC's began in in 1969 (when the Internet was the ARPANET). An Internet Document can be submitted to the IETF by anyone, but the IETF decides if the document becomes an RFC. Eventually, if it gains enough interest, it may evolve into an Internet standard.
Each RFC is designated by an RFC number. Once published, an RFC never changes.

Modifications to an original RFC are assigned a new RFC number. These mods have caused many RFC's to be "obsoleted" or "updated", by a more recent RFC that provides more details or changes the RFC altogether. That RFC, in turn, may be obsoleted or updated by another - forming a chain.

The RFC Process - the "Standards Track" and the 7 "Maturity Levels" (the 7 types of RFC's)

First off - before anything can become an RFC, it must fist be proposed as an "Internet Draft". Then if it is approved and becomes an actual RFC, the the following path is adhered to. This path is called the "Standards Track", and consists of three "Standards Maturity Levels". However, not all RFC's are standards - there are four "Non-standards Maturity Levels":

Type	Number	Title	Author or Ed.	Date	Format	More Info (Obs&Upd)	Status
PS	RFC4002	IANA Registration for Enumservice 'web' and 'ft'	R. Brandner, L. Conroy, R. Stastny	February 2005	ASCII		PROPOSED STANDARD
DS	RFC2863	The Interfaces Group MIB	K. McCloghrie, F. Kastenholz	June 2000	ASCII	Obsoletes RFC2233	DRAFT STANDARD
STD	RFC1870 STD0010	SMTP Service Extension for Message Size Declaration	J. Klensin, N. Freed, K. Moore	November 1995	ASCII	Obsoletes RFC1653	STANDARD
BCP	RFC2050 BCP0012	Internet Registry IP Allocation Guidelines	K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel	November 1996	ASCII	Obsoletes RFC1466	BEST CURRENT PRACTICE
INF* and FYI*	FYI0006 RFC1198	FYI on the X window system	R.W. Scheifler	Jan-01-1991	ASCII		INFORMATIONAL [pub as:FYI]
INF* only	RFC3429	Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions	H. Ohta	November 2002	ASCII		INFORMATIONAL
EXP*	RFC3940	Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol	B. Adamson, C. Bormann, M. Handley, J. Macker	November 2004	ASCII		EXPERIMENTAL
HIST*	RFC2341	Cisco Layer Two Forwarding (Protocol) L2F	A. Valencia, M. Littlewood, T. Kolar	May 1998	ASCII		HISTORIC

* the IETF does not use the acronyms INF, EXP, and HIST - but are used on this website for clarity, since all the other RFC types have acronyms

Both BCP's and FYI's are also RFC's !!! Each has their own number, and each has an RFC number. For example, if you look at BCP 0001 (BCP 1) you will see that it is RFC1818.

The FYI series of notes is designed to provide Internet users with a central repository of information about any topics which relate to the Internet. FYIs topics may range from historical memos on "Why it was was done this way" to answers to commonly asked operational questions. Every FYI is actually an RFC with it's own RFC number, and it's own corresponding FYI number. For example, the FYI that describes FYI's is FYI 0001 (also called FYI 1) , and it is stored as RFC1150. (RFC1150 = FYI 1)

The IETF created a process where first an author must submit a document called an "Internet Draft", which is then scrutinized by the technical community. If accepted, it then becomes an official "RFC" - which may be a standard, or may be simply an "Informational Document".

Documents placed in the Internet-Drafts directories have a maximum life of six months. After that time, they must be updated, or they will be deleted. After a document becomes an RFC, it will be replaced in the Internet-Drafts Directories with an announcement to that effect. See RFC3667 and RFC3668 for more information. Internet-Drafts are generally in the format of an RFC, although they are expected to be rough drafts.

During the development of a specification, draft versions of the document are made available for informal review and comment by placing them in the IETF's "Internet-Drafts" directory, which is replicated on a number of Internet hosts. This makes an evolving working document readily available to a wide audience, facilitating the process of review and revision.

Removal of Internet Drafts - an Internet-Draft that is published as an RFC, or that has remained unchanged in the Internet-Drafts directory for more than six months without being recommended by the IESG for publication as an RFC, is simply removed from the Internet-Drafts directory. At any time, an Internet-Draft may be replaced by a more recent version of the same specification, restarting the six-month timeout period.

How an Internet Draft becomes an RFC - after being reviewed, if recommended by the IESG for publication as an RFC - then the draft becomes an RFC

When reading RFC's - if it has graphics created from the text, make sure you have the font set to a fixed-width style (most font's are variable-width). You can use Courier New or the older "fixed-sys". For example, viewing RFC791's description of IP headers in a fixed-width font (Courier New) vs a variable-width font (Times New Roman):

Most rfc sources on the web simply pull up the text file (all RFC's are text files) and that's it. RFC's (Request For Comments) are free and there are many sources to view any RFC. There are also several search engines that let you search through all the RFC's for any text string.

But the RFC Editor search engine blows away all the rest, because it is sponsored by the group that manages all RFC's - the IETF: http://www.rfc-editor.org/rfcsearch.html

BOOKMARK that SITE !!! It lets you search for any RFC number, or for any text string or topic. It then lists the RFC number, the Title, the Author, the Status (Proposed Standard, Informational, etc), and whether or not the RFC has been "obsoleted" by another, and if so it provides the new RFC number and a link to it.

For example, if you want the RFC's that describe MPLS, and type that term into the search field, a total of 33 matches show up !! Here are the first few to show you the format of the listings - the most recent are at the top:

As with all standards, the concepts are refined and changed as time passes. These changes are "mods" (modifications) that only list the text that has changed, been added, or deleted.

Errata - plural for erratum - an error in printing or writing, which is typically noted in a list of corrections. Errata are short updates, that do not require an entire RFC update document with a new number. This is useful for small errors or omissions in the original RFC that need to be clarified. An erratum is an update, but it is a very small update. Conversely, a standard RFC update is given it's own reference number.

Using the RFC Editor search engine - the "More Info" column will show two things: a list of all RFC's that this one "Updates" (and those updates RFC are then considered obsolete), and the RFC number that "Obsoletes" this one. The RFC search engine lists that information in the column marked "More Info (Obs&Upd)".

IMPORTANT: new RFC's list any RFC's that they have Obsoleted or Updated. However, the old RFC will not list this information, since at the time it was created, there was no way to know that it would be obsoleted - and the RFC's are NEVER EDITED after they are completed !!!

Before you waste a lot of time reading/studying an RFC, you must know whether or not it has been obsoleted or updated !!! And since the old RFC will not tell you - you ABSOLUTELY need to check first to see - this is why the RFC Search Engine at http://www.rfc-editor.org/rfcsearch.html is so important - it gives you that crucial piece of info !!

Here are a few listings from the RFC search engine as an example - if you click on an RFC in Column 1 (Number), it will open the RFC in your browser. If your click on an RFC in column 6 (More Info), it will move that RFC to column 1 and show you a new row with the info on that RFC. If there is a chain of updated RFC's, just keep clicking on the next updated RFC in column 6 until you get to the last and final update. Some RFC's have been updated several times:

And here is the actual text at the top of RFC2460, which tell the reader that it "obsoletes RFC1883":

Standards Ordered by STD	Standards Ordered by RFC
Draft Standards
Proposed Standards
Experimental
Historic
Best Current Practice by BCP	Best Current Practice by RFC

Number	Title	Author or Ed.	Date	Format	More Info (Obs&Upd)	Status
RFC3919	Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS)	E. Stephan, J. Palet	October 2004	ASCII		INFORMATIONAL
RFC3815	Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)	J. Cucchiara, H. Sjostrand, J. Luciani	June 2004	ASCII		PROPOSED STANDARD
RFC3814	Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)	T. Nadeau, C. Srinivasan, A. Viswanathan	June 2004	ASCII		PROPOSED STANDARD
" "	" "	" "	" "	" "	" "	" "

Number	Title	Author or Ed.	Date	Format	More Info (Obs&Upd)	Status
RFC3468	The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols	L. Andersson, G. Swallow	February 2003	ASCII	Updates RFC3212, RFC3472, RFC3475, RFC3476	INFORMATIONAL
RFC3473	Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions	L. Berger, Ed.	January 2003	ASCII	Updated by RFC4003 Errata	PROPOSED STANDARD
RFC1883	Internet Protocol, Version 6 (IPv6) Specification	S. Deering, R. Hinden	December 1995	ASCII	Obsoleted by RFC2460	PROPOSED STANDARD
RFC2460	Internet Protocol, Version 6 (IPv6) Specification	S. Deering, R. Hinden	December 1998	ASCII	Obsoletes RFC1883	DRAFT STANDARD