Along the same though process of a middle box server that is a session endpoint performing L4 checksum. So the middle box would have to be final destination if it’s session endpoint and then in that case the L4 checksum would succeed.
So then I don’t see any issue with the middle boxes. On Fri, Jun 14, 2024 at 1:29 AM Gyan Mishra <hayabusa...@gmail.com> wrote: > > Hi Tom / All > > AFAIK what Robert is trying to say is that compare to IPv4, the IPv6 > header does not have a checksum field. The designers of IPv6 believed > that the link layer checksumming provided by protocols like PPP and > Ethernet, combined with checksums in upper layer protocols like TCP and > UDP, would be enough. They also wanted to make the header more efficient > and easier to process by removing the CRC check > > So that being said the L4 upper layer protocols TCP, UDP would perform the > checksum which would be done by the session endpoints as Robert pointed > out. > > Another point is that all customer traffic TCP, UDP endpoint flows would > be IPv6 encapsulated in the payload which would be unfettered and untouched > and thus the session endpoint would be perform the L4 checksum would > succeed. > > SRv6 would be deployed in a single administrative domain which could be > many domains or sub domains within a single administrative control. In > that case the operator would take precaution's per the draft as to middle > boxes being deployed in an SRv6 domain to avoid any L4 checksum issues or > upgrade as necessary to avoid any issues. The rarity of this issue is that > not only would the operator have to deploy these middle boxes, but the > middle boxes as well would have to be session endpoints in the middle of > the SRv6 domain. Quite rare. I don’t see a use case where a network > appliance middle box would be a session endpoint. Even a sniffer middle box > would be just mirroring the flows but would not be terminating the > session. The only possible case I see is if a server was a middle box > siting as one of the transit nodes as a session endpoint. In most operator > networks the underlay transport network P nodes are kept ultra clean and > stable minimal changes as well kept clean of any devices that could > comprise the integrity of the underlay. That being said makes it even more > rare that an operator would put server or devices that could potentially be > harmful and impact stability of the SRv6 core transport. > > I don’t see why there would be a need to update RFC 8200 to account for > the highly remote possibility of middle boxes L4 checksum issue given that > it is within an operators domain whom has full control to easily avoid this > circumstance or situation ever occurring at all costs. > > Kind Regards > > Gyan > On Thu, Jun 13, 2024 at 1:29 PM Tom Herbert <tom= > 40herbertland....@dmarc.ietf.org> wrote: > >> 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 >> >> > >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> i...@ietf.org >> Administrative Requests: >> -------------------------------------------------------------------- >> >
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
