The Internet Engineering Steering Group has been approving Internet-Drafts right and left--48 of them. Plus there's been a flurry of other activity as IETF 48 approaches.
We're coming down to the wire for submissions of Internet-Drafts (I-Ds) to be considered during Internet Engineering Task Force (IETF) 48 in Pittsburgh, Pa., next week (July 31-August 4), and the usual flurries of I-Ds have turned into a veritable blizzard of drafts. Despite a July 14 deadline for I-Ds for this session, several hundred were announced late.
In the meantime, the Request for Comments (RFC) Editor announced a sparse half-dozen new RFCs, while the Internet Engineering Steering Group (IESG) has been busy approving I-Ds and pushing them on the RFC Editor's pile: over four dozen new protocol and document actions, with one new full Standard and two new Best Current Practices (BCPs) in the pipeline.
RFCs Published July 10-23, 2000
shows the meager offering of new RFCs from the past couple of weeks, mostly informational with only two proposed standards. Don't let the sparseness of the latest crop of RFCs fool you, though--This list contains some important stuff.
First, we have the new standards-track RFCs: RFC 2874, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering," and RFC 2875, "Diffie-Hellman Proof-of-Possession Algorithms."
If you don't believe in IPv6, you can skip RFC 2874. But if you're interested in how DNS is going to work with IPv6 (and IPv4, at the same time), then you'll want to read this RFC; it defines how the Domain Name System (DNS) must change "to support renumberable and aggregatable IPv6 addressing." As the abstract explains, "The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering and updated definitions of existing query types that return Internet addresses as part of additional section processing."
If you're into cryptography, the other new proposed standard, RFC 2875, should be of interest. It describes two new methods for generating integrity check values from Diffie-Hellman key pairs. Of course, as the RFC states, "This behavior is needed for such operations as creating the signature of a PKCS #10 certification request." However, be warned: "These algorithms are designed to provide a proof-of-possession rather than general purpose signing."
Informational RFC 2791, "Scalable Routing Design Principles," is a must-read for anyone interested in the continued growth of the Internet or simply the continued growth of ISPs or large corporate networks. Author Jieyun (Jessica) Yu, who works for CoSine Communications Inc., has written an excellent document that serves not only as a blueprint for dealing with routing in large networks, but also as a cogent introduction to large network routing issues and design goals.
If you use XML for any kind of sensitive data, you'll want to study Informational RFC 2807, "XML Signature Requirements," which "lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination."
Informational RFC 2876, "Use of the KEA and SKIPJACK Algorithms in CMS," breaks down all the protocol and procedures of using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithms with the Cryptographic Message Syntax (CMS). CMS in turn is described in RFC 2630, "Cryptographic Message Syntax."
Finally, Informational RFC 2877, "5250 Telnet Enhancements," updates old RFC 1205, "5250 Telnet Interface," which was published in 1991. Unless your applications require IBM 5250 support for telnet, you can probably safely skip this one.
Document, protocol, and working group actions
The real action of the past couple of weeks was at the IESG, where a ton of new I-Ds (49, listed in Table 2) were approved for publication as RFCs. It will take some time for the RFC Editor to catch up on the backlog, but in the meantime these are one step away from RFC-hood. Be careful, though, because drafts are often approved for publication as long as minor changes are made--check out the IESG announcements for the details.
Among the biggest news was approval of a new Internet Standard, "SMTP Service Extension for Command Pipelining," which updates RFC 2197 (same title) and "defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation." According to the specification, "using a single TCP send operation for multiple commands can improve SMTP performance significantly."
Also exciting was approval of drafts of two new BCP documents. The first, "Domain Name System (DNS) IANA Considerations," lays out how Internet Assigned Number Authority (IANA) parameters are to be assigned for DNS classes, resource record (RR) types, operation codes, error codes, and so on.
The other newly-approved BCP-to-be, "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types," will be BCP 29, updating and replacing RFC 2489, "Procedure for Defining New DHCP Options." The new BCP is an update of the procedures for defining new options and message types for the Dynamic Host Configuration Protocol (DHCP) through the Internet Assigned Numbers Authority (IANA).
Table 2 : IESG Protocol and Document Actions, July 10-23, 2000
In working-group news, two new ones were formed last week: the ICMP Traceback (ITRACE) and Kerberos WG (KRB) working groups. According to the ITRACE working group description, "It is often useful to learn the path that packets take through the Internet," especially (but not exclusively) for handling some denial-of-service attacks that depend on forged source IP addresses. ITRACE will work on an ICMP Traceback message that can offer network administrators a tool to determine where IP packets originate and the route they take.
The Kerberos authentication tool has been implemented on a wide range of platforms and deployed throughout the Internet and private networks over the years. The KRB-WG working group has been established to "strive to improve the interoperability of these systems while improving security." Two primary goals have been selected for the working group: to "clarify and amplify the Kerberos specification (RFC 1510) to make sure interoperability problems encountered in the past that occurred because of unclear specifications do not happen again," and to choose new or improved functions that will enhance Kerberos.
Next time, we should have some juicy bits of news from IETF 48. In the meantime, there's been a lot of activity on the mailing lists for the Detailed Revision/Update of Message Standards (DRUMS) and Network News Transfer Protocol (NNTP) working groups. Could that portend good things for those who have been waiting patiently through the years for updates to SMTP, NNTP, and other aged protocols? //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.