Internet Standards: RFC Protocols

All about Internet Standards

Some of the solutions that researchers and developers have come up with since 1969 to do interoperable internetworking have been quite clever, some of them have been pretty simple. All of them that are considered to be Internet standards are published in a series of documents called Request for Comments or RFCs. Though these are the most “famous” Internet documents, they are far from the only ones.

The first and possibly most important thing to remember about Internet standards is that while all Internet standards are documented in RFCs, not all RFCs document Internet standards. Only a relative few RFCs document actual Internet standards; many of the rest document specifications that are on the standards track, meaning they are at some point in the process that takes a specification and turns it into a standard. Non-standard, non-standards track RFCs may be published for information purposes only, or may document experimental protocols, or may simply be termed historical documents because their contents are now deemed obsolete (this is the RFC “state” which we’ll come back to later).

Internet Documents

There are several important published document series related to Internet standards and practices. They include:

RFCs

These are Requests for Comments, and are an archival document series. RFCs never change. They are intended to be always available, though RFC status can change over time as a specification moves from being a proposed standard to a draft standard to an Internet standard to an historical RFC.

STDs

The STD (for “standard”) series of documents represents Internet standards. A particular STD may consist of one or more RFCs that define how a particular thing must be done to be considered an Internet standard. An STD may consist of a single document, which is the same as some single RFC. However, the STD number stays the same if that RFC is deprecated and replaced by a newer RFC, but the document to which the STD points changes to the newer RFC.

FYIs

This series consists of “for your information” documents. According to RFC 1150, “F.Y.I. Introduction to the F.Y.I. Notes”, the series is designed to give Internet users information about Internet topics, including answers to frequently asked questions and explanations of why things are the way they are on the Internet.

BCPs

The Best Current Practices series are defined in RFC 1818, “Best Current Practices”, which says that BCP documents describe current practices for the Internet community. They provide a conduit through which the IETF can distribute information that has the “IETF stamp of approval” on it but that does not have to go through the arduous process of becoming a standard. BCPs may also cover meta-issues, such as describing the process by which standards are created (see below or RFC 2026for more on the Internet standards process).

Others

There are a bunch of different documents that, over time, have been treated with more or less respect. This includes RTRs (RARE Technical Reports), IENs (Internet Engineering Notes), and others. We won’t be covering these, as they rarely come up in discussions of current issues. Also, while the STD, FYI, and BCP document series contain RFCs, these other documents are not necessarily RFCs.

RFCs and Internet-Drafts

Some readers may wonder why Internet-Drafts (I-Ds) are not included in the list above with all the rest, but I-Ds are quite distinct from RFCs. For one thing, anyone can write and submit an I-D; RFCs are published (from I-Ds) only after an I-D has been through a sequence of edits and comments. For another thing, I-Ds expire six months from the time they are published. They are considered works in progress, and each one is supposed to state explicitly that the document must not be cited by other works. Where the RFC series is archival, I-Ds are ephemeral working documents that expire if no one is interested enough in them to move them forward through the standards process.

This is a critical distinction. Networking product vendors often claim that their product, protocol, service, or technology has been given some kind of certification by the IETF because they have submitted an I-D. Nothing could be further from the truth (though even publication as an RFC may mean little if it is published as an Informational RFC).

I-Ds become RFCs only after stringent review by the appropriate body (as we’ll see in Part 4). Some more differences:

• RFCs are numbered, I-Ds are not (they are given filenames, by which they are usually referenced). RFC numbers never change. RFC 822will always be the specification for Internet message format, written in 1982. If substantial errors are found in an RFC, a new RFC may have to be written, submitted, and approved; you can’t just go back and make edits to an RFC.
• RFCs are given a “state” or maturity level (where they are on the standards track, or some other indicator) as well as a “status” that indicates a protocol’s status as far as requirements level. We’ll come back to these topics in the next section. I-Ds, on the other hand, are just I-Ds. The authors may make suggestions about what kind of RFC the draft should eventually become, but if nothing happens after six months, the I-D just expires and is supposed to simply vanish.
• RFCs are usually the product of IETF working groups, though I-Ds can come from anywhere and anyone.

RFCs States and Status Levels

RFCs can have a state, meaning what kind of an RFC it is; and a status, meaning whether or not the protocol specified in the RFC should be implemented (or how it should be implemented). Valid RFC states include:

RFC States

Standard Protocol: These are Internet Standards with a capital “S”, which means that the IESG has approved it as a standard. If you are going to do what the protocol in the RFC does, you have to do it the way the RFC says to do it. Very few RFCs represent full Internet Standards.

Draft Standard Protocol: Draft standards are usually already widely implemented, and are under active consideration by the IESG for approval. A draft standard is quite likely to eventually become an Internet Standard, but is also likely to require some modification (based on feedback from implementers as well as from the standards bodies) and the authors are supposed to be prepared to deal with that (by making the changes that have to be made).

Proposed Standard Protocol: Proposed standards are being proposed for consideration by the IETF in the future. A proposed standard protocol must be implemented and deployed, so it can be tested and evaluated, to be given proposed standard state. Proposed standards almost always get revised (sometimes revised significantly) before advancing along the standards track.

Experimental Protocol: Experimental RFCs describe protocols that are not intended for general use, and that are, well, considered experimental. In other words, don’t try this at home.

Informational Protocol: Informational RFCs are often published without the intention of putting the protocol on the standards track, but rather because they provide useful information for the Internet community. For example, the Network File System (NFS) protocol was published as an Informational so that implementers other than Sun Microsystems could build NFS clients and servers.

Historical Protocol: Though most of the other designations are included in first page of the RFC, an RFC that was once on the standards track can be redefined as historical if the protocol is no longer relevant, was never accepted, or was proved flawed in some way.

RFC Status Levels

The status of a particular protocol relates to how necessary it is to implement. The status levels include:

Required Protocol: A required protocol must be implemented on all systems.

Recommended Protocol: All systems should implement a recommended protocol, and should probably have a very good reason not to implement it if they don’t. It’s not really optional, but it’s not entirely required either.

Elective Protocol: A system may choose to implement an elective protocol. But if it does implement the protocol, the system has to implement it exactly as defined in the specification.

Limited Use Protocol: Probably not a good idea to implement this type of protocol, because it is either experimental, limited in scope or function, or no longer relevant.

Not Recommended Protocol: Not recommended for general use. In other words, there’s probably no good reason for you to implement this protocol.

Turning I-Ds into Standards

You can’t tell the players without a scorecard, and there are a number of different players in the Internet standards game. Before you can truly understand how the process works, it helps to know who is involved.

It might be nice if there were a nice, orderly org chart that laid out the different entities involved in the standards process. On the other hand, the standards process is an organic, human one that sometimes, over the years, adapts to market or political forces. The figure gives an idea of the entities involved.

Internet Society (ISOC)

ISOC is the umbrella organization to all Internet standard activity. Positioned as the professional organization for the Internet and TCP/IP networking, ISOC sponsors conferences, newsletters, and other activities pertaining to the Internet.

Internet Architecture Board (IAB)

The IAB was first formed in 1983, when it was known as the Internet Activities Board, and then reconstituted as a component of ISOC, the Internet Architecture Board, in 1992. Its early history is documented in RFC 1160 and its current charter in RFC 1601. The IAB chooses the steering groups’ members and provides oversight to the Internet standards process, publishes RFCs and assigns Internet-related numbers.

Internet Engineering Task Force (IETF)

Though often portrayed as a very formal entity, the IETF consists of anyone who shows up (either in person or by mailing list) and participates in IETF activities. IETF activities are organized by areas (active IETF areasare listed at the IETF website), and within each area are more focused working groups. Each area has one or two area directors, and each working group has one or two chairs as well as an area advisor; these individuals guide the work of the groups.

Internet Engineering Steering Group (IESG)

The IESG consists of the IETF area directors and the IETF chair, and this is the body that has final say over whether a specification or protocol becomes a standard or not.

Internet Corporation for Assigned Names and Numbers (ICANN)

ICANN is the controversial new entity with shaky finances that was formed last year to take over the functions of the RFC Editor and the Internet Assigned Numbers Authority (IANA). Both those functions had previously been carried out by the late Jon Postel, whose untimely death highlighted the need for a new structure to handle the publication of RFCs as well as maintaining lists of protocol and address numbers that have been assigned or reserved for all the different mechanisms, specifications, and protocols defined by the IETF.

The Internet Research Task Force (IRTF) and Internet Research Steering Group (IRSG) fulfill similar functions for long-term planning and research, but the IRTF is not generally an open organization as the IETF is, and these two entities have less immediate impact on Internet issues, so they generally perform their functions in the background.

RFC 2026, “The Internet Standards Process – Revision 3,” documents the process by which the Internet community standardizes processes and protocols. On its face, the process is simple: a group or individual submits their draft for publication as an Internet-Draft. This is the first step. At this point, the document is publicly posted on the Internet and a notification of its publication is posted to the IETF-announce mailing list (IETF mailing lists are archived at the IETF website). Most I-Ds don’t progress beyond this point.

Assuming that there is enough interest in the draft to generate discussion, the authors may be called upon to incorporate edits. Once there is consensus among those who are working on the draft (usually work is done in working groups, much of the work taking place in the context of the working group mailing list), a “Last Call” will be issued for further comments on the draft. Any further comments may be incorporated into the draft after the Last Call period (usually some number of weeks), at which point the draft can be submitted to the IESG for approval and publication as an RFC.

Of course, the draft may be published as an experimental or informational RFC; but if it makes it onto the standards track, it starts out as Proposed Standard. Over time, the specification may advance along the standards track (depending on whether it is accepted by the community and implemented, how well it works, and whether or not something better comes along).

A standards track specification may need to go through a revision process as it progresses. Thus, the same specification may be rewritten several times over a period of years before it becomes an Internet standard. There are only about 50 full Internet standards; most of the protocols that we take for granted as being “standards,” including HTTP, DHCP, MIME, and many others, are actually either Proposed Standards or Draft Standards. Lynn Wheeler maintains a web page that lists all current RFCs along with their status. It is an interesting and instructive list.

Few people really understand the distinctions between different types of Internet standard (and non-standard) documents-not so much because the concepts are so complicated but rather because they are relatively obscure. And networking vendors often misrepresent standards activities when they announce them. Armed with the information in this article, you can easily determine whether the latest and greatest protocol just released by Novell, Microsoft, or Cisco is actually a new Internet standard or just documented in yet another Internet-Draft.

Finding RFCs

The IETF publication mechanism does not provide the best interface or search engine for locating RFCs. However, it should be considered canonical. This list is not comprehensive, as there are probably scores if not hundreds of websites and FTP servers serving some or all RFCs. However, these are good places to go to when you need to locate a particular RFC or to find out more about what might be in an RFC or I-D.

• Internet Standards Archive. This is a good easy site, and they’ve got good search facilities for RFCs and I-Ds. A good “go-to” site for RFCs.
• Lynn Wheeler’s RFC Index. This is another excellent resource if you’re trying to figure out what’s current, what is a standard, and what is not.
• The NORMOS Standards Repository. Another good site, it has particularly good search capabilities; very flexible. It also returns all the hits (unlike the Internet Standards Archive above).
• Invisible Worlds RFC Land. This seems to be a pretty cool site. Carl Malamud and others had a neat idea about XML-tagging RFCs. There’s a lot of graphics and very involved programming underneath the website, so I’d like it better if it were simpler without all that stuff, and they still need to finish the XML-ification (at least, that’s how it seems), but this site is recommended as well.
• The RFC Editor Page. This is the official place, and there’s lots of good information here as well.
• The RFC Editor’s Search through the RFC Database Page. This used to be nothing more than a simple listing, but has become virtually overnight one of the best resources on the web for RFCs. It is canonical, and you can download the whole RFC database from here too.

Pete Loshin (pete@loshin.com) began using the Internet as a TCP/IP networking engineer in 1988, and began writing about it in 1994. He runs the website Internet-Standard.com where you can find out more about Internet standards.