On Thu, Jun 13, 2024 at 10:14 AM Robert Raszuk <rob...@raszuk.net> wrote: > > Tom, > > For starter let's take a look at RFC1958 .. > > Entire document is pretty good including statements like this: > > The basic argument is that, as a first principle, certain required end-to-end > functions can only be performed correctly by the end-systems themselves.
Robert, RFC1958 does not mention the checksum nor any normative protocol requirements. And if we're going to base the argument on principles, then I'll quote the robustness principle: "Be conservative in what you send". For the past thirty years the checksum has always been sent to be correct on the wire unless there's a routing header, so changing that behavior would be a violation of the robustness principle. Tom Tom > > Thx, > R. > > > On Thu, Jun 13, 2024 at 6:54 PM Tom Herbert <t...@herbertland.com> wrote: >> >> On Thu, Jun 13, 2024 at 9:28 AM Robert Raszuk <rob...@raszuk.net> wrote: >> > >> > All, >> > >> > As far as I recall during IPv6 discussions a notion of end-to-end >> > principle of Internet design was treated as paramount. Number of decisions >> > made in shaping IPv6 encoding were derived from this. >> > >> > One of those is checksum which has been removed from the IP header and >> > shifted to higher layers (TCP or UDP or UDP-light etc ...). >> > >> > That means that no transit node (ie the node which is not the ultimate >> > destination of the transport and above layers) have the right to validate >> > any IPv6 checksum. If it is being done that is a spec violation and they >> > should do it at their own risk. >> >> Robert, >> >> Please cite the RFC that expressly forbids an intermediate node from >> validating the transport layer checksum for operational or debugging >> purposes >> >> Tom >> >> > >> > So with that "the time has come to say" that this discussion which aims to >> > simply block the subject draft which many customers do use today for >> > various real network applications should just end. >> > >> > Regards, >> > Robert >> > _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
