Well software could know that but not NICs nor ASICs ... 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
