]> Aalyria Technologies, Inc.

ek.ietf@gmail.com

Energy Sciences Network

buraglio@forwardingplane.net

Operations and Management SRv6 Operations Segment Routing for IPv6 Segment Identifiers SRv6 SIDs This specification proposes an experimental structure for use of the SRv6 SIDs prefix in support of Inter-Domain SRv6 networks. The core of the proposal is to structure the address space by Autonomous System Number (ASN). Use of this proposed structure is entirely voluntary. The goal of this experiment is to aid SRv6 operations while preserving the ability to use this prefix across cooperating SRv6 domains, but not across the general Internet. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the SRv6 Operations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction requested of IANA a dedicated prefix for Segment Routing over IPv6 Segment Identifiers (SRv6 SIDs), with the aim of "improv[ing] security by making it simpler to filter traffic at the edge of the SR domains." The prefix 5f00::/16 was allocated for this purpose . No requirements were placed on the use of this prefix nor any recommendations made for structured use of this prefix. This specification proposes an experimental structure for use of the SRv6 SIDs prefix in support of Inter-Domain SRv6 networks. The core of the proposal is to structure the address space by Autonomous System Number (ASN). Use of this proposed structure is entirely voluntary. The goal is to aid SRv6 operations while preserving the ability to use this prefix across cooperating SRv6 domains, but not across the general Internet. The SID space prefix was allocated to improve ease of filtering. Where SRv6 traffic using these prefixes may be shared with cooperating partner networks, this proposal makes it easier to craft filters that permit only SRv6 traffic from identified ASNs. As a point of historical interest, this proposal contains echos of the structure of the original 6bone test allocation .

Proposed Structure The recommendation of this specification is for SRv6 domains to allocate SIDs from prefixes that are concatenations of the SRv6 SID prefix (5f00::/16) and an applicable ASN. Assuming 32-bit ASNs, this yields a /48 per ASN in use within an SRv6 domain, i.e. 5f00:as-hi16:as-lo16::/48.

Generation of ASN derived SRv6 prefix SID Each unique ASN generates a prefix from the IANA allocation by converting mutually agreed upon ASNs to hexidecimal, and inserting this hex into a /48 prefix.

SRv6 SID Documentation Prefixes Using 16-bit and 32-bit ASNs reserved for documentation purposes yields several SRv6 SID prefixes that might be used for SRv6 documentation purposes. These prefixes presently include ASNs in the range of 64496-64511 as defined in : or any /48 prefix between these. It should be noted that 32-but ASNs do not have a specific range dedicated for documentation but do have a private use block as defined in .

SRv6 SID Private Use Prefixes Using 16-bit and 32-bit ASNs reserved for private use purposes and defined by yields several SRv6 SID prefixes for private use. These prefixes are defined by RFC 6996 and presently include:

ASN size	Private Use Range
16-bit	64512-65534
32-bit	4200000000-4294967294

yielding: and or any /48 prefix between these, as private use ASN-derived SID prefixes.

Routing and Filtering As noted in , it is assumed that each ASN participating in the SRv6 SID space experiment has deployed their respective SRv6 implementations within a limited domain with appropriate filtering at the domain boundaries. Because this is a shared space experiment, the requisite filtering exceptions must be made between each SRv6 domain to allow for the desired Inter-Domain communication to occur. Care should be taken to allow only the desired and necessary communication between each SRv6 domain. The mechanisms used should be conformant with the given domain's security policy and may include, but are not limited to:

• routing filters such as BGP prefix-lists, route-maps, route-policies, or other analogous mechanisms, or
• access control filters at the domain edge

Example test case One possible test case is the exchange of the IPv6 prefix SID between two autonomous systems with independent management domains. In this example, AS4294967294 exchanges their SRv6 SID prefix (5f00:ffff:fffe::/48) with AS4200000000 who announces their ASN derived SRv6 SID prefix (5f00:fa56:ea00::/48). Within this structure, appropriate and agreed upon policy may be shared between the partner ASNs. Defining the policy or use cases is outside of the scope of this document.

Evaluating the Experiment A survey of participants in the experiment and subsequent evaluation of the results will determine the ease of deployment and operation, or lack thereof, and will inform if further work can be performed to improve ease of implementation and operation.

Security Considerations This document does not alter the inherent security posture of SRv6 , . The SID space prefix was allocated to improve ease of filtering. Where SRv6 traffic using these prefixes may be shared with cooperating partner networks, this proposal makes it easier to craft filters that permit only SRv6 traffic from identified ASNs.

IANA Considerations This document has no IANA actions.

References Normative References n.d. n.d. n.d. Informative References This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This document specifies an Experimental protocol for the Internet community. 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. To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of Autonomous System numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like. This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation. This memo provides information for the Internet community. This document describes the reservation of Autonomous System Numbers (ASNs) that are for Private Use only, known as Private Use ASNs, and provides operational guidance on their use. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10 of that document. There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus. n.d.

Acknowledgments TODO acknowledge.