IETF—History, Background, and Role in Today's Internet
Gary C. Kessler
Hill Associates, Inc.
kumquat@hill.com
1 February 1996
Copyright Gary Kessler. All Rights Reserved.
It is often said that the
Internet is one of the best success stories of anarchy or, even,
socialism in modern history. The Internet has proven itself to be
an example of cooperation between countries, (often-competing)
commercial entities, government agencies, and educational
institutions for the sole purpose of enhancing communication. Yet
even this loose cooperative requires some central administrative
authority for such things as operational guidelines, protocol
specifications, and address assignment.
The key to the success of
communication over the Internet is the use of a standard set of
protocols, based on TCP/IP. The Internet Engineering Task Force (IETF)
is the group that oversees the Internet standards process. This
chapter will focus on the history of the IETF, its organization
and function, and, in particular, its role in developing Internet
security specifications.
The Evolving Administration of
the Internet
The Internet began as a project
funded by the U.S. Department of Defense (DoD), as an experiment
in the use of packet switching technology. Starting with only four
nodes in 1969, the ARPANET spanned the continental U.S. by 1975
and was reaching to other continents by the end of the 1970s.
In 1979, the Internet Control and
Configuration Board (ICCB) was formed. The charter of the ICCB was
to provide an oversight function for the design and deployment of
protocols within the connected Internet.
In 1983, the ICCB was renamed as
the Internet Activities Board (IAB). With an original charter
similar to that of the ICCB, the IAB evolved into a full-fledged de
facto standards organization dedicated to ratifying standards
used within the Internet. The Chairman of the IAB was called the
Internet Architect. That individual's major function was to
coordinate the activities of numerous task forces within the IAB,
each of which focused on a specific architectural or protocol
issue.
In 1984, the ARPANET was split
into two components: the ARPANET, used for research and
development, and MILNET, used to carry unclassified military
traffic. With this division, designation of TCP/IP as the official
protocol suite, and subsequent National Science Foundation (NSF)
funding, the modern Internet was born.
In 1986, the IAB was reorganized
to provide an oversight function for a number of subsidiary
groups. The Internet Research Task Force (IRTF) was put into place
to oversee research activities related to the TCP/IP protocol
suite and the architecture of the Internet. The activities of the
IRTF are coordinated by the Internet Research Steering Group (IRSG).
The IETF was formed to concentrate on short-to-medium term
engineering issues related to the Internet.
The U.S. Internet has
historically received funding from government agencies, such as
the DoD, Department of Energy, NASA, and the NSF. By the end of
the 1980s, it became apparent that this funding would decrease
over time. In addition, the introduction of commercial users and
an increasing number of commercial Internet service providers
foreshadowed the loss of a dominate central administration which,
in turn, threatened the long-term process for making Internet
standards.
In January 1992, the Internet
Society (ISOC) was formed with a charter of providing an
institutional home for the IETF and the Internet standards
process. ISOC provides a number of services in support of this
role including sponsoring conferences and workshops, and raising
funds from industry, government, and other sources. Although
headquartered in the U.S., the ISOC is an international
organization providing administrative support for the
international Internet. Included in this administrative structure
is the IAB, IETF, IRTF, and the Internet Assigned Number Authority
(IANA)1.
To reflect its new role as a part
of ISOC, the Internet Activities Board was renamed the Internet
Architecture Board in June 1992. ISOC provides support for the
IETF and IRTF, as they have historically been a part of the IAB.
The relationship between ISOC and
the IETF has changed slightly each year as they both determine
exactly what that relationship should be. In June 1995, the ISOC
Board of Trustees confirmed that their main goal remains to
"keep the Internet going." It is still committed to
providing services that facilitate the standards process as
carried out by the IETF.
IETF Overview and Charter
The IETF provides a forum for
working groups to coordinate technical developments of new
protocols. Its most important function is the development and
selection of standards within the Internet protocol suite.
When the IETF was formed in 1986,
it was a forum for technical coordination by contractors for the
U.S. Defense Advanced Projects Agency (DARPA) working on the
ARPANET, Defense Data Network (DDN), and Internet core gateway
system. Since that time, the IETF has grown into a large open
international community of network designers, operators, vendors,
and researchers concerned with the evolution of the Internet
architecture and the smooth operation of the Internet.
The IETF mission includes:
- Identifying, and proposing
solutions to, operational and technical problems in the
Internet.
- Specifying the development or
usage of protocols and the near-term architecture to solve
technical problems for the Internet.
- Facilitating technology
transfer from the IRTF to the wider Internet community.
- Providing a forum for the
exchange of relevant information within the Internet community
between vendors, users, researchers, agency contractors, and
network managers.
Figure 1 shows the general
hierarchy of the IETF. Technical activity on any specific topic in
the IETF is addressed within working groups, which are organized
roughly by function into nine areas. Each area is led by one or
more Area Directors who have primary responsibility for that one
aspect of IETF activity. Together with the Chair of the IETF,
these technical directors compose the Internet Engineering
Steering Group (IESG).
----------------
| Internet |
| Architecture |
| Board |
-------+--------
|
----------+-------------
| Internet Engineering |
| Steering Group |
----------+-------------
|
------------------+---------------------
| |
---+---- ---+----
| Area | o o o o o | Area |
---+---- ---+----
| |
----------+---------- ----------+----------
| | | | | |
----+---- ----+---- ----+---- ----+---- ----+---- ----+----
|Working| |Working| |Working| |Working| |Working| |Working|
| Group | | Group | | Group | | Group | | Group | | Group |
--------- --------- --------- --------- --------- ---------
FIGURE 1. IETF Organization.
The IAB is a technical advisory
group of the Internet Society. Its responsibilities include:
- IESG Selection: The IAB
appoints a new IETF Chair and all other IESG candidates, from
a list provided by the IETF Nominating Committee.
- Architectural Oversight:
The IAB provides oversight of the architecture for the
protocols and procedures used by the Internet.
- Standards Process Oversight
and Appeal: The IAB provides oversight of the process used
to create Internet Standards. The IAB serves as an appeal
board for complaints of improper execution of the standards
process.
- RFC Series and IANA:
The IAB is responsible for editorial management and
publication of the Request for Comments (RFC) document series
and for administration of the various Internet assigned
numbers.
- External Liaison: The
IAB acts as representative of the interests of the Internet
Society in liaison relationships with other organizations
concerned with standards and other technical and
organizational issues relevant to the world-wide Internet.
- Advice to ISOC: The IAB
acts as a source of advice and guidance to the Board of
Trustees and Officers of the Internet Society concerning
technical, architectural, procedural, and (where appropriate)
policy matters pertaining to the Internet and its enabling
technologies.
IETF Structure and Internet
Standards Process
The IETF provides a central focus
for technical aspects of the Internet. The work is undertaken by a
number of functional areas within the IETF that have general
responsibilities and the areas are comprised of individual working
groups (WGs) with specific tasks (Figure 2).
-------------------------------------
|Internet Engineering Steering Group|
-----------------+-------------------
|
----------+--------+--------+--------+---------+-------+--------+--------
| | | | | | | | |
------+------- | ------+------ | ------+------- | -----+------ | -----+------
|Applications| | | IP: Next | | |Operational | | | Security | | | User |
| Area (app) | | |Generation | | |Requiremnets| | |Area (sec)| | | Services |
-------------- | |Area (ipng)| | | Area (ops) | | ------------ | |Area (usv)|
| ------------- | -------------- | | ------------
| | | |
-----+------ -----+------ -----+------ -----+------
| Internet | | Network | | Routing | |Transport |
|Area (int)| |Management| |Area (rtg)| |Area (tsv)|
------------ |Area (mgt)| ------------ ------------
------------
FIGURE 2. Internet Engineering Steering Group and IETF Areas
The WGs form the backbone of the
IETF. In general, each WG is formed with a relatively narrow focus
rather than looking at large problems. Furthermore, the WGs
usually start with, or quickly define, a limited number of options
with which to achieve their goals. When formed, each WG defines a
charter with a specific set of goals and milestones. In addition,
each WG maintains an Internet electronic mail discussion list and
an on-line archive.
The working groups conduct
business during IETF plenary meetings, meetings outside of the
IETF, and via electronic mail. The IETF holds week-long plenary
sessions three times a year. These meetings include working group
sessions, technical presentations, network status reports, working
group reports, and an open IESG meeting. Proceedings of each IETF
plenary are published, which include reports from each area, each
working group, and each technical presentation, as well as a
summary of all current standardization activities. Meeting
reports, working group charters and mailing list information, and
general information on current IETF activities are available
on-line via anonymous FTP and the World Wide Web (WWW).
Unlike most other
"standards" groups, the plenary sessions and proceedings
are not the only place where important work is accomplished and
documented. In fact, most final decisions are made via e-mail or,
at the very least, circulated by e-mail. One reason for this
apparent looseness is that WG meetings and discussions are open to
anyone within the Internet community (which includes just about
everyone) with something to contribute.
In another departure from other
"standards" groups, the IETF WGs do not require
unanimity before progressing with work. Furthermore, only proven
and working protocols become standards. One of the guiding forces
of the Working Groups is the IETF Credo, attributed to David
Clark:
We reject kings, presidents,
and voting.
We believe in rough consensus and running code.
The effect of this principle is
that there is no formal voting within the WGs. Instead, disputes
are resolved by discussion and demonstrations of working models.
These discussions take place at the plenaries and on the
discussion lists.
The result of the WG activities
is the publication of various Internet documents. The IETF
publishes two types of documentation:
- Internet-Drafts (ID)
are working documents, and referred to as a "work in
progress." IDs have no official status and expire after 6
months; they are not archived beyond their expiration date.
The IETF Secretariat distributes the announcement for new
Internet-Drafts.
- Request for Comments
are the literature of the Internet. In particular, they are
the series of documents that provide an historical record of
the IAB. RFCs are edited, assigned a number, and announced by
the RFC Editor.
There are four categories of RFC:
- Historic
refers to an RFC that is important for historic purposes, but
is unlikely to become (or remain) an Internet standard either
due to lack of interest or because it has been superseded by
later work. Examples include the Common Management Information
Services over TCP/IP (CMOT) specification (RFC 1189) and the
Border Gateway Protocol version 3 (BGP-3; RFCs 1267 and 1268).
- Experimental
refers to an RFC describing experimental work related to the
Internet and not a part of an operational service offering.
Examples (as of November 1995) are the Stream Protocol Version
2 (ST2; RFC 1819)and UNARP (RFC 1868).
- Informational
refers to RFCs that provide general, historical, and tutorial
information for the Internet community; these are usually
produced by a standards organization or other group or
individual outside of the IESG. Examples are the Novell IPX
Over Various WAN Media (IPXWAN) specification (RFC 1634) and A
Primer on Internet and TCP/IP Tools (RFC 1739).
- Standards Track
refers to RFCs that are intended to become Internet standards.
There are three classes of
Standards Track RFCs:
- A Proposed Standard is
a complete, credible specification that has a demonstrated
utility for use on the Internet. A Proposed Standard has an
expiration date from between 6 months and 2 years of the
publication date, by which time it must be elevated to a
higher status, updated, or withdrawn.
- A Draft Standard is
written only after there have been several independent,
interoperable implementations of a specification. Draft
Standards usually reflect some limited operational experience,
but enough knowledge that the specification seems to work
well. A Draft Standard has an expiration date from between 4
months and 2 years of the publication date, by which time it
must be moved to a different status, updated, or withdrawn.
Examples (as of November 1995) are the HyperText Markup
Language (HTML) version 2 (RFC 1866) and Relative Uniform
Resource Locators (URLs; RFC 1808).
- An Internet Standard is
"the real thing" and refers to specifications with
demonstrated operational stability; examples are IP (RFC 791;
also known as STD 5) and TCP (RFC 793; also known as STD 7).
An RFC can stay as a Standard forever or may be reclassified
as Historic.
Contacting the Internet
Society and IETF
References
RFC
1601: Charter of the
Internet Architecture Board (IAB)
RFC
1602: The Internet
Standards Process -- Revision 2
RFC
1603: IETF Working Group
Guidelines and Procedures
Footnotes
- The
IANA is responsible for the assignment and central management
of IP addresses, domain names, protocol numbers, RFC numbers,
and other addresses and numbers relevant to the Internet. (Back
to main text)
|
