By using this site, you agree to the Privacy Policy
IETF Corner, March, 2001

IETF Corner, March, 2001

Tuesday Mar 13th 2001 by Pete Loshin

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.

Table: New RFCs, February 2001

RFC Title Status URL
3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol Proposed Standard ftp://ftp.rfc-editor.org/in-notes/rfc3019.txt
3025 Mobile IP Vendor/Organization-Specific Extensions Proposed Standard ftp://ftp.rfc-editor.org/in-notes/rfc3025.txt
3029 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols Experimental ftp://ftp.rfc-editor.org/in-notes/rfc3029.txt
3040 Internet Web Replication and Caching Taxonomy Informational ftp://ftp.rfc-editor.org/in-notes/rfc3040.txt
3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Proposed Standard ftp://ftp.rfc-editor.org/in-notes/rfc3041.txt
3043 The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations Informational ftp://ftp.rfc-editor.org/in-notes/rfc3043.txt
3044 Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace Informational ftp://ftp.rfc-editor.org/in-notes/rfc3044.txt
3046 DHCP Relay Agent Information Option Proposed Standard ftp://ftp.rfc-editor.org/in-notes/rfc3046.txt
3047 RTP Payload Format for ITU-T Recommendation G.722.1 Proposed Standard ftp://ftp.rfc-editor.org/in-notes/rfc3047.txt
3048 Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer Informational ftp://ftp.rfc-editor.org/in-notes/rfc3048.txt
3049 TN3270E Service Location and Session Balancing Proposed Standard ftp://ftp.rfc-editor.org/in-notes/rfc3049.txt
3050 Common Gateway Interface for SIP Informational ftp://ftp.rfc-editor.org/in-notes/rfc3050.txt
3051 IP Payload Compression Using ITU-T V.44 Packet Method Proposed Standard ftp://ftp.rfc-editor.org/in-notes/rfc3051.txt
3052 Service Management Architectures Issues and Review Informational ftp://ftp.rfc-editor.org/in-notes/rfc3052.txt
3053 IPv6 Tunnel Broker Informational ftp://ftp.rfc-editor.org/in-notes/rf3053c.txt
3054 Megaco IP Phone Media Gateway Application Profile Informational ftp://ftp.rfc-editor.org/in-notes/rfc3054.txt
3055 Management Information Base for the PINT Services Architecture Proposed Standard ftp://ftp.rfc-editor.org/in-notes/rfc3055.txt
3057 ISDN Q.921-User Adaptation Layer Proposed Standard ftp://ftp.rfc-editor.org/in-notes/rfc3057.txt
3058 Use of the IDEA Encryption Algorithm in CMS Informational ftp://ftp.rfc-editor.org/in-notes/rfc3058.txt
3059 Attribute List Extension for the Service Location Protocol Proposed Standard ftp://ftp.rfc-editor.org/in-notes/rfc3059.txt
3060 Policy Core Information Model -- Version 1 Specification Proposed Standard ftp://ftp.rfc-editor.org/in-notes/rfc3060.txt
3061 A URN Namespace of Object Identifiers Informational ftp://ftp.rfc-editor.org/in-notes/rfc3061.txt
3062 LDAP Password Modify Extended Operation Proposed Standard ftp://ftp.rfc-editor.org/in-notes/rfc3062.txt
3063 MPLS Loop Prevention Mechanism Experimental ftp://ftp.rfc-editor.org/in-notes/rfc3063.txt
3064 MGCP CAS Packages Informational ftp://ftp.rfc-editor.org/in-notes/rfc3064.txt
3065 Autonomous System Confederations for BGP Proposed Standard ftp://ftp.rfc-editor.org/in-notes/rfc3065.txt
3066 (BCP 47) Tags for the Identification of Languages Best Current Practice ftp://ftp.rfc-editor.org/in-notes/rfc3066.txt
3067 TERENA'S Incident object Description and Exchange Format Requirements Informational ftp://ftp.rfc-editor.org/in-notes/rfc3067.txt
3069 VLAN Aggregation for Efficient IP Address Allocation Informational ftp://ftp.rfc-editor.org/in-notes/rfc3069.txt
3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay Proposed Standard ftp://ftp.rfc-editor.org/in-notes/rfc3070.txt

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