Hi Ron, Is there a problem ?
If I read RFC8200 L4 checksum is computed by the packet *originator and validated by the packet's ultimate receiver. * In all SPRING work to the best of my knowledge the vast majority of packets are only encapsulated by transit nodes. Is there any formal mandate in any of the RFCs that an encapsulating node must mangle the inner packet's L4 checksum ? I don't think so but stand open to get my understanding corrected. Cheers, Robert On Mon, Feb 5, 2024 at 5:04 PM Ron Bonica <rbonica= 40juniper....@dmarc.ietf.org> wrote: > Folks, > > Has anyone proposed a solution to the L4 checksum problem that Andrew > talks about? > > Ron > > Juniper Business Use Only > ------------------------------ > *From:* spring <spring-boun...@ietf.org> on behalf of Andrew Alston - > IETF <andrew-ietf=40liquid.t...@dmarc.ietf.org> > *Sent:* Monday, February 5, 2024 5:21 AM > *To:* spring@ietf.org <spring@ietf.org> > *Subject:* [spring] draft-ietf-spring-srv6-srh-compression > > > [External Email. Be cautious of content] > > Hi All, > > > > (In capacity as a contributor and wearing no other hats) > > > > At this point I cannot support progression of this document until the > issues around the L4 Checksum have been resolved. It’s been clearly stated > in other emails on the list that in certain circumstances the behavior > described in this document break the L4 checksum as defined in RFC8200. > This requires an update to RFC8200 to fix it – and I’m not sure that spring > can update 8200 absent the consent of 6man, which I’m not sure has been > asked for, nor am I sure that a spring document can update something like > 8200 in an area so fundamental as the checksum without a -BIS, which would > have to be done via 6man. The L4 checksum issue though is real – and it > cannot simply be ignored. > > > > I also have deep concerns that the compression document creates something > that (in a similar way to SRv6) creates something that is completely > non-conformant with RFC4291. There are multiple references to this in > draft-6man-sids, and should draft-6man-sids become an RFC I would argue > that it should probably be a normative reference in this document – on the > logic that this document relies on similar RFC4291 violations that srv6 > itself does (and for the record, just because SRv6 itself violates RFC4291 > as is clearly documented in draft-6man-sids – does not make it acceptable > to do so in yet another draft without clear and unambiguously stating the > deviations and ideally updating RFC4291 to allow for said deviations) > > > > I believe these two issues alone are sufficient that to pass this document > would create still further tensions about the relationship between SRv6 and > IPv6 and lead to confusion. As such – I believe these issues need to be > adequately dealt with – and the solutions to them need to be approved by > 6man as the working group that holds responsibility for ipv6 maintenance. > > > > Thanks > > > > Andrew Alston > > > > > > Internal All Employees > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
