rfc9602xml2.original.xml   rfc9602.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <!DOCTYPE rfc [
ce.RFC.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC4291 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <!ENTITY zwsp "&#8203;">
ce.RFC.4291.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC6052 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <!ENTITY wj "&#8288;">
ce.RFC.6052.xml">
<!ENTITY RFC6169 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6169.xml">
<!ENTITY RFC7343 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7343.xml">
<!ENTITY RFC8402 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8402.xml">
<!ENTITY RFC8499 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8499.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.xml">
<!ENTITY RFC8754 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.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">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
<?rfc strict="yes" ?> etf-6man-sids-06" number="9602" consensus="true" ipr="trust200902" obsoletes=""
<?rfc toc="yes"?> updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" sy
<?rfc tocdepth="4"?> mRefs="true" sortRefs="true" version="3">
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-6man-sids-06" ipr="trust200902">
<front> <front>
<title abbrev="SRv6 SIDs">SRv6 Segment Identifiers in the IPv6 Addressing Ar chitecture</title> <!-- [rfced] Please note that the title of the document has been updated as foll ows:
<author fullname="Suresh Krishnan" initials="S." Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
surname="Krishnan"> Style Guide"). Please review as this leads to a repeat of "segment".
<organization>Cisco</organization>
Original:
SRv6 Segment Identifiers in the IPv6 Addressing Architecture
Current:
Segment Routing over IPv6 (SRv6) Segment Identifiers in the IPv6 Addressing Arch
itecture
-->
<title abbrev="SRv6 SIDs">Segment Routing over IPv6 (SRv6) Segment Identifie
rs in the IPv6 Addressing Architecture</title>
<seriesInfo name="RFC" value="9602"/>
<author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
<organization>Cisco</organization>
<address> <address>
<postal> <email>suresh.krishnan@gmail.com</email>
<street></street> </address>
</author>
<date month="June" year="2024"/>
<city></city> <area>INT</area>
<workgroup>6man</workgroup>
<region></region> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<code></code> <keyword>example</keyword>
<country></country> <!--[rfced] We had the following questions about the Abstract.
</postal>
<email>suresh.krishnan@gmail.com</email> a) Please review our edits to the Abstract to ensure we have
maintained your intended meaning.
</address> b) Please also review if the first sentence might be rewritten to
</author> eliminate some redundancy (i.e., "over IPv6" and "IPv6 as underlying"
seem similar).
<date/> 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?
<area>Internet</area> 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.
<workgroup>6man</workgroup> 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> <abstract>
<t>The data plane for Segment Routing over IPv6 (SRv6) is built using IPv6 <t>The data plane for Segment Routing over IPv6 (SRv6) is built using
as the underlying forwarding plane. IPv6 as the underlying forwarding plane. Thus, Segment Identifiers (SIDs)
Due to this underlying use of IPv6, Segment Identifiers (SIDs) used by SRv used by SRv6 can resemble IPv6
6 can resemble IPv6 addresses and behave like them addresses and behave like them in some situations while exhibiting slightl
while exhibiting slightly different behaviors in some situations. This doc y different
ument explores the characteristics of SRv6 SIDs behaviors in others. This document explores the characteristics
and focuses on the relationship of SRv6 SIDs to the IPv6 Addressing Archit of SRv6 SIDs and focuses on the relationship of SRv6 SIDs to the IPv6
ecture. This document allocates and makes a dedicated prefix available for SRv6 Addressing Architecture. This document allocates and makes a dedicated
SIDs. prefix available for SRv6 SIDs.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default">
<section title="Introduction"> <name>Introduction</name>
<t> <t>
Segment Routing over IPv6 (SRv6) <xref target="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 endpoi nt nodes process a local segment present in the Destination Address of an IPv6 h eader. Thus Segment Identifiers (SIDs) in SRv6 can and do appear in the Destinat ion Address of IPv6 datagrams by design. This document explores the characterist ics of SRv6 SIDs and focuses on the relationship of SRv6 SIDs to the IPv6 Addres sing Architecture <xref target="RFC4291"/>. This document allocates and makes a dedicated prefix available for SRv6 SIDs. Segment Routing over IPv6 (SRv6) <xref target="RFC8754" format="default"/> uses IPv6 as the underlying data plane. In SRv6, SR source nodes initiate packe ts 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 Destinati on Address of an IPv6 header. Thus, SIDs in SRv6 can, and do, appear in the Dest ination Address of IPv6 datagrams by design. This document explores the characte ristics of SRv6 SIDs and focuses on the relationship of SRv6 SIDs to the IPv6 Ad dressing Architecture <xref target="RFC4291" format="default"/>. This document a llocates and makes a dedicated prefix available for SRv6 SIDs.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<name>Terminology</name>
<t>The following terms are used as defined in <xref target="RFC8402" forma
t="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>
</li>
</ul>
<t>The following terms are used as defined in <xref target="RFC8754" forma
t="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>
</li>
</ul>
<section title="Terminology"> <t>
<t>The following terms are used as defined in <xref target="RFC8402"/>. The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<list style="symbols"> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
<t>Segment Routing (SR)</t> ",
<t>SR Domain</t> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<t>Segment</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t>Segment Identifier (SID)</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<t>SRv6</t> be
<t>SRv6 SID</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
</list> target="RFC8174"/> when, and only when, they appear in all capitals, as
</t> shown here.
<t>The following terms are used as defined in <xref target="RFC8754"/>. </t>
<list style="symbols">
<t>Segment Routing Header (SRH)</t>
<t>SR Source Node</t>
<t>Transit Node</t>
<t>SR Segment Endpoint Node</t>
</list>
</t>
<t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when
, and only when, they
appear in all capitals, as shown here.
</t>
</section>
<section title="SRv6 SIDs and the IPv6 Addressing Architecture">
</section>
<section numbered="true" toc="default" anchor="section3">
<name>SRv6 SIDs and the IPv6 Addressing Architecture</name>
<t> <t>
<xref target="RFC8754"/> defines the Segment List of the SRH as a contiguo us array of 128-bit IPv6 addresses, and that each of the elements in this list a re 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 <xref t arget="RFC8754"/> as "A FIB entry that represents a local interface, not locally instantiated as an SRv6 SID". From this it follows that not all the SIDs that a ppear in the SRH are SRv6 SIDs as defined by <xref target="RFC8402"/>. <xref target="RFC8754" format="default"/> defines the Segment List of the SRH as a contiguous array of 128-bit IPv6 addresses; further, it states that ea ch of the elements in this list are SIDs. But all of these elements are not nece ssarily made equal. Some of these elements may represent a local interface as de scribed in <xref target="RFC8754" sectionFormat="of" section="4.3"/> as "A FIB e ntry 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 defin ed by <xref target="RFC8402" format="default"/>.
</t> </t>
<t> <t>
As stated above, the non-SRv6-SID elements that appear in As stated above, the non-SRv6-SID elements that appear in
the SRH SID list are simply IPv6 addresses assigned to local the SRH SID list are simply IPv6 addresses assigned to local
interfaces and they need to conform to <xref target="RFC4291"/>. So, the foll owing discussions are applicable solely to SRv6 SIDs that are not assigned to lo cal interfaces. interfaces, and they need to conform to <xref target="RFC4291" format="defaul t"/>. So, the following discussions are applicable solely to SRv6 SIDs that are not assigned to local interfaces.
</t> </t>
<t> <t>
One of the key questions to address is how these SRv6 SIDs appearing as IP v6 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 ). One of the key questions to address is how these SRv6 SIDs appearing as IP v6 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>
<t> <t>
Section 3.1. of <xref target="RFC8986"/> describes the format of an SRv6 S <xref target="RFC8986" sectionFormat="of" section="3.1"/> describes the fo
ID as composed of three parts LOC:FUNCT:ARG, where a locator (LOC) is encoded in rmat of an SRv6 SID as being composed of three parts, LOC:FUNCT:ARG, where a loc
the L most significant bits of the SID, followed by F bits of function (FUNCT) ator (LOC) is encoded in the L most significant bits of the SID followed by F bi
and A bits of arguments (ARG). If L+F+A &lt; 128, ts of function (FUNCT) and A bits of arguments (ARG). If L+F+A &lt; 128,
the ARG is followed by enough zero bits to fill the 128 bit SID. Such an S the ARG is followed by enough zero bits to fill the 128-bit SID. Such an S
Rv6 SID is assigned to a node within a prefix defined as a Locator of length L. Rv6 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 match prefix corresponding to the Locator <xref target="BCP198"/> is <!--[rfced] Looking at BCP 198, we see the use of
used by the transit node to forward the packet to the node identified by the Lo "longest-match-first". But it is used to describe rules and
cator. 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 <xref target="BCP198
" format="default"/> is used by the transit node to forward the packet to the no
de identified by the Locator.
</t> </t>
<t> <t>
It is clear that this format for SRv6 SIDs is not compliant with the requi It is clear that this format for SRv6 SIDs is not compliant with the requ
rements set forth in <xref target="RFC4291"/> for IPv6 addresses but it is also irements set forth in <xref target="RFC4291" format="default"/> for IPv6 address
clear that SRv6 SIDs are not intended for assignment onto interfaces on end host es, but it is also clear that SRv6 SIDs are not intended for assignment onto int
s. They look and act similarly to other mechanisms that use IPv6 addresses with erfaces on end hosts.
different formats such as <xref target="RFC6052"/> that defines the IPv6 Address
ing of IPv4/IPv6 Translators and <xref target="RFC7343"/> that describes ORCHIDv <!--[rfced] Might it be preferrable to use the titles of these
2 (a cryptographic hash identifier format). documents in lieu of a description?
</t>
Original:
They look and act similarly 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).
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 diff
erent 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 ver
sion 2 (ORCHIDv2) (a cryptographic hash identifier format)).
</t>
<t> <t>
While looking at the transit nodes it becomes apparent that these While looking at the transit nodes, it becomes apparent that these
addresses are used purely for forwarding and not addresses are used purely for forwarding and not
for packet delivery to end hosts. for packet delivery to end hosts.
Hence the relevant specification to apply here is <xref target="BCP198"/ Hence, the relevant specification to apply here is <xref target="BCP198"
> that requires implementations to support the use of variable format="default"/>, which requires implementations to support the use of variab
length prefixes in forwarding while explicitly decoupling IPv6 routing a le-length prefixes in forwarding while explicitly decoupling IPv6 routing and fo
nd forwarding from the IPv6 address/prefix semantics described in <xref target=" rwarding from the IPv6 address/prefix semantics described in <xref target="RFC42
RFC4291"/>. Please note that <xref target="BCP198"/> does not override the rules 91" format="default"/>. Please note that <xref target="BCP198" format="default"/
in <xref target="RFC4291"/>, but merely limits where their impact is observed. > does not override the rules in <xref target="RFC4291" format="default"/>: it m
erely limits where their impact is observed.
</t> </t>
<t> <t>
Furthermore, in the SRv6 specifications, all SIDs assigned within a given Locator prefix are located inside the node identified by Locator. Therefore the re does not appear to be a conflict with section 2.6.1 of <xref target="RFC4291" /> since subnet-router anycast addresses are neither required nor useful within a node. Furthermore, in the SRv6 specifications, all SIDs assigned within a given Locator prefix are located inside the node identified by Locator. Therefore, th ere does not appear to be a conflict with <xref target="RFC4291" sectionFormat=" of" section="2.6.1"/> since subnet-router anycast addresses are neither required nor useful within a node.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<name>Special Considerations for Compressed SIDs</name>
<t>
<section title="Special Considerations for Compressed SIDs"> <!--[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?
<t> Original:
<xref target="CSID"/> introduces an encoding for compressed segment lists (C-SIDs)
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 me Perhaps:
chanism accomplishes this by using the ARG part <xref target="RFC8986"/> of the Compressed-SIDs (C-SIDs)
Destination Address of the IPv6 header to derive a new Destination Address. 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 <xref target="I-D.ietf-spring-srv6-srh-compression" format="default"/> int
the SRH. roduces 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 me
chanism accomplishes this by using the ARG part <xref target="RFC8986" format="d
efault"/> of the Destination Address of the IPv6 header to derive a new Destinat
ion Address. That is, the Destination Address field of the packet changes at a s
egment endpoint in a way similar to how the address changes as the result of pro
cessing a segment in the SRH.
</t> </t>
<t> <t>
One key thing to note here is that the Locator Block at the beginning of t he address does not get modified by the operations needed for supporting compres sed 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 and any changes are restricted to SR aware nodes. One key thing to note here is that the Locator Block at the beginning of t he address does not get modified by the operations needed for supporting compres sed 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 re stricted to SR-aware nodes.
</t> </t>
</section> </section>
<section numbered="true" toc="default" anchor="section5">
<section title="Allocation of a Global Unicast Prefix for SIDs"> <name>Allocation of a Global Unicast Prefix for SIDs</name>
<t>All of the SRv6-related specifications discussed above are intended to
<t>All of the SRv6 related specifications discussed above are intended to be applicable to a contained SR Domain or between collaborating SR Domains. Node
be applicable to a contained SR Domain or between collaborating SR Domains. Node s either inside or outside the SR Domains that are not SR-aware
s either inside or outside the SR Domains that are not SR-aware
will not perform any special behavior for SRv6 SIDs and will treat will not perform any special behavior for SRv6 SIDs and will treat
them solely as IPv6 routing prefixes. them solely as IPv6 routing prefixes.
</t> </t>
<t> <t>
As an added factor of security, it is desirable to allocate some address s pace that explicitly signals that the addresses within that space cannot be expe cted to comply with <xref target="RFC4291"/>. As described in Section 3 above, t here is precedent for mechanisms that use IPv6 addresses in a manner different f rom that specified in <xref target="RFC4291"/>. This would be useful in identify ing and potentially filtering packets at the edges of the SR Domains to make it simpler for the SR domain to fail closed. As an added factor of security, it is desirable to allocate some address s pace that explicitly signals that the addresses within that space cannot be expe cted to comply with <xref target="RFC4291" format="default"/>. As described in < xref target="section3"/>, there is precedent for mechanisms that use IPv6 addres ses in a manner different from that specified in <xref target="RFC4291" format=" default"/>. This would be useful in identifying and potentially filtering packet s at the edges of the SR Domains to make it simpler for the SR domain to fail cl osed.
</t> </t>
<t> <t>
At the present time, global DNS <xref target="RFC8499"/> SHOULD NOT refere nce addresses assigned from this block. Further specifications are needed to des cribe 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 wit h their requirements. At the present time, global DNS <xref target="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 conven tions and guidelines in line with their requirements.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<section title="IANA Considerations"> <!--[rfced] We had the following questions/comments about the IANA
<t>IANA is requested to assign the following /16 address block from the IP Considerations section:
v6 Unicast Address Registry <xref target="UNICAST"/> for the purposes described
in Section 5 and record the allocation in the IPv6 Special-Purpose Address Regis
try <xref target="SPECIAL"/>.
</t> a) We note that the two IANA registries:
<t>
Address Block: 5f00::/16
<br/>Name: 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>
</section>
<section title="Security Considerations"> https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-a
<t>The security considerations for the use of Segment Routing <xref target ddress-assignments.xhtml
="RFC8402"/>, SRv6 <xref target="RFC8754"/>, and SRv6 network programming <xref
target="RFC8986"/> and
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-re
gistry.xhtml
Use two different headings / column titles.
We have updated the lead-in text to indicate 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 the "IPv6 Unicas
t Address Assignments" registry <xref target="UNICAST" format="default"/> for th
e purposes described in <xref target="section5"/> and recorded the allocation in
the "IANA IPv6 Special-Purpose Address Registry" <xref target="SPECIAL" format=
"default"/> as follows:
</t>
<dl newline="true">
<dt>Address Block:</dt> <dd>5f00::/16</dd>
<dt>Name:</dt><dd>Segment Routing (SRv6) 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>
<section numbered="true" toc="default">
<name>Security Considerations</name>
<t>The security considerations for the use of Segment Routing <xref target
="RFC8402" format="default"/>, SRv6 <xref target="RFC8754" format="default"/>, a
nd SRv6 network programming <xref target="RFC8986" format="default"/>
apply to the use of these addresses. The use of IPv6 tunneling mechanisms (including SRv6) also 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 <xref target="RFC 6169"/>. 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. brings up additional concerns such as those described in <xref target="RFC 6169" format="default"/>. The usage of the prefix allocated by this document imp roves security by making it simpler to filter traffic at the edge of the SR doma ins.
</t> </t>
<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 and they do not accidentally enter SR unaware doma ins. Similarly, as stated in Section 5.1 of <xref target="RFC8754"/>, the SR dom ain needs to be configured to filter out packets entering that use the selected prefix. 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 <xref 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> </t>
</section> </section>
<section title="Acknowledgments"> </middle>
<back>
<t>The author would like to extend a special note of thanks to Brian Carpe <displayreference target="I-D.ietf-spring-srv6-srh-compression" to="CSID"/>
nter 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, Fred Baker, Ron Bonica, Nick Buraglio, Bruno Decrae
ne, Dhruv Dhody, Darren Dukes, Linda Dunbar, Reese Enghardt, Adrian Farrel, Clar
ence Filsfils, Jim Guichard, Joel Halpern, Ted Hardie, Bob Hinden, Murray Kucher
awy, 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 and Juan Carlos Zuniga for their ideas and comments to improve thi
s document.
</t>
</section> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
291.xml"/>
</middle> <referencegroup anchor="BCP198" target="https://www.rfc-editor.org/info/bcp198">
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7608.xm
l"/>
</referencegroup>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
754.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
052.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
169.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
343.xml"/>
<back> <!-- [I-D.ietf-spring-srv6-srh-compression] IESG state: I-D Exists as of 04/17/2
4 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-sp
ring-srv6-srh-compression.xml"/>
<references title="Normative References"> <!--[rfced] Please note that we have removed the reference to
&RFC2119; draft-ietf-spring-compression-analysis as there were no citations
&RFC4291; to it in the text. Please let us know any objections.-->
<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 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 i
mplementations of routing and forwarding should therefore impose no rules on pre
fix 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"> <reference anchor="UNICAST" target="https://www.iana.org/assignments/ipv
&RFC6052; 6-unicast-address-assignments">
&RFC6169; <front>
&RFC7343; <title>IPv6 Global Unicast Address Assignments</title>
<reference anchor="CSID" target="https://www.ietf.org/archive/id/draft-iet <author fullname="IANA"/>
f-spring-srv6-srh-compression-09.txt"> </front>
<front>
<title>Compressed SRv6 Segment List Encoding 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 the Segment Routing (SR) seg
ment endpoint behaviors defined in RFC 8986, which enable the compression of an
SRv6 segment list. Such compression significantly reduces the size of the SRv6 e
ncapsulation needed to steer packets over long segment lists.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-srh-comp
ression-09"/>
</reference> </reference>
&I-D.ietf-spring-compression-analysis;
<reference anchor="UNICAST" target="https://www.iana.org/assignments/ipv6- <reference anchor="SPECIAL" target="https://www.iana.org/assignments/ian
unicast-address-assignments/ipv6-unicast-address-assignments.xhtml"> a-ipv6-special-registry">
<front> <front>
<title>IPv6 Global Unicast Address Assignments</title> <title>IANA IPv6 Special-Purpose Address Registry</title>
<author fullname="IANA"/> <author fullname="IANA"/>
</front> </front>
</reference> </reference>
<reference anchor="SPECIAL" target="https://www.iana.org/assignments/iana-
ipv6-special-registry/"> <!--[rfced] Please note that RFC 8499 has been obsoleted by RFC 9499.
<front> We have updated the reference and citation to point to the
<title>IANA IPv6 Special-Purpose Address Registry</title> latter. However, please review this time-related text (i.e., "at
<author fullname="IANA"/> the present time") and let us know if any further updates are
</front> necessary.
</reference>
&RFC8499; Original:
</references> 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.9
499.xml"/>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The author would like to extend a special note of thanks to <contact fu
llname="Brian Carpenter"/> and <contact fullname="Erik Kline"/> for their preci
sely summarized thoughts
on this topic that provided the seed of this document. The author would al
so like to thank <contact fullname="Andrew Alston"/>, <contact fullname="Fred B
aker"/>, <contact fullname="Ron Bonica"/>, <contact fullname="Nick Buraglio"/>,
<contact fullname="Bruno Decraene"/>, <contact fullname="Dhruv Dhody"/>, <contac
t fullname="Darren Dukes"/>, <contact fullname="Linda Dunbar"/>, <contact fullna
me="Reese Enghardt"/>, <contact fullname="Adrian Farrel"/>, <contact fullname="C
larence 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"/>, <contac
t fullname="Acee Lindem"/>, <contact fullname="Jen Linkova"/>, <contact fullname
="Gyan Mishra"/>, <contact fullname="Yingzhen Qu"/>, <contact fullname="Robert R
aszuk"/>, <contact fullname="Alvaro Retana"/>, <contact fullname="Michael Richar
dson"/>, <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 fullna
me="Éric Vyncke"/>, <contact fullname="Rob Wilton"/>, <contact fullname="Jingron
g Xie"/>, <contact fullname="Chongfeng Xie"/>, and <contact fullname="Juan Carl
os Zuniga"/> for their ideas and comments to improve this document.
</t>
</section>
<!--[rfced] Throughout the text, the following terminology appears to
be used inconsistently. Please review these occurrences and let
us know if/how they may be made consistent.
Segment List v. Segment list
SR Domain v. SR domain
-->
<!-- [rfced] Please review the "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> </back>
</rfc> </rfc>
 End of changes. 61 change blocks. 
278 lines changed or deleted 402 lines changed or added

This html diff was produced by rfcdiff 1.48.