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

["[e-mail]" <[e-mail]>]

> On Mar 21, 2024, at 8:01 AM, Tom Herbert <[e-mail]> wrote:
> 
>> I haven’t seen it mentioned yet (apologies if so), but there is a big difference between extension headers and encapsulated protocols.
>> 
>> Extension headers - no matter how many - can each refer back to the base header. Same for the first encapsulated protocol.
>> 
>> E.g.:
>> 
>> IP1 IP2 IP3 TCP…. TCP uses a pseudo header based on IP3
>> But:
>> IPv6a EHb EHc TCP… TCP uses a pseudo header based on IPv6a; each of the EH’s can also refer back to IPv6a
>> 
>> I see NO way to do this with any mechanism for IPv4 except options (whose space is limited). There’s no way to redefine protocol processing to ensure that information can be “Carried” forward across EHs.
>> 
>> This seems like a show-stopper; has it been addressed?
> 
> Joe,
> 
> It already happens in IPv4. Consider the header chain IPv4-AH-TCP. In
> practice, host stacks have already accounted for this so I don't see
> this as a problem.
> 
> Tom

There’s a big difference and it relates to discussions we've had about UDP options.

With IPsec, the assumption is “if I add it, it MUST be checked”, so an endpoint that doesn’t know to check would drop the packet as expected.

But that means these extensions can only be useful where they MUST be supported; you can’t send them to (or through) legacy devices (or NATs) and have them work correctly.

In which case, rather than this mechanism, you could as easily do basically ANYTHING else too - because it’s no longer a matter of backward compatibility.

The idea of a chain of headers appears to have shown itself not very tenable for IPv6; I can’t see why we would want to emulate it in a protocol that (as others noted) I thought we were no longer evolving.

Joe