On Fri, Aug 4, 2023 at 2:23 AM Tal Mizrahi <tal.mizrahi....@gmail.com> wrote: > > Hi Tom, > > > 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. > > It is important to remember than an SR ingress node which incorporates > a DA with a compressed segment list is also aware of the final DA as > expected to be received by the SR egress node, and therefore can > compute the checksum.
Tal, Nodes in a path can and sometimes do compute transport layer checksums, not just the source and destination. Even at the endpoints, we have checksum offload which can compute checksums on behalf of their host. If all the packet is in plaintext and unless there is a routing header, it is a long established invariant that the transport layer checksum can be correctly computed by any node just by inspecting the packet contents with no additional state or context. The problem being created here is that the IPv6 Destination address is being overloaded with semantics outside of the standard definition that requires context external to the packet to correctly interpret. I think this is going to have several ill effects in deployment and not just checksum calculation. For instance, there is also a proposal to give SR its own EtherType to make filtering of SR packets at border routers feasible. IMO, the best solution is to always require a SRH with segment routing. This provides a sufficient codepoint in the packet to identify the destination address as SID, addresses the checksum computation concern, and provides a very easy method for border routers to identify SR packets (no new EtherType needed, just look for a routing header). A minimal SRH could even be used at the cost of eight bytes. If it's a hard requirement for SR packets to be sent without SRH (although I'm not sure why it would be) then I do suggest looking at something like NAT to maintain a correct transport checksum when addresses change in flight. As others have said, updating a fundamental requirement in an Internet standard for a narrow use case requiring external context for correct packet processing will be difficult. Tom > > Cheers, > Tal. > > > On Thu, Aug 3, 2023 at 5:47 PM Tom Herbert <t...@herbertland.com> wrote: > > > > 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://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://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
