On Mar 20, 2024, at 9:35 PM, Toerless Eckert <t...@cs.fau.de> wrote:
>
> On Wed, Mar 20, 2024 at 09:20:24PM -0700, Tom Herbert wrote:
>>> In other words, Destination Option Headers do not have fundamentally
>>> distinct
>>> processing requirements on the destination host examining it than any other
>>> possible protocol header (e.g.: UDP, TCP), or at least we could not find
>>> such a description
>>> for any such guiding rules or treatment differences in RFC8200.
>>
>> Yes, that's mostly how all the IP protocols are implemented.
>> Processing of an encapsulated protocol isn't completely independent,
>> for instance the pseudo header for the TCP and UDP checksum is
>> different for IPv4 and IPv6.
>
> Right. But it seems unrelated to whether or not a header is an extension
> header,
> TCP and UDP not being extension headers for example.
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_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
