On Thu, Mar 21, 2024 at 7:46 AM to...@strayalpha.com <to...@strayalpha.com> wrote: > > 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, 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 > > Joe _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
