Hi Andrew, The originator of an IPv6 packet with a SID in its destination address is an SR source node per RFC 8754. If this SID is one of draft-ietf-spring-srv6-srh-compression, then the node must follow the SR source node specification in section 6 of this document.
I am curious to know which Linux box would verify the upper-layer checksum of transit packets by default (and drop them if unable to validate it). Can you share any pointer (e.g., kernel version)? In my testing on a Linux 5.15 node acting as a software router (default config with only IPv6 forwarding enabled and a static route), those packets were forwarded without any issue. Thanks, Francois On 4 Apr 2024 at 16:27:51, Andrew Alston - IETF <andrew-i...@liquid.tech> wrote: > Francois, > > > > Node A sends packet to a microsid – without an SRH > > > > 1. The system by default and in all current implementations will have > no way to know it’s a microsid – TX checksumming would therefore break and > the packet would be dropped – irrespective of if its on hardware offload to > every NIC in existence or if the kernel is doing it – the kernel cannot > differentiate between a microsid outbound and a normal ipv6 address > 2. If you get around (a) then the checksum is invalid in flight until > the end node – if you have a software router that is doing RX validation on > received packets – which – most linux boxes will do by default – the packet > will get dropped > 3. If you get around (a) and assume that the linux box in question is > doing RX HW checksumming – same thing applies – the checksum will be > invalid according to the DA – and without an SRH it cannot calculate it > > > > > > This makes this entire thing incompatible with existing deployments of any > software based routers out there based on bsd, linux and other such kernels > – and is therefore – a direct violation of the spring charter which says > that compatibility with existing deployments cannot be affected. > > > > Andrew > > > > > > * Internal All Employees From: *Francois Clad <fclad.i...@gmail.com> > *Date: *Thursday, 4 April 2024 at 17:19 > *To: *Andrew Alston - IETF <andrew-i...@liquid.tech> > *Cc: *SPRING WG List <spring@ietf.org>, Robert Raszuk <rob...@raszuk.net>, > Joel Halpern <jmh.dir...@joelhalpern.com> > *Subject: *Re: [spring] C-SIDs and upper layer checksums > (draft-ietf-spring-srv6-srh-compression) > > 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. > > > > Andrew, > > > > What do you mean “in the middle”? Is this software router the SR source > node, transit node, an intermediate SR segment endpoint, or the last SR > segment endpoint node by RFC 8754 terminology? > > > > Thanks, > > Francois > > > > On 4 Apr 2024 at 16:07:31, Andrew Alston - IETF <andrew-i...@liquid.tech> > wrote: > > Francois, > > > > So what happens with software routers in the middle that are doing rx > offloading? The NIC’s will reject the packets. And in a pure software > router by default any software router will see an incorrect checksum – and > reject the packet. Because effectively in this case software routers are > acting as middle boxes. > > > > Thanks > > > > Andrew > > > > > > > > > > Internal All Employees > > *From: *Francois Clad <fclad.i...@gmail.com> > *Date: *Thursday, 4 April 2024 at 16:59 > *To: *Andrew Alston - IETF <andrew-i...@liquid.tech> > *Cc: *SPRING WG List <spring@ietf.org>, Robert Raszuk <rob...@raszuk.net>, > Joel Halpern <jmh.dir...@joelhalpern.com> > *Subject: *Re: [spring] C-SIDs and upper layer checksums > (draft-ietf-spring-srv6-srh-compression) > > 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 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> > 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
