Subject: [Stackevo-discuss] some comments on draft-iab-protocol-transitions-05

From: Joe Touch <[email-masked]>
Date: Tue, 10 Jan 2017 14:50:25 -0800

Hi, Dave (et al.),

I had some thoughts on this doc, summarized below. I hope they're useful.

Joe

-------

The discussion of IPv4-6 transition might include a discussion of paths
not taken in IPv4, e.g., earlier versions included variable length
addressing.

Regarding new features, it might be useful to discuss how options are
handled. We include them to future-proof a protocol, to ease the
transition to new features. However, we too often succumb to commercial
pressures to ignore this flexibility in favor of performance or economy.
That's why IPv4 fragments are being dropped, why IPv6 options are now
limited in total length, and why options are generally deprecated for
traffic that expects to successfully traverse the Internet. It's also
how we're boxing ourselves into needing IPv-next rather than augmenting
what we have in our hands.

There are a few design lessons here that might be useful to point out. A
discussion of TLV vs. fixed tag encodings would be useful. Reasons to
put version IDs, or demuxing tags in most protocols would be useful too
(as we learned for the TCP Experimental option codepoints). It might be
useful to have a more detailed discussion of handling "TBD" fields,
e.g., when they MUST be set to X by legacy sources, MUST be ignored vs.
discarded if not zero by legacy receivers, and when to use each strategy.

I.e., we're constantly oscillating between considering a "thin waist"
either ossification or stability; the former when we actually need new
capabilities (like more addresses), the latter when we actually want
things to work (like running DNS over HTTP). We need to understand that
to know whether and how we want to support transitions like these.

------

---

From: Tom Herbert <[email-masked]>
Date: Tue, 10 Jan 2017 15:52:37 -0800

> what we have in our hands.
Agreed. The topic of extensibility to facilitate protocol transition
needs more discussion. The principle to "Design for extensibility
[RFC6709] so that things can be fixed up later." really doesn't seem
to have worked out very well for either IPv4 (IP options) or IPv6
(ext. hdrs.) in practice.

Tom

> _______________________________________________
> Stackevo-discuss mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo-discuss