Skip to main content

Segment Identifiers in SRv6
draft-ietf-6man-sids-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Author Suresh Krishnan
Last updated 2022-04-21 (Latest revision 2022-04-14)
Replaces draft-krishnan-6man-sids
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-6man-sids-00
6man                                                         S. Krishnan
Internet-Draft                                                     Cisco
Intended status: Informational                             14 April 2022
Expires: 16 October 2022

                      Segment Identifiers in SRv6
                        draft-ietf-6man-sids-00

Abstract

   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 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 16 October 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Krishnan                 Expires 16 October 2022                [Page 1]
Internet-Draft                  SRv6 SIDs                     April 2022

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  SRv6 SIDs and the IPv6 addressing architecture  . . . . . . .   3
   4.  Special Considerations for Compressed SIDs  . . . . . . . . .   4
     4.1.  Open Issues to be Addressed with C-SIDs . . . . . . . . .   5
     4.2.  Applicability to other forms of compressed SIDs . . . . .   5
   5.  Allocation of a Global Unicast Prefix for SIDs  . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

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

   *  Segment Routing (SR)

   *  SR Domain

   *  Segment

   *  Segment ID (SID)

Krishnan                 Expires 16 October 2022                [Page 2]
Internet-Draft                  SRv6 SIDs                     April 2022

   *  SRv6

   *  SRv6 SID

   *  SR Policy.

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

   *  Segment Routing Header (SRH)

   *  SR Source Node

   *  Transit Node

   *  SR Segment Endpoint Node

   *  Reduced SRH

   *  Segments Left

   *  Last Entry

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

Krishnan                 Expires 16 October 2022                [Page 3]
Internet-Draft                  SRv6 SIDs                     April 2022

   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 on the fly 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.

Krishnan                 Expires 16 October 2022                [Page 4]
Internet-Draft                  SRv6 SIDs                     April 2022

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.

Krishnan                 Expires 16 October 2022                [Page 5]
Internet-Draft                  SRv6 SIDs                     April 2022

   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 global unicast 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, and Eric Vyncke for their ideas and
   comments to improve this document.

9.  References

9.1.  Normative References

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC7608]  Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
              Length Recommendation for Forwarding", BCP 198, RFC 7608,
              DOI 10.17487/RFC7608, July 2015,
              <https://www.rfc-editor.org/info/rfc7608>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

Krishnan                 Expires 16 October 2022                [Page 6]
Internet-Draft                  SRv6 SIDs                     April 2022

   [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, <https://www.rfc-editor.org/info/rfc8402>.

   [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,
              <https://www.rfc-editor.org/info/rfc8754>.

   [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,
              <https://www.rfc-editor.org/info/rfc8986>.

9.2.  Informative References

   [I-D.filsfilscheng-spring-srv6-srh-compression]
              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, 28 July
              2021, <https://www.ietf.org/archive/id/draft-
              filsfilscheng-spring-srv6-srh-compression-02.txt>.

   [I-D.ietf-spring-compression-analysis]
              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, 27 September 2021,
              <https://www.ietf.org/archive/id/draft-ietf-spring-
              compression-analysis-00.txt>.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              DOI 10.17487/RFC6052, October 2010,
              <https://www.rfc-editor.org/info/rfc6052>.

   [RFC6169]  Krishnan, S., Thaler, D., and J. Hoagland, "Security
              Concerns with IP Tunneling", RFC 6169,
              DOI 10.17487/RFC6169, April 2011,
              <https://www.rfc-editor.org/info/rfc6169>.

Krishnan                 Expires 16 October 2022                [Page 7]
Internet-Draft                  SRv6 SIDs                     April 2022

   [RFC7343]  Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
              Routable Cryptographic Hash Identifiers Version 2
              (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September
              2014, <https://www.rfc-editor.org/info/rfc7343>.

Author's Address

   Suresh Krishnan
   Cisco
   Email: suresh.krishnan@gmail.com

Krishnan                 Expires 16 October 2022                [Page 8]