On Thu, Nov 21, 2024 at 7:39 AM Tom Herbert wrote: > That is an interesting use case, but I think packing multiple acks > into a single packet is more of a transport layer issue than a network > layer issue and is independent of using larger MTUs. I suggest that > this can be solved by changing LTP to carry more information in a > packet, or if changing the protocol is prohibitive then maybe a new > UNSAFE UDP option would do the trick. Either way this seems like an > end-to-end issue so we shouldn't have to expose this to routers (i.e. > a HBH option isn't warranted).
I agree with all that, subject to one caveat: if and when the larger MTUs exceed 64K bytes, the intermediate systems probably need some indication of the larger payload length. But I think that can be done with UDP options and a modest clarification to RFC 2675. Upon taking another look as Section 4 of that RFC, it seems to me that if the term "length of UDP data" is taken to mean the length of the user data, not including any UDP options, then there is no prohibition against having a non-zero UDP Length field in the UDP header. The interpretation would simply be that the length of the surplus area where the options reside is equal to the Jumbo Payload Length minus the length of the UDP header all IPv6 extension headers present between the IPv6 header and the UDP header minus the length of the UDP header itself minus the value in the UDP Length field. In the interesting case of an UNSAFE UDP option that would include a parcel integrity block plus the payloads of several user-level datagrams, the UDP Length field would be 8. Note that RFC 2675 says: For verifying the received UDP checksum, use the calculated length of the UDP header plus data, NOT zero, in the checksum pseudo-header. This actually produces the correct result owing to the design of the OCS field that is at the front of the UDP options trailer. This discussion hinges upon the observation that RFC 2675 is silent regarding the combination of IPv6 Length == 0, the presence of a Jumbo Payload Option with a Jumbo Payload Length > 65536, and a UDP header with a non-zero length. It would be appreciated if others interested in this topic would independently re-read RFC 2675 and speak up if I've missed something. If I am right, and if there is interest in using an UNSAFE UDP option to transfer packets larger than 65,535 bytes, it may be wise to publish a clarification to RFC 2675 to emphasize this point. And Appendix E of draft-templin-6man-parcels would definitely need to be updated to remove the statement that "Standard [RFC2675] jumbograms are incompatible with UDP options." Certain functions that are now specified in draft-templin-6man-parcels cannot be accomplished by using an UNSAFE UDP option as described above: * The probing capabilities would still need a Hop-by-Hop option conceptually similar to the IPv6 Minimum Path MTU HBH Option. * L2 FCS coverage would need to be signalled some other way than through the IPv6 payload length, and since it needs to be inspected by each hop, it also should be a Hop-by-Hop option. Making it a stand-alone option would allow it to be used in other contexts. I won't offer any comments on Tom's idea for an extended L2TP since I am totally uninformed about that protocol. Mike Heard _______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
