A slow start to September - Page 2

By Pete Loshin | Posted Oct 7, 2000
Page 2 of 2   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

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.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter