All About RFC
The Internet protocol suite is still evolving through the mechanism of Request for
Comments (RFC). New protocols (mostly application protocols) are being
designed and implemented by researchers, and are brought to the attention of
the Internet community in the form of an Internet draft (ID).1 The largest source
of IDs is the Internet Engineering Task Force (IETF), which is a subsidiary of the
IAB. However, anyone can submit a memo proposed as an ID to the RFC Editor.
There are a set of rules which RFC/ID authors must follow in order for an RFC to
be accepted. These rules are themselves described in an RFC (RFC 2223),
which also indicates how to submit a proposal for an RFC.
After an RFC has been published, all revisions and replacements are published
as new RFCs. A new RFC that revises or replaces an existing RFC is said to
“update” or to “obsolete” that RFC. The existing RFC is said to be “updated by” or
“obsoleted by” the new one. For example RFC 1542, which describes the
BOOTP protocol, is a “second edition,” being a revision of RFC 1532 and an
amendment to RFC 951. RFC 1542 is therefore labelled like this: “Obsoletes
RFC 1532; Updates RFC 951." Consequently, there is never any confusion over
Some of these protocols can be described as impractical at best. For instance, RFC 1149 (dated 1990 April 1) describes the transmission of IP datagrams by carrier pigeon and RFC 1437 (dated1993 April 1) describes the transmission of people by electronic mail.
Some RFCs are described as information documents, while others describe
Internet protocols. The Internet Architecture Board (IAB) maintains a list of the
RFCs that describe the protocol suite. Each of these is assigned a state and a
status.
An Internet protocol can have one of the following states:
Standard
The IAB has established this as an official protocol for the Internet. These are separated into two groups:
IP protocol and above, protocols that apply to the
whole Internet Network-specific protocols, generally specifications
of how to do IP on particular types of networks
Draft standard
The IAB is actively considering this protocol as a possible
standard protocol. Substantial and widespread testing
and comments are desired. Submit comments and test
results to the IAB. There is a possibility that changes will
be made in a draft protocol before it becomes a standard.
Proposed standard
These are protocol proposals that might be considered by
the IAB for standardization in the future. Implementations
and testing by several groups are desirable. Revision of
the protocol is likely.
Experimental
A system should not implement an experimental protocol
unless it is participating in the experiment and has
coordinated its use of the protocol with the developer of
the protocol.
Informational Protocols
developed by other standard organizations, or
vendors, or that are for other reasons outside the purview
of the IAB may be published as RFCs for the convenience
of the Internet community as informational protocols.
Such protocols might, in some cases, also be
recommended for use on the Internet by the IAB.
Historic
These are protocols that are unlikely to ever become
standards in the Internet either because they have been
superseded by later developments or due to lack of
interest.
Protocol status can be any of the following:
Required
A system must implement the required protocols.
Recommended A system should implement the recommended protocol.
Elective A system may or may not implement an elective protocol.
The general notion is that if you are going to do something
like this, you must do exactly this.
Limited use
These protocols are for use in limited circumstances. This
may be because of their experimental state, specialized
nature, limited functionality, or historic state.
Not recommended These protocols are not recommended for general use.
This may be because of their limited functionality,
specialized nature, or experimental or historic state.
Internet standards
Proposed standard, draft standard, and standard protocols are described as
being on the Internet Standards Track. When a protocol reaches the standard
state, it is assigned a standard (STD) number. The purpose of STD numbers is to
clearly indicate which RFCs describe Internet standards. STD numbers
reference multiple RFCs when the specification of a standard is spread across
multiple documents. Unlike RFCs, where the number refers to a specific
document, STD numbers do not change when a standard is updated. STD
numbers do not, however, have version numbers because all updates are made
through RFCs and the RFC numbers are unique. Therefore, to clearly specify
which version of a standard one is referring to, the standard number and all of
the RFCs that it includes should be stated. For instance, the Domain Name
System (DNS) is STD 13 and is described in RFCs 1034 and 1035. To reference
the standard, a form such as “STD-13/RFC1034/RFC1035” should be used.
For some Standards Track RFCs, the status category does not always contain
enough information to be useful. It is therefore supplemented, notably for routing
protocols, by an applicability statement, which is given either in STD 1 or in a
separate RFC.
The following Internet standards are of particular importance:
STD 1 – Internet Official Protocol Standards
This standard gives the state and status of each Internet protocol or standard
and defines the meanings attributed to each state or status. It is issued by the
IAB approximately quarterly. At the time of writing, this standard is in RFC
3700.
STD 2 – Assigned Internet Numbers
This standard lists currently assigned numbers and other protocol parameters
in the Internet protocol suite. It is issued by the Internet Assigned Numbers
Authority (IANA). The current edition at the time of writing is RFC 3232.
STD 3 – Host Requirements
This standard defines the requirements for Internet host software (often by
reference to the relevant RFCs). The standard comes in three parts:
– RFC 1122 – Requirements for Internet hosts – communications layer
– RFC 1123 – Requirements for Internet hosts – application and support
– RFC 2181 – Clarifications to the DNS Specification
STD 4 – Router Requirements
This standard defines the requirements for IPv4 Internet gateway (router)
software. It is defined in RFC 1812 – Requirements for IPv4 Routers.
A number of RFCs that are intended to be of wide interest to Internet users are
classified as For Your Information (FYI) documents. They frequently contain
introductory or other helpful information. Like STD numbers, an FYI number is
not changed when a revised RFC is issued. Unlike STDs, FYIs correspond to a
single RFC document. For example, FYI 4 - FYI on Questions and Answers -
Answers to Commonly asked “New Internet User” Questions, is currently in its
fifth edition. The RFC numbers are 1177, 1206, 1325 and 1594, and 2664.
Obtaining RFCs
RFC and ID documents are available publicly and online and best obtained from
the IETF Web site:
http://www.ietf.org
A complete list of current Internet Standards can be found in RFC 3700 – Internet
Official Protocol Standards.
