Re: [Edm] [arch-d] Call for Comment: <draft-iab-use-it-or-lose-it-02> (Long-term Viability of Protocol Extension Mechanisms)

[Christian Huitema <[e-mail]>]

On 8/25/2021 4:17 PM, Brian E Carpenter wrote:
> I support Joel's point, but here are two more.
>
> (1) At least for the Internet layer, we have a major problem in deploying new extensions, especially IPv6 extension headers, but this problem goes back 25 years as far as new IPv4 options are concerned. I hoped that section 2.3 "Multi-Party Interactions and Middleboxes" would touch on this, but it doesn't.

In the IP case, I found that using the example of the 4 bit version 
number is a bit weak. "The version field in IP was rendered useless when 
encapsulated over Ethernet" -- AFAIK, that's not just Ethernet. And I 
don't think anyone seriously considered using the same encapsulation for 
v4 and v6, or using the version number for anything besides debugging...

The really big example at the IP level would be the IP options (IPv4) or 
the IPV6 extension headers. Neither of those really works as intended, 
pretty much because of the implementation issues that Joel mentions. 
There is a reason why QUIC runs on top of UDP, not on top of 
"payload-type = QUIC" -- and that's very much in line with the central 
point in the draft.

> Looking back in the draft, I see that it intentionally ducks the question: "This document largely assumes that extensions are not deliberately blocked." But what if they are? That's what firewalls do for a living and it's a major block on innovation. In my world, it's much more significant than the concerns in this draft, and none of the suggested techniques help, as far as I can see.
> I'm not suggesting that this document can solve the problem, but can we have a more complete acknowledgement of it than the sentence quoted above?

I have some sympathy for the assumption in the draft that features are 
not deliberately blocked. For me, the big issue partial blockage, such 
as intermediaries allowing some configuration of an e2e protocol but not 
others. For e2e deployments, that translates into random failures for 
obscure reasons. Discussing that will require a fair bit of text, much 
more than the current section 4.3. I can see why this would be better 
addressed in a different draft -- like the wire-image draft. But yes, 
this draft could explicitly point to wire-image for that discussion.

-- Christian Huitema