Internet Architecture Board

RFC2850

IP Stack Evolution Program

Home»Activities»Programs»IP Stack Evolution Program

Description

The IP Stack Evolution program covers various topics in the evolution of IPv4 and IPv6, the transport protocols running over IP, and the overall protocol stack architecture. The program addresses challenges that affect the stack in some way and where the IETF community requires architectural guidance, responding to community requests as well as actively monitoring work within IETF WGs which touch on relevant topics.

There is an observed trend of functionality moving “up the stack”: where the “waist” was once IP, now most applications run over TCP/IP, or even HTTP/TCP/IP; the stack has become increasingly ossified. This is in response both to reduced path transparency within the Internet — middleboxes that limit the protocols of the traffic that can pass through them — as well as insufficiently flexible interfaces for platform and application developers. The emergence of both new application requirements demanding more flexibility from the stack, especially at layer 4, as well as the increasing ubiquity of encryption to protect against pervasive surveillance, provides an opportunity to re-evaluate and reverse this trend.

This program aims to provide architectural guidance, and a point of coordination for work at the architectural level to improve the present situation of ossification in the Internet protocol stack. Where a working group relevant to a particular aspect of IP stack evolution exists, the program will facilitate cross-group and cross-area coordination. The program also produces documents on the IAB stream providing general guidance on and covering architectural aspects of stack evolution.

Current active work in the program includes:

(1) Definition of requirements and principles for encapsulation-based approaches to work around path transparency issues and to allow explicit cooperation between endpoints and devices on path, while cryptographically protecting information which should remain end-to-end (including transport headers). This work follows discussions at the IAB SEMI (Stack Evolution in a Middlebox Internet) workshop and the SPUD (Substrate Protocol for User Datagrams) BoF at IETF 92 in Dallas. Discussion of this work occurs on the SPUD mailing list: [email protected].

(2) Evolution of interfaces to transport and network-layer services: improving the access of applications to the specific transport services they need (e.g. reliability, latency guarantees, congestion control properties, message boundary and order preservation, etc.) beyond the traditional SOCK_STREAM and SOCK_DGRAM interfaces. Further architectural work in this space awaits the results of related engineering being done in the IETF TAPS Working Group (mailing list: [email protected]), the activities of which the program monitors.

(3) Discussion of principles for making new protocols within the IP stack deployable, following in part on RFC 5218 “What Makes for a Successful Protocol”.

(4) Definition of principles for the use of encapsulation at various layers within the protocol stack. UDP-based encapsulations are not only useful for evolution above the IP layer, but in many tunneling contexts as well. The probable commonalities among all these applications of encapsulation might be useful in simplifying their implementation, deployment, and use.

(5) Architectural guidance on the creation of new protocol stacks for constrained devices [Erik and Ralph to provide text to flesh this out].

(6) Architectural guidance for stack evolution should be informed by empirical evidence where possible and appropriate, so the program encourages efforts to collect, disseminate, and analyze data pertaining to the present state of the Internet with respect to its other activities. Work here currently focuses on the potential establishment of an IRTF research group to coordinate measurement of path transparency issues caused by middleboxes, following on the HOPS (“How Ossified is the Protocol Stack”) Bar BoF at IETF 92 in Dallas. Discussion of this work occurs on the HOPS mailing list: [email protected]

(7) Architectural guidance on traffic filtering and blocking, to result in the publication of draft-iab-filtering-considerations.

This program has itself evolved from the IP Evolution Program, which looked at general architectural issues in the evolution of IPv4 and IPv6 and the overall protocol stack architecture, and produced the following documents:

Members

IAB Members

  • Brian Trammell (Lead)
  • Mary Barnes
  • Marc Blanchet
  • Ralph Droms
  • Ted Hardie
  • Joe Hildebrand
  • Erik Nordmark
  • Robert Sparks
  • Dave Thaler

Non-IAB Members

  • David Black
  • Ken Calvert
  • Stuart Cheshire
  • Spencer Dawkins
  • Lars Eggert
  • Aaron Falk
  • Jana Iyengar
  • Mirja Kuehlewind
  • Eliot Lear
  • Xing Li
  • Eric Rescorla
  • Natasha Rooney
  • Martin Stiemerling
  • Michael Welzl

Mailing List

Meeting Minutes