Hi Joel, The ping behavior is described in section 9.1 of the draft ( https://www.ietf.org/archive/id/draft-ietf-spring-srv6-srh-compression-14.html#section-9.1 ).
Specifically, "When pinging a SID of this document via a segment list, the SR source node MUST construct the IPv6 packet as described in Section 6 and compute the ICMPv6 checksum as described in Section 6.5." Please let me know if anything in this text is not clear. Thanks, Francois On 4 Apr 2024 at 16:10:11, Joel Halpern <jmh.dir...@joelhalpern.com> wrote: > <No Hat> > > Does this mean that if I have a source and destiantion host inside an SRv6 > domain, and I am trying to verify a uSID path between them, so I issue the > command ping <usUD-DA>, it will fail? Given that we have documents > describing the use of ping and traceroute with SRv6, shouldn't the > comrpession document say someething about this? > > Your,s > > Joel > On 4/4/2024 9:59 AM, Francois Clad wrote: > > Hi Andrew, > > The originator (TX Linux box in your case) acting as an SR source node for > C-SID must follow the entire Section 6 of > draft-ietf-spring-srv6-srh-compression, including section 6.5 about the > checksum calculation. One cannot expect it to work if it only implements > half of it. > > On the receive side, there is nothing special to do. The DA in the > received IPv6 header is the one that was used for the checksum calculation. > > I do not see anything broken. > > Cheers, > Francois > > On 4 Apr 2024 at 15:32:12, Andrew Alston - IETF <andrew-i...@liquid.tech> > <andrew-i...@liquid.tech> wrote: > >> So in investgiating this further, there is a further problem. >> >> >> >> I’ve checked on 4 different linux boxes with 4 different network cards. >> >> >> >> Linux by default offloads TX checksumming on a lot of network cards. If >> you originate a packet with a microsid and no SRH – and the linux box >> offloads the checksum generation – the checksum generated by the NIC will >> be incorrect – and when the packet arrives at the end host – if that end >> host is running RX checksumming – the checksum will fail and the packet >> will be dropped. >> >> >> >> If you disable TX checksumming – the kernel will have no way to tell if >> the packet is an Ipv6 or a microsid packet, it will therefore use the DA – >> and generate an incorrect checksum. Again – if RX checksumming is enabled >> on the receiving end point – the packet will get dropped. >> >> >> >> Effectively this does NOT just affect middle boxes – it effects anything >> generating a packet directed to a microsid that either offloads the tx to >> hardware (whichi will have no clue this is a microsid) or in the >> alternative is generating tx checksums itself via kernel mechanisms that >> will treat these packets as standard Ipv6 packets. >> >> >> >> This is broken – severely broken. >> >> >> >> Andrew >> >> >> >> >> >> * Internal All Employees From: *spring <spring-boun...@ietf.org> on >> behalf of Francois Clad <fclad.i...@gmail.com> >> *Date: *Thursday, 4 April 2024 at 14:49 >> *To: *Joel Halpern <jmh.dir...@joelhalpern.com> >> *Cc: *SPRING WG List <spring@ietf.org>, Robert Raszuk <rob...@raszuk.net> >> *Subject: *Re: [spring] C-SIDs and upper layer checksums >> (draft-ietf-spring-srv6-srh-compression) >> >> Some people who received this message don't often get email from >> fclad.i...@gmail.com. Learn why this is important >> <https://aka.ms/LearnAboutSenderIdentification> >> >> CAUTION: This email has originated from a free email service commonly >> used for personal email services, please be guided accordingly especially >> if this email is asking to click links or share information. >> >> >> >> Hi all, >> >> >> >> Section 6.5 of draft-ietf-spring-srv6-srh-compression specifies how an SR >> source node originating a packet with an upper layer checksum determines >> the Destination Address for use in the IPv6 pseudo-header. >> >> >> >> As a co-author, I’d say that the current text of 6.5 is good. >> >> >> >> This text is aligned with RFC 8200. It only indicates how the text in >> Section 8.1 of RFC 8200 applies to the SIDs of >> draft-ietf-spring-srv6-srh-compression. This is necessary since RFC 8200 >> does not specify the format nor behavior of any source routing scheme. >> >> >> >> Thanks, >> >> Francois >> >> >> >> >> >> On 4 Apr 2024 at 00:10:55, Joel Halpern <jmh.dir...@joelhalpern.com> >> wrote: >> >> I can not speak to the "norm" for other working groups. The SPRING >> charter is very specific about what we have to do if we want to change an >> underlying protocol. We have to go back to the WG which owns that >> protocol. >> >> 6man gets to decide if the change is acceptable, and if it is acceptable >> how it is to be represented. SPRINGs job is to make sure we are asking the >> question we intend. >> >> Yours, >> >> Joel >> >> On 4/3/2024 6:05 PM, Robert Raszuk wrote: >> >> Ok Joel, >> >> >> >> Thank you for this clarification. >> >> >> >> To me the actual spirit of RFC8200 8.1 is to say that it is ok to >> compute the checksum by the src such that it comes out right at the final >> destination. >> >> >> >> But I guess we can have different opinions about that. >> >> >> >> But what I find specifically surprising here is that it is a norm in IETF >> to have new specifications defining protocol extensions and their behaviour >> and never go back to the original protocol RFC to check if this is ok or >> not. If that would not be a normal process I bet we would still be using >> classful IPv4 routing all over the place. >> >> >> >> Regards, >> >> Robert >> >> >> >> >> >> On Wed, Apr 3, 2024 at 11:28 PM Joel Halpern <j...@joelhalpern.com> wrote: >> >> The concern with regard to the text that the chairs are asking about is >> not about intermediate nodes verifying the checksum. The text does not >> talk aabout that, so we are not asking about that. >> >> But, the text in 8200 specifies how the originating node is to compute >> the upper layer checksum. It doesn't say "do whatever you need to do to >> make the destination come out right". It provides specific instructions. >> Yes, it is understandable that those instructions do not cover the >> compressed container cases. Which is why the compression document >> specifies changes to those procedures. >> >> Thus, we need to ask 6man how they want to handle the change in the >> instructions in 8200. >> >> the question we are asking SPRING is whether there is any clarification >> people want to the text in the compression draft before we send the >> question over to 6man. >> >> Yours, >> >> Joel >> >> On 4/3/2024 5:15 PM, Robert Raszuk wrote: >> >> Hi Joel, >> >> >> >> My interpretation of text from RFC8200 is that it allows discrepancy >> between the header and the upper layer checksum as long as final packet's >> destination sees the correct one. >> >> >> >> The last condition is met. >> >> >> >> So I see no issue. >> >> >> >> Sure RFC8200 does not talk about SRH nor cSIDs, but provides a hint on >> how to handle such future situations. >> >> >> >> With that being said I would like to still understand what real problem >> are we hitting here ... >> >> >> >> Kind regards, >> >> Robert >> >> >> >> On Wed, Apr 3, 2024 at 11:09 PM Joel Halpern <j...@joelhalpern.com> wrote: >> >> There are two cases covered in section 6.5 of the compression draft that >> appear to be at variance with secton 8.1 of RFC 8200. >> >> First, if the final destination in the routing header is a compressed >> container, then the ultimate destination address will not be the same as >> the final destination shown in the routing header. >> >> Second, if a uSID container is used as the destination address and no SRH >> is present, then in addition to the above problem there is no routing >> header to trigger the behavior described. >> >> Yours, >> >> Joel >> >> On 4/3/2024 4:22 PM, Robert Raszuk wrote: >> >> Hi Alvaro, >> >> >> >> Section 6.5 of draft-ietf-spring-srv6-srh-compression describes the >> behavior when an originating node inside an SRv6 domain creates a >> packet with a C-SID as the final destination. >> *This description differs from the text in Section 8.1 of RFC8200.* >> >> >> >> I would like you to clarify the above statement - specifically of the >> last sentence. >> >> >> >> Reason for this that after looking at both drafts I find section 6.5 of >> the subject draft to be exactly in line with RFC8200 section 8.1 especially >> with the paragraf which says: >> >> >> >> >> >> >> >> >> * 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.* >> >> >> >> So before we dive into solutions (as Andrew has already provided a few >> of) I think we should first agree on what precise problem are we solving >> here ? >> >> >> >> Many thx, >> >> Robert >> >> >> >> PS. As a side note I spoke with my hardware folks - just to check if >> validation of upper-layer checksum is even an option for transit nodes. The >> answer is NO as most data plane hardware can read at most 256 bytes of >> packets. So unless there is some specialized hardware processing up to 9K >> packets in hardware at line rates this entire discussion about checksum >> violations, fears of firing appeals is just smoke. >> >> >> >> _______________________________________________ >> 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
