Re: [Stackevo] Updated description for stack evolution program

[Dave Thaler <[e-mail]>]

I think RFC 7305 needs to be added to the list at the end.
Otherwise good.

Dave

-----Original Message-----
From: Stackevo [mailto:[e-mail]] On Behalf Of Brian Trammell
Sent: Wednesday, June 10, 2015 8:26 AM
To: IAB Board; Stackevo
Subject: [Stackevo] Updated description for stack evolution program

Greetings, all,

The result of our discussions here has (I think) resulted in the following unified text. Please speak up if this isn't ready to ship.

Thanks, cheers,

Brian

--

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: [e-mail].

(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: [e-mail]), 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 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: [e-mail]

(6) 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:

IAB Thoughts on IPv6 Network Address Translation (RFC 5902) Evolution of the IP Model (RFC 6250) Smart Objects Workshop Report (RFC 6574) Architectural Considerations of IP Anycast (RFC 7094)