ICMP Error Handling for VPNs in SRv6 Networks

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 allows visibility of traversed nodes outside the provider network. This document proposes a solution that is 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).

While a solution for diagnostics in MPLS VPNs has been created, the solution created 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. IPv6 encapsulation used by SRv6 has a srcIP 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 to be fully inline with . Node functions in the described method are as follows: Ingress PE (ingress node of the SRv6 tunnel): VPN packet encapsulation follows Uniform model. The node adds VPN specific information to the encapsulated packet (i.e., srcIP=VPN-specific-SID of the Ingress PE) and forwards it over the SRv6 network. P node = Originator of the ICMP error (within the SRv6 domain): it does standard 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., as the Hop Limit of the packet expired). Ingress PE: it processes the ICMP error message and forwards it to the original source of the (passenger) packet (located within the VPN context). This function is called as VPN-associated-ICMP-leak-function and is described in detail in .

shows the reference topology used to describe the ICMP error handling. Packet processing works as follows: HostA sends packet to HostB. PE1 encapsulates the packet in an SRv6 tunnel (Uniform model used). The srcIP of the encapsulation is a VPN specific SID of PE1. Encapsulated packet reaches P2 where Hop Limit expires. P2 generates an ICMP Error Message and sends it to PE1, using the VPN specific SID as a dstIP. PE1 process the ICMP Error Message according to its VPN-associated-ICMP-leak-function and identifies the related VPN instance. PE1 send the processed ICMP Error Message to HostA. HostA is informed about the Hop Limit expire event and its network location (i.e., P2).

| | | +-----+ +----+ +----+ +-----+ HostA----+ PE1 +------+ P1 |------| P2 +------+ PE2 +------HostB +-----+ +----+ +----+ +-----+ | | |<--------------- VPN -------------->| ]]> The VPN-associated-ICMP-leak-function operation contains the followig steps: It processes the received ICMP error message (originated e.g., from a P node within the SRv6 domain). It identifies the related VPN, based on the VPN specific srcIP value in the SRv6 encapsulation of the received ICMP error message. It modifies the ICMP error message: It removes the SRv6 domain specific encapsulation/header(s) of the received ICMP error message. It identifies the VPN specific source of the original packet that caused the ICMP error message, based on the invoking packet header part of the ICMP error message payload. It removes the SRv6 domain specific header(s) from the invoking packet header part of the ICMP error message payload. It creates a new header for the ICMP error message, where srcIP=SRv6Originator-of-the-ICMP-error-message and dstIP=SourceIP-of-the-invoking-packet. Forwards the modified ICMP error message according to the local VPN routing table (vrf). In case of an IPv4-VPN service, a translation of involved IP addresses is needed (between the related IPv6 and IPv4 addresses). The VPN-associated-ICMP-leak-function may translate the IP address of the SRv6Originator-of-the-ICMP-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 SID values of the domain nodes.

ICMP Error Handling for VPNs in SRv6 Networks has the following characteristics: It is compliant to existing standards, like . It eliminates the shortcomings of the MPLS based solutions, as (1) it works in case of failures between ingress-PE and egress-PE and (2) it supports direct localization of failures. It does not result in additional complexity on P nodes. It makes P nodes service agnostic and allows building IPv6-only core networks. It uses a SID as a source address. It can hide the SIDs used inside the SRv6 domain and can provide different visibility for served VPNs if needed.