Hi Joel, I agree that this may be a corner case, but it still needs to be covered. As you pointed out, the compression document should certainly mention how the checksum computation is affected by the compression.
There are two main issues with the text in [RFC8200]. The first is that the following sentence is no longer correct: "... the Destination Address used in the pseudo-header is that of the final destination. At the originating node, that address will be in the last element of the Routing header". The second issue is that the text in [RFC8200] currently does not cover the case where SRv6 is used without an SRH. I believe that the first issue requires an update to [RFC8200], because otherwise it contradicts the compression document. The second issue, in my opinion, should be updated in [RFC8200] to avoid confusion, and it is pretty straightforward if we are already updating this paragraph regarding the first issue. > Probably. Please suggest text. Sure. I have summarized the problem and my suggestion of how to address it in the following new draft: https://datatracker.ietf.org/doc/draft-mizrahi-spring-l4-checksum-srv6/ As suggested, I am opening a separate thread that includes SPRING and 6MAN. Cheers, Tal. On Wed, Aug 2, 2023 at 4:52 PM Joel Halpern <j...@joelhalpern.com> wrote: > > Speaking personally, not as chair. > > As far as I know, there is no need for an update to 8200 for this > quasi-problem. > > Let's state the problem with or without SRH. > > If two trusted hosts inside a trusted domain that uses SRv6 are > communicating, and the path they wish to select has more than one hop, > then when the sending host computes the upper layer checksum, it has to > use the eventual destination, not the destination with which it will > send the packet to the wire. This is true whether SRH is used, whether > gSID or uSID are used, or any other technique we invent later. > > Should this have been better spelled out in RFC 8754? Probably. > > Should the compression document note that it adds more cases to this? > Probably. Please suggest text. > > Is this a corner case that I personally consider quite rare? Yes, > although it was the original excuse for the authentication TLV. > > Yours, > > Joel > > On 8/2/2023 1:58 AM, Tal Mizrahi wrote: > > Darren, Authors, Chairs, > > > > Thanks for the quick response. > > > > In that case I have two comments: > > > > 1. I believe that the fact that a compressed segment list can be sent > > without an SRH should be explained earlier in the document, i.e., in > > the introduction. Actually the title of the draft is a bit misleading. > > I would suggest to change it from "Compressed SRv6 Segment List > > Encoding in SRH" to simply "Compressed SRv6 Segment List Encoding". > > > > 2. It appears that there is an issue with the L4 checksum computation > > which requires an update to RFC 8200. The L4 checksum is computed > > using a pseudo-header which includes the IPv6 addresses. In the case > > where a compressed segment list is sent without an SRH, this would > > cause an inconsistent L4 checksum computation between the sender and > > the receiver (SR ingress and egress nodes). While there is some text > > in Section 10.2 of the compression draft that slightly hints to this > > problem, there needs to be an explicit update to RFC 8200. > > > > A question to the chairs: is the L4 checksum issue something that can > > be resolved in SPRING, or does it have to go through 6MAN? > > > > Here is the text I was referring to from [RFC 8200]: > > OLD: > > If the IPv6 packet contains a Routing header, the Destination > > Address used in the pseudo-header is that of the final > > destination. At the originating node, that address will be in > > the last element of the Routing header; at the recipient(s), > > that address will be in the Destination Address field of the > > IPv6 header. > > > > I would propose the following alternative text to [RFC 8200]: > > NEW: > > If the IPv6 packet contains a Routing header, the Destination > > Address used in the pseudo-header is that of the final > > destination. At the recipient(s), that address will be in the > > Destination Address field of the IPv6 header. At the > > originating node, that address will be the Destination > > Address as it is expected to be received by the destination. > > Note, that if segment list compression > > [I-D.ietf-spring-srv6-srh-compression] is used, then the > > Destination Address as received by the destination may be > > different than the last element of the Routing header. > > Similarly, if segment list compression is used without using the > > Routing header, then the Destination Address used in the > > pseudo-header is the address that is expected to be received > > by the destination. > > > > Cheers, > > Tal. > > > > On Tue, Aug 1, 2023 at 6:46 PM Darren Dukes (ddukes) <ddu...@cisco.com> > > wrote: > >> That is correct. > >> ________________________________ > >> From: spring <spring-boun...@ietf.org> on behalf of Tal Mizrahi > >> <tal.mizrahi....@gmail.com> > >> Sent: Tuesday, August 1, 2023 4:29 AM > >> To: draft-ietf-spring-srv6-srh-compress...@ietf.org > >> <draft-ietf-spring-srv6-srh-compress...@ietf.org>; spring@ietf.org > >> <spring@ietf.org> > >> Subject: [spring] Question regarding draft-ietf-spring-srv6-srh-compression > >> > >> Dear Authors, > >> > >> I have a question regarding the following two paragraphs from the > >> draft (at the bottom of the message). > >> If I understand the text correctly, if the compressed segment list > >> fits into a single SID, then the entire compressed list can be encoded > >> in the DA, and the packet can be sent without an SRH. Note that this > >> is specifically relevant with the NEXT-C-SID flavor. > >> > >> I would highly appreciate if you can confirm my understanding. > >> > >> Thanks, > >> Tal. > >> > >> > >> Quoting the relevant text from the draft: > >> > >> Regardless of how a compressed segment list is produced, it is encoded > >> in the IPv6 header and optional SRH as described in Section 4.1 and > >> 4.1.1 of [RFC8754]. The text is reproduced below for reference. > >> > >> A source node steers a packet into an SR Policy. If the SR Policy > >> results in a Segment List containing a single segment, and there is > >> no need to add information to the SRH flag or add TLV; the DA is set > >> to the single Segment List entry, and the SRH MAY be omitted. > >> > >> _______________________________________________ > >> spring mailing list > >> spring@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
