6man Working Group Z. Ali Internet-Draft Cisco Systems, Inc. Intended status: Standards Track B. Varga Expires: 8 April 2027 Ericsson J. Halpern K. Szarkowicz HPE M. Manish Meta 5 October 2026 ICMP Error Handling for VPNs in SRv6 Networks draft-alivar-6man-icmp-error-srv6-vpn-00 Abstract The document specifies procedures for handling ICMP error messages in SRv6-based Virtual Private Network (VPN). It describes three methods to improve the ICMP Error Handling for SRv6-VPNs. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Ali, et al. Expires 8 April 2027 [Page 1] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. ICMP Error Handling for SRv6-VPNs . . . . . . . . . . . . . . 4 3.1. Network scenario and Reference Topology . . . . . . . . . 4 3.2. Current operation and limitations . . . . . . . . . . . . 5 4. Improving the ICMP Error Handling for SRv6-VPNs . . . . . . . 6 4.1. Method-1: Involving egress-PE in ICMP forwarding (Changing P operation) . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6 4.1.2. Details of ICMP Error Handling of Method-1 . . . . . 7 4.1.3. Characteristics of Method-1 . . . . . . . . . . . . . 7 4.2. Method-2: VPN associated ICMP processing (Changing ingress-PE operation) . . . . . . . . . . . . . . . . . . 8 4.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Details of ICMP Error Handling of Method-2 . . . . . 9 4.2.3. Optional capabilities . . . . . . . . . . . . . . . . 11 4.2.4. Characteristics of Method-2 . . . . . . . . . . . . . 11 4.3. Method-3: Involving egress-PE in ICMP forwarding (Changing ingress-PE operation) . . . . . . . . . . . . . . . . . . 11 5. Illustration CE-to-CE Traceroute from IPv6 customer edge . . 12 5.1. Method-1: Changing P operation . . . . . . . . . . . . . 12 5.2. Method-2: VPN associated ICMP processing . . . . . . . . 15 5.3. Method-3: Involving egress-PE in ICMP forwarding . . . . 17 6. Illustration CE-to-CE Traceroute from IPv4 customer edge . . 17 6.1. Method-1: Changing P operation . . . . . . . . . . . . . 17 6.2. Method-2: VPN associated ICMP processing . . . . . . . . 21 6.3. Method-3: Involving egress-PE in ICMP forwarding . . . . 22 7. Dealing with complex scenarios . . . . . . . . . . . . . . . 23 7.1. Multi-level encapsulations . . . . . . . . . . . . . . . 23 7.2. Multi-technology . . . . . . . . . . . . . . . . . . . . 23 8. Operational Considerations . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Ali, et al. Expires 8 April 2027 [Page 2] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 1. Introduction Troubleshooting is an essential part of all IP networks. IP VPN service of transport networks always represented a special challenge to provide ICMP error handling, as the hosts in a VPN are not part of the transport network. For VPNs the main challenge to use ICMP for connectivity check and fault localization is that network internal nodes (a.k.a. P routers) are not service (i.e., VPN) aware. Therefore, P routers cannot route VPN-specific ICMP error messages back to the original source of the packet, that triggered the generation of the ICMP error message. Furthermore, in SRv6 networks the P routers may be IPv6-only (i.e., may not support the protocol (e.g. IPv4) or address space used by the VPN clients). The Uniform Model defined in [RFC3443] allows visibility of traversed nodes outside the provider network. This is acheived by allowing the time-to-live (TTL) or hop-limit (HL) fields to propagate during the SRv6 encapsulation of the customer packet. This document proposes solutions that are capable to allow (1) ping or trace for VPN endpoints with transport network visibility; and (2) find broken link or node within the transport network (e.g., SRv6 domain). 2. Terminology 2.1. Terms Used in This Document This document uses the Segment Routing terminology established in [RFC8402] and in [RFC9252]. The reader is assumed to be familiar with those documents and their terminology. The following terms used within this document are defined in [RFC8402]: Segment Routing, SR domain, Segment ID (SID), SRv6, SRv6 SID, Active Segment, and SR Policy. The following terms used within this document are defined in [RFC8754]: Segment Routing Header (SRH). The following terms used within this document are defined in [RFC8986]: NH (next header), SL (the Segments Left field of the SRH), FIB (Forwarding Information Base), SA (Source Address), DA (Destination Address), and SRv6 Endpoint Behavior. Ali, et al. Expires 8 April 2027 [Page 3] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 2.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. ICMP Error Handling for SRv6-VPNs 3.1. Network scenario and Reference Topology [RFC9259] describes how the IPv6 OAM mechanisms can be used to diagnose problems within the SRv6 networks. For example, [RFC9259] explains how the existing traceroute mechanisms for PE-to-PE traceroute. However, [RFC9259] does not describe a mechanism for a CE-to-CE traceroute when the provider network deploys Uniform Model [RFC3443]. Figure 1 shows the reference topology used to describe the ICMP error handling. |<--------- SRv6 Domain -------->| | | +-----+ +----+ +----+ +-----+ CE1----+ PE1 +------+ P1 |------| P2 +------+ PE2 +------CE2 +-----+ +----+ +----+ +-----+ | | |<--------------- VPN -------------->| Figure 1: ICMP Error Handling for VPNs in SRv6 Networks: Reference Topology In the reference topology: CE1 and CE2 are Customer Edge devices of IPv4 or IPv6 data plane capability. CE1::1 is an IPv6 address assigned to CE1. CE2::1 is an IPv6 address assigned to CE2. CE1.1.1.1 is an IPv4 address assigned to CE1. CE2.2.2.2 is an IPv4 address assigned to CE2. PE1 and PE2 are provider edge nodes. Ali, et al. Expires 8 April 2027 [Page 4] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 Node PEj has an IPv6 loopback address PEj::1/128. P1 and P2 are provider core nodes. Node Pj has an IPv6 loopback address Pj::1/128. Node Pj might have or might not have IPv4 address; if IPv4 address is assigned, it has an IPv4 loopback address Pj.j.j.j/32. Note: The IPv6 notations used in this document are not syntactically valid. Letters such as 'P', 'j', 'src', and 'dst' are not hexadecimal IPv6 components, but used for better human readability and refer to symbolic placeholders. (SA1,DA1,HL=x,NH=IPv6)(SA2,DA2,HL=y,NH=UDP)(UDP payload) represents an IPv6 packet with: * Outer IPv6 header with source address SA1, destination address DA1, and IPv6 as the next header. The hop limit of the packet is x. * IPv6 follows the inner IPv6 header with source address SA2 and destination address DA2 with hop limit of y and NH = UDP. * (UDP payload) represents the UDP payload of the packet. (SA1,DA1,HL=x,NH=IPv4)(SA2,DA2,TTL=y)(UDP payload) represents a similar IPv6 packet with an IPv4 inner header with TTL of y. Note: The CE nodes can be IPv6 or IPv4 nodes. Please note that traceroute to a SID is exemplified using UDP probes. However, the procedure is equally applicable to other implementations of the traceroute mechanism. The UDP-encoded message to traceroute a SID uses the UDP ports assigned by IANA for "traceroute use". Without loss of generality, the rest of the document focuses on ce- to-ce traceroute in SRv6-VPN. However, the procedure applies to all ICMPv6 error types handling in SRv6-based VPN. 3.2. Current operation and limitations The issue addressed by this draft is illustrated using a traceroute scenario using the reference topology. CE1 and CE2 are IPv6-capable routers. Consider processing the following traceroute packet at P1: Ali, et al. Expires 8 April 2027 [Page 5] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 CE1_out : (CE1::1, CE2::1, HL=2, NH=UDP)(Traceroute probe) Please note, in PE1 HL propagation is enabled, thus the value of HL in the outer header is propagated from the inner header, i.e.,: PE1_out : (PE1::1, PE2:DT6::, HL=1, NH=IPv6) ((CE1::1, CE2::1, HL=1, NH=UDP)(Traceroute probe)) When the packet comes to P1, the hop limit expires at P1. P1 implements the standard procedure from [RFC4443] Section 3.3, [RFC2473] Section 8, and sends an ICMPv6 erro 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))]) When the ICMP error arrives to PE1, PE1 needs to generate an ICMPv6 (or ICMPv4) error message towards the originating CE1. However, the ICMP error message does not contains any local information about the VPN, where CE1 resides in. Therefore, despite the fact that CE1 is directly connected, PE1 cannot route directly the VPN-specific ICMP error messages back to the original source of the packet (i.e., CE1), that triggered the generation of the ICMP error message. 4. Improving the ICMP Error Handling for SRv6-VPNs 4.1. Method-1: Involving egress-PE in ICMP forwarding (Changing P operation) 4.1.1. Overview In Method-1 procedure the SRv6 capable P node sends (tunneles) the error towards the end of SRv6 cloud using the VPN SID of the egress PE. The VPN SID of the egress PE is obtained from the invoking packet. This is similar to handling such cases in MPLS network where message is sent (tunneled) to end of the LSP. Once the packet reaches the egress PE, ICMP packet is decapsulated. Subsequent forwarding table lookup on ICMP packet DA results in the ICMPv6 packet being forwarded to the ingress PE using the VPN SID of the Ingress PE. The ingress PE decapsulates the packet and send it to the intended CE. Ali, et al. Expires 8 April 2027 [Page 6] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 4.1.2. Details of ICMP Error Handling of Method-1 Method-1 proposes an alternative procedure in which an SRv6-capable P node can generate the ICMP error message towards the originating CE. Method-1 approach is different compared to the procedure documented in [RFC4443], Section 3.3, and [RFC2473], Section 8 - in SRv6 based networks, for sending ICMP Error messages, triggered in response to received IPv6-encapsulated IPv4 or IPv6 packets are trapped due to HL expiration. This alternate procedure of Method-1 does not require support from the PE1 node. Additionally, an implementation might provide means to administratively limit the application of the alternate procedure for sending ICMP Error messages to only IPv6 packets where the destination address of the upper IPv6 header (provider header) is in the SRv6 Locator block, such as 5f00::/16 reserved address block ([RFC9602]), or any other block used for SRv6 locators in particular deployment. If such administrative limits are imposed, the alternative procedure on sending ICMP Error messages is not applied to packets with a destination address outside the specified SRv6 locator block. CE-to-CE traceroute from IPv6 customer edge when the customer enables HL propagation, as well as ICMP tunneling, works in a way similar to its MPLS counterpart. The P node where HL expires generates an ICMPv6 Time Exceeded message for the CE that initiated the traceroute request. The ICMP error is sent (tunneled) towards the end of the SRv6 cloud using the VPN SID of the egress PE (similar to MPLS, where it is sent to the end of the LSP). The VPN SID of the egress PE is obtained from the packet that the ICMP error invoking packet. Once the packet reaches egress PE, the ICMPv6 packet is decapsulated. Subsequent forwarding table lookup on the ICMPv6 packet destination address results in the ICMPv6 packet being forwarded to the CE that initiated the traceroute request. The CE-to-CE traceroute from the IPv4 customer edge works in the same fashion as the CE-to-CE traceroute from the IPv6 customer edge. The exception is that it is assumed the P node, where TTL expiry occurs, is capable of generating an ICMPv4 Time Exceeded message. That ensures that the IPv4 CE can consume the ICMP message properly. For cases when the provider router is not capable of generating an ICMPv4 packet, we recommend not enabling TTL propagation. 4.1.3. Characteristics of Method-1 ICMP Error Handling of Method-1 has the following characteristics: Ali, et al. Expires 8 April 2027 [Page 7] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 * It assumes that there are no failures between ingress-PE and egress-PE. * It defines new functions only P nodes. * It might provide means to administratively limit the application of the alternate ICMP procedure. * It does not result in additional complexity on PE nodes. * It involves Egress PE nodes in the forwarding of the ICMP error messages. Note: further details (with all pros and cons) to be added in a latter version of the document with similar structure for all three methods. 4.2. Method-2: VPN associated ICMP processing (Changing ingress-PE operation) 4.2.1. Overview While a solution for diagnostics in MPLS VPNs has been created, the solution designed for MPLS based VPN ping or traceroute has many inherited drawbacks. MPLS technology has its special encapsulation, i.e., the MPLS header is a label stack. In case of MPLS, P routers have no options to identify the ingress of the MPLS tunnel, as labels in the header point towards the network egress point. This characteristic restricts the possible solutions to provide VPN- specific ICMP handling in MPLS networks and resulted in involving of egress-PE nodes in the forwarding of the ICMP error messages. IPv6 encapsulation used by SRv6 has an IP SA field referring to the originator of the IP packet, i.e., the ingress endpoint of the SRv6 tunnel. Therefore the MPLS restriction does not have to apply for SRv6 networks. The solution described here takes advantages from this presence of the ingress endpoint information to provide an optimal method and not to change [RFC4443] procedures for P nodes. Node functions in the described method are as follows: 1. Ingress PE (ingress node of the SRv6 tunnel): VPN packet encapsulation follows [RFC3443] Uniform model. The node adds VPN-specific information to the encapsulated packet (i.e., IP SA=VPN-specific-SID of the Ingress PE) and forwards it over the SRv6 network. Ali, et al. Expires 8 April 2027 [Page 8] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 2. P node = Originator of the ICMP error (within the SRv6 domain): it does standard [RFC4443] operation, so an ICMP error message is sent to the originator (i.e., the ingress PE) of the SRv6 encapsulated packet, that caused the ICMP message generation (e.g., when the Hop Limit of the packet expired). 3. Ingress PE: it processes the ICMP error message and forwards it to the original source of the (payload) packet, what is located within the VPN context. This processing is done by a VPN- associated-ICMP-process-function and is described in detail in Section 4.2.2. 4.2.2. Details of ICMP Error Handling of Method-2 Figure 1 shows the reference topology used to describe the ICMP error handling. Packet processing as per Method-2 works as follows: 1. CE1 sends a packet to CE2. 2. PE1 encapsulates the packet in an SRv6 tunnel (using the Uniform model). The IP SA of the encapsulation is a VPN-specific SID of PE1. 3. Encapsulated packet reaches P2 where Hop Limit expires. 4. P2 generates an ICMP Error Message and sends it to PE1, using the VPN-specific SID as an IP DA. 5. PE1 processes the ICMP Error Message according to its VPN- associated-ICMP-process-function and identifies the related VPN instance. 6. PE1 sends the processed ICMP Error Message to CE1. 7. CE1 is informed about the Hop Limit expire event and its network location (i.e., P2). Ali, et al. Expires 8 April 2027 [Page 9] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 The VPN-specific SID of PE1 refers to the VPN instance where the prefixes of the VPN can be looked up. The VPN-specific SID is allocated by the PE. SIDs processing already defines the upper-layer header steps (as per [RFC8986], section 4.1.1). The upper-layer = ICMPv6, therefore there is no need for extra parsing rules. There might be no need for extra SID allocation for a VPN. The solution uses a SID per VPN, what is allocated for the VPN service. More specifically for a VPN service the PE node can allocate SID(s) per- prefix (e.g., End.DX6) or per-vrf (e.g., End.DT6). The solution uses a per-vrf SID (e.g., End.DT6) in the IP SA of the SRv6 encapsulated packets. For more sophisticated VPN configurations (e.g., Hub-and-Spoke VPN) where multiple VRFs (and SIDs) are configured for a given VPN, the VPN specific SID of PE1 always refers to the VRF instance (and its per-vrf SID) where the prefixes of the connected customer site(s) can be looked up. As the locator part of the VPN-specific SID is routable within the SRv6 domain other PE and P nodes of the SRv6 domain can send/route packets to it. The SRv6 encapsulation process on the ingress PE node needs several input information to construct the outer SRv6 header. One group of information is related to the IP DA and the SRH part of the SRv6 encapsulation. They are derived from the remote service information (e.g., VPN SID on the egress PE) and the SR policy (if exists). The SR policy defines the path to which an ingress PE node steers a packet flow. Applying a SR policy means to select the path (e.g., defined by a SID list) and placing the path descriptors into the IP DA and the SRH fields of the outer SRv6 encapsulation. Another group of information is needed as well for the SRv6 encapsulation, like IP SA, Traffic Class, FlowLabel, HopLimit, NextHeader. They are derived by various local functionalities. The here described solution (Method-2) impacts only the selection of the IP SA. As per [RFC9256] the source IP MUST resolve to a unique node in the SRv6 domain, what is fulfilled by the above described VPN- specific SID. All other fields are defined by related RFCs. For example, Traffic Class might be copied from the inner packet, FlowLabel might be locally generated, etc. Ali, et al. Expires 8 April 2027 [Page 10] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 4.2.3. Optional capabilities The VPN-associated-ICMP-process-function may translate the IP address of the Originator-of-the-ICMPv6-error-message (e.g., a P node) to limit the VPN-specific visibility characteristics. For example, if the SRv6 domain operator does not want to export the real NodeIP or SID values used by the SRv6 domain nodes. 4.2.4. Characteristics of Method-2 ICMP Error Handling of Method-2 has the following characteristics: * It works even in case of failures between ingress-PE and egress-PE and it supports direct localization of failures. * It defines new functions only for Ingress PE nodes. * It uses a VPN specifc SID as a source address on ingress PE nodes. * It does not result in additional complexity on P nodes. * It is compliant to existing standards on P nodes, like [RFC4443]. * It makes P nodes service agnostic and allows building IPv6-only core networks. * It does not involve Egress PE nodes in the forwarding of the ICMP error messages. * It can hide the SIDs used inside the SRv6 domain and can provide different visibility for served VPNs if needed. Note: further details (with all pros and cons) to be added in a latter version of the document with similar structure for all three methods. 4.3. Method-3: Involving egress-PE in ICMP forwarding (Changing ingress-PE operation) Rules for processing the received ICMP error message at PE1 is a local decision at PE1. PE1 needs to generate an ICMPv6 or ICMPv4 error message towards the originating CE. If the source address of the original probe packet is a local address, PE1 consumes the packet (e.g., this may be an ICMP error associated with a probe generated by PE1 itself). Ali, et al. Expires 8 April 2027 [Page 11] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 If the source address of the probe packet is not a local address at PE1 (e.g., CE1::1 address is not local), PE1 encapsulate the ICMPv6 or ICMPv4 message with an outer IPv6 header with destination set to the matching VPN SID (PE2:DT6::) and forwards it towards the egress PE. The generated packet loops back from the egress PE towards the invoking CE using the SRv6 data plane. The advantage of this approach is that the node generating ICMP error (P1 in this example) can be a node without SRv6 capability. Node functions in the described method are as follows: 1. Ingress PE (ingress node of the SRv6 tunnel): VPN packet encapsulation follows [RFC3443] Uniform model and forwards it over the SRv6 network. It uses a generic source IPv6 (e.g. loopback IPv6 address) when doing the SRv6 encapsulation. 2. P node = Originator of the ICMP error (within the SRv6 domain): it does standard [RFC4443] operation, so an ICMP error message is sent to the originator (i.e., the ingress PE) of the SRv6 encapsulated packet, that caused the ICMP message generation (e.g., when the Hop Limit of the packet expired). 3. Ingress PE: it processes/manipulates the ICMP error message and forwards it over the network towards the egress-PE. The manipulated ICMP error message is encapsulated based on the outer header(s) of the invoking packet (found in the payload of the received ICMP error packet). 4. Egress PE: it makes a vrf lookup to identify the location of the original source and sends the packet towards it over the network. Note: further details to be added in a latter version of the document. For example, at step 3 in the above list the ingress PE first process the packet in the global routing table to find out what further processing is needed. 5. Illustration CE-to-CE Traceroute from IPv6 customer edge 5.1. Method-1: Changing P operation This section illustares for Method-1 the CE-to-CE Traceroute from IPv6 customer edge in an SRv6-VPN network where the provider network deploys Uniform Model [RFC3443]. Using the reference topology, consider a scenario where CE1 initiates a traceroute request to CE2. CE1 and CE2 are both IPv6 routers. Ali, et al. Expires 8 April 2027 [Page 12] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 The tracerout packet with hop limit set to 2 as it leaves CE1 is encoded as follows: CE1_out : (CE1::1, CE2::1, HL=2, NH=UDP)(Traceroute probe) On PE1, HL propagation is enabled, thus HL value from inner packet is propagated to outer header. PE1_out : (PE1::1, PE2:DT6::, HL=1, NH=IPv6) ((CE1::1, CE2::1, HL=1, NH=UDP)(Traceroute probe)) Note: In some scenarios, a packet might have multiple transport outer IPv6 headers preceding the customer's inner IPv6 header. TI LFA is an example of such a scenario. Specifically, when SRv6 encapsulation mode is used to construct backup TI LFA next-hop, an additional IPv6 header is pushed on the packet. The proposed procedure handles such scenarios. The traceroute displays the TI-LFA backup path when it is active. However, the illustration does not cover such scenarios. When the packet comes to P1, the hop limit expires at P1. Based on a local policy at P1, P1 doesn't follow the standard procedure described in RFC9259 and sends an ICMPv6 packet towards CE1 as follows: P1_out : (PE1::1:,PE2:DT6::,HL=64;NH=IPv6) ((P1::1,CE1::1;HL=64,NH=ICMPv6) (ICMPv6,Time Exceeded, [copy of the invoking packet = ((CE1::1, CE2::1;HL=1,NH=UDP) (Traceroute probe)]) Essentially, the encapsulation of the generated ICMPv6 packet is constructed as follows: * Copy of the original inner IPv6 header and packet (original Traceroute probe). * ICMPv6 packet with: SA = IPv6 address of local node DA = IPv6 source address of the original inner IPv6 header HL = 64 * IPv6 header with: Ali, et al. Expires 8 April 2027 [Page 13] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 SA = IPv6 source address of the original IPv6 outer header DA = IPv6 destination address of the original IPv6 outer header HL = 64 When original packet might have multiple "transport" outer IPv6 headers, or Segment Routing Header (SRH). In such case, the procedure is as follows (from inner to outer): * Copy of the original most inner IPv6 header and packet (original Traceroute probe). * ICMPv6 packet with: SA = IPv6 address of local node DA = IPv6 source address of the original most inner IPv6 header HL = 64 * Copy of all "transport" outer IPv6 and Segment Routing headers from the original packet, except for the most outer IPv6 header. * IPv6 header with: SA = IPv6 source address of the original IPv6 outer header DA = IPv6 destination address of the original IPv6 most outer header HL = 64 The encapsulated packet as it leaves P2 is as follows: P2_out: (PE1::1, PE2:DT6::, HL=63, NH=IPv6)( (P1::1, CE1::1, HL=64, NH=ICMPv6) (ICMPv6, Time Exceeded, [copy of the invoking packet = ((CE1::1, CE2::1, HL=1, NH=UDP) (Traceroute probe)) ]) ) Ali, et al. Expires 8 April 2027 [Page 14] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 When a packet arrives at PE2, it performs the local END.DT6 (or END.DT46) processing, decapsulating the packet and processing the inner IPv6 header. As the destination in the inner packet is CE1::1, PE2 encapsulates it so it can be delivered to CE1::1. Assuming HL/TTL propagation is enabled to PE2, PE2 generates the following packet: PE2_out: (PE2::1, PE1:DT6::, HL=62, NH=IPv6)( (P1::1, CE1::1, HL=62, NH=ICMPv6) (ICMPv6, Time Exceeded, [copy of the invoking packet = (CE1::1, CE2::1, HL=1, NH=UDP)(Traceroute probe) ]) ) The packet is IPv6 routed back to PE1. When this packet arrives at PE1, PE1 performs the local END.DT6 (or END.DT46) processing, decapsulates the packet, and processes the inner IPv6 header. Assuming HL/TTL propagation is enabled on PE1, the inner packet is IPv6 routed back to the CE1 node as follows: PE1_out: (P1::1, CE1::1, HL=59, NH=ICMPv6) (ICMPv6, Time Exceeded, [copy of the invoking packet = ((CE1::1, CE2::1, HL=1, NH=UDP)(Traceroute probe)) ]) CE1 processes the hop limit exceeded packet sourced at P1. CE1 generates a new Traceroute probe with incremented HL. This time, the packet expires at P2. The processing of the packet at P2 is similar to the packet processing at P1. 5.2. Method-2: VPN associated ICMP processing In case of IPv6-VPN service the The VPN-associated-ICMP-process- function operation contains the following steps: 1. It processes the received ICMPv6 error message (originated e.g., from a P node within the SRv6 domain). 2. It identifies the related VPN, based on the VPN-specific IP DA value in the received ICMPv6 error message. Ali, et al. Expires 8 April 2027 [Page 15] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 3. It modifies the ICMP error message: * It removes the SRv6 domain specific encapsulation/header(s) of the received ICMPv6 error message. * It identifies the VPN-specific source of the original packet that caused the ICMPv6 error message, based on the invoking packet header part of the ICMPv6 error message payload. * It removes the SRv6 domain specific header(s) from the invoking packet header part of the ICMPv6 error message payload. * It creates a new header for the ICMP error message, where the IP SA refers to the Originator-of-the-ICMPv6-error-message and the IP DA=SourceIP-of-the-invoking-packet. 4. Forwards the modified ICMP error message according to the local VPN routing table (VRF). From encapsulation perspective the SRv6 VPN service is an IPv6 Tunnel. The described operation of the VPN-associated-ICMP-process- function is inline with the sense of Section 8. of [RFC2473] and can be treated as extending it to use the VPN-specific information in the IP SA for finding the the source of the original IPv6 packet. The ingress PE node is the tunnel entry-point node that receives the ICMP error message generated by a node inside the tunnel, i.e., the P node. The VPN-associated-ICMP-process-function differs from Section 8. of [RFC2473] by keeping the SA of the original ICMP error message and using it in the relayed ICMP error message for the here described VPN described. This section illustares a VPNv6 Traceroute from a customer host. HostA is behind CE1 and HostB is behind CE2. HostA sends the following traceroute packet to HostB. CE1_out : (A::1, B::1, HL=3, NH=UDP) (Traceroute probe) PE1 encapsulates in SRv6. In PE1 HL propagation is enabled. PE1_out : (PE1:VPN1::, PE2:DT6::, HL=2, NH=IPv6) ((A::1, B::1, HL=2, NH=UDP) (Traceroute probe)) Ali, et al. Expires 8 April 2027 [Page 16] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 P1 forwards the SRv6 packet. P1_out : (PE1:VPN1::, PE2:DT6::, HL=1, NH=IPv6) ((A::1, B::1, HL=2, NH=UDP) (Traceroute probe)) Hop limit expires at P2. P2 implements the standard procedure from [RFC4443] and generates an ICMPv6 error message. P2_out : (P2::1:, PE1:VPN1::, HL=64; NH=ICMPv6) (ICMPv6, Time Exceeded, [copy of the invoking packet = (PE1:VPN1::, PE2:DT6::, HL=1, NH=IPv6) ((A::1, B::1, HL=2, NH=UDP)(Traceroute probe)) ]) P1 forwards the ICMPv6 packet. P1_out : (P2::1:, PE1:VPN1::, HL=63; NH=ICMPv6) (ICMPv6, Time Exceeded, [copy of the invoking packet = (PE1:VPN1::, PE2:DT6::, HL=1, NH=IPv6) ((A::1, B::1, HL=2, NH=UDP)(Traceroute probe)) ]) PE1 modifies the received ICMPv6 packet, by removing the SRv6 encapsulation related information. Invoking packet specific VPN service is explicitly identified based on the IP SA of the received ICMPv6 error message. PE1_out : (P2::1, A::1, HL=62, NH=ICMPv6) (ICMPv6, Time Exceeded, [copy of the invoking packet = (A::1, B::1, HL=2, NH=UDP)(Traceroute probe) ]) HostA receives the ICMP error message via CE1. 5.3. Method-3: Involving egress-PE in ICMP forwarding Note: further details to be added in a latter version of the document. 6. Illustration CE-to-CE Traceroute from IPv4 customer edge 6.1. Method-1: Changing P operation This section outlines CE-to-CE traceroute for IPv4 customer edge. Consider the following traceroute packet received at P1 and its processing there: Ali, et al. Expires 8 April 2027 [Page 17] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 CE1_out: (CE1.1.1.1, CE2.2.2.2, TTL=2)(Traceroute probe) On PE1, TTL/HL propagation is enabled; thus, the TTL value from the inner packet is propagated to the outer header: PE1_out: (PE1::1, PE2:DT4::, HL=1, NH=IPv4) ((CE1.1.1.1, CE2.2.2.2, TTL=1) (Traceroute probe)) When the packet reaches P1, its hop limit expires. With ICMP tunneling enabled on P1, it does not follow the standard procedure described in RFC9259 but instead generates and sends an ICMPv4 packet destined to CE1 tunneled via PE2. P1 is assumed to be a node capable of generating ICMPv4. P1 will inspect the payload of the invoking packet and decide to generate an ICMPv4 Time Exceeded message. However, P1 might or might not have a local IPv4 address that could be used as the source address of the ICMPv4 Time Exceeded message. If P1 has a local IPv4 address, it generates and sends an ICMPv4 packet as follows: P1_out: (PE1::1, PE2:DT4::, HL=64, NH=IPv4)( P1.1.1.1, CE1.1.1.1, TTL=64, ICMPv4 Time Exceeded, [copy of the invoking packet = (CE1.1.1.1, CE2.2.2.2, TTL=1)(Traceroute probe)]) If P1 has no local IPv4 address, it sends: P1_out: (PE1::1, PE2:DT4::, HL=64, NH=IPv4)( 192.0.0.8, CE1.1.1.1, TTL=64, ICMPv4 Time Exceeded, NIO=P1::1, [copy of the invoking packet = (CE1.1.1.1, CE2.2.2.2, TTL=1)(Traceroute probe)]) P1 uses 192.0.0.8 as the dummy address for the IPv4 source of the ICMPv4 message, in accordance with Section 4.8 of RFC 7600. It also attaches an NIO (Node Identification Object) to the ICMPv4 message, as specified in Section 3 of [I-D.ietf-intarea-extended-icmp-nodeid]. The NIO provides information about P1's real IPv6 address. Encapsulation of the ICMPv4 packet generated at P1 is as follows (from inner to outer): * Copy of the original inner IPv4 header and packet (original Traceroute probe). * ICMPv4 packet with: Ali, et al. Expires 8 April 2027 [Page 18] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 SA = IPv4 address of local node (if exists), or 198.0.0.8 (if local IPv4 address doesn't exist) DA = IPv4 source address of the original inner IPv4 header TTL = 64 NIO = IPv6 address of local node (only if IPv4 address doesn't exist) * IPv6 header with: SA = IPv6 source address of the original IPv6 outer header DA = IPv6 destination address of the original IPv6 outer header HL = 64 When the original packet has multiple "transport" outer IPv6 headers, the procedure is: * Copy of the original most inner IPv4 header and packet (original Traceroute probe). * ICMPv4 packet with: SA = IPv4 address of local node (if exists), or 198.0.0.8 (if local IPv4 address doesn't exist) DA = IPv4 source address of the original inner IPv4 header TTL = 64 NIO = IPv6 address of local node (only if IPv4 address doesn't exist) * Copy of all "transport" outer IPv6 headers from the original packet. * IPv6 header with: SA = IPv6 source address of the original IPv6 outer header DA = IPv6 destination address of the original IPv6 most outer header HL = 64 Ali, et al. Expires 8 April 2027 [Page 19] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 Examples: P2_out: (PE1::1, PE2:DT4::, HL=63, NH=IPv4)( P1.1.1.1, CE1.1.1.1, TTL=64, ICMPv4 Time Exceeded, [copy of the invoking packet = (CE1.1.1.1, CE2.2.2.2, TTL=1)(Traceroute probe)]) P2_out: (PE1::1, PE2:DT4::, HL=63, NH=IPv4)( 192.0.0.8, CE1.1.1.1, TTL=64, ICMPv4 Time Exceeded, NIO=P1::1, [copy of the invoking packet = (CE1.1.1.1, CE2.2.2.2, TTL=1)(Traceroute probe)]) When a packet arrives at PE2, it performs the local END.DT4 (or END.DT46) processing, decapsulates the packet, and processes the inner IPv4 header. As the destination is CE1.1.1.1, PE2 re- encapsulates the packet for delivery to CE1. Assuming TTL propagation is enabled, PE2 generates the following: PE2_out: (PE2::1, PE1:DT4::, HL=62, NH=IPv4)( P1.1.1.1, CE1.1.1.1, TTL=62, ICMPv4 Time Exceeded, [copy of the invoking packet = (CE1.1.1.1, CE2.2.2.2, TTL=1)(Traceroute probe)]) PE2_out: (PE2::1, PE1:DT4::, HL=62, NH=IPv4)( 192.0.0.8, CE1.1.1.1, TTL=62, ICMPv4 Time Exceeded, NIO=P1::1, [copy of the invoking packet = (CE1.1.1.1, CE2.2.2.2, TTL=1)(Traceroute probe)]) Once received at PE1, it performs END.DT4 (or END.DT46), decapsulates the packet, and routes it to CE1: PE1_out: (P1.1.1.1, CE1.1.1.1, TTL=59, ICMPv4 Time Exceeded, [copy of the invoking packet = (CE1.1.1.1, CE2.2.2.2, TTL=1)(Traceroute probe)]) PE1_out: (192.0.0.8, CE1.1.1.1, TTL=59, ICMPv4 Time Exceeded, NIO=P1::1, [copy of the invoking packet = (CE1.1.1.1, CE2.2.2.2, TTL=1)(Traceroute probe)]) CE1 processes the ICMPv4 Time Exceeded message sourced at P1. If the packet has IPv4 source address 192.0.0.8 with an NIO, CE1 does not use the IPv4 address but instead uses the NIO for operator display. If CE1 does not support NIO, it displays the IPv4 address 192.0.0.8. Ali, et al. Expires 8 April 2027 [Page 20] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 CE1 then generates a new traceroute probe with incremented TTL. This time, the packet expires at P2. P2's processing of the packet is similar to that of P1. 6.2. Method-2: VPN associated ICMP processing In case of IPv4-VPN service the VPN-associated-ICMP-process-function operates as follows (v4/v6 are noted for clarity): 1. It processes the received ICMPv6 error message (originated e.g., from a P node within the SRv6 domain). 2. It identifies the related VPN, based on the VPN-specific IP DA value in the received ICMPv6 error message. 3. It synthesizes an ICMPv4 error message based on the received ICMPv6 error message: * It identifies the VPNv4 specific source of the original IPv4 packet that caused the ICMPv6 error message, based on the invoking packet header parts of the ICMPv6 error message payload. * It creates the header for the ICMPv4 error message, in accordance with [RFC7600] (Section 4.8) and [I-D.ietf-intarea-extended-icmp-nodeid] (Section 3), i.e., IPv4 SA=192.0.0.8, Node Identification Object containing the IPv6 SA of the ICMPv6 error message and IPv4 DA=IPv4-SA-of- the-original-packet. 4. Forwards the modified ICMPv4 error message according to the local VPNv4 routing table (VRF). When PE node is aware of the IPv4 address of the SRv6 node that generated the ICMPv6 error message, then the PE node may use it as the IPv4 SA of the synthesized ICMPv4 message. How the PE node is aware of that information is out-of-scope in this document. This section illustares a VPNv4 Traceroute from a customer host. HostA sends the following traceroute packet to HostB. CE1_out : (A.1.1.1, B.2.2.2, TTL=3, Prot=UDP) (Traceroute probe) PE1 encapsulates in SRv6. In PE1 HL propagation is enabled. PE1_out : (PE1:VPN1::, PE2:DT6::, HL=2, NH=IPv4) ((A.1.1.1, B.2.2.2, TTL=2, Prot=UDP) (Traceroute probe)) Ali, et al. Expires 8 April 2027 [Page 21] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 P1 forwards the SRv6 packet. P1_out : (PE1:VPN1::, PE2:DT6::, HL=1, NH=IPv4) ((A.1.1.1, B.2.2.2, TTL=2, Prot=UDP) (Traceroute probe)) Hop limit expires at P2. P2 implements the standard procedure from [RFC4443] and generates an ICMPv6 error message. P2_out : (P2::1:, PE1:VPN1::, HL=64; NH=ICMPv6) (ICMPv6, Time Exceeded, [copy of the invoking packet = (PE1:VPN1::, PE2:DT6::, HL=1, NH=IPv4) ((A.1.1.1, B.2.2.2, TTL=2, Prot=UDP)(Traceroute probe)) ]) P1 forwards the ICMPv6 packet. P1_out : (P2::1:, PE1:VPN1::, HL=63; NH=ICMPv6) (ICMPv6, Time Exceeded, [copy of the invoking packet = (PE1:VPN1::, PE2:DT6::, HL=1, NH=IPv4) ((A.1.1.1, B.2.2.2, TTL=2, Prot=UDP)(Traceroute probe)) ]) PE1 processes the received ICMPv6 packet and removes the SRv6 encapsulation related information. Invoking packet specific service is explicitly identified based on the IP SA of the received ICMPv6 error message. An ICMPv4 packet is synthetized. PE1_out : (192.0.0.8, A.1.1.1, TTL=62, Prot=ICMPv4) (ICMPv4, Time Exceeded, NIO=P2::1, [copy of the invoking packet = (A.1.1.1, B.2.2.2, TTL=2, Prot=UDP)(Traceroute probe) ]) or when IPv4 address of P2 is known by PE1 PE1_out : (P2.2.2.2, A.1.1.1, TTL=62, NH=ICMPv4) (ICMPv4, Time Exceeded, [copy of the invoking packet = (A.1.1.1, B.2.2.2, TTL=2, Prot=UDP)(Traceroute probe) ]) HostA receives the ICMPv4 error message via CE1. 6.3. Method-3: Involving egress-PE in ICMP forwarding Note: further details to be added in a latter version of the document. Ali, et al. Expires 8 April 2027 [Page 22] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 7. Dealing with complex scenarios 7.1. Multi-level encapsulations Some network scenarios result in a packet having multiple transport outer IPv6 headers preceding the customer's inner IP header. Note: further details to be added in a latter version of the document. 7.2. Multi-technology Network scenarios with daisy-chain of multiple technologies are left for further analysis. Note: further details to be added in a latter version of the document. 8. Operational Considerations To be added in a latter version of the document. 9. Security Considerations This document does not impose any additional security challenges to be considered beyond the security threats described in [RFC9252]. 10. IANA Considerations This document makes no IANA requests. 11. Contributors Gyan Mishra Verizon Inc. Email: gyan.s.mishra@verizon.com Sijo Joy Cisco Systems, Inc. Email: sijoy@cisco.com Ali, et al. Expires 8 April 2027 [Page 23] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 12. Acknowledgements Authors extend their appreciation to Janos Farkas, Ferenc Fejes, Xiao Min, Liu Yao, Greg Mirsky, Syed Kamran Raza, and Mustapha Aissaoui for their insightful comments and productive discussion that helped to improve the document. 13. References 13.1. Normative References [I-D.ietf-intarea-extended-icmp-nodeid] Fenner, B. and R. Thomas, "ICMP Message Extension for Originating Node Identification", Work in Progress, Internet-Draft, draft-ietf-intarea-extended-icmp-nodeid- 06, 28 September 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC7600] Despres, R., Jiang, S., Ed., Penno, R., Lee, Y., Chen, G., and M. Chen, "IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)", RFC 7600, DOI 10.17487/RFC7600, July 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . Ali, et al. Expires 8 April 2027 [Page 24] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, . [RFC9602] Krishnan, S., "Segment Routing over IPv6 (SRv6) Segment Identifiers in the IPv6 Addressing Architecture", RFC 9602, DOI 10.17487/RFC9602, October 2024, . 13.2. Informative References [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, . [RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI 10.17487/RFC9252, July 2022, . [RFC9259] Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. Chen, "Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6)", RFC 9259, DOI 10.17487/RFC9259, June 2022, . Authors' Addresses Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com Ali, et al. Expires 8 April 2027 [Page 25] Internet-Draft ICMP Error Handling for VPNs in SRv6 Net October 2026 Balazs Varga Ericsson Email: balazs.a.varga@ericsson.com Joel Halpern HPE Email: joel.halpern@hpe.com Krzysztof Grzegorz Szarkowicz HPE Email: krzysztof.szarkowicz@hpe.com Manish Kumar Meta Email: mksingh@meta.com Ali, et al. Expires 8 April 2027 [Page 26]