Hi Alvaro, all, RFC 8754 allows the SR source node to omit the SRH when it contains redundant information with what is already carried in the base IPv6 header. Mandating its presence for C-SID does not resolve any problem because it will not provide any extra information to the nodes along the packet path.
Specifically for the case of middleboxes attempting to verify the upper-layer checksum, - An SRv6-unaware middlebox will not be able to verify the upper-layer checksum of SRv6 packets in flight, regardless of whether an SRH is present or not. - An SRv6 and C-SID aware middlebox will be able to find the ultimate DA and verify the upper-layer checksum in flight, regardless of whether an SRH is present or not. Furthermore, transit nodes (e.g., middleboxes) should not attempt to identify SRv6 traffic based on the presence of the SRH, because they will miss a significant portion of it: all the best-effort or Flex-Algo traffic steered with a single segment may not include an SRH, even without C-SID. Instead, RFC 8402, 8754, and 8986 define identification rules based on the SRv6 SID block. Thanks, Francois On 2 Apr 2024 at 19:44:51, Alvaro Retana <aretana.i...@gmail.com> wrote: > [Moving this conversation up on your mailbox. :-) ] > > [Thanks, Robert and Tom for your input!] > > > We want to hear from more of you, including the authors. Even if you > already expressed your opinion in a different thread, please chime in here. > > We will collect feedback until the end of this week. > > Thanks! > > Alvaro. > > On March 28, 2024 at 8:06:18 AM, Alvaro Retana (aretana.i...@gmail.com) > wrote: > > > Focusing on the C-SID draft, some have suggested requiring the presence of > the SRH whenever C-SIDs are used. Please discuss whether that is the > desired behavior (or not) -- please be specific when debating the benefits > or consequences of either behavior. > > Please keep the related (but independent) discussion of requiring the SRH > whenever SRv6 is used separate. This larger topic may impact several > documents and is better handled in a different thread (with 6man and spring > included). > > Thanks! > > Alvaro > -- for spring-chairs > > -------------------------------------------------------------------- > 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
