Joel, > On Mar 28, 2024, at 8:46 AM, Joel Halpern <j...@joelhalpern.com> wrote: > > Robert, as far as I can tell, you are asking for a different change than any > of the other proposals. If I understand, you are proposing that even end > hosts inside an SRv6 domain should encapsulate the underlying IPv6 packet. > In order to help the chairs keep track, and tell if there are other folks who > also support such a change, I have changed the subject line and ask that if > there is more to say, people use this subject line. > > I look forward to comments from folks beyond Tom and Robert on this subject. >
The text Robert quotes from RFC8200 is correct. However, as it says, the use of zero checksum in encapsulated UDP must follow the recommendations in RFC6936. I don’t know if what is being proposed does that or not. It would be good to clarify that. Bob > Yours, > > Joel M. Halpern > > On 3/28/2024 11:40 AM, Robert Raszuk wrote: >> Hi Tom, >> >> Not really. >> >> RFC8200 defines an exception which is tunneling and says: >> As an exception to the default behavior, protocols that use UDP >> as a tunnel encapsulation may enable zero-checksum mode for a >> specific port (or set of ports) for sending and/or receiving. >> Any node implementing zero-checksum mode must follow the >> requirements specified in "Applicability Statement for the Use >> of IPv6 UDP Datagrams with Zero Checksums" [RFC6936 >> <https://datatracker.ietf.org/doc/html/rfc6936>]. >> >> So in practice if we always tunnel SRv6 there is no issue. >> >> Even Andrew agreed with that :) >> >> Cheers, >> Robert >> >> On Thu, Mar 28, 2024 at 4:36 PM Tom Herbert <t...@herbertland.com >> <mailto:t...@herbertland.com>> wrote: >>> On Thu, Mar 28, 2024 at 7:46 AM Robert Raszuk <rob...@raszuk.net >>> <mailto:rob...@raszuk.net>> wrote: >>> > >>> > Hi Tom, >>> > >>> > > because of SRH >>> > >>> > Ok I buy this that there are devices which do check checksum and are not >>> > final destination of the packets ... I was more talking about plain >>> > forwarding devices (aka P routers). Then I doubt firewalls would be >>> > sitting in the core of the networks. >>> > >>> > But let me come black to what I believe is the main disconnect. >>> > >>> > Why SRH would cause an issue ? I think there is claimed issue *ONLY* with >>> > SRv6 packets which are not encapsulated - call it raw - sent by the hosts >>> > which talk SRv6 and sent with more then one SID/uSID which may get >>> > swapped on the way. >>> > >>> > Because only in those cases the destination address will be changing >>> > while checksum of the tunnel header will not be zero. >>> > >>> > So what we should I think discuss are really B.1 and B.2.2 cases. >>> >>> Robert, >>> >>> The scenario that I'm talking about is really simple, and it's not >>> specific to segment routing. If someone sends a TCP in an IPv6 packet >>> with no routing header then the convention is that the TCP checksum is >>> valid end to end. So if the addresses are changed in flight, like in >>> NAT, then we expect that some part of the packet covered by the >>> checksum is adjusted to offset the change. If a packet is sent in >>> segment routing without an SRH with EtherType 0x86DD then it IS an >>> IPv6 packet to the network so all the conventions and requirements of >>> IPv6 should be applied. IMO, if SRv6 can't maintain these conventions >>> and requirements then it should fork from IPv6 and use a different >>> EtherType. >>> >>> Tom >>> >>> > >>> > Francois, Pablo - could you comment on this how often do we see those >>> > type of SRv6 deployments ? And also could you comment if operator who >>> > enables SRv6 in the first place sees those checksum errors how difficult >>> > is to address it ? >>> > >>> > Thx, >>> > Robert >>> > >>> > >>> > On Thu, Mar 28, 2024 at 3:29 PM Tom Herbert <t...@herbertland.com >>> > <mailto:t...@herbertland.com>> wrote: >>> >> >>> >> On Thu, Mar 28, 2024 at 6:26 AM Robert Raszuk <rob...@raszuk.net >>> >> <mailto:rob...@raszuk.net>> wrote: >>> >> > >>> >> > Hi Alvaro, >>> >> > >>> >> > On this specific topic I think you have flatted it a bit too much. >>> >> > >>> >> > These are apparently the options on the table: >>> >> > >>> >> > A) Original packet get's encapsulated with IPv6 header >>> >> > >>> >> > A.1 SHR is added to it >>> >> > >>> >> > A.1.1. Regular SIDs are used >>> >> > A.1.2 Compresses SIDs are used >>> >> > >>> >> > A.2 SRH is not added to it >>> >> > >>> >> > A.2.1. Regular SID is used as destination >>> >> > A.2.2 Compresses SIDs are used in a container >>> >> > A.2.3 Compresses SID is used >>> >> > >>> >> > B) Original packet get's send from SRv6 host (without encapsulation) >>> >> > >>> >> > B.1 SHR is added to it >>> >> > >>> >> > B.1.1. Regular SIDs are used >>> >> > B.1.2 Compresses SIDs are used >>> >> > >>> >> > B.2 SRH is not added to it >>> >> > >>> >> > B.2.1. Regular SID is used as destination >>> >> > B.2.2 Compresses SIDs are used in a container >>> >> > B.2.3 Compresses SID is used >>> >> > >>> >> > So within all checksum related discussions so far it seems that the >>> >> > only concern is about B.2.2 and perhaps B.1 however folks did state >>> >> > that if there is SRH added there is no issue so I am not sure how the >>> >> > presence of SRH fixes it. >>> >> > >>> >> > Maybe there was some assumption that presence of SRH mandates >>> >> > encapsulation, but I do not believe this is the case for native SRv6 >>> >> > hosts. >>> >> > >>> >> > All in all I think it should be no business for transit nodes to >>> >> > verify packet's upper layer checksum. I do not know if there is any >>> >> > RFC which would describe what is an expected behavior for transit >>> >> > nodes or even say that they MAY do it. >>> >> >>> >> Robert, >>> >> >>> >> I can go further than that. I believe that intermediate nodes have no >>> >> business parsing into the transport layer, and yet firewalls do that >>> >> all the time even though there is no standard RFC on it (I've asked >>> >> for someone to formalize the requirements of firewalls, but to no >>> >> avail). Validating the checksum in flight is an instance of this, and >>> >> there are devices that commonly do this in deployment. Protocol >>> >> specific checksum offload in NICs is one example. Also, if someone is >>> >> seeing checksum failures in their network, an obvious action is to >>> >> sample packets from routers in the path and look at the traces. If the >>> >> checksum is incorrect on the wire because of SRH then the operator >>> >> sees a whole bunch of checksum errors at the router, but has no way to >>> >> distinguish those packets that are actually good from those that are >>> >> bad. >>> >> >>> >> It's a long established convention in IP that the transport checksum >>> >> is maintained to be correct on the wire-- this is done in NAT by >>> >> adjusting the checksum directly, there's also checksum neutral NAT >>> >> that adjusts another part of the IPv6 header to keep the transport >>> >> layer checksum correct. IMO, deviating from this convention is risky, >>> >> not just to SRH packets but that can have collateral damage like >>> >> breaking the user's ability to debug bad links as I described above. >>> >> >>> >> Tom >>> >> >>> >> > >>> >> > Kind regards, >>> >> > Robert >>> >> > >>> >> > >>> >> > >>> >> > On Thu, Mar 28, 2024 at 1:06 PM Alvaro Retana <aretana.i...@gmail.com >>> >> > <mailto: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 <mailto:i...@ietf.org> >>> >> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> >> >> -------------------------------------------------------------------- >>> >> > >>> >> > -------------------------------------------------------------------- >>> >> > IETF IPv6 working group mailing list >>> >> > i...@ietf.org <mailto: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
