Hi Mike, Re: Are you using HL counting out as a means to do something? No – as explained in the following.
A traceroute tool typically attempts to discover the path to a destination by sending OAM probes with a specific Hop Limit value in the IP packet header and trying to provoke an ICMP error (TIME_EXCEEDED) response from the target node. The target node, if local policy permits, creates an ICMP error message with IPv6 HL set to 64. The draft does not discuss any other use or manipulation of the HL beyond this traceroute use case. As the draft addresses the CE-to-CE (traceroute) use case where the provider is using the Uniform Model [RFC3443], HL is copied from the inner packet to the provider header. Nonetheless, the provider core only operates on the HL value in the provider header. The contents of the inner header are used to find the initiator CE address so an ICMP error can be sent to the initiating node. Per local policy, the P node applies SRv6 encapsulation to the ICMP error response to route the packet to the initiator CE. The scope of the draft is OAM, and hence the procedure is applied only for sending an ICMP error (to a CE node). Thanks Regards … Zafar From: Mike Simpson <[email protected]> Date: Monday, October 20, 2025 at 8:49 AM To: Zafar Ali (zali) <[email protected]> Cc: Mustapha Aissaoui <[email protected]>, Krzysztof Szarkowicz <[email protected]>, Alexander Vainshtein <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, List SPRING WG <[email protected]>, Zafar Ali (zali) <[email protected]> Subject: Re: [IPv6]Re: draft-ali-6man-srv6-vpn-icmp-error-handling Are you using HL counting out as a means to do something? It looks like what you are wanting is that HL will count down but at the point at which the packet is discarded you want it to “de-encapsulate” the SRV6 address, give it another non-zero HL, then send it on its way. What’s the point of HL in your scenario? Why can you resurrect a packet that has exceeded its hop limit. How are you able to demonstrate that this will never lead to rogue behaviour and if your answer to that is “limited domain” then this is just self-interest motivated shenanigans and is exactly the sort of BS that the IETF should have been able to resist if it wasn’t for malignant behaviour by vendors who only care about their quarterly earnings report. It’s like a bad joke. “When is a hop limit not a hop limit” These changes are going to go down in our short history as the worst changes to be inflicted on the internetworks ever and will be as a direct result of sociopathic behaviour. -please remember that the people shoving this through don’t care about the damage they will do. They and the vendors that are behind them driving this aren’t working for the common good. All of this needs to have its own special corner where its vendors can deploy it. An actual walled garden, as it is allowing this crap to claim that it’s IPv6 in its header means that it is going to be appearing everywhere and causing all sorts of trouble to a huge proportion of the *gigantic amounts of deployed running code*. -we surely realise by now that “limited domain” is code for at best “someone else’s problem” Forcing them to have a new protocol version means that all the current install base will have a chance at handling it gracefully and anyone that has to use the new features can be the ones to deploy it and the rest of us get the choice rather than having it forced down our pipes. We used to prioritise deployed code. How did the culture change to the point where we are thinking of doing this? LOn 17 Oct 2025, at 15:15, Zafar Ali (zali) <[email protected]> wrote: Hello Mustapha, Many thanks for your comments – much appreciated! Based on your feedback, we have added further clarification w.r.t. to the procedure in [RFC2473], Section 8. Please see updates in https://www.ietf.org/archive/id/draft-ali-6man-srv6-vpn-icmp-error-handling-01.txt We will be happy to provide any additional clarification in the draft. Please advise if you have any further comments. Thanks Regards … Zafar From: Mustapha Aissaoui (Nokia) <[email protected]> Date: Friday, July 25, 2025 at 2:30 PM To: Krzysztof Szarkowicz <[email protected]> Cc: Zafar Ali (zali) <[email protected]>, Alexander Vainshtein <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Zafar Ali (zali) <[email protected]>, SPRING WG List <[email protected]> Subject: Re: draft-ali-6man-srv6-vpn-icmp-error-handling Krzysztof, You are correct. When the ping/traceroute probe originates outside of the SRv6 network, example on a CE device, then the relay function as described in RFC 2473 will only work for prefixes in the global routing table and which are resolved to an SRv6 tunnel. The ingress PE cannot perform a relay function for prefixes resolved in a VRF. If the probe originates at the SRv6 PE router, then the relay function can translate the ICMP error received from the SRv6 transit router into the correct routing context in both a VRF and the global routing table. The other point related to RFC 2473 is that the transit SRv6 router must always originate the ICMP reply back to the ingress SRv6 PE. So, the ICMP tunneling feature is not an alternative to it as stated in your draft, it is an alternative to the ICMP relay function. Regards, Mustapha. From: Krzysztof Szarkowicz <[email protected]> Date: Friday, July 25, 2025 at 10:10 AM To: Mustapha Aissaoui (Nokia) <[email protected]> Cc: Zafar Ali (zali) <[email protected]>, Alexander Vainshtein <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Mr. Zafar Ali <[email protected]>, SPRING WG List <[email protected]> Subject: Re: draft-ali-6man-srv6-vpn-icmp-error-handling CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Mustapha, Behavior described in RFC 2473, Section 8 cannot be really used for SRv6 networks. In SRv6, typically ingress PE, when doing IPv6 encap, uses local IPv6 loopback address as the source IPv6 address in the outer header. For all services (i.e., say for all 100 locally configured VRFs). Based on RFC 2473, Section 8, If some transit router would send ICMP error message to the tunnel ingress, how the ingress PE could determine, in which VRF context (out of 100 locally configured VRFs) the to handle it? This problem is highlighted in Section 2 of draft-ali-6man-srv6-vpn-icmp-error-handling, as Zafar already quoted: When the packet comes to P1, the hop limit expires at P1. Without ICMP tunneling enabled on P1, P1 implements the standard procedure from RFC9259<https://datatracker.ietf.org/doc/html/rfc9259>, and therefore sends an ICMPv6 packet towards PE1 as follows: P1_out : (P1::1, PE1::1, HL=64, NH=ICMPv6) (ICMPv6, Time Exceeded, [copy of the invoking packet = (PE1::1, PE2:DT6::, HL=1, NH=IPv6) ((CE1::1, CE2::1, HL=1, NH=UDP)(Traceroute probe))]) the Processing the message at PE1 requires context that the packet was not sourced at PE1. Rules described in RFC 2473, Section 8 do not provide such context. Regards, -- Krzysztof Grzegorz Szarkowicz, HPE Networking PLM, Solutions Architect | Phone: +49 89 203 012 127 Please consider my current time zone, when calling: CEST (UTC+02:00) On 2025 Jul 24, at 23:01, Mustapha Aissaoui (Nokia) <[email protected]> wrote: [External Email. Be cautious of content] Hi Zafar, As far as I know, RFC 9259 did not cover reporting by SRv6 transit routers of ICMP errors when the original probe was for an address of a IPv4/IPv6 prefix which is in the SRv6 service overlay (ICMP message has its own IPv4/IPv6 header which is then encapsulated into SRv6). It only covered ping/traceroute for an IPv6 address of a prefix in the SRv6 underlay (ICMP message encapsulated directedly into SRv6). So, it is a good thing to lay out the procedures of the former case. I would however point that some of the elements of the procedures have been defined in https://datatracker.ietf.org/doc/html/rfc2473#section-8<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc2473*section-8__;Iw!!NEt6yMaO-gk!CQq_FdKjC1gmIXsGJG4jQ7N1Vqiian8wAqFRv79hihx0kcrkd9DMQMiDKTMEWmjTVjCAp5ToOHpDhefmyEnrsOAOGLTzd08$>. This RFC, which builds on a few earlier RFCs, specifies that an ICMP reply must always be sent to the ingress of the outer IP tunnel. In addition, the ingress of the outer IP tunnel will in some cases “relay” the received ICMP error message to the source address of the original payload packet by translating it into the proper error code (it is not an exact 1-to-1 replication of the error code). So, we are dealing with a couple of ICMP error reply messages and not one. The way I interpret this is in the context of SRv6 is as follows: 1. A transit SRv6 router must always send an ICMP error message to the ingress of the SRv6 tunnel and include the IP header and leading payload octets of the original datagram. This is always required. 2. The translation and relaying of the ICMP error message could be done in a few ways. The ingress of the SRv6 tunnel can perform the relay function as described in RFC 2473 or an ICMP tunneling function can perform it at the transit SRv6 router along the lines of what you are proposing in your draft. Regards, Mustapha. From: Zafar Ali (zali) <[email protected]<mailto:[email protected]>> Date: Thursday, July 24, 2025 at 6:45 AM To: Alexander Vainshtein <[email protected]<mailto:[email protected]>>, Krzysztof Szarkowicz <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Zafar Ali (zali) <[email protected]<mailto:[email protected]>>, SPRING WG List <[email protected]<mailto:[email protected]>> Subject: [spring] Re: draft-ali-6man-srv6-vpn-icmp-error-handling CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for additional information. Hi Sasha Many thanks for a fruitful meeting offline. As per your suggestion, I am adding Spring. Re: The situation with MPLS-encapsulated IP-VPN packets is different This is an excellent observation, and you are right. The draft acknowledges the fact that IPv6 case is different than MPLS. “Without ICMP tunneling enabled on P1, P1 implements the standard procedure from RFC9259, and therefore sends an ICMPv6 packet towards PE1 as follows: P1_out : (P1::1, PE1::1, HL=64, NH=ICMPv6) (ICMPv6, Time Exceeded, [copy of the invoking packet = (PE1::1, PE2:DT6::, HL=1, NH=IPv6) ((CE1::1, CE2::1, HL=1, NH=UDP)(Traceroute probe))])” It then lists the motivations for proposing this optional “alternate” procedure (to tunnel ICMP messages). Re: the update tag The scope of processing is an SRv6 capable node with the capability enabled for it. The processing at P node is also limited to the packets where destination of the upper IPv6 header (provide header) is in the SRv6 LOC block, e.g., 5f00::/16 [rfc9602] (which is known to all SRv6 nodes in any deployment). The procedure is never applied to ICMP error handing for packets with destination outside SRv6 LOC block. Therefore, we believe it is backward compatible. No changes to ICMP error processing are suggested (just adds an optional alternate way to “transport” ICMP error message. Thanks Regards … Zafar From: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Date: Thursday, July 24, 2025 at 4:37 AM To: Krzysztof Szarkowicz <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: RE: draft-ali-6man-srv6-vpn-icmp-error-handling Krzysztof, Lots of thanks for your email. I would like to clarify that I do not have any problems with the solution proposed in the draft. I was just trying to say that * The situation with MPLS-encapsulated IP-VPN packets is different * The proposal modifies an existing Standards Track RFC - with all the implications (text, process etc.). My 2c, Sasha From: Krzysztof Szarkowicz <[email protected]<mailto:[email protected]>> Sent: Wednesday, July 23, 2025 10:14 PM To: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [EXTERNAL] Re: draft-ali-6man-srv6-vpn-icmp-error-handling Importance: High Hi Sahsa, Indeed, that are good comments. Thank you for providing them. We will be taking these comments in the next version of the draft. Please see as well my one comment inline. -- Krzysztof Grzegorz Szarkowicz, HPE Networking PLM, Solutions Architect | Phone: +49 89 203 012 127 Please consider my current time zone, when calling: CEST (UTC+02:00) On 2025 Jul 22, at 17:30, Alexander Vainshtein <[email protected]<mailto:[email protected]>> wrote: [External Email. Be cautious of content] Hi, I have watched the presentation of the draft<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ali-6man-srv6-vpn-icmp-error-handling-00__;!!NEt6yMaO-gk!AGUwJRsj-OEw3JuEo5_a5D_zet7e9jK64lzPkSjSJeO2kUwWMXdrxPamVAcN1_roA4oDKbLt0v6-hHLRNepvkvyT5uN7QZc$> at the 6MAN WG session in Madrid today, and I have also looked up the draft after the session was over. I think that the analogy with using the uniform model for TTL handling in MPLS that the draft acknowledges is problematic: When the TTL in the top label in the label stack of an MPLS-encapsulated customer IP packet used for traceroute and this packet is trapped to the CP, the CP knows that this is a labeled packet. It can then look up at the first nibble of the payload (immediately following the BOS), recognize the packet as IPv4 or IPv6, generate a suitable ICMP error message with the destination IPv4 or IPv6 address taken from the MPLS-encapsulated IP header and tunnel it to the remote PE by pushing the label stack of the trapped labeled packet and using the top label to identify the egress interface and the next hop. (The CP does not have any alternatives because MPLS LSPs are unidirectional and does not use any kind of ICMP) [Krzysztof] Not sure, what exactly problem you see. In the draft, the text says, that destination destination IPv4 or IPv6 address from the most inner header is taken (in case, there are more headers), and the packet is tunneled to the remote PE by pushing the original stack of IPv6 headers (just modifying the top header: changing the source address to local address, and initializing HL). Destination IPv6 address of top header is used to identify the egress interface and the next hop. Not sure, what problems you see here. When the HL in the IPv6 header pushed by the ingress PE on the customer IP packet used for traceroute expires and this packet is trapped to the CP, the CP sees just an IPv6 packet with HL expired. There is source IPv6 address in the IPv6 header, so that the normal reaction of the CP would be to create an ICMPv6 error message with the destination address taken from the source IP address in this header, i.e., IP address of the ingress PE. This is standardized in Section 3.3 of RFC 4443<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4443*section-3.3__;Iw!!NEt6yMaO-gk!AGUwJRsj-OEw3JuEo5_a5D_zet7e9jK64lzPkSjSJeO2kUwWMXdrxPamVAcN1_roA4oDKbLt0v6-hHLRNepvkvyTkyjjX4k$> – but this is not what you would like to see. From my POV the draft proposes (without explicitly stating that) to change the standard processing of the HL Expired events in IPv6 along the following lines: If the Next Header value in the IPv6 header of an IPv6 packet trapped due to HL expiration is IPv6 or IPv4, consider this packet as an received a SRV6-encapsulated packet used for CE-to-CE traceroute, generate a suitable ICMPv6/ICMP error message, push the IPv6 header with high enough HL value and the rest of the fields copied from the UIPv6 header of the trapped packet and subject it to IPv6 forwarding. If f the above understanding is correct, then: The draft: Indeed should be handled by the 6MAN WG The intended status should remain Standards Track The metadata should say that the draft updates RFC 443 (if approved) The text should be augmented with appropriate IETF terms expressing requirement levels and explicitly define the desired behavior using these terms (instead of or in addition to) illustrations. It should also address the situations in which the IPv6 header is following by the SRH header etc. Hopefully, these notes will be useful. Regards, Sasha Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] List Info: https://mailman3.ietf.org/mailman3/lists/[email protected]/ --------------------------------------------------------------------
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
