In Like a Lamb, Out Like a Lion

IETF Corner

The first half of September may have been pretty slow in terms of IESG actions, but the last half saw publication of quite a few new RFCs, as well as quite a flurry of protocol and document action announcements.

The new crop is a very mixed bag, with topics as diverse as MPLS VPNs, DNS security issues, three different multicast topics, a new Internet Standard SMTP extension, phone numbers and DNS, several MIME RFCs, and yes, yet another IPv6 Informational.

Perhaps more notable was the publication of RFC 2799, “Request for Comments Summary RFC Numbers 2700-2799.” Every hundred RFCs this type of summary document is released, containing brief descriptions of the previous 99 RFCs in the series. Though RFC 2798 was published half a year ago, the summary RFCs are held back until all the RFC numbers in the series are released–the hold-up was publication of RFC 2700, just this past August. Though notable, RFC 2799 is of relatively little significance, because it is an Informational–and because it doesn’t really describe any protocol.

New RFCs

Table 1 lists the new RFCs announced between September 18 and October 1. There were quite a few new ones in the past two weeks–18 in all, which is quite a few when compared to the meager crop from the first half of the month. In addition, the IESG announced approval of 20 new documents as RFCs (see Table 2).

Table 1: RFCs Announced September 18 through October 1, 2000

A Multiplicity of Multicast Documents

The trio of multicast RFCs released, 2907 through 2909, covers a range of issues with various RFC types: RFC 2907, “MADCAP Multicast Scope Nesting State Option,” is a Proposed Standard; RFC 2908, “The Internet Multicast Address Allocation Architecture,” is an Informational; and RFC 2909, “The Multicast Address-Set Claim (MASC) Protocol,” is an Experimental.

It’s best to start with the Informational in this triplet, “The Internet Multicast Address Allocation Architecture.” RFC 2908 describes a proposed architecture for handling the way multicast addresses are allocated with the Internet. The approach taken is similar to that taken by the Dynamic Host Configuration Protocol (DHCP) to allocate unicast addresses (although it is not similar enough to share any significant protocol specifications).

RFC 2908 divides the architecture into three layers; it starts with Layer 1, at which individual clients are able to request multicast addresses from multicast address allocation servers (MAASs). At Layer 2, the MAASs coordinate with each other and with “Prefix Coordinators” within their own domains (intra-domain) to make sure that the MAASs have unique ranges of multicast addresses to allocate to their clients. Finally, at Layer 3, Prefix Coordinators can coordinate the allocation of multicast addresses across domains (inter-domain).

Going next to the Proposed Standard, RFC 2907, “MADCAP Multicast Scope Nesting State Option,” we see an example of a modification to one of the leading mechanisms for allocating multicast addresses at Layer 1. Multicast Address Dynamic Client Allocation Protocol (MADCAP) defines such a mechanism; RFC 2907 defines an option by which MADCAP clients can “learn not only which scopes exist via the existing ‘Multicast Scope List’ option,” but “also how these scopes nest inside each other.” As a result, clients can “make better scope selections for a given session” and can also “construct hierarchies of administratively scoped zones.” With those hierarchies, the clients can “perform expanding scope searches instead of the expanding ring or increasing-TTL searches.”

Finally, the Experimental RFC 2909: “The Multicast Address-Set Claim (MASC) Protocol.” MASC defines a mechanism for exchanging information about multicast address allocations across domains–at Layer 3 of the architecture described in RFC 2908.

The DNS Collection

Late September’s newest BCP, RFC 2929, “Domain Name System (DNS) IANA Considerations,” is one of five DNS-related RFCs that came out in late September. RFC 2929, or BCP 42 as it is also known, discusses the general parameters that have Internet Assigned Number Authority (IANA) considerations–in other words, any values in the DNS headers or in DNS Resource Records (RRs) that might be chosen from valid values under the authority of the IANA. Although this document is certainly important for DNS implementers, it is also a useful resource for those who want to understand DNS from the ground up; it includes comprehensive references to seminal documents describing DNS.

RFC 2915, “The Naming Authority Pointer (NAPTR) DNS Resource Record,” is a Proposed Standard updating RFC 2168, “Resolution of Uniform Resource Identifiers using the Domain Name System.” Originally created as a way to build DNS RRs that could consist of rule-sets capable of being redelegated over time (for example, to point to new services instead of old ones that have been removed), the NAPTR DNS RR is updated in RFC 2915.

Another Proposed Standard, RFC 2916, “E.164 number and DNS,” describes how the DNS can be used to identify available telephone services connected with E.164 numbers (more commonly known as telephone numbers).

The last two DNS RFCs, RFC 2930, “Secret Key Establishment for DNS (TKEY RR),” and RFC 2931, “DNS Request and Transaction Signatures ( SIG(0)s ),” are both Proposed Standards. Both describe mechanisms that help improve DNS security.

In RFC 2845, “Secret Key Transaction Authentication for DNS (TSIG),” a mechanism for authenticating DNS queries and responses using shared secret keys, is defined in the Transaction Signature (TSIG) RR. However, the document does not provide any mechanism for sharing the secret keys, other than by manually exchanging them. RFC 2930 describes a mechanism, called a Transaction Key (TKEY) RR, which can be used to set up the sharing of secret keys between DNS clients and servers.

RFC 2535, “Domain Name System Security Extensions,” defines extensions to DNS that are used to “provide data origin and transaction integrity” as well as “authentication to security aware resolvers and applications through the use of cryptographic digital signatures.” Implementers have discovered that the extensions as defined in RFC 2535 don’t exactly work the way they should, and RFC 2931 describes modifications that fix the problems.

Document, Protocol, and Working Group Actions

Table 2 lists all the document and protocol actions announced by the IESG in the past couple of weeks–and there were quite a few.

Important new document actions include several related to Multiprotocol Label Switching (MPLS), including two on the Label Distribution Protocol (LDP) and one on the use of the Virtual Connection Identifier (VCID) to support the ATM Label Switching Router (ATM-LSR). Also new is the approval of the NFS version 4 specification as a Proposed Standard.

Table 2: IESG Document and Protocol Actions Announced September 18 through October 1, 2000

What’s Next

After a four-month run, this column is going on hiatus. If you like it, let me know at [email protected] . Let EarthWeb know, too. Meanwhile, you can check out the latest developments on //

Pete Loshin has been writing about IP networking since 1988, and is the author of 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