On Fri, Mar 22, 2024 at 7:45 AM to...@strayalpha.com <to...@strayalpha.com> wrote: > > On Mar 21, 2024, at 10:58 PM, Tom Herbert <t...@herbertland.com> 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 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
