A slow start to September

Saturday Oct 7th 2000 by Pete Loshin

It takes a couple of months to get back in gear after summer vacation--and the IETF is no exception.

IETF Corner

How much do you normally get done in the first two weeks after the end of summer vacation? If you're like the Internet Engineering Task Force (or at least the RFC Editor) this year, probably not a whole lot--a bare seven new RFCs were published (one a BCP), and just one IESG workgroup action and one proposed workgroup were announced. No document or protocol actions were taken, either; and precious few last calls, for that matter.

No matter. This time, we can look at the new RFCs in more detail. And we can anticipate a more active end to the month, as over a dozen document and protocol actions were announced on September 18 (I'll take a peek at the most interesting of them so you won't have to wait).

New RFCs

Table 1 lists the new RFCs announced between September 5 and September 17. Not only is the pace of RFC releases maddeningly slow, some of these are stragglers from August. Even though there are just seven, they include some important stuff, such as a new BCP about network congestion control principles and an Informational that reports on an IAB routing workshop held over two years ago. Read on to find out what it's all about.

Table 1: RFCs announced August 21-September 4, 2000

Newest best current practice

The Best Current Practice (BCP) series just gets better and better. These documents consistently deliver key information about core Internet practices, and the latest--BCP 41 (also known as RFC 2914), "Congestion Control Principles"--delivers an excellent foundation for anyone who wants to know more about congestion control in the Internet. This one is a must-read for anyone in the business of delivering packets over the Internet, as well as anyone whose business depends on getting those packets.

According to the abstract, "The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. One specific goal is to illustrate the dangers of neglecting to apply proper congestion control. A second goal is to discuss the role of the IETF in standardizing new congestion control protocols."

Author Sally Floyd, with the AT&T Center for Internet Research at ICSI (ACIRI), begins with an overview of current IETF standards covering congestion control, and continues with discussions of the development of end-to-end congestion control, the role of the standards process, description of congestion collapse, and forms of end-to-end congestion control. She concludes with a special section covering TCP congestion along with the obligatory (but in this case quite meaningful) security considerations.

Refreshing BGP and other routing news

Until this month, no mechanism would allow a BGP-4 router to dynamically request a BGP peer to readvertise its routes. With publication of RFC 2918, "Route Refresh Capability for BGP-4," this lack has been addressed with a new Proposed Standard.

RFC author Enke Chen of Redback Networks Inc. wrote a very short (three pages) document that describes the "Router Refresh Capability" for BGP so that (for example) routing policy changes can be effected without disrupting routing.

Perhaps more interesting and certainly more substantial is RFC 2902, "Overview of the 1998 IAB Routing Workshop." Though hardly breaking news, this Informational's authors include such Internet luminaries as Cisco's Stephen Deering and Sun's Radia Perlman, and it provides more than merely a two-year old workshop summary.

Attended by about 30 of the leading Internet routing experts, this workshop generated significant results that are directing much of the IETF's routing efforts. The RFC summarizes the discussions; but more important, it lists conclusions reached by the group and suggestions for future work. Some of the results will surprise you: For example, the very first conclusion reported is that "Most of the current unicast routing stability problems can be fixed with improved implementation."

If you want more details, check out the RFC itself and then take a look at the IAB Web site (www.iab.org) for the full report.

Brother, can you spare a MIME?

A pair of Proposed Standard RFCs about MIME (Multipurpose Internet Mail Extensions, just in case you were wondering) were released early in September. RFC 2912, "Indicating Media Features for MIME Content," and RFC 2913, "MIME Content Types in Media Feature Expressions," add new MIME header tools for specifying exactly what kind of data is contained in MIME messages.

Using the media features headers and content-types, applications can specify limitations or special features for one or all parts of a MIME message. For example, you can specify that a fax contained within a MIME enclosure be printed on an A4 size page of letterhead stationary, or you can specify all necessary parameters to properly decode a voice message encapsulated within a MIME enclosure.

More from MEGACO

Remember last time? A gaggle of Media Gateway Control (MEGACO) RFCs was announced; this time, a straggler comes in: "Proposal for an MGCP Advanced Audio Package," RFC 2897. This Informational is actually a proposal "to add a new event/signal package to the MGCP (Media Gateway Control Protocol) protocol to control an ARF (Audio Resource Function) which may reside on a Media Gateway or specialized Audio Server."

In other words, RFC 2897 outlines a mechanism for putting recordings on media gateways. According to the author, David Cromwell of Nortel Networks, an audio structure can be as simple as an announcement like, "Welcome to Bell South's Automated Directory Assistance Service." Or such structures can be quite complex sound bites "that are qualified by user defined selectors such as language, audio file format, gender, accent, customer, or voice talent." This RFC defines the parameters and events associated with a protocol that can deliver this kind of audio package.

Obligatory IPv6 RFC

Hardly does a fortnight go by without an RFC on IPv6. This time around, we see another Informational, RFC 2921, "6BONE pTLA and pNLA Formats (pTLA)."

Simply parsing the title tips off the bulk of the contents of this RFC: 6BONE is the experimental IPv6 backbone network established to help researchers and early implementers get some real-world experience with IPv6 networks. TLA is "Top-Level Aggregation Identifier," and a pTLA is a pseudo Top-Level Aggregation Identifier. An NLA is a Next-Level Aggregation Identifier, so of course a pNLA is a pseudo Next-Level Aggregation Identifier.

So, this RFC merely documents the way that 6BONE network addresses are allocated within the 3FFE::/16 IPv6 address prefix (allocated in RFC 2471, "IPv6 Testing Address Allocation," and how those addresses are organized to allow TLAs (read "upstream access providers") to aggregate NLAs' (read "smaller access providers") addresses.

Why "pseudo"? Because the 6BONE address allocation is experimental and does not draw from the actual production IPv6 address space. Anyone acting as a TLA on the 6BONE would still have to go get production address space before they could host any real-life production IPv6 networks.

Document, protocol, and working group actions

The news in working groups can be summed up in two acronyms: KINK and IPS. KINK, for "Kerberized Internet Negotiation of Keys," is now an active working group; and IPS, for "IP Storage," is currently a proposed working group.

The charter for the KINK working group calls for it to create a standards-track protocol that enables centralized key management for IPsec security associations (SAs). The idea is that KINK will provide an alternative for the Internet Key Exchange (IKE) protocol defined in RFC 2409, using the Kerberos architecture defined in RFC 1510 (among others). Kerberos does not depend on public key operations, and as such should be able to serve as the basis of a faster and easier protocol in support of IPsec.

The KINK working group mailing list archives are available online at http://www.vpnc.org/ietf-kink/. The site includes instructions for joining the list, as well.

The proposed IPS working group is interesting because it would help bring IP networking to the "infranet"--as storage area network vendors are starting to apply standard networking protocols to the communications within computers between the CPU and disk storage, important issues need to be addressed. I hope to report soon on the establishment of the IPS group.

What's next

As I wrote this column, IESG protocol and document announcements have been streaming across my e-mail inbox. In addition to some frost on the pumpkin in early October, I'll be writing about approval of Internet-Drafts about NFSv4, Label Distribution Protocol (LDP), TCP's retransmission timer, and mobile IP challenge/response extensions, among many others. //

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

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved