Tal, Tom and all, IMHO and FWIW Tal has exposed a real and critical issue with compressed lists of SRv6 SIDs.
I wonder if this issue could be addressed by explicitly stating that compressed lists of SIDs can only appear in the SRv6 header but not in the Destination Address of an IPv6 packet. My 2c, Sasha -----Original Message----- From: spring <spring-boun...@ietf.org> On Behalf Of Tom Herbert Sent: Thursday, August 3, 2023 5:48 PM To: Tal Mizrahi <tal.mizrahi....@gmail.com> Cc: spring@ietf.org; i...@ietf.org Subject: [EXTERNAL] Re: [spring] [IPv6] New draft: L4 Checksums in SRv6 Tal, >From the draft: "Compressed segment lists can be used in the Destination Address without the presence of a Routing header, and in this case the IPv6 Destination address can be modified along the path. This is another case in which the checksum is computed based on the Destination Address value as expected to be received by the destination." This is a major problem with regards to L4 checksum computation in deployment. RFC8200 and even IPv4 assume that the transport layer checksum can be correctly calculated solely based on the contents of the packet without additional context. A compressed segment list in the DA without a Routing header requires additional context to correctly compute a transport layer checksum, namely identification of the Destination address as being a compressed segment list. This will break checksum computation of many deployed devices like firewalls and some forms of NIC checksum offload that wouldn't have this context and compute transport layer checksums per the requirements of RFC8200. Tom On Thu, Aug 3, 2023 at 12:02 AM Tal Mizrahi <tal.mizrahi....@gmail.com> wrote: > > Hi, > > This new draft introduces a proposed update to [RFC8200], which is > intended to address compressed segment lists in SRv6 > [draft-ietf-spring-srv6-srh-compression]. > > Link to the new draft: > https://clicktime.symantec.com/15t5ZtbBX3A66Q81WsZJg?h=DbGL-Qe3I8lQuiN > i6P8J8oghLKYGX_DLpXaanpVDrrU=&u=https://clicktime.symantec.com/15siFAn > Y3bSpnbjrFAeFn?h=s-A8BVch4u7vs066w80SXA7SbA_OzVSgtAMARilMuPQ=&u=https: > //datatracker.ietf.org/doc/draft-mizrahi-spring-l4-checksum-srv6/ > > There was some discussion in the SPRING mailing list about this issue. > > The current thread is intended to allow a wider discussion that > includes the 6MAN working group, and therefore the new draft includes > a wider background. > > Feedback will be welcome. > > Cheers, > Tal. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: > https://clicktime.symantec.com/15t5einTyeqgWLww4RxTJ?h=gP-qggN0YXJGjyn > 22ZsRBlHGQG3pufGXSh3A423wvog=&u=https://clicktime.symantec.com/15siKzy > pWD8RCYZmnj3QQ?h=FXcro4NP1hHJRFJGlsol7d774f9al9lncx88wUHJOy0=&u=https: > //www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://clicktime.symantec.com/15t5jYykSGXGvHmrbzMbv?h=_tPPaWpFo2ZaTG3XZKa-xRkKF4GS6aP9YO6rqwjz5ow=&u=https://clicktime.symantec.com/15siQqB6xpp1cVPhLHSZ2?h=xEl4biISq5woSElZ3SsIbaJHHkiH8Sekd6B6smkJ4c4=&u=https://www.ietf.org/mailman/listinfo/spring Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
