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

[Tom Herbert <[e-mail]>]

On Thu, Mar 21, 2024 at 5:38 PM [e-mail]
<[e-mail]> wrote:
>
> 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.

Joe,

As you know from the discussions on UDP Options, I believe that if
someone sends security information in a packet then the information
MUST be verified. It's always better to drop something you don't
understand, rather than accept it and put the user at risk for
security or data corruption.

>
> 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.

We can't send AH, ESP, DCCP, SCTP, GRE through NAT either. For that
matter, has any ever tested if IPv6 EH can make it through NAT. In any
case, from IPv6 data we already know that extension headers will
probably ever only be useful in limited domains, so I don't believe
NAT traversal is a showstopper.

>
> 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.

But isn't that the *whole point* of an extensible protocol like IP?...
to allow innovation and extensions to be able to solve problems that
would never have been foreseen when the protocol was first developed.
And not everything we do can be backwards compatible, if that were a
requirement IETF never could have created IPv6.

>
> 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.

I believe there are a lot of people in IETF that would disagree with
that sentiment.

Tom

>
> Joe
>