The Internet Engineering Task Force dealt with some 30 Requests For Comment in February, dealing with topics including IPv6, privacy, routing, and security logging. Included are links to all the month's original RFCs.
30 RFCs in 28 Days
February was a good month for new RFCs, with over one a day announced on average throughout the month. More impressive is the breadth of topics covered: from IPv6 security to reliable multicast to mobile IP to web replication and caching to routing to security logging to IP telephony, and more. There is truly something for everyone this month.
Choosing one or two of this month's crop to profile is next to impossible, so I've selected a handful of the more interesting or significant RFCs to highlight. But be sure to skim the full list so you don't miss anything important.
IPv6 Privacy Issues
One of IPv6's coolest features is stateless address autoconfiguration. Stateful autoconfiguration has been around since BOOTP, and later the Dynamic Host Configuration Protocol (DHCP): all authorized hosts are added explicitly to a boot server's list, and when a host is ready to connect, it gets checked off the list. This is fine, as long as you know all the hosts you'll ever possibly want to allow to be connected to your network. With stateless autoconfiguration, any host that asks for a network address can get one. As originally specified, stateless autoconfiguration had the host using its link layer (e.g., Ethernet) interface address in its IPv6 address. This would, in theory, allow web publishers (and others) to link traffic with individual hosts, resulting in a potential privacy hack. RFC 3041, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6," specifies a way for hosts to randomly choose an address that periodically changes, making privacy invasion a non-issue.
Building Blocks for Reliable Multicast
Reliability is something that might, at first sight, seem impossible to apply to multicast. One to many transmission over the Internet must use as its transport the User Datagram Protocol (UDP), which can give no guarantees about reliability. However, reliable multicast is still a rational goal to work toward, especially considering the great benefits it could provide. RFC 3048, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer," reports on some of the research that is being done in this area and breaks down the problem into a set of building blocks. For a quick but complete introduction to the problem domain, first read RFC 2887, "The Reliable Multicast Design Space for Bulk Data Transfer," and then RFC 3048.
BGP Confederations and Autonomous Systems
As originally specified, the Border Gateway Protocol (BGP) used for Internet backbone routing requires that all BGP routing entities within a routing domain must be fully-meshed. This poses a serious scalability obstacle as more entities become a part of the domain. Since the mid 1990s, BGP confederations have been used to subdivide the domains, allowing groups of entities to represent themselves as a single BGP entity for routing purposes. An extension to BGP supporting confederations was proposed in experimental RFC 1965, "Autonomous System Confederations for BGP," published in 1996. This month, a new version of this specification was published under the same title as RFC 3065, as a Proposed Standard. The new status reflects the widespread acceptance of BGP confederations by the industry.
Licking Loops
RFC 3063, "MPLS Loop Prevention Mechanism," is an experimental RFC, which can often be interpreted as "trained professionals only: don't try this protocol at home." However, given that this month we saw the advancement of another experimental to the standards track (BGP confederations), it's always wise to stay on top of the research today to see what tomorrow holds. Toshiba and/or Cisco, notes the RFC under the Intellectual Property Considerations section, may at some point seek patent or other intellectual property protection for this mechanism, don't be too surprised if you start seeing it supported in products from those companies. Of course, two of the four authors work for Toshiba and one for Cisco.
MPLS loops can happen when there are transients in routing paths, such that some intermediate switch uses more current switching tables than some oth/er, downstream, switch. The whole point of using MPLS, of course, is to improve performance, so anything that prevents looping within the MPLS domain is a good thing. The authors propose a threading mechanism for MPLS that would differentiate routing threads and associate specific hop counts for each route.
BCP 47: Language Tags
The Internet is a global network, even if many users assume that it's all in English. RFC 3066, "Tags for the Identification of Languages," defines a mechanism by which a client can determine the language, associated character set and any other related information, necessary to identify and decode language content in an information object. Also published as BCP 47, this document obsoletes RFC 1766 of the same title, which was published six years ago as a Proposed Standard.
This type of specification may not necessarily reflect clever engineering so much as agreement on the standards for representing different languages and character sets. Interoperability in this case depends on everyone agreeing to use the same authorities for denoting languages, with the same syntax. BCP 47 can be applied to any kind of content with an RFC 822-style header (such as email or news postings), web pages, or MIME objects.
What's Next
This will be my last IETF Corner column for CrossNodes, although my IETF-oriented columns in other publications will continue. I've been grateful for the opportunity to write this column, and especially for all the readers who've supported it. Thank you.
Pete Loshin is author of 24 books and frequently consults on Internet standards issues; he can be reached at pete@Internet-Standard.com.
Subscribe
Twitter
Full Site
About
RSS