Laboring on Labor Day

Pete Loshin - IETF Corner

For the past couple of months, I’ve spent every other Sunday putting together this column: reading RFCs and Internet-Drafts, and putting together lists. This time around I had my Sunday off, but to pay for it I’m staying in on this rainy, cool Labor Day to write about RFCs. Which worked out pretty well, overall.

A full baker’s dozen of new RFCs and ten protocol and document actions were announced in the past two weeks, so clearly things are starting to get busy again. Announcements included some truly significant new RFCs, including a new version of STD-1, “Internet Official Protocol Standards,” RFC 2700, and a new FYI (FYI 37), “Guide to Administrative Procedures of the Internet Infrastructure,” (RFC 2901).

And there were some interesting IESG actions announced, including one new BCP, “IANA Charset Registration Procedures,” which replaces BCP 19 (RFC 2278), of the same name. Also approved was a document from the Internet Architecture Board (IAB), “Next Steps for the IP QoS Architecture,” elaborating on the future of Quality of Service (QoS) architectures.

New RFCs

Table 1 lists the new RFCs announced between August 21 and September 4; the big news is the update to STD-1. Not that it changes much: “Internet Official Protocol Standards” is not much more than a series of lists.

Table 1: RFCs Announced Aug. 21-Sept. 4, 2000

But if you’re into Internet protocols, it’s a good document to print out and keep handy. It lists all the full Internet Standard protocol RFCs, followed by Draft Standards, Proposed Standards, Experimentals, Informationals, and Historic Protocols. Each new or changed listing gets an asterisk, so you don’t need to flip back and forth between the previous version of this document (RFC 2600) to know what’s new.

The other important new RFCs come in a couple of clusters. First, the Megaco RFC 2885, “Megaco Protocol 0.8,” and RFC 2886, “Megaco Errata,” are both listed as Proposed Standards and they should actually be read as one document (unless you’re willing to wait for the anticipated rewrite of the Megaco Protocol document that will incorporate the errata).

Controlling media gateways

What’s Megaco, you may well ask. It stands for “Media Gateway Control” and is a working group in the Transport Area of the IETF. A media gateway is a network element that converts data carried over telephone circuits into data carried over IP networks (like the Internet), and vice versa. For example, a media gateway can link users of Voice over IP (VoIP) transmissions with users of the traditional telephone network.

These media gateways need to be controlled somehow, and that’s where media gateway controllers (MGCs) come in. The Megaco Protocol defines how control messages are passed to media gateways so as to correctly handle telephone services including call setup, maintenance, and termination.

Megaco is deeply connected with telephony protocols, and the RFC itself is “common text” with the ITU-T H.248 specification; though this specification has great significance for IP telephony, it can be heavy slogging for anyone without at least some telephony experience.

AAA authorization, mostly

The Authentication, Authorization and Accounting (AAA) working group focuses on issues of allowing authorized and authenticated users access to network resources while preventing unauthorized access; and at the same time, keeping track of who is using what. These new RFCs don’t come from the AAA working group but rather from the AAA Architecture (AAAarch) Research Group of the Internet Research Task Force (IRTF).

The IRTF serves as a clearinghouse for research rather than actual engineering related to the Internet, and is intended to generate future directions for the Internet. Four new RFCs written by the AAAarch Research Group have just been published; one Experimental and three Informationals.

The concept of a generic AAA architecture, one that can use standardized AAA servers to interface with specific applications, is still experimental. Interaction between disparate networks and services in terms of authorization, authentication, and accounting is mired in proprietary and custom applications. RFC 2903, “Generic AAA Architecture,” proposes an architecture under which such standardized AAA servers would be able to authenticate users, handle authorization requests, and collect accounting data and interface with application specific modules (ASMs), which would manage that data for each specific application.

RFC 2903 draws on work done by AAAarch and documented in the three new Informationals. RFC 2904, “AAA Authorization Framework,” builds a foundation for authorization in an Internet network, starting with a discussion of authorization entities and trust relationships. Other topics covered in this document include authorization messages and the sequences in which they are exchanged, authorization policies, using X.509 certificates to store authorization information, and managing authorization sessions and resources.

RFC 2905, “AAA Authorization Application Examples,” gives some concrete examples of applications that can use AAA authorization tools: everything from PPP dial-up to e-commerce and distance learning. RFC 2906, “AAA Authorization Requirements,” lays out a set of protocol requirements, including definition of authorization information, securing that information, application topologies, proxying, building trust models, and much more.

The AAA Authentication specification isn’t even that, at least not yet, but these documents will shape the future development of the specification.

For your information

A new FYI was just announced, FYI 37, “Guide to Administrative Procedures of the Internet Infrastructure.” This is an important document, especially if you’re getting ready to put your network on the global Internet (as opposed to getting Internet access for individuals or small offices through a single IP address), but it will help anyone who wants to better understand the issues of Internet connectivity.

FYI 37 explains what must be done to get your network on the Internet: how to determine your organization’s type and status and assess your administrative and technical contacts. The document also covers considerations when budgeting for the connection (and how to charge back internally for services), how to choose a carrier, and much more.

Document, protocol, and working group actions

Some interesting IESG actions were announced in the past couple of weeks, including a new BCP document. “IANA Charset Registration Procedures.” It replaces RFC 2278 of the same name, though with relatively little modification.

Of greater interest are some new Informationals: “Differentiated Services and Tunnels,” for example, explores how diffserv interacts with IP tunnels. And “Next Steps for the IP QoS Architecture” comes out of discussions of the future of Quality of Service (QoS) in the Internet by the Internet Architecture Board (IAB).

Another important RFC-to-be, “Behavior of and Requirements for Internet Firewalls” lays down some behaviors expected of Internet firewalls and some requirements for interoperability, with the objective of making firewalls behave more consistently and “in line with accepted IP protocol practices.”

Table 2: IESG protocol and document actions, Aug. 21- Sept. 4, 2000

What’s next

With Labor Day 2000 behind us and school, work, or both in front of us, we should be seeing more new RFCs and more document and protocol actions announced. If you’re into planning ahead, mark your calendar for IETF 49, coming up in San Diego and scheduled for December 10-15, 2000. More information about registration should be available at after Columbus Day. //

Pete Loshin has been writing about IP networking since 1988, including 20 books about networking, the Internet, and Internet standards. The founder of, Pete frequently consults on Internet protocol issues.

Latest Articles

Follow Us On Social Media

Explore More