Hi, Actually for OAM responses in vast majority of cases vanilla IPv6 packets can be used.
Kind regards, R. On Wed, Feb 7, 2024, 10:58 Mark Smith <markzzzsm...@gmail.com> wrote: > > > On Wed, 7 Feb 2024, 20:08 Robert Raszuk, <rob...@raszuk.net> wrote: > >> 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. >> > > I think it would also occur with an SRH if a middlebox is ignoring the SRH > EH (e.g. unaware of how to handle it, or ignoring some or all IPv6 EHs) and > validating the pseudo-header checksum when the packet's current DA isn't > the final one, which of course it may not be if the packet is somewhere > where in flight between the origin SA and the final DA. > > For a middlebox to validate the L4 pseudo header checksum somewhere during > flight, it would have to determine the final DA for the calculation by > digging it out of the SRH rather than using the packet's current DA. > > Without an SRH the middlebox would have to process the C-SIDs in the > packet's DA field until it could identify the final DA before then > performing the L4 pseudo-header calculation and validation. > > The would be conditional on the SRv6 payload being TCP, UDP or ICMPv6 and > the middlebox being SRv6 aware (i.e. understand SRH when present) and SR > configured to identify C-SID DAs (SRH'less). > > So I don't really see how including an SRH in OAM packets solves the > problem unless the middlebox is SRv6 aware. > > 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
