In November, we published the Rough Guide to IETF 76’s Hot Topics. Here now is the follow up to the meetings highlighted in that guide.
For IETF 76, which was held in Hiroshima, Japan, we focused our attention on working groups, BoFs, plenaries, and other events at IETF 75 in the following broad categories:
Common and Open Internet
Security and Stability
In addition to the main IETF content, ISOC also held another expert panel, this time on “Internet Bandwidth Growth: Dealing with Reality”. You can listen to a recording of that event, or read the transcript, here:
Looking ahead, the final preparations are underway for IETF 77, in Anaheim, USA, 21-26 March 2010, so we will soon be bringing you a guide to the expected highlights of that meeting.
Common and Open Internet
As P2P and VoIP technologies become more prevalent, and network usage patterns sometimes deviate from their architects’ expectations, managing bandwidth to allow best use for customers becomes an increasingly important topic.
mptcp (Multipath TCP)
This is a new working group since the successful BoF meeting held during IETF75. The Multipath TCP (MPTCP) working group develops mechanisms that add the capability of simultaneously using multiple paths to a regular TCP session. The primary output of the group will be the protocol extensions needed to deploy MPTCP, and adaptations to congestion control to safely support multipath resource sharing. Initially the WG will only produce documents that are experimental or informational.
Full charter: http://www.ietf.org/dyn/wg/charter/mptcp-charter.html
A productive and lively meeting took place during IETF76.
The MPTCP WG (Multipath TCP) scheduled an Interim meeting by audio on
Wednesday 10 February 2010.
The WG is now mainly focussed on meeting it’s first milestone, namely establishing WG consensus on the mptcp architecture.
There was also a separate mptcp implementers meeting held in Hiroshima. There are several ongoing implementation efforts. The plan is to have a publicly available reference implementation in under 6 months. A Linux implementation from UC Louvain in Belgium is here: http://inl.info.ucl.ac.be/mptcp
There is a good web page on mptcp including details of the UC London implementation here: http://nrg.cs.ucl.ac.uk/mptcp/
Meeting materials: http://www.ietf.org/proceedings/76/mptcp.html#slides
IETF wiki here: http://trac.tools.ietf.org/area/tsv/trac/wiki/MultipathTcp
conex (Congestion Exposure) BOF
Congestion Exposure (ConEx) is a proposed new IETF activity to enable congestion to be exposed along the forwarding path of the Internet. By revealing expected congestion in the IP header of packets, congestion exposure provides a generic network capability which allows greater freedom over how capacity is shared. Such information could be used for many purposes, including congestion policing, accountability and inter-domain SLAs. It may also open new approaches to QoS and traffic engineering.
The meeting in Hiroshima was packed and lively.
The meeting went well, considering that the topic is complex and has many architectural implications. Many speakers thought that the problem space was important, and that the IETF should begin some work here.
The discussion of Re-ECN as an example solution got sidetracked for a bit, because people needed to ask clarification questions about the proposal, and then tried to understand in more detail all the different aspects of the proposal.
There is significant interest and energy in the community, but there is a need for more time to discuss and work through exactly what problems to try to solve. Discussion is continuing on the re-ecn mailing list.
A draft charter has been sent to the IESG for consideration, and there is a possibility it will meet as a WG in Anaheim. Although not yet approved, it is likely that this group will at least meet as a BOF at IETF 77.
There is an article discussing congestion exposure in the latest issue of IETF Journal
homegate (Broadband Home Gateway) BOF
This is a new initiative. Device manufacturers, and/or the organizations what specify requirements for such devices, are not certain which IETF standards and best current practices should be supported, and when/why that support is needed. As a result of this, millions of devices are being deployed every year which do not work with important IETF protocols, standards, and best practices that are central to the future of the Internet. The primary objective of this group is to document a baseline of ‘core’ RFCs/BCPs which must be supported, followed by some ‘advanced’ RFCs/BCPs which are to be considered optional. A secondary problem is compatibility with and capability for the use of the Internet of tomorrow. New security needs related to DNS are motivating a move to DNSSEC. However, many if not most home gateways cannot handle DNSSEC, which is expected to be a major problem that could significantly impede the deployment of DNSSEC globally. Support for IPv6 is also lacking to a great degree and there is no clear understanding of how such devices should support IPv6.
The BOF went well, and there is interest and energy in the community to take on work in this space. There were people from ISPs, vendors, and others in the room, which was promising.
However, it is not entirely clear what exactly the scope of a homegate working group would be. There’s also a need to better understand how an IETF effort can complement the efforts of other groups in this space.
ppsp (Peer to Peer Streaming Protocol) BOF
The purpose of PPSP BOF is to determine whether a working group should be formed to develop standard signaling protocols (called PPSP protocols) for multiple types of entities (such as intelligent endpoints, caches, content distribution network nodes, and/or other edge devices) to participate in P2P streaming systems in both fixed and mobile Internet.
The meeting concluded with agreement that the proposed charter needed more work before a decision could be made about forming a WG. Discussion is continuing on the mailing list and a revised charter will be sent to the IESG for consideration very soon.
There is steadily increasing momentum to deploy IPv6 as the IPv4 address pool approaches depletion. While much work is ongoing to support interoperability in coexisting IPv4 and IPv6 network environments, there are also interesting developments in emerging IPv6 environments.
6lowpan (IPv6 over Low power WPAN)
The 6lowpan WG deals with the use of IPv6 over low powered networks (such as sensornets). This is protocol development for devices on “the Internet of Things”. The basic concept in 6lowpan is that IP may become a unifying layer for low powered devices for interoperability, potentially over the Internet. 6lowpan is intensely focused on developing the protocols to enable this to happen.
Full charter: http://www.ietf.org/html.charters/6lowpan-charter.html
There was an agreement that the routing requirements document would be submitted to the IESG for approval. There seemed to be some agreement that SNMP could be used for managing these kinds of devices although details remain. No document for this has been accepted as a working group item.
Although this working group has been going on for some time and has a sense of urgency now due to the SmartGrid efforts currently gaining a lot of attention in the United States, there remains some churn on the neighbor discovery document. There was a consensus call about how to proceed with the document after the meeting in Hiroshima and it was determined to split out the basic 6lowpan ND functions from the rest of the document. That draft has now been created.
Meeting materials: http://www.ietf.org/proceedings/76/slides/6lowapp-0.pdf
behave (Behavior Engineering for Hindrance Avoidance)
While behave was chartered to create mechanisms for transiting NATs in reliable ways, most of its activity is now focused on protocol translation from IPv4 to IPv6 in a number of different scenarios. Of particular interest in these scenarios is how the proposed mechanisms deal with DNS operation across the two protocol realms (and whether it is possible to maintain any kind of reasonable operation of secure DNS in such a scenario).
Full charter: http://www.ietf.org/html.charters/behave-charter.html
The working group last call is about to be issued on 6 documents related to v6v4 translation and reviewers for all of those documents were requested to identify themselves. The WGLC was in fact issued on 12/18. The documents are:
Reviews have been completed and posted to the WG mailing list.
Of interest to people who are following this work, the 3gpp and the IETF are holding a joint meeting 1-3 March in San Francisco to go over IPv6 in 3gpp scenarios and identify areas where work may need to be performed in both organizations. It is an open meeting. Details are here: http://webapp.etsi.org/meetingcalendar/MeetingDetails.asp?mid=28391
Meeting materials: http://www.ietf.org/proceeding/76/behave.html
v6ops (IPv6 Operations)
The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides operational guidance on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations.
Full charter: http://www.ietf.org/html.charters/v6ops-charter.html
Discussion in Hiroshima included recommendations for IPv6 CPE devices, new transition tools, new measurements of IPv6 traffic, IPv6 deployment scenarios for ISPs, and IPv6 deployment in Internet exchange points.
There is now a CPE requirements document that represents more of a unified view of possible requirements. The list is however extensive and it’s not quite clear to what extent all requirements will be adopted in all CPE devices and in what timeframe, so there is still the possibility of fragmentation in the market.
Minutes: not yet published
Meeting materials: http://www.ietf.org/proceedings/76/v6ops.html
aplusp (Address Plus Port) BOF
There are a couple of efforts underway to standardize the use of NATs further in the network rather than at the edges. One of the approaches is called DS-lite and it is being standardized in softwires. Another approach uses address and port sharing. It may be used on its own or in a way to supplement DS-lite.
As an output of the Internet Society IPv6 Roundtable event in the Spring, Mat Ford updated the Internet draft on problems with address sharing (http://tools.ietf.org/html/draft-ford-shared-addressing-issues-01) and this draft was discussed in this BOF.
There was no consensus to do new work in this space and there will be no new working group on this topic in the IETF at this time.
6lowapp (Application Protocols for Low-power v6 Networks) BOF
6LOWAPP is a BOF considering whether different protocols, or modifications to existing protocols, are needed for very low power devices that may proliferate for sensor type networks. There is a great deal of enthusiasm not just to define the work of a potential working group coming out of this BOF but also to start defining problems and protocols.
The mailing list for this BOF had a lot of traffic before the meeting and continues to have traffic after the meeting. It was agreed that there is work that needs to be done in this area and there is now on the BOF mailing list discussion about the charter for a working group to do that work. It appears the name of the new working group will be CoRE. To subscribe to the mailing list send a request to firstname.lastname@example.org.
Minutes: not yet published
Meeting materials: http://www.ietf.org/proceedings/76/slides/6lowapp-0.pdf
Security and Stability
Securing the DNS and greater assurance in routing is critical for the ongoing expansion and evolution of the Internet in all areas of our societies and economies.
dnsext (DNS Extensions)
This working group is involved in developing a wide range of functional extensions to the DNS. dnsext also tracks the DNS implications of the behave WG.
Full charter: http://www.ietf.org/dyn/wg/charter/dnsext-charter.html
During the summary of documents in working-group (WG) last call, it was pointed out that although 5 participants agreed to review the GOST document when it was adopted as a WG item, none have commented during the last call. (This omission was corrected on the list shortly after the meeting and the draft was advanced to the IESG. Paul Hoffman’s related draft concerning allocation of new DNSSEC algorithms was described as ready for last call following a small set up updates.
Whether the DNSSEC-bis document should specify default policy for trust anchors was discussed without resolution; the document will just document alternatives. Discussion of whether TCP is mandatory transport for DNS included discussion of modified TCP and alternative (such as SCTP) transport protocols.
DNSOP (Domain Name System Operations)
The dnsop WG works on various operational aspects of the Domain Name System.
Full charter: http://www.ietf.org/dyn/wg/charter/dnsop-charter.html
The draft on dnssec-key-timing was discussed and adopted as a WG item. Several questions were asked, but need resolution on the mailing list, regarding resolver priming. The trust-anchor history service was not discussed.
The DNSSEC Signing Policy & Practice Statement (DPS) Framework, which has already been used by Verisign and ICANN in drafts for signing the root, was adopted as a WG item.
Reverse DNS in IPv6 was discussed but not adopted, although there are strong views that operators are not required to populate the reverse tree, especially for small office and residential networks.
Discussion of top-level domain name specification, which concentrates on potential confusion among internationalized domain names, got push-back as more a matter of policy than protocol or technology.
A proposal for a DNS query to “local.arpa” to bypass DHCP-provided resolver addresses was introduced, with several problems identified and to be discussed further.
IANA described changes to unify protocol port and service registries was described, with an alternative proposal to be posted to the mailing list.
sidr (Secure Inter-Domain Routing)
The sidr WG working group is chartered to formulate an extensible architecture for an inter-domain routing security framework.
Full charter: http://www.ietf.org/dyn/wg/charter/sidr-charter.html
At least 12 draft updates were reported; only those with significant discussion summarized here.
Discussion of Route Origin Authorization (ROA) validation exposed different opinions whether operators prefer to validate on BGP-routers or on provisioning servers.
Different views of whether, or under what condition changing RPKI algorithm were no more complicated than rolling a key were discussed, especially with respect to propagating algorithm change through a tree of authorization.
Discussion of Local Trust Anchor Management suggested wider support than at the previous meeting, along with clearer examples.
The results of ISOC’s roundtable on securing routing information (http://www.isoc.org/educpillar/resources/docs/routingroundtable_200909.pdf) were summarized and appreciated by the WG.
savi (Source Address Validation Improvements)
The savi WG is chartered to design methods for IP source address validation that complement ingress filtering with finer-grained protection.
Full charter: http://www.ietf.org/dyn/wg/charter/savi-charter.html
There was an lengthy discussion of the SAVI protocol framework, following which, the draft-vogt-savi-framework was considered by the WG to be a good starting point.
This was followed by a discussion of SAVI for locally generated addresses, focused on the local network segment, with address ownership based on FCFS.
There were also discussions on DHCP, liaison with the Broadband Forum, and a CERNET/CNGI implementation update.
karp (Keying and Authentication for Routing Protocols) BOF
Many routing protocol deployments, if they use authentication at all, are using older (possibly deprecated) cryptographic algorithms and missing some modern security mechanisms, like replay protection, algorithm agility, or key rollover. In addition, many use the same key permanently. This needs to be fixed. Additionally, key management for routing protocols needs to be added to easily address the terminated-employee problem of compromised shared secrets. Such key management needs to work over multicast media, and needs to work directly over the link layer in some cases (since routing depends upon it).
A productive meeting took place in Hiroshima and the discussion has continued on the mailing list to agree how to divide up the work and how to refine the charter. The expectation is that karp will have its first WG meeting at IETF77 in Anaheim.
ISOC Member Newsletter. Suggestions, comments, and questions welcome to, email@example.com
ISOC's key initiatives target the critical issues that affect all aspects of Internet development and growth. They embody ISOC's philosophy that the Internet is for everyone and they provide the organization with a solid foundation from which to positively influence standards development, access, business practices, and government policies. www.isoc.org