On Wed, Jul 3, 2024 at 9:35 AM Bob Hinden <bob.hin...@gmail.com> wrote: > > Alvaro, Spring Chairs, > > The 6MAN chairs have reviewed the discussion on your query to the IPv6 list. > This is our thoughts. > > Process wise we don’t think we can declare any kind of formal consensus on > this. We are sure you have also read the discussion. We do have some > feedback from our reading of the discussion. > > Our read is there is a number of people who don’t like using C-SIDs due to > issues relating to verify transport checksums due to not having access to > final destination address. We don’t think this is a significant issue as > long as they are in a SRH header. That provides additional context that > C-SIDs may be in use. > > We think there is a stronger issue when using C-SIDs without a SRH header. > There isn’t any context for knowing how to handle these packets. We also > agree with the point was that for an endpoint, there would be no way for that > endpoint to do hardware offload for the TCP checksum. Even if the NIC > supported SRH it would not know how to restore the original destination > address. These NICs commonly fail to do TCP offload with any routing header > or other extension headers too, so the failure is there. It is made worse > without having any context that C-SIDs are being used. > > We think this issue could be reduced if there was a way to identify that the > packets contained C-SIDs. For example, if they were using the prefix defined > in <draft-ietf-6man-sids>. We note that > <draft-ietf-spring-srv6-srh-compression> does reference this prefix defined > in <draft-ietf-6man-sids>, but does not require its use. >
Bob, The prefix would need to be defined as a standard code point, but even so it would be complex to implement in offloads and still wouldn't be compatible with protocol specific checksum offloads. Additionally, then we'd have to update all network devices that might want to look at the checksum in flight to understand the prefix. I don't think it's a feasible solution. How about recommending doing a checksum-neutral mapping like in RFC 6296 where instead of affecting the source address, manipulate bits in the destination address? Tom > Bob, Ole, Jen > > > -------------------------------------------------------------------- > 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
