SRv6 BSID with Notification Message Relay

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 4 January 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 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

The Segment Routing (SR) Architecture [RFC8402] specifies a mechanism to steer packets through an ordered list of segments. As in [RFC8402], the Binding SID (BSID) is bound to an SR Policy, instantiation of which may involve a list of SIDs.¶

[RFC8986] defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors. In [RFC8986], 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 [RFC2473], 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 [RFC2473]. 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 [RFC4443].¶
• 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, [RFC2473] 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 [RFC2473] may be unsuitable in some scenarios:¶

• Due to the MTU constraints of ICMPv6 error messages [RFC4443], 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.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses the terminology from [RFC8402], [RFC8754], and [RFC8986]. 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 [RFC8986]¶

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.¶

3. 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 [RFC8986]. 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 [RFC8986]. 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:¶

S01.  When an SRH is processed {
S02.    If (Segments Left == 0) {
S03.      Stop processing the SRH, and proceed to process the next
             header in the packet, whose type is identified by
             the Next Header field in the routing header.
S04.    }
S05.    If (IPv6 Hop Limit <= 1) {
S06.      Send an ICMP Time Exceeded message to the Source Address
             with Code 0 (Hop limit exceeded in transit),
             interrupt packet processing, and discard the packet.
S07.    }
S08.    max_LE = (Hdr Ext Len / 2) - 1
S09.    If ((Last Entry > 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 [RFC1195] [RFC2328] or BGP-LS [RFC9552]. Alternatively, End.B6.Encaps.Relay SIDs MAY be assigned by a centralized network controller and advertised to the network nodes through Netconf/YANG [RFC6241] [RFC6020], BGP [RFC4271], or PCEP [RFC5440].¶

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.¶

4. 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:¶

+---+  +---+  +---+  +---+  +---+  +---+
|PE1|--|R1 |--|T1 |--|R2 |--|R3 |--|PE2|
+---+  +---+  +---+  +---+  +---+  +---+
  |                                  |
+---+                              +---+
|CE1|                              |CE2|
+---+                              +---+

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 [RFC4443], 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.¶

5. Operational Considerations

6. Security Considerations

The relay of ICMPv6 error messages follows the model defined in [RFC2473] and [RFC4443]. Implementations SHOULD apply standard ICMP rate limiting to prevent ICMP flooding attacks.¶

The security considerations of [RFC8402], [RFC8754], and [RFC8986] 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.¶

7. 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:¶

Author's Address