Joe Touch feedback on draft-iab-protocol-transitions-05

[Joe Touch <touch@…>]

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.

[dthaler@…]

Tom Herbert added:
"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."

[dthaler@…]

To circle back, I agree and have added a new "Extensibility" section to address these comments and others. However much of the detailed technical discussion is actually in RFC 6709, which is cited in the new section.