Cisco

suresh.krishnan@gmail.com

INT 6man Segment Routing over IPv6 (SRv6) uses IPv6 as the underlying data plane. Thus, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them while exhibiting slightly different behaviors in some situations. This document explores the characteristics of SRv6 SIDs and focuses on the relationship of SRv6 SIDs to the IPv6 Addressing Architecture. This document allocates and makes a dedicated prefix available for SRv6 SIDs.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2024 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 () 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

• .  Introduction
• .  Terminology
• .  SRv6 SIDs and the IPv6 Addressing Architecture
• .  Special Considerations for Compressed SIDs
• .  Allocation of a Prefix for SIDs
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Author's Address

Introduction Segment Routing over IPv6 (SRv6) uses IPv6 as the underlying data plane. In SRv6, SR source nodes initiate packets with a Segment Identifier (SID) in the Destination Address of the IPv6 header, and SR segment endpoint nodes process a local segment present in the Destination Address of an IPv6 header. Thus, SIDs in SRv6 can, and do, appear in the Destination Address of IPv6 datagrams by design. This document explores the characteristics of SRv6 SIDs and focuses on the relationship of SRv6 SIDs to the IPv6 Addressing Architecture . This document allocates and makes a dedicated prefix available for SRv6 SIDs.

Terminology The following terms are used as defined in .

• Segment Routing (SR)
• SR Domain
• Segment
• Segment Identifier (SID)
• SRv6
• SRv6 SID

The following terms are used as defined in .

• Segment Routing Header (SRH)
• SR Source Node
• Transit Node
• SR Segment Endpoint Node

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.

SRv6 SIDs and the IPv6 Addressing Architecture defines the Segment List of the SRH as a contiguous array of 128-bit IPv6 addresses; further, it states 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 as "A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID". It follows that not all the SIDs that appear in the SRH are SRv6 SIDs as defined by . As stated above, the non-SRv6-SID elements that appear in the SRH SID list are simply IPv6 addresses assigned to local interfaces, and they need to conform to . So, the following discussions are 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). describes the format of an SRv6 SID as being 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). If L+F+A < 128, the ARG is followed by enough zero bits to fill the 128-bit SID. Such an SRv6 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 of an IPv6 header, only the longest matching prefix corresponding to the Locator is used by the transit node 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 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 like other mechanisms that use IPv6 addresses with different formats, such as those described in "" and "" . While looking at the transit nodes, it becomes apparent that these addresses are used purely for forwarding and not for packet delivery to end hosts. Hence, the relevant specification to apply here is , which requires implementations to support the use of variable-length prefixes in forwarding while explicitly decoupling IPv6 routing and forwarding from the IPv6 address/prefix semantics described in . Please note that does not override the rules in : it 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 since subnet-router anycast addresses are neither required nor useful within a node.

Special Considerations for Compressed SIDs introduces an encoding for Compressed-SIDs (C-SIDs), and describes how to use a single entry in the Segment List as a container for multiple SIDs. A node taking part in this mechanism accomplishes this by using the ARG part of the Destination Address of the IPv6 header to derive a new Destination Address. That is, 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 here is that the Locator Block at the beginning of the address does not get modified by the operations needed for supporting C-SIDs. As we have established that the SRv6 SIDs are being treated simply as routing prefixes on transit nodes within the SR Domain, this does not constitute a modification to the IPv6 data plane on such transit nodes: any changes are restricted to SR-aware nodes.

Allocation of a 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. Nodes either inside or outside the SR Domains that are not SR-aware will not perform any special behavior for SRv6 SIDs and will treat them solely as IPv6 routing prefixes. As an added factor of security, it is desirable to allocate some address space that explicitly signals that the addresses within that space cannot be expected to comply with . As described in , there is precedent for mechanisms that use IPv6 addresses in a manner different from that specified in . This would be useful in identifying and potentially filtering packets at the edges of the SR Domains to make it simpler for the SR Domain to fail closed. At the time of writing, global DNS SHOULD NOT reference addresses assigned from this block. Further specifications are needed to describe the conventions and guidelines for the use of this newly allocated address block. The SRv6 operational community, which is the first intended user of this block, is requested to come up with such conventions and guidelines in line with their requirements.

IANA Considerations IANA has assigned the following /16 address block for the purposes described in and recorded the allocation in the "IANA IPv6 Special-Purpose Address Registry" as follows:

Address Block:

5f00::/16

Name:

Segment Routing (SRv6) SIDs

RFC:

RFC 9602

Allocation Date:

2024-04

Termination Date:

N/A

Source:

True

Destination:

True

Forwardable:

True

Globally Reachable:

False

Reserved-by-Protocol:

False

Security Considerations The security considerations for the use of Segment Routing , SRv6 , and SRv6 network programming 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 . The usage of the prefix allocated by this document improves security by making it simpler to filter traffic at the edge of the SR Domains. In case the deployments do not use this allocated prefix, additional care needs to be exercised at network ingress and egress points so that SRv6 packets do not leak out of SR Domains and do not accidentally enter SR-unaware Domains. Similarly, as stated in , the SR Domain needs to be configured to filter out packets entering that use the selected prefix.

References Normative References IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. Informative References China Mobile Cisco Systems, Inc. Huawei Technologies Orange Cisco Systems, Inc. Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 dataplane. This document specifies new flavors for the SR segment endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 SID list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists. Work in Progress This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK] A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK] This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.

Acknowledgments The author would like to extend a special note of thanks to and for their precisely summarized thoughts on this topic that provided the seed of this document. The author would also like to thank , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , and for their ideas and comments to improve this document.

Author's Address Cisco

suresh.krishnan@gmail.com