What makes a version negotiation mechanism successful?

[tfpauly]

From https://tools.ietf.org/html/draft-iab-use-it-or-lose-it-00#section-2.1 :

[Simple version negotiation in the initial protocol] has proven to be insufficient in practice. Many protocols have
evidence of imperfect implementation of critical mechanisms of this
sort. Mechanisms that aren't used are the ones that fail most often.
The same paragraph from RFC 6709 acknowledges the existence of this
problem, but does not offer any remedy:

Looking through this, I wonder if we can make some comments on the versions negotiation mechanisms that have been successful. I think one property that stands out is that many of the most "successful" mechanisms really are relying on other, lower layers to declare versions, as opposed to having a protocol negotiate a version in-band.

For example:

• HTTP/1.1 vs HTTP/2 uses ALPN from TLS; as long as your TLS implementation works, you don't have to have a parser that tries to read 1.1 or 2.
• HTTP/2 to HTTP/3 use entirely different transport protocols, and also have ALPN
• IPv4 and IPv6 have different types in Ethernet headers rather than actually using the version number in practice

The cited instances like TLS version negotiation within the protocol itself had to abandon the original mechanism.

Looking at QUIC, it has version negotiation built-in, but that's yet to be fully played out in the wild. However, the strong definition it has for Invariants means that the Invariants themselves are like a mini-protocol layer that is just about flow identification and version negotiation, upon which the actual QUIC protocol is riding.

[martinthomson]

The question I have is whether this is the result of the switch at the lower layer having some property that is desirable, or whether it is because that switch is more available because the mechanisms at that layer are in active use.

At the time we did ALPN for HTTP/2, we knew that it was possible to deploy TLS extensions with confidence. Obviously, we know that you can deploy protocols over UDP for QUIC. I'm less sure about Ethernet, but my understanding is that IP was not the only protocol with positive prospects, at least at the time that IPv6 was introduced.

[tfpauly]

Yes—I think one way to look at it is to say that its best to put your version negotiation mechanism within some layer that has active use, to avoid having a broken version mechanism. Extensions of a lower protocol (like TLS is to HTTP) are good candidates for version negotiation, since there are more things sharing the extension space than just the one protocol.

Looking at Ethernet types vs doing IP versions in IP packets themselves, there are more Ethernet types than just IPv4 and IPv6, and it made it easier to get implementations to understand just another new value in the Ethernet frame, as opposed to differentiating using the IP headers contents.

[cabo]

https://github.com/t2trg/wishi/blob/master/slides/2019-11-07-versions.pdf

https://github.com/t2trg/wishi/blob/master/slides/2020-02-20-versions-numbers.pdf

People didn't like it when I had a slide at IETF108 that outright said "version numbers are stupid".
https://datatracker.ietf.org/meeting/108/materials/slides-108-core-sessb-core-consolidated-slides-v00-03#page=38
Actually, they aren't, as long as they are used to entirely prevent false interoperability (SNMP example from draft).