<?xmlversion="1.0" encoding="US-ASCII"?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYRFC4291 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml">zwsp "​"> <!ENTITYRFC6052 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6052.xml">nbhy "‑"> <!ENTITYRFC6169 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6169.xml"> <!ENTITY RFC7343 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7343.xml"> <!ENTITY RFC8402 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"> <!ENTITY RFC8499 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"> <!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC8754 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"> <!ENTITY RFC8986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8986.xml"> <!ENTITY I-D.ietf-spring-compression-analysis SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-spring-compression-analysis-03.xml"> <!ENTITY RFC8986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8986.xml">wj "⁠"> ]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <?rfc strict="yes" ?> <?rfc toc="yes"?> <?rfc tocdepth="4"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes" ?> <?rfc compact="yes" ?> <?rfc subcompact="no" ?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-ietf-6man-sids-06"ipr="trust200902">number="9602" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <front> <!-- [rfced] Please note that the title of the document has been updated as follows: Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review as this leads to a repeat of "segment". Original: SRv6 Segment Identifiers in the IPv6 Addressing Architecture Current: Segment Routing over IPv6 (SRv6) Segment Identifiers in the IPv6 Addressing Architecture --> <title abbrev="SRv6SIDs">SRv6SIDs">Segment Routing over IPv6 (SRv6) Segment Identifiers in the IPv6 Addressing Architecture</title> <seriesInfo name="RFC" value="9602"/> <author fullname="Suresh Krishnan" initials="S." surname="Krishnan"> <organization>Cisco</organization> <address><postal> <street></street> <city></city> <region></region> <code></code> <country></country> </postal><email>suresh.krishnan@gmail.com</email> </address> </author><date/> <area>Internet</area><date month="June" year="2024"/> <area>INT</area> <workgroup>6man</workgroup><abstract> <t>The<!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <!--[rfced] We had the following questions about the Abstract. a) Please review our edits to the Abstract to ensure we have maintained your intended meaning. b) Please also review if the first sentence might be rewritten to eliminate some redundancy (i.e., "over IPv6" and "IPv6 as underlying" seem similar). c) (Perhaps related to b) Please review the differences between the similar text in the Abstract and the Introduction and let us know if any updates need to be made to make them more uniform. That is, might the Abstract begin with the same sentence as now starts the Introduction? Original: The data plane for Segment Routing over IPv6 (SRv6) 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 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. Current: The data plane for Segment Routing over IPv6 (SRv6) is built using IPv6 as the underlying forwarding plane. Thus, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them in some situations while exhibiting slightly different behaviors in others. 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. --> <abstract> <t>The data plane for Segment Routing over IPv6 (SRv6) is built using IPv6 as the underlying forwarding plane. Thus, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them in some situations while exhibiting slightly different behaviors in others. 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. </t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t> Segment Routing over IPv6 (SRv6) <xreftarget="RFC8754"/>target="RFC8754" format="default"/> uses IPv6 as the underlying data plane. In SRv6, SR source nodes initiate packets with asegment identifierSegment 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 Segment Identifiers (SIDs)Thus, SIDs in SRv6cancan, anddodo, 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 <xreftarget="RFC4291"/>.target="RFC4291" format="default"/>. This document allocates and makes a dedicated prefix available for SRv6 SIDs. </t> </section> <sectiontitle="Terminology">numbered="true" toc="default"> <name>Terminology</name> <t>The following terms are used as defined in <xreftarget="RFC8402"/>. <list style="symbols">target="RFC8402" format="default"/>. </t> <ul spacing="normal"> <li> <t>Segment Routing (SR)</t> </li> <li> <t>SR Domain</t> </li> <li> <t>Segment</t> </li> <li> <t>Segment Identifier (SID)</t> </li> <li> <t>SRv6</t> </li> <li> <t>SRv6 SID</t></list> </t></li> </ul> <t>The following terms are used as defined in <xreftarget="RFC8754"/>. <list style="symbols">target="RFC8754" format="default"/>. </t> <ul spacing="normal"> <li> <t>Segment Routing Header (SRH)</t> </li> <li> <t>SR Source Node</t> </li> <li> <t>Transit Node</t> </li> <li> <t>SR Segment Endpoint Node</t></list> </t> <t>The</li> </ul> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> <sectiontitle="SRv6numbered="true" toc="default" anchor="section3"> <name>SRv6 SIDs and the IPv6 AddressingArchitecture">Architecture</name> <t> <xreftarget="RFC8754"/>target="RFC8754" format="default"/> defines the Segment List of the SRH as a contiguous array of 128-bit IPv6addresses, andaddresses; 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 inSection 4.3 of<xreftarget="RFC8754"/>target="RFC8754" sectionFormat="of" section="4.3"/> as "A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID".From this itIt follows that not all the SIDs that appear in the SRH are SRv6 SIDs as defined by <xreftarget="RFC8402"/>.target="RFC8402" format="default"/>. </t> <t> As stated above, the non-SRv6-SID elements that appear in the SRH SID list are simply IPv6 addresses assigned to localinterfacesinterfaces, and they need to conform to <xreftarget="RFC4291"/>.target="RFC4291" format="default"/>. So, the following discussions are applicable solely to SRv6 SIDs that are not assigned to local interfaces. </t> <t> 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). </t> <t>Section 3.1. of<xreftarget="RFC8986"/>target="RFC8986" sectionFormat="of" section="3.1"/> describes the format of an SRv6 SID as being composed of threepartsparts, LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of theSID,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 the128 bit128-bit SID. Such an SRv6 SID is assigned to a node within a prefix defined as a Locator of length L. <!--[rfced] Looking at BCP 198, we see the use of "longest-match-first". But it is used to describe rules and algorithms (we do see "implement longest-match-first on prefixes" in the Abstract). Should the use of "longest match" be updated here? Original: When an SRv6 SID occurs in the IPv6 Destination Address of an IPv6 header, only the longest match prefix corresponding to the Locator [BCP198] is used by the transit node to forward the packet to the node identified by the Locator. Perhaps: When an SRv6 SID occurs in the IPv6 Destination Address of an IPv6 header, only the longest-match-first prefix corresponding to the Locator [BCP198] is used by the transit node to forward the packet to the node identified by the Locator. Or perhaps: When an SRv6 SID occurs in the IPv6 Destination Address of an IPv6 header, only the longest matching prefix corresponding to the Locator [BCP198] is used by the transit node to forward the packet to the node identified by the Locator. --> When an SRv6 SID occurs in the IPv6 Destination Address of an IPv6 header, only the longest match prefix corresponding to the Locator <xreftarget="BCP198"/>target="BCP198" format="default"/> is used by the transit node to forward the packet to the node identified by the Locator. </t> <t> It is clear that this format for SRv6 SIDs is not compliant with the requirements set forth in <xreftarget="RFC4291"/>target="RFC4291" format="default"/> for IPv6addressesaddresses, but it is also clear that SRv6 SIDs are not intended for assignment onto interfaces on end hosts. <!--[rfced] Might it be preferrable to use the titles of these documents in lieu of a description? Original: They look and act similarly to other mechanisms that use IPv6 addresses with different formats such as<xref target="RFC6052"/>[RFC6052] that defines the IPv6 Addressing of IPv4/IPv6 Translators and<xref target="RFC7343"/>[RFC7343] that describes ORCHIDv2 (a cryptographic hash identifier format). Perhaps: They look and act like other mechanisms that use IPv6 addresses with different formats, such as those described in "IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052] and "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)" [RFC7343]. --> They look and act like other mechanisms that use IPv6 addresses with different formats, such as <xref target="RFC6052" format="default"/> (which defines the IPv6 Addressing of IPv4/IPv6 Translators) and <xref target="RFC7343" format="default"/> (which describes Overlay Routable Cryptographic Hash Identifiers version 2 (ORCHIDv2) (a cryptographic hash identifier format)). </t> <t> While looking at the transitnodesnodes, it becomes apparent that these addresses are used purely for forwarding and not for packet delivery to end hosts.HenceHence, the relevant specification to apply here is <xreftarget="BCP198"/> thattarget="BCP198" format="default"/>, which requires implementations to support the use ofvariable lengthvariable-length prefixes in forwarding while explicitly decoupling IPv6 routing and forwarding from the IPv6 address/prefix semantics described in <xreftarget="RFC4291"/>.target="RFC4291" format="default"/>. Please note that <xreftarget="BCP198"/>target="BCP198" format="default"/> does not override the rules in <xreftarget="RFC4291"/>, buttarget="RFC4291" format="default"/>: it merely limits where their impact is observed. </t> <t> Furthermore, in the SRv6 specifications, all SIDs assigned within a given Locator prefix are located inside the node identified by Locator.ThereforeTherefore, there does not appear to be a conflict withsection 2.6.1 of<xreftarget="RFC4291"/>target="RFC4291" sectionFormat="of" section="2.6.1"/> since subnet-router anycast addresses are neither required nor useful within a node. </t> </section> <sectiontitle="Specialnumbered="true" toc="default"> <name>Special Considerations for CompressedSIDs">SIDs</name> <t> <!--[rfced] For a closer 1:1 mapping between abbreviation and expansion and to match the use in [CSID], may we update the expansion of C-SIDs as follows? Original: compressed segment lists (C-SIDs) Perhaps: Compressed-SIDs (C-SIDs) --> <xreftarget="CSID"/>target="I-D.ietf-spring-srv6-srh-compression" format="default"/> introduces an encoding for compressed segment lists (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 <xreftarget="RFC8986"/>target="RFC8986" format="default"/> of the Destination Address of the IPv6 header to derive a new Destination Address.i.e.,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. </t> <t> 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 compressed SIDs. As we have established that the SRv6 SIDs are being treated simply as routing prefixes on transit nodes within the SRdomaindomain, this does not constitute a modification to the IPv6 data plane on such transitnodes andnodes: any changes are restricted toSR awareSR-aware nodes. </t> </section> <sectiontitle="Allocationnumbered="true" toc="default" anchor="section5"> <name>Allocation of a Global Unicast Prefix forSIDs">SIDs</name> <t>All of theSRv6 relatedSRv6-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. </t> <t> 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 <xreftarget="RFC4291"/>.target="RFC4291" format="default"/>. As described inSection 3 above,<xref target="section3"/>, there is precedent for mechanisms that use IPv6 addresses in a manner different from that specified in <xreftarget="RFC4291"/>.target="RFC4291" format="default"/>. 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. </t> <t> At the present time, global DNS <xreftarget="RFC8499"/> SHOULD NOTtarget="RFC9499" format="default"/> <bcp14>SHOULD NOT</bcp14> 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. </t> </section> <sectiontitle="IANA Considerations"> <t>IANA is requestednumbered="true" toc="default"> <name>IANA Considerations</name> <!--[rfced] We had the following questions/comments about the IANA Considerations section: a) We note that the two IANA registries: https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml and https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml Use two different headings / column titles. We have updated the lead-in text toassignindicate the version shown matches the second registry. Please let us know if any further updates are necessary/desired. b) FYI - We have updated the allocation date to match that listed in the IANA registry. --> <t>IANA has assigned the following /16 address block from theIPv6"IPv6 Unicast AddressRegistryAssignments" registry <xreftarget="UNICAST"/>target="UNICAST" format="default"/> for the purposes described inSection 5<xref target="section5"/> andrecordrecorded the allocation in the "IANA IPv6 Special-Purpose AddressRegistryRegistry" <xreftarget="SPECIAL"/>.target="SPECIAL" format="default"/> as follows: </t><t> Address Block: 5f00::/16 <br/>Name: Segment<dl newline="true"> <dt>Address Block:</dt> <dd>5f00::/16</dd> <dt>Name:</dt><dd>Segment Routing (SRv6)SIDs <br/>RFC: This document <br/>Allocation Date: Allocation Date <br/>Termination Date: N/A <br/>Source: True <br/>Destination: True <br/>Forwardable: True <br/>Globally Reachable: False <br/>Reserved-by-Protocol: False </t>SIDs</dd> <dt>RFC:</dt> <dd>RFC 9602</dd> <dt>Allocation Date:</dt> <dd>2024-04</dd> <dt>Termination Date:</dt> <dd>N/A</dd> <dt>Source:</dt> <dd>True</dd> <dt>Destination:</dt> <dd>True</dd> <dt>Forwardable:</dt> <dd>True</dd> <dt>Globally Reachable:</dt> <dd>False</dd> <dt>Reserved-by-Protocol:</dt> <dd>False</dd></dl> </section> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>The security considerations for the use of Segment Routing <xreftarget="RFC8402"/>,target="RFC8402" format="default"/>, SRv6 <xreftarget="RFC8754"/>,target="RFC8754" format="default"/>, and SRv6 network programming <xreftarget="RFC8986"/>target="RFC8986" format="default"/> 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 <xreftarget="RFC6169"/>.target="RFC6169" format="default"/>. 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. </t> <t> 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 andtheydo not accidentally enterSR unawareSR-unaware domains. Similarly, as stated inSection 5.1 of<xreftarget="RFC8754"/>,target="RFC8754" sectionFormat="of" section="5.1"/>, the SR domain needs to be configured to filter out packets entering that use the selected prefix. </t> </section> </middle> <back> <displayreference target="I-D.ietf-spring-srv6-srh-compression" to="CSID"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/> <referencegroup anchor="BCP198" target="https://www.rfc-editor.org/info/bcp198"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7608.xml"/> </referencegroup> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6052.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6169.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7343.xml"/> <!-- [I-D.ietf-spring-srv6-srh-compression] IESG state: I-D Exists as of 04/17/24 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-spring-srv6-srh-compression.xml"/> <!--[rfced] Please note that we have removed the reference to draft-ietf-spring-compression-analysis as there were no citations to it in the text. Please let us know any objections.--> <reference anchor="UNICAST" target="https://www.iana.org/assignments/ipv6-unicast-address-assignments"> <front> <title>IPv6 Global Unicast Address Assignments</title> <author fullname="IANA"/> </front> </reference> <reference anchor="SPECIAL" target="https://www.iana.org/assignments/iana-ipv6-special-registry"> <front> <title>IANA IPv6 Special-Purpose Address Registry</title> <author fullname="IANA"/> </front> </reference> <!--[rfced] Please note that RFC 8499 has been obsoleted by RFC 9499. We have updated the reference and citation to point to the latter. However, please review this time-related text (i.e., "at the present time") and let us know if any further updates are necessary. Original: At the present time, global DNS [RFC8499] SHOULD NOT reference addresses assigned from this block. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/> </references> </references> <sectiontitle="Acknowledgments">numbered="false" toc="default"> <name>Acknowledgments</name> <t>The author would like to extend a special note of thanks toBrian Carpenter and Erik Kline<contact fullname="Brian Carpenter"/> and <contact fullname="Erik Kline"/> for their precisely summarized thoughts on this topic that provided the seed of thisdraft.document. The author would also like to thankAndrew Alston, Fred Baker, Ron Bonica, Nick Buraglio, Bruno Decraene, Dhruv Dhody, Darren Dukes, Linda Dunbar, Reese Enghardt, Adrian Farrel, Clarence Filsfils, Jim Guichard, Joel Halpern, Ted Hardie, Bob Hinden, Murray Kucherawy, Cheng Li, Acee Lindem, Jen Linkova, Gyan Mishra, Yingzhen Qu, Robert Raszuk, Alvaro Retana, Michael Richardson, John Scudder, Petr Spacek, Mark Smith, Dirk Steinberg, Ole Troan, Eduard Vasilenko, Eric Vyncke, Rob Wilton, Jingrong Xie, Chongfeng Xie<contact fullname="Andrew Alston"/>, <contact fullname="Fred Baker"/>, <contact fullname="Ron Bonica"/>, <contact fullname="Nick Buraglio"/>, <contact fullname="Bruno Decraene"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname="Darren Dukes"/>, <contact fullname="Linda Dunbar"/>, <contact fullname="Reese Enghardt"/>, <contact fullname="Adrian Farrel"/>, <contact fullname="Clarence Filsfils"/>, <contact fullname="Jim Guichard"/>, <contact fullname="Joel Halpern"/>, <contact fullname="Ted Hardie"/>, <contact fullname="Bob Hinden"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Cheng Li"/>, <contact fullname="Acee Lindem"/>, <contact fullname="Jen Linkova"/>, <contact fullname="Gyan Mishra"/>, <contact fullname="Yingzhen Qu"/>, <contact fullname="Robert Raszuk"/>, <contact fullname="Alvaro Retana"/>, <contact fullname="Michael Richardson"/>, <contact fullname="John Scudder"/>, <contact fullname="Petr Spacek"/>, <contact fullname="Mark Smith"/>, <contact fullname="Dirk Steinberg"/>, <contact fullname="Ole Troan"/>, <contact fullname="Eduard Vasilenko"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Rob Wilton"/>, <contact fullname="Jingrong Xie"/>, <contact fullname="Chongfeng Xie"/>, andJuan<contact fullname="Juan CarlosZunigaZuniga"/> for their ideas and comments to improve this document. </t> </section></middle> <back> <references title="Normative References"> &RFC2119; &RFC4291; <reference anchor="BCP198" target="https://www.rfc-editor.org/info/rfc7608"> <front> <title>IPv6 Prefix Length Recommendation for Forwarding</title> <author fullname="M. Boucadair" initials="M." surname="Boucadair"/> <author fullname="A. Petrescu" initials="A." surname="Petrescu"/> <author fullname="F. Baker" initials="F." surname="Baker"/> <date month="July" year="2015"/> <abstract> <t> IPv6 prefix length, as in IPv4, is a parameter conveyed and<!--[rfced] Throughout the text, the following terminology appears to be usedin IPv6 routinginconsistently. Please review these occurrences andforwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefixlet us know if/how they may beany 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. </t> </abstract> </front> <seriesInfo name="BCP" value="198"/> <seriesInfo name="RFC" value="7608"/> <seriesInfo name="DOI" value="10.17487/RFC7608"/> </reference> &RFC8402; &RFC8174; &RFC8754; &RFC8986; </references> <references title="Informative References"> &RFC6052; &RFC6169; &RFC7343; <reference anchor="CSID" target="https://www.ietf.org/archive/id/draft-ietf-spring-srv6-srh-compression-09.txt"> <front> <title>Compressed SRv6made consistent. Segment ListEncoding in SRH</title> <author fullname="Weiqiang Cheng" initials="W." surname="Cheng"> <organization>China Mobile</organization> </author> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> <organization>Cisco Systems</organization> </author> <author fullname="Zhenbin Li" initials="Z." surname="Li"> <organization>Huawei Technologies</organization> </author> <author fullname="Bruno Decraene" initials="B." surname="Decraene"> <organization>Orange</organization> </author> <author fullname="Francois Clad" initials="F." surname="Clad"> <organization>Cisco Systems</organization> </author> <date day="23" month="October" year="2023"/> <abstract> <t> This document specifies new flavors for thev. SegmentRouting (SR) segment endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size oflist SR Domain v. SR domain --> <!-- [rfced] Please review theSRv6 encapsulation needed to steer packets over long segment lists. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-srh-compression-09"/> </reference> &I-D.ietf-spring-compression-analysis; <reference anchor="UNICAST" target="https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml"> <front> <title>IPv6 Global Unicast Address Assignments</title> <author fullname="IANA"/> </front> </reference> <reference anchor="SPECIAL" target="https://www.iana.org/assignments/iana-ipv6-special-registry/"> <front> <title>IANA IPv6 Special-Purpose Address Registry</title> <author fullname="IANA"/> </front> </reference> &RFC8499; </references>"Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </back> </rfc>