On Thu, Apr 4, 2024, 4:59 PM Robert Raszuk <rob...@raszuk.net> wrote:
> > Well software could know that but not NICs nor ASICs ... > Robert, Sure they do. If a NIC or an ASIC wants to look at the transport layer then they'd have to parse over the Routing Header. So they *know* it's there, and the processing of routing headers is well specified. If they ignore the RH and try to verify checksum based an intermediate address then it won't work-- that's expected behavior. So when RH is present, everyone knows how L4 checksum works. Tom > On Thu, Apr 4, 2024 at 10:57 PM Tom Herbert <t...@herbertland.com> wrote: > >> >> >> On Thu, Apr 4, 2024, 4:00 PM Robert Raszuk <rob...@raszuk.net> wrote: >> >>> Tom, >>> >>> I have full sympathy for your points. >>> >>> But I can not understand how suddenly SR uSID is the issue and normal >>> IPv6 vanilla Routing Headers are ok as defined checksum wise in RFC8200. >>> >>> Maybe someone could elaborate a bit on that ? >>> >> >> Robert, >> >> Because, when a routing header is present we know that the final address >> in the list is the one to used as the destination address in the pseudo >> header. If the last address is uncompressed or can be decompressed without >> additional state then we can calculate the checksum based on that (also, >> that allows us to track flows in the network which is another useful thing >> in a data center). >> >> Tom >> >> >>> Thx, >>> R. >>> >>> PS. And of course in spite of all effort from Alvaro to sort the topics >>> the threads again got completely mangled and everyone is describing their >>> perceived issue in random thread. My gently hint for the chairs would be to >>> log issues in github and have more structured processing them there. >>> >>> >>> >>> On Thu, Apr 4, 2024 at 9:50 PM Tom Herbert <t...@herbertland.com> wrote: >>> >>>> >>>> >>>> On Thu, Apr 4, 2024, 3:37 PM Ole Trøan <otroan= >>>> 40employees....@dmarc.ietf.org> wrote: >>>> >>>>> Tom, >>>>> >>>>> Can you point to any IETF specification requiring that middle boxes >>>>> should be able to validate a l4 checksum? IPsec be damn. It just seems >>>>> like a path we should not go down. >>>>> >>>> >>>> Ole, >>>> >>>> No, but neither can I point to an RFC that says firewalls have to parse >>>> deep into packets. The point is that we know people can and do such things >>>> (packet traces and checksum offload are deployed use cases for this). >>>> >>>> The transport checksum has been maintained to be correct on the wire in >>>> plain UDP,TCP/IPv6 for thirty years even in NAT. Breaking that convention >>>> without considering the ramifications could very well lead to some >>>> unhappiness. And my concern is that problems would not just be confined to >>>> SR packets, but could affect non-SR (like how we debug checksum problems in >>>> non-SR traffic). >>>> >>>> Tom >>>> >>>> >>>>> O. >>>>> >>>>> >>>>> >>>>> On 4 Apr 2024, at 21:22, Tom Herbert <tom= >>>>> 40herbertland....@dmarc.ietf.org> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Apr 4, 2024, 3:12 PM Robert Raszuk <rob...@raszuk.net> wrote: >>>>> >>>>>> Tom, >>>>>> >>>>>> > SR aware routers to update L4 checksum >>>>>> >>>>>> That is completely unrealistic. >>>>>> >>>>>> Show me the box which can forward all interfaces at 800 Gb/s and read >>>>>> entire each packet and compute upper layer checksum on it. >>>>>> >>>>> >>>>> Robert, >>>>> >>>>> It's not necessary to calculate the whole checksum, only the L4 >>>>> checksum needs to be updated by adding in the delta checksum. With IPv6 we >>>>> can also do a checksum neutral mapping. Basically, this uses the low order >>>>> 16 bits in the DA address as the checksum adjustment value. For instance, >>>>> if we can use the low order bits in a SID block then that would be >>>>> simplest >>>>> to implement. >>>>> >>>>> Tom >>>>> >>>>> >>>>>> If anything just do encap and move on. >>>>>> >>>>>> Thx, >>>>>> R. >>>>>> >>>>>> >>>>>> On Thu, Apr 4, 2024 at 7:06 PM Tom Herbert <t...@herbertland.com> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 4, 2024, 12:30 PM Robert Raszuk <rob...@raszuk.net> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Tom, >>>>>>>> >>>>>>>> Yes I am with you here. >>>>>>>> >>>>>>>> However let's observe that this is pretty common best practice to >>>>>>>> disable any hardware offload on the box when running tcpdump or >>>>>>>> wireshark. >>>>>>>> >>>>>>>> In fact some implementations (F5) do it for you automagically :) >>>>>>>> >>>>>>>> And as it has been said based on the fact that hardware offload >>>>>>>> does not understand any Routing Headers it really does not matter if >>>>>>>> it is >>>>>>>> there or not :) >>>>>>>> >>>>>>> >>>>>>> Robert, >>>>>>> >>>>>>> tcpdump is independent of hardware offload. If the checksum is >>>>>>> incorrect per the packet contents we'll see bad checksums reported if we >>>>>>> snoop packets, but like I said, we can't differentiate the bad from the >>>>>>> good. >>>>>>> >>>>>>> Offload becomes an issue for NICs that do protocol specific checksum >>>>>>> offload. We lose the capability on RX which is an inconvenience, on TX >>>>>>> we'd >>>>>>> need to change the implementation to ensure the checksum is not >>>>>>> computed by >>>>>>> HW. >>>>>>> >>>>>>> If SR without SRH is needed, then I believe the best answer is for >>>>>>> SR aware routers to update L4 checksum when they change DA per NAT >>>>>>> requirements. This solves tcpdump as well as offloads. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> >>>>>>>> Cheers, >>>>>>>> R. >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Apr 4, 2024 at 6:11 PM Tom Herbert <tom= >>>>>>>> 40herbertland....@dmarc.ietf.org> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Apr 4, 2024, 11:48 AM Francois Clad <fclad.i...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Tom, >>>>>>>>>> >>>>>>>>>> Tcpdump can determine that this packet is steered onto an SRv6 >>>>>>>>>> path by checking if the DA matches the SRv6 SID block. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Francois, >>>>>>>>> >>>>>>>>> That would require introducing external state to tcpdump for >>>>>>>>> correct operation. This would be a major divergence in both >>>>>>>>> implementation >>>>>>>>> and ops compared to how things work today. >>>>>>>>> >>>>>>>>> Tom >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> -------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> -------------------------------------------------------------------- >>>>>>>>> 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
