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
