IETF 96 Thoughts

But while the numbers are interesting, what matters more is whether our gatherings have an impact on the real-life Internet out there. I certainly felt that the topics handled during the week were very significant for the Internet’s evolution. But more on that in a bit.

Not Just about the IETF

I also wanted to observe that the IETF meetings are not just about the IETF. We typically get many other meetings happening around the IETF time as well. This time we had for instance 6LO interop event with ETSI, an applied networking research workshop, an informal gathering of the operators in the IEPG meeting, interaction between the RIOT summit and our working groups, and many others.

And of course the IETF meeting itself is not just talk and specifications. We also love running code, for it is what actually makes the Internet tick 

One of the ways that we can focus on running code is through the IETF Hackathon, which started with the main gathering on Saturday and Sunday, but for the first time ran through the week in the lounge and at the Bits-n-Bites event. The Hackathon had more participants than ever, 158. But again the numbers are not as interesting as what the people were doing. You could feel the buzz of excitement and ongoing hacking just by entering the room.

The winning project hacked FD.io to make it do identifier-locator based forwarding on IPv6. Another project interop tested 7 implementations of TLS1.3. This has a direct impact on how well our browsers work.

Technical Topics

But back to our technical program during the main meeting week. With 128 different meetings, I cannot report on everything, but here are some highlights:

• The QUIC (Quick UDP Internet Connections) BOF was held to consider a proposal that has originally come from Google, and is already seeing widespread usage there. The basic idea is that an efficient and secure transport can be built by applications, encompassing both TCP and TLS functionality. The new transport would run on top of UDP, and promises the ability for protecting more of the session than TCP and TLS-based designs can, absorbing multipath- and mobility functionality, and be very efficient transport for web traffic.A standard in this space would likely see significant deployment in the Internet.  For me the most interesting aspect of this design is that as an application level implementation, further evolution of the design is easy and can happen in a distributed manner.The BOF was the most well-attended IETF session during the week, or possibly ever. I’m very excited to see what comes out of it!

• The transport community was also otherwise very active. For instance, the L4S BOF considered proposals for improved TCP performance on latency and scalability. The area is also still working to meet the needs for managing radio networks in an encrypted world that operators told us about in the IAB MARNEW workshop last fall, and any new encrypted transport protocol will have to find some way to address those needs.

• The LEDGER meeting discussed standards for interoperability between payment systems, for instance the ability to make payments across multiple payment networks or Bitcoin­-like systems. This would be a new area for the IETF, and I don’t know if we’ll be working on this yet. But some of the technical challenges here related to security, naming, and routing certainly appear familiar.One of the underlying primitives that LEDGER would need is something called Crypto Conditions, an ability to specify when a condition is fulfilled, for instance when a sufficient number of parties from a group have signed something. This is another topic that I’m interested to follow.

• The HOMENET working group had observed a mistake that had been made with respect to a recently published RFC, RFC 7788. This RFC accidentally refers to the “.home” special use name, but doesn’t specify its semantics in other DNS systems and didn’t go through the process normally required for special use name allocations.While this problem has been recognised and there’s an approved erratum for the RFC, I believe it is important that a more permanent fix be developed by approving a new RFC without the reference in the near future. The assignment of possible special use names for HOMENET use can take place in parallel.

• The NETMOD working group and the IETF Routing Area have been steadily working on producing YANG models. There have been several NETMODrefinements to aid in this, such as improved ways to combine data models. We are now focusing on how to get the YANG models – such as topology, BGP, IS-IS, OSPF, and MPLS – to be completed in the next year. Implementation experience on these is very welcome!

• The LPWAN meeting discussed how to run IPv6 and higher layer Internet protocols such as CoAP on highly constrained low power wide area networks (LPWANs). The energy and packet size constraints on these networks require highly innovative solutions to just be able to run IP in these networks. Participants representing four of the major LPWAN technologies were present in the meeting and showed high levels of interest in both participating in as well as utilizing the output from this effort.

• The recently-chartered SIPBRANDY working group met for the first time this week. The group is describing best practices for cryptographic protection of SIP-signaled real-time media. It hopes to solve keying issues that have so far prevented wide deployment of the Secure Realtime Protocol (SRTP).

• Open source is a big part of our efforts. Some of the events beyond the IETF Hackathon included the first meeting of the BABEL working group, focused on a new routing protocol from the open source world, and a gathering of the open source developers from the routing area.

IETF Financing and Sponsors

I would very much like to thank Juniper Networks for hosting this successful meeting in Berlin. Juniper is one of our IETF Global Hosts, companies who are committed to supporting several meetings across 10 years.

I was also happy to hear that the IETF Endowment received over 3 million dollars from our friends at AfriNIC, ARIN, RIPE NCC, and ISOC. This is a major show of support for the IETF mission, and much, much appreciated. Thank you all.

I should also note that it is important that we evolve the IETF funding model. We’re very meeting focused in our funding that with regards to meeting fees from the participants and sponsor support. Re-balancing that to both meetings and other IETF’s work is important. The IETF Endowment is one step in this direction. For your information, ISOC will be holding an information and discussion session on the endowment on September 9, 2016 at 1400 UTC.

Next Steps

Finally, what’s next? Back to work, of course, on the mailing lists, virtual meetings, and design teams. Our next physical meeting is in Seoul, South Korea.

Video

A brief version of this article exists also as a video:

Jari Arkko, IETF Chair

The author would like to acknowledge the help of Alia Atlas, Spencer Dawkins, Deborah Brungard, Stephen Farrell, Joe Hildebrand, Ari Keränen, Alissa Cooper, Suresh Krishnan, Ben Campbell and others in understanding what happened at IETF96 and writing this article 

Photo credits: Dan York, Jari Arkko, and Afrinic