[spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)

2024-06-13 Thread Ted Hardie
On Thu, Jun 13, 2024 at 9:13 AM Andrew Alston - IETF wrote: > Hi All, > > > > As I have repeatedly stated in spring and will state so again here. In > certain circumstances the use of C-SID breaks the checksums as relates to > transit nodes. RFC8200 lays out specific processing rules for upper

[spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)

2024-06-13 Thread Tom Herbert
On Thu, Jun 13, 2024 at 1:12 AM Andrew Alston - IETF wrote: > Hi All, > > > > As I have repeatedly stated in spring and will state so again here. In > certain circumstances the use of C-SID breaks the checksums as relates to > transit nodes. RFC8200 lays out specific processing rules for upper

[spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)

2024-06-13 Thread Tom Herbert
On Thu, Jun 13, 2024 at 9:28 AM Robert Raszuk 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 wh

[spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)

2024-06-13 Thread Tom Herbert
On Thu, Jun 13, 2024 at 10:14 AM Robert Raszuk 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 cor

[spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)

2024-06-13 Thread Robert Raszuk
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.* Thx, R. On Thu, Jun 13, 2024

[spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)

2024-06-13 Thread Robert Raszuk
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 (

[spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)

2024-06-13 Thread Gyan Mishra
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, w

[spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)

2024-06-13 Thread Gyan Mishra
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