[spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Checksum s (draft-ietf-spring-srv6-srh-compression)
Tom Herbert <[email protected]>
| Newsgroups | gmane.ietf.spring,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <CALx6S35fQKHKGRbB_myYJCjv3Pc_yjYh4axQLtSRzvE6me+oBA@mail.gmail.com> |
On Thu, Jun 13, 2024 at 10:14 AM Robert Raszuk <[email protected]> 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 <[email protected]> wrote: >> >> On Thu, Jun 13, 2024 at 9:28 AM Robert Raszuk <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]