Plenary Report

Unlike previous IETF meetings, the IETF 69 plenary did not feature a technical presentation. Olaf Kolkman explained that it can be a challenge to find good speakers and topics that are interesting and relevant enough for the entire IETF community. The open mic discussion that ensued prompted several suggestions, including one by Aaron Falk, chair of the Internet Research Task Force (IRTF), who proposed that more research topics be included, which, he said, might have the added benefit of encouraging more researchers to participate in the work of the IETF. Another participant added that it might be beneficial to have an IETF working group (WG) or an IRTF research group (RG) present its work to a wider audience, such as IETF plenary participants, if the scope of the work is not too narrow.

In general, it was agreed that the session would benefit from presentations that coherently address the larger challenges for the Internet-such as IPv4 address exhaustion and cybercrime- but not only from a technical perspective. In other words, the IETF should be thinking more about benefits for end users instead of thinking only about engineering issues. Former Internet Architecture Board (IAB) chair Leslie Daigle supported that position, saying it would be good for IETF meeting planners to think about what makes a topic relevant to the IETF. For example, is it something that requires action on the part of the IETF? Or is it a topic of imminent importance to the community? “We tended to shy away from this in the past few years,” she said. IAB member Elwyn Davies added that the IAB is taking steps to address the wider community by, for example, working with ISOC to raise awareness of unwanted traffic.

After a lively discussion about IPv6, firewalls, NAT (network address translation), and NAT traversal mechanisms, one participant commented that 10 years ago, when he started working in the IETF, he believed that the architectural principles, such as the end-to-end principle, represented a shared vision. Today, he said, there doesn’t seem to be much in the way of coherent work that spans multiple areas. Instead, narrow pieces of standards work are being done, all of which are driven by business and the marketplace. “Where is the endto- end-principle in applications these days?” he asked. “That underlying principle made the Internet grow the way it did. If this is not a shared vision anymore, this will have to be discussed.”

In response, another participant suggested looking more at conclusions than at principles. “End-to-end was a conclusion,” he said. In the 1980s, he added, former IETF chair Dave Clark wrote a document that discussed where in the network might be the best point to put complexity. At the time, Dave came to the conclusion that complexity and management are best placed at the edges of the network, which meant that end to end was an important feature. Since then, circumstances have changed. Putting complexity at the edges is no longer a good idea; there are too many of them. Furthermore, neither is putting network management at the core of the Internet a good idea. The speaker suggested that today, complexity should be at the point between the intranets (internal networks) and the Internet. “That is the point network operators have control over and can manage,” he said. “Does that mean we need to get rid of old principles if they no longer apply? The most important goal is to keep the robustness of the Internet.”

On the subject of firewalls, Thomas Narten warned the IETF not to make the same mistake it made in earlier days. As Thomas explained, in the past the IETF did not make recommendations on the behaviour and use of firewalls, because firewalls were generally seen as “a bad thing.” This created a gap that was filled by the industry in a way that created inconsistencies. Consequently, firewalls do not work very well. “If we want the IETF to help make the Internet work better, we have to admit that we missed an opportunity with respect to firewalls,” he said. “Now we have the opportunity to influence firewall behaviour in IPv6.” The same, he said, applies to NATs. “The industry filled a gap because the IETF made no clear recommendations,” Thomas said. “This means there’s no predictability regarding how applications work. Now we’re having the same discussion with IPv6: Do we need NAT-PT [IPv6 NAT]? No, we don’t. But the reality is that people will create NATs in IPv6. The point is that with NAT-PT, we may be making a big mistake by leaving a vacuum out there.”

Other speakers added that what seems to be missing is for the end hosts to tell the firewall what kind of traffic it wants to receive. (Note: NAT just happens to let traffic through, whereas the behaviour of a firewall is a policy decision.) This has not been developed or successfully deployed.

Brian Carpenter referred to a paper by Mark Handley titled Why the Internet Only Just Works (PDF).

As Handley says in the paper, the Internet is going to suffer growing pains as it moves from providing 80 percent of the functionality to providing more than 90 percent of the functionality, as called for by the new requirements. The track record, he writes, is not at all good. Historically, all of the major changes that were successful were implemented at the last minute. This, Brian pointed out, should not be a surprise. “There are always too many immediate issues to be concerned with to invest time and money on those that are not currently critical,” he said. “And consensus for architectural change is very hard to reach unless you’re faced with a specific and pressing problem.”

