Hi Tom, Tcpdump can determine that this packet is steered onto an SRv6 path by checking if the DA matches the SRv6 SID block.
Thanks, Francois On 4 Apr 2024 at 16:59:59, Tom Herbert <t...@herbertland.com> wrote: > > > On Thu, Apr 4, 2024, 9:39 AM Francois Clad <fclad.i...@gmail.com> wrote: > >> Hi Mark, >> >> Tcpdump/wireshark decodes the IPv6 header just fine. I do not see any >> issue here. >> > > Francois, > > The problem is that tcpdump can't tell that a packet is an SR packet if > there's no SRH. For instance, if the checksum is not maintained to be > correct in the wire then tcpdump will show that the packet has a bad L4 > checksum, but there's no way to tell if that is an SR packet or if the > checksum is actually bad. This will make debugging checksum failures in the > network much more difficult, and this affects our ability to debug all > traffic not just SR packets. > > Tom > > >> Cheers, >> Francois >> >> On 4 Apr 2024 at 14:09:43, Mark Smith <markzzzsm...@gmail.com> wrote: >> >>> >>> >>> On Thu, 4 Apr 2024, 22:50 Francois Clad, <fclad.i...@gmail.com> wrote: >>> >>>> 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. >>>> >>> >>> How are troubleshooting tools like 'tcpdump' going to know how to >>> automatically decode these packets as SRv6 packets if there is no SRH? >>> >>> >>> >>>> 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 >>>>> -------------------------------------------------------------------- >>>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> i...@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> >>> -------------------------------------------------------------------- >> 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
