IETF Corner, March, 2001
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.
By Pete Loshin | Posted Mar 13, 2001
Page 1 of 3
30 RFCs in 28 DaysFebruary 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 IssuesOne 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 MulticastReliability 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.