Tom, so moving SRv6 into NAT equivalent space is an interesting take, granted (and sure better than bis'ing STD).
Thinking along those lines a) SRv6 becomes L4 aware and goes chasing all the checksums in all L4s to inc adjust them and gets silicon rev'ed up on every new L4 in the future. b) somehow the checksum gets diff'ed up on the compressed header changes into some magic bits to absorb the diff. For this spare bits are needed, possibly quite a lot, I don't remember the precise increment csum math. But where would we find those bits given L4 TCP only goes over src/dst and protocol/tcp len AFAIR so we cannot put it into SRH (which may have been palatable just as NAT was palatable out of desperation). And let's assume we somehow have them, even then to get any performance we start to keep per flow state in some hash for fast adjustments. Not a particularly efficacious use of limited silicon and especially very limited power to drive it to maximize goodput. c) so the SRH with some more magic inside driving endpoint to change the L4 stack seems feasible (xiao draft probably) while hoping that none of the intermediate hops do for any reason csum validation on the frame flying by after the sids in the destination address changed. And even then, I remember years and years of supposedly fun things like having to re-muck FTP and bunch other things due to reasons you surely remember once NAT was in place; SIP/IPSEC NAT detection and so on. Endpoint could possibly remedy that by patching the destination address into frame from SRH of course. But yeah, let's see we start to see further fallout here as well. -- tony On Thu, Aug 3, 2023 at 8:18 PM Tom Herbert <t...@herbertland.com> wrote: > On Thu, Aug 3, 2023 at 9:30 AM Tony Przygienda <tonysi...@gmail.com> > wrote: > > > > well, turns out using a destination address to piggy back some > computation semantics and especially changing it in mid-flite is not a > great idea. Who knew ... > > Tony, > > We already have a working example on how to change destination > addresses in flight and deal with L4 checksums: NAT. So compressed > SIDs in Destination address could work if typical NAT processing to > adjust the TCP/UDP checksum is performed each time the Destination > address is written with a different SID. This method would require no > update to RFC8200 nor any changes to deployed IPv6 stacks. > > Tom > > > > > as to bis'ing STD86 I was quickly thinking "it's not April yet" ... > > > > -- tony > > > > > > On Thu, Aug 3, 2023 at 9:43 AM <xiao.m...@zte.com.cn> wrote: > >> > >> Hi Tal, > >> > >> > >> Please note that there is an existing draft: > >> > >> https://datatracker.ietf.org/doc/draft-xiao-spring-srv6-checksum/ > >> > >> which attempts to address the problem you found and another one > described in the penultimate paragraph of the Introduction section, in a > different way not requiring to update RFC 8200. > >> > >> > >> Best Regards, > >> > >> Xiao Min > >> > >> Original > >> From: TalMizrahi <tal.mizrahi....@gmail.com> > >> To: spring@ietf.org <spring@ietf.org>;i...@ietf.org <i...@ietf.org>; > >> Date: 2023年08月03日 15:03 > >> Subject: [IPv6] New draft: L4 Checksums in SRv6 > >> > >> Hi, > >> > >> This new draft introduces a proposed update to [RFC8200], which is > >> intended to address compressed segment lists in SRv6 > >> [draft-ietf-spring-srv6-srh-compression]. > >> > >> Link to the new draft: > >> https://datatracker.ietf.org/doc/draft-mizrahi-spring-l4-checksum-srv6/ > >> > >> There was some discussion in the SPRING mailing list about this issue. > >> > >> The current thread is intended to allow a wider discussion that > >> includes the 6MAN working group, and therefore the new draft includes > >> a wider background. > >> > >> Feedback will be welcome. > >> > >> Cheers, > >> Tal. > >> > >> -------------------------------------------------------------------- > >> 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