Thomas agreed, adding that there is a brief window of one to three years before people will need to look at IPv6. Only in that short window can things be fixed, he said. “The IETF tends to work best when things really hit, and yes, things are starting to hit now.”

A number of other issues were raised during the plenary, including the concern that there appears to be no formal procedure for revisiting older specifications or RFCs. In some cases, the WG, or even the entire IETF area, is no longer in existence, which makes it difficult to address requests to revise or revisit specifications.

Following that was a lengthy discussion on an issue related to the IPv6 WG. Some disappointment was expressed that the WG did not meet during IETF 69 despite requests from within the WG. It’s expected that the WG will be rechartered to include maintenance issues, but it’s also possible that the group will take on new work, such as issues related to the deployment of IPv6. Some people felt that multiple WGs might be needed: one to address protocol work and others to address more-operational issues. In addition, the IPv4-to-IPv6 transition mechanisms may need to be revisited. One participant said he believed that the slow deployment of IPv6 is the result of its having been created inside the IETF instead of in cooperation with industry players. In most cases, when work comes to the IETF, a deployment constituency is already in place. IPv6, on the other hand, has been developed internally by the IETF with the assumption that it’s needed and that it will eventually be adopted by the market. With this in mind, the IETF will need to think about how to sell IPv6 to the world.

Another topic raised during the open discussion was the update of RFC 2026, which describes the standards process. The RFC currently describes the standards process as a three-step procedure, but in reality, one or more steps are often omitted before the industry starts using it. Many folks within the IETF agree that the RFC should be updated to reflect how the standards process is realised in practice, which not only would be fairer to newcomers to the IETF but also would benefit the entire community. It was agreed, however, that any adjustments to the RFC should be viewed as a “process documentation correction” and not a change in the actual process. In other words, the underlying principles should be kept in place. One participant suggested that this be represented as an ongoing process and not as a three-step process, because many protocols will, in fact, never be completely finished (many require ongoing maintenance). In conclusion, it was agreed that when important documents, such as the standards procedure documents, get changed, one must be sure that the outcome is what the entire community wants.

News and Announcements from the IAB and the IETF

Reports from the IAB workshop on Unwanted Traffic and the workshop on Routing and Addressing are currently in the RFC Editor queue and will be soon published as RFCs. In addition, there are a few nonarchitectural documents:

• RFC 4844: The RFC Series and RFC Editor
• RFC 4845: Process for Publication of IAB RFCs
• RFC 4846: Independent Submissions to the RFC Editor

A number of personnel changes were announced at IETF 69. Ted Hardie has been appointed to the ISOC Board of Trustees. Loa Andersson is now IAB liaison to the Internet Engineering Steering Group. Danny McPherson has been appointed IAB liaison to the NomCom. Stewart Bryant will serve as liaison for ITU-MPLS. And Scott Brim has stepped down as liaison for ITU-NGN.

It was announced that the ITU has been looking for input on its role in Internet policy and standards development. Those who are interested can find the IAB’s input.

There was also an informal gathering between the IETF and the ITU on 21 July 2007. The goal of the meeting was primarily to get to know each other better and to develop personal working relationships so that future collaborations can be effective and fruitful. The next IAB retreat will cover the following topics:

• Routing and Addressing: Actively following developments and building common understanding of architectural issues
• IP Fundamentals: What assumptions are made in stacks and how they relate to original design goals; IP and NAT (architectural questions)
• Bridging gaps with partner organisations like ISOC, the IRTF and others

At the last IETF meeting, the IETF Trust produced a license agreement for authors who want to sign their RFCs over to the Trust. It is a bit disappointing to see that not many people have done that so far. The license agreements can be found on the IETF Administrative Support Activity (IASA) Web site.

With respect to the IASA budget, there is a shortfall between the planned budget and the current income for meeting the budget line in 2007. However, special thanks are extended to Microsoft and Cisco Research for hosting IETF 70 in Vancouver, Canada.