Internet-Draft SRv6 SIDs May 2022
Krishnan Expires 18 November 2022 [Page]
Intended Status:
S. Krishnan

Segment Identifiers in SRv6


The data plane for Segment Routing over IPv6 (SRv6) [RFC8754] is built using IPv6 as the underlying forwarding plane. Due to this underlying use of IPv6, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them [RFC8754][RFC8986] while exhibiting slightly different behaviors in some situations. This document intends to explore the characteristics of SRv6 SIDs and to clarify the relationship of SRv6 SIDs to the IPv6 Addressing Architecture [RFC4291].

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

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 18 November 2022.

Table of Contents

1. Introduction

Segment Routing over IPv6 (SRv6) [RFC8754] uses IPv6 as the underlying data plane. In SRv6, SR source nodes initiate packets with a segment identifier in the Destination Address of the IPv6 header, and SR segment endpoint nodes that process a local segment present the Destination Address of an IPv6 header. Thus Segment Identifiers (SIDs) in SRv6 can and do appear in the Destination Address field of IPv6 datagrams by design.

2. Terminology

The following terms are used as defined in [RFC8402].

The following terms are used as defined in [RFC8754].

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. SRv6 SIDs and the IPv6 addressing architecture

[RFC8754] defines the Segment List of the SRH as a contiguous array of 128-bit IPv6 addresses, and that each of the elements in this list are SIDs. But all of these elements are not necessarily made equal. Some of these elements may represent a local interface as described in Section 4.3 of [RFC8754] as "A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID". From this it follows that all the SIDs that appear in the SRH are not SRv6 SIDs as defined by [RFC8402].

It is also fairly clear that the non-SRv6-SID elements that appear in the SRH SID list are simply IPv6 addresses assigned to local interfaces annd MUST conform to [RFC4291]. So, the following discussions are intended to be applicable solely to SRv6 SIDs that are not assigned to local interfaces.

One of the key questions to address is how these SRv6 SIDs appearing as IPv6 Destination Addresses are perceived and treated by "transit nodes" (that are not required to be capable of processing a Segment or the Segment Routing Header).

Section 3.1. of [RFC8986] describes the format of an SRv6 SID as composed of three parts LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). Such a SID is assigned to a node within a prefix defined as a Locator of length L. When an SRv6 SID occurs in the IPv6 destination address field of an IPv6 header, only the longest match prefix corresponding to the locator is used to forward the packet to the node identified by the Locator.

It is clear that this format for SRv6 SIDs is not compliant with the requirements set forth in [RFC4291] for IPv6 addresses but it is also clear that SRv6 SIDs are not intended for assignment onto interfaces on end hosts. They look and act similar to other mechanisms that use IPv6 addresses with different formats such as [RFC6052] that defines the IPv6 Addressing of IPv4/IPv6 Translators and [RFC7343] that describes ORCHIDv2 (a cryptographic hash identifier format).

While looking at the transit nodes it becomes apparent that these addresses are used purely for routing and not for packet delivery to end hosts. Hence the relevant standard to apply here is [RFC7608] that allows the use of variable length prefixes in forwarding while explicitly decoupling IPv6 routing and forwarding from the IPv6 address/prefix semantics described in [RFC4291]. Please note that [RFC7608] does not override the rules in [RFC4291], but merely limits where their impact is observed

Furthermore, in the SRv6 specifications, all SIDs assigned within a given Locator prefix are located inside the node identified by Locator. Therefore there does not appear to be a conflict with section 2.6.1 of [RFC4291] since subnet-router anycast addresses are neither required nor useful within a node.

4. Special Considerations for Compressed SIDs

The C-SID document [I-D.filsfilscheng-spring-srv6-srh-compression] describes how to use a single entry in the SRH list as a container for multiple SIDs and defines a few flavors of how to do so. A node taking part in this mechanism accomplishes this by using the ARG part [RFC8986] of the Destination address field of the IPv6 header to come up with a new Destination address in some of these flavors. i.e. The destination address field of the packet changes at a segment endpoint in a way similar to how the address changes as the result of processing a segment in the SRH.

One key thing to note in here is that the Locator Block at the beginning of the address does not get modified by the operations needed for supporting compressed SIDs. As we have established that the SRv6 SIDs are being treated simply as routing prefixes on transit nodes this does not constitute a modification to the IPv6 data plane on such transit nodes and any changes are restricted to SR aware nodes.

4.1. Open Issues to be Addressed with C-SIDs

There are a few issues that need to be addressed in the C-SID draft prior to its publication as RFC:

  • This draft needs to provide an updated definition for the SegmentsLeft field of the SRH since the current definition in [RFC8754][RFC8200] no longer holds true in the presence of C-SIDs.
  • In some cases it is possible that the SR policy can be expressed purely with C-SIDs without requiring an SRH. In this case, to allow the SR domain to fail closed, some form of filtering based on the LOC part of the SRv6 SID is required as relying purely on the presence of an SRH will not be sufficient.
  • The use of C-SIDs might cause some difficulty in troubleshooting error conditions signaled by ICMPv6. Section 5.4 of [RFC8754] describes the ICMPv6 error processing that is required to be performed on the SR Source Nodes to correlate packets since the Destination Address field of the packet changes in flight. Similar logic needs to be specified for SR Source Nodes that use C-SIDs to determine the destination address for use by protocol-error handlers.

4.2. Applicability to other forms of compressed SIDs

The spring working group is in the process of analyzing multiple mechanisms for compressing the SRv6 SID list as described in [I-D.ietf-spring-compression-analysis]. Even though this document focuses on [I-D.filsfilscheng-spring-srv6-srh-compression], the considerations specified in this document might also be applicable to the other mechanisms being analyzed and compared.

5. Allocation of a Global Unicast Prefix for SIDs

All of the SRv6 related specifications discussed above are intended to be applicable to a contained SR Domain or between collaborating SR Domains. Hence the behavior of SRv6 SIDs is visible purely within the SR domain and they would be treated solely as IPv6 routing prefixes by nodes that are not SR aware.

As an added factor of safety, it might be prudent to allocate some address space that explicitly signals that the addresses within that space are not intended to comply with [RFC4291]. As described in Section 3 above, there is precedent for mechanisms that use IPv6 addresses in a manner different from that specified in [RFC4291]. This would be useful in identifying and potentially filtering packets at the edges of the SR Domains as described in Section 4.1.

The SRv6 operational community, which is the first intended user of this block, is requested to come up with conventions and guidelines for the use of this newly allocated address block in line with their requirements.

6. IANA Considerations

IANA is requested to assign a /16 address block for the purposes described in Section 5 out of the "Reserved by IETF" range defined in the Internet Protocol Version 6 Address Space registry.

7. Security Considerations

The security considerations for the use of Segment Routing [RFC8402], SRv6 [RFC8754], and SRv6 network programming [RFC8986] apply to the use of these addresses. The use of IPv6 tunneling mechanisms (including SRv6) also brings up additional concerns such as those described in [RFC6169].

8. Acknowledgments

The author would like to extend a special note of thanks to Brian Carpenter and Erik Kline for their precisely summarized thoughts on this topic that provided the seed of this draft. The author would also like to thank Andrew Alston, Ron Bonica, Bruno Decraene, Darren Dukes, Clarence Filsfils, Jim Guichard, Joel Halpern, Bob Hinden, Alvaro Retana, Ole Troan, Eric Vyncke and Jen Linkova for their ideas and comments to improve this document.

9. References

9.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, , <>.
Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix Length Recommendation for Forwarding", BCP 198, RFC 7608, DOI 10.17487/RFC7608, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <>.
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <>.
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, , <>.
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, , <>.

9.2. Informative References

Cheng, W., Filsfils, C., Li, Z., Decraene, B., Cai, D., Voyer, D., Clad, F., Zadok, S., Guichard, J., Liu, A., Raszuk, R., and C. Li, "Compressed SRv6 Segment List Encoding in SRH", Work in Progress, Internet-Draft, draft-filsfilscheng-spring-srv6-srh-compression-02, , <>.
Bonica, R., Cheng, W., Dukes, D., Henderickx, W., Li, C., Peng, S., and C. Xie, "Compressed SRv6 SID List Analysis", Work in Progress, Internet-Draft, draft-ietf-spring-compression-analysis-00, , <>.
Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, , <>.
Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, DOI 10.17487/RFC6169, , <>.
Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, , <>.

Author's Address

Suresh Krishnan