Hi Mark, > however UDP and ICMPv6 would be for OAM per RFC 9269
I do agree if we are talking about no SRH containing packets. And this is precisely why I said "vast majority of packets" not "all packets" Glad that you nailed it on the list. Cheers, R. PS. What Ron suggests is too big of a hammer. Instead I see no reason why OAM packets should not contain SRH and resolve the nit that way. On Wed, Feb 7, 2024 at 5:44 AM Mark Smith <markzzzsm...@gmail.com> wrote: > > > On Tue, 6 Feb 2024, 03:17 Robert Raszuk, <rob...@raszuk.net> wrote: > >> 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. >> > > > If the payload of the SRv6 packet is another IP packet or layer 2 frame > e.g. Ethernet, common for L2 and L3 VPNs, then the layer 4 checksum issue > probably wouldn't occur, because those protocols don't include the IPv6 > pseudo-header fields in their checksum calculations if they even have a > checksum at all - RFC 2473 IPin IPv6 doesn't, and in GRE it is optional. > > However, if SRv6 was used to to directly carry an upper layer transport > layer protocol PDU like UDP, TCP or ICMPv6, then that's when the > checksum/middlebox issue arises, because they do include the IPv6 > pseudo-header in their checksum, which would therefore include the SRv6 SA > and DAs. > > Not sure if TCP would be commonly carried directly in an SRv6 packet, > however UDP and ICMPv6 would be for OAM per RFC 9269. > > So your SRv6 L2 or L3 VPN might be able to carry customer traffic > successfully through a middle box, however you may not be able to SRv6 > traceroute or ping across it successfully, or have ICMPv6 error > successfully sent between SRv6 nodes. > > Regards, > Mark. > > >> 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 >> >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
