On Thu, Mar 21, 2024, 8:28 PM to...@strayalpha.com <to...@strayalpha.com> wrote:
> <Joe> > > > You’ve just described a transport protocol that the intermediate nodes >> know. >> > > Joe, > > A transport protocol doesn't meet the requirements. They don't work with > any transport protocol other than themselves, > > > They do when you define them that way, i.e., “here’s a transport protocol > header A, after which you can use any transport protocol, as indicated in > field X”. > > and intermediate nodes cannot robustly parse transport headers > > > They can’t parse these either. But, if upgraded to do so for headers “A”, > as per above. > > This has to be L3 protocol. > > > It’s not. It’s L4, or at least that’s what it is* to IP. > Joe, Please give one concrete example of a transport protocol explicitly designed to be processed and modified by intermediate nodes. If you say TCP as in modifying port numbers for NAT, I'll point out it that the TCP was never designed for this, it breaks TCP Auth option, and QUIC closed this architectural aberration by encrypting the transport layer so that intermediate nodes can't muck with it :-) IMO, network nodes have no business participating in transport layer, doing so has led to a lot of protocol ossification. Tom > IPv6 can call them extensions because all IPv6 nodes already know what to > do with them, even for codepoints they’ve never seen. IPv4 implementations > have no knowledge of this new transport protocol - only those who have been > upgraded. > > No different in principle - or implementation - than DCCP or SCTP. > No easier to deploy. > No more unique utility, IMO. > > Joe > > *All protocol layers are relative, so you COULD do the following: > > IPa IPb UDPc UDPd > > To IPa, its view of itself is layer 3, IPb is layer 4, not an extension to > layer 3. > > To IPb, its view of itself is layer 3, IPa is layer 2 and UDPc is layer 4. > >
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
