SRv6 BSID with Notification Message Relay

Introduction The Segment Routing (SR) Architecture specifies a mechanism to steer packets through an ordered list of segments. As in , the Binding SID (BSID) is bound to an SR Policy, instantiation of which may involve a list of SIDs. defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors. In , End.B6.Encaps and End.B6.Encaps.Red are defined as instantiations of a Binding SID. When a node (BSID node) receives a packet whose destination address matches a local BSID, it encapsulates the packet with a new outer IPv6 header and an optional Segment Routing Header (SRH), and then forwards the packet to the SRv6 policy associated with that BSID. According to , the tunnel entry-point node MUST use one of its own routable IPv6 addresses as the source address of the outer IPv6 header. Since the BSID behavior is essentially a form of IPv6-in-IPv6 tunneling, it MUST also comply with this general requirement of . This means that the BSID node, acting as the tunnel entry-point, MUST set the source address of the newly encapsulated outer IPv6 header to an IPv6 address that belongs to itself. In SRv6 tunneling scenarios, various types of tunnel-internal notification messages may be generated by nodes inside the tunnel and need to be delivered to the source of the original packet. Examples of such messages include:

ICMPv6 error messages, such as Time Exceeded (Type 3), Destination Unreachable (Type 1), Packet Too Big (Type 2), and Parameter Problem (Type 4), as defined in .
Network congestion notification messages, which may be generated by nodes experiencing congestion or processing overload. Such messages inform the source node of the congestion condition, enabling it to adjust its transmission behavior accordingly.

For ICMP error messages, defines a relay procedure. When an error occurs inside a tunnel, the ICMP error message is first sent to the tunnel entry-point node (since the entry-point is the source of the outer IPv6 header). Upon receiving the ICMP error, the tunnel entry-point node extracts the invoking packet from the ICMP payload, decapsulates it to retrieve the original packet, and then relays a new ICMP error message to the original source address extracted from the original packet. However, in SRv6 networks, the ICMPv6 error message may contain both outer tunnel IPv6 extension headers (e.g., SRH, Hop-by-Hop Options, Destination Options) as well as inner IPv6 extension headers of the original packet. The relay approach in may be unsuitable in some scenarios:

Due to the MTU constraints of ICMPv6 error messages , the IPv6 Source Address field of the inner original packet may not be fully included in the ICMPv6 error payload. As a result, the relay node is unable to retrieve the source address of the original packet, making the relay procedure infeasible.
Since the outer IPv6 extension headers have variable length, parsing through the outer encapsulation to locate the inner IPv6 header imposes processing complexity on the relay node. For some devices, such deep header parsing cannot be performed efficiently.

For network congestion notification messages, similar challenges exist:

Some network congestion messages need to be delivered to the host side. However, if the host source address extracted from the packet payload is used directly as the destination address of the notification message, the route may be unreachable from the congestion reporting node. Therefore, it may still be necessary to send the notification message to the headend node of the path first, and then have the headend node forward it to the host. In this case, the same BSID node relay issue may arise.
Congestion notification messages have various formats. Some congestion notification messages do not include all the packet header information. In such cases, the BSID node is unable to extract the original source address information from the congestion notification message.
Even if the congestion notification message, similar to ICMPv6 messages, includes as much of the original packet information as possible, it will still face the same issues as the ICMPv6 relay case described above. This is particularly problematic in scenarios where congestion notification messages need to be delivered as quickly as possible, as the deep parsing required to locate the original source address introduces additional processing latency, adversely affecting transmission performance.

To address the above issues, this document defines a new SRv6 behavior to be used on the BSID node. This behavior enables the BSID node to relay ICMPv6 error messages and other tunnel-internal notification messages to the original source node of the SR path.

Terminology 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 when, and only when, they appear in all capitals, as shown here. This document uses the terminology from , , and . In particular:

SRv6:: Segment Routing over IPv6
SID:: Segment Identifier
SRH:: Segment Routing Header
BSID:: Binding SID
End.B6.Encaps:: the BSID behavior defined in Section 4.13 of

This document defines the following new term:

End.B6.Encaps.Relay:: a variant of End.B6.Encaps that enables the BSID node to relay tunnel-internal notification messages to the upstream tunnel source node through a stateful mapping mechanism.

End.B6.Encaps.Relay: Endpoint Bound to an SRv6 Policy with Notification Relay In this section, a new SRv6 Endpoint Behavior is proposed for SRv6 based notification relay in nested tunnel scenarios. The "Endpoint Bound to an SRv6 Policy with Notification Relay" behavior ("End.B6.Encaps.Relay" for short) is a variant of the End.B6.Encaps behavior as defined in . Its main use is to enable the BSID node to relay tunnel-internal notification messages (e.g., ICMPv6 errors, congestion notifications, or other notification messages) to the upstream tunnel source node. The End.B6.Encaps.Relay behavior addresses the notification return path breakage issue in nested SRv6 tunnels, where the standard End.B6.Encaps behavior overwrites the outer IPv6 source address and consequently prevents downstream tunnel-internal notification messages from reaching the original source. By maintaining a local mapping between a dynamically allocated argument and the upstream source address, the End.B6.Encaps.Relay behavior ensures that tunnel-internal notification messages can be relayed back to the original source through layer-by-layer relay. Any SID instance of this behavior is associated with an SR Policy B and a source address A. The SID follows the LOC:FUNCT:ARG format as defined in . The ARG field serves as a dynamically allocated session identifier that uniquely identifies each encapsulation session. When N receives a packet whose IPv6 DA is S and S is a local End.B6.Encaps.Relay SID, N does the following: max_LE) or (Segments Left > Last Entry+1)) { S10. Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S11. } S12. } S13. If (ARG == 0) { S14. Record the source address of the received IPv6 header as ORIG_SA. S15. If (local relay table does NOT contain ORIG_SA) { S16. Allocate a new ARG value, NEW_ARG. S17. Create a mapping entry (NEW_ARG -> ORIG_SA) in the local relay table. S18. } Else { S19. Retrieve NEW_ARG associated with ORIG_SA from the local relay table. S20. } S21. Push a new IPv6 header with its own SRH containing B. S22. Update the ARG field of N to NEW_ARG, and set it as the outer IPv6 SA. S23. Set the outer IPv6 DA to the first SID of B. S24. Set the outer Payload Length, Traffic Class, Flow Label, Hop Limit, and Next Header fields per [RFC2473] and [RFC6437]. S25. Submit the packet to the egress IPv6 FIB lookup for transmission. S26. } S27. If (ARG != 0) { S28. If (local relay table does not contain this ARG) { S29. Interrupt packet processing and discard the packet. S30. } S31. Retrieve ORIG_SA from the local relay table using the ARG. S32. If (the received packet is a message that needs to be relayed) { S33. Decapsulate the received packet and push a new IPv6 header. S34. Set the IPv6 SA of the resulting packet to A. S35. Set the IPv6 DA to ORIG_SA. S36. Set the outer Payload Length, Traffic Class, Flow Label, Hop Limit, and Next Header fields per [RFC2473] and [RFC6437]. S37. Submit the packet to the egress IPv6 FIB lookup for transmission. S38. } Else { S39. Process the packet locally. S40. } S41. } ]]> End.B6.Encaps.Relay SIDs MAY be allocated by the network nodes and announced to the network controller with the information of the ARG length using IGP or BGP-LS . Alternatively, End.B6.Encaps.Relay SIDs MAY be assigned by a centralized network controller and advertised to the network nodes through Netconf/YANG , BGP , or PCEP . With the information of End.B6.Encaps.Relay SIDs, the network controller or headend nodes could use End.B6.Encaps.Relay SIDs together with other types of SRv6 SIDs to build SRv6 SID lists that support reliable notification message relay in nested tunnel scenarios.

Application Example This section provides an application example of the End.B6.Encaps.Relay behavior defined in Section 3. It shows how the behavior enables relay of ICMPv6 error messages generated inside a BSID tunnel back to the original headend of the SR Policy including this BSID. The reference topology is shown in Figure 1, where:

Reference Topology Step 1: Encapsulation at PE1

CE1 sends packets to CE2.
PE1 performs SRv6 function H.Encaps with SRv6 Policy, and the corresponding SID list is <SID-R1, BSID-T1, SID-PE2>, wherein SID-T1 is an End.B6.Encaps.Relay BSID instantiated on node T1 which is associated with an SR Policy <SID-T2, SID-T3> and its argument is set to 0.
Packet leaving PE1: IPv6<SA=add-PE1, DA=SID-R1> SRH<SID-R1, BSID-T1, SID-PE2> payload.

Step 2: End.B6.Encaps.Relay Processing

When the packet arrives at T1, based on End.B6.Encaps.Relay BSID SID-T1 (ARG=0), T1 records the source address of the received IPv6 header (i.e., add-PE1), and checks whether the local relay table already contains add-PE1.
Since this is a new session, T1 allocates a new ARG value, e.g., 0x1001.
T1 creates a mapping entry in the local relay table: (0x1001 -> add-PE1).
T1 pushes a new IPv6 header with its own SRH containing the SRv6 Policy towards PE2 with the outer SA set to BSID-T1' (generated based on SID-T1 with ARG=0x1001) and the outer IPv6 DA = first SID of the policy <SID-T2, SID-T3>.
Packet leaving T1: IPv6<SA=BSID-T1', DA=SID-T2> SRH<SID-T2, SID-T3> IPv6<SA=add-PE1, DA=BSID-T1> SRH<SID-R1, SID-T1, SID-PE2> payload.

Step 3: ICMP Error Generation inside BSID Tunnel

At T2, an error condition occurs, e.g., the Hop Limit expires. As per , T2 generates an ICMPv6 error message. The destination address of the ICMP error is set to the source address of the invoking packet, which is BSID-T1', and is sent to node T1.
Packet leaving T2: IPv6<SA=add-T2, DA=BSID-T1'> ICMPv6.

Step 4: ICMP Error Relay at T1

When the packet arrives at T1, based on End.B6.Encaps.Relay BSID SID-T1' (ARG=0x1001), T1 looks up the local relay table with ARG=0x1001 and retrieves the original source address add-PE1.
T1 decapsulates the received packet and pushes a new IPv6 header, with DA set to add-PE1 and SA set to a suitable local address (e.g., add-T1), and forwards it to PE1 based on the DA.
Packet leaving T1: IPv6<SA=add-T1, DA=add-PE1> ICMPv6.

Operational Considerations

Mapping Table Management The End.B6.Encaps.Relay behavior relies on a local mapping table that stores associations between dynamically allocated ARG values and the upstream source addresses. To prevent unbounded growth of the mapping table, an implementation SHOULD provide mechanisms for managing table entries. An implementation MAY support a configurable timer for each mapping entry. When a mapping entry remains inactive for a period exceeding the configured timer, the entry SHOULD be removed and the associated ARG value SHOULD be recycled for future allocations. The default timer value is implementation specific and MAY be configured by the network operator based on the expected session duration and traffic patterns. Additionally, an implementation MAY support a configurable maximum number of mapping entries. When the table reaches the maximum capacity, new session establishment requests MAY be rejected, or the implementation MAY replace the oldest entries based on a configurable policy. The choice of policy is implementation specific and out of scope of this document.

Selective Relay An implementation of the End.B6.Encaps.Relay behavior MAY support selective relay based on configurable policies. For example, a network operator may configure the End.B6.Encaps.Relay BSID node to relay only specific types of tunnel-internal notification messages, such as ICMPv6 error messages (e.g., Time Exceeded, Destination Unreachable, Packet Too Big, Parameter Problem) while processing other types of messages locally or discarding them.

Path Orchestration Considerations Not all SRv6 paths that include BSIDs require the End.B6.Encaps.Relay behavior. When orchestrating SR paths, the network controller SHOULD select the appropriate BSID type based on the requirements of the path. If the path requires that tunnel-internal notification messages (e.g., ICMPv6 errors) generated inside the BSID tunnel be relayed to the upstream tunnel source node, the controller SHOULD use an End.B6.Encaps.Relay SID for that path. If such relay capability is not required, the controller MAY use the standard End.B6.Encaps SID as defined in to reduce state requirements on the BSID node.

Scope of the Solution The End.B6.Encaps.Relay behavior defined in this document addresses the relay of tunnel-internal notification messages from inside a BSID tunnel back to the upstream tunnel source node. It does not address the subsequent delivery of such notifications from the upstream tunnel source node to the final host or customer edge device. For example, in VPN scenarios where ICMPv6 errors need to be delivered to customer edge devices, the End.B6.Encaps.Relay behavior can be used in conjunction with the ICMP error handling mechanisms defined in , which specifies how an ingress PE processes ICMP error messages and forwards them to the host.

Security Considerations The relay of ICMPv6 error messages follows the model defined in and . Implementations SHOULD apply standard ICMP rate limiting to prevent ICMP flooding attacks. The security considerations of , , and also apply to this specification. This document does not introduce additional security threats beyond those already present in the SRv6 architecture and the underlying IPv6 and ICMPv6 protocols.

IANA Considerations This document defines a new SRv6 Endpoint behavior called End.B6.Encaps.Relay. IANA is requested to allocate the following code point for End.B6.Encaps.Relay from the "SRv6 Endpoint Behaviors" sub-registry in the "Segment-routing with IPv6 data plane (SRv6) Parameters" registry: SRv6 Endpoint Behaviors Registry

Value	Hex	Endpoint Behavior	Reference
TBA1	TBA1	End.B6.Encaps.Relay	This document