Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

[Tom Herbert <[e-mail]>]

On Fri, Mar 22, 2024 at 7:45 AM [e-mail]
<[e-mail]> wrote:
>
> On Mar 21, 2024, at 10:58 PM, Tom Herbert <[e-mail]> wrote:
>
>
> Again, I’m not saying it’s not useful. I’m saying it’s just another transport - one with particular properties, but still just a transport.
>
>
> Extension headers are not transport protocols per the standard,
> RFC8200 clearly distinguishes extension headers from upper layer
> protocols which can be transport layer protocols.
>
>
> IPv6 EH = extension headers to IPv6
>
> IMO, IPv6 EH per this draft = just another transport protocol

Joe,

I disagree. EH is not a transport protocol. There's already precedent
for supporting EH in IPv4 in AH and ESP. No one would ever call these
transport layer protocols. The same thing is true for other EH if they
are enabled for IPv4 just like ESP and AH were enabled.

Tom

>
> RFC8200 does not apply to this proposal.
>
> There is NOTHING that can be done for IPv4 to permit legacy endpoints to silently ignore an EH when so desired by the sender. That’s what makes IPv6 EHs different than this (IMO, again) transport protocol.
>
> It’s misleading to call this proposal an EH or having to do with IPv4.
> It doesn’t help the programmer or user by doing so.
> It doesn’t imbue the proposed solution with any properties a transport protocol couldn’t have, by design.
>
> I don’t think this is being proposed in the correct IETF area; it belongs in TSVWG.
>
> Joe