rfc9602.original   rfc9602.txt 
6man S. Krishnan Internet Engineering Task Force (IETF) S. Krishnan
Internet-Draft Cisco Request for Comments: 9602 Cisco
Intended status: Informational 15 February 2024 Category: Informational October 2024
Expires: 18 August 2024 ISSN: 2070-1721
SRv6 Segment Identifiers in the IPv6 Addressing Architecture Segment Routing over IPv6 (SRv6) Segment Identifiers in the IPv6
draft-ietf-6man-sids-06 Addressing Architecture
Abstract Abstract
The data plane for Segment Routing over IPv6 (SRv6) is built using Segment Routing over IPv6 (SRv6) uses IPv6 as the underlying data
IPv6 as the underlying forwarding plane. Due to this underlying use plane. Thus, Segment Identifiers (SIDs) used by SRv6 can resemble
of IPv6, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 IPv6 addresses and behave like them while exhibiting slightly
addresses and behave like them while exhibiting slightly different different behaviors in some situations. This document explores the
behaviors in some situations. This document explores the
characteristics of SRv6 SIDs and focuses on the relationship of SRv6 characteristics of SRv6 SIDs and focuses on the relationship of SRv6
SIDs to the IPv6 Addressing Architecture. This document allocates SIDs to the IPv6 Addressing Architecture. This document allocates
and makes a dedicated prefix available for SRv6 SIDs. and makes a dedicated prefix available for SRv6 SIDs.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 18 August 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9602.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology
3. SRv6 SIDs and the IPv6 Addressing Architecture . . . . . . . 3 3. SRv6 SIDs and the IPv6 Addressing Architecture
4. Special Considerations for Compressed SIDs . . . . . . . . . 4 4. Special Considerations for Compressed SIDs
5. Allocation of a Global Unicast Prefix for SIDs . . . . . . . 5 5. Allocation of a Prefix for SIDs
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address
1. Introduction 1. Introduction
Segment Routing over IPv6 (SRv6) [RFC8754] uses IPv6 as the Segment Routing over IPv6 (SRv6) [RFC8754] uses IPv6 as the
underlying data plane. In SRv6, SR source nodes initiate packets underlying data plane. In SRv6, SR source nodes initiate packets
with a segment identifier in the Destination Address of the IPv6 with a Segment Identifier (SID) in the Destination Address of the
header, and SR segment endpoint nodes process a local segment present IPv6 header, and SR segment endpoint nodes process a local segment
in the Destination Address of an IPv6 header. Thus Segment present in the Destination Address of an IPv6 header. Thus, SIDs in
Identifiers (SIDs) in SRv6 can and do appear in the Destination SRv6 can, and do, appear in the Destination Address of IPv6 datagrams
Address of IPv6 datagrams by design. This document explores the by design. This document explores the characteristics of SRv6 SIDs
characteristics of SRv6 SIDs and focuses on the relationship of SRv6 and focuses on the relationship of SRv6 SIDs to the IPv6 Addressing
SIDs to the IPv6 Addressing Architecture [RFC4291]. This document Architecture [RFC4291]. This document allocates and makes a
allocates and makes a dedicated prefix available for SRv6 SIDs. dedicated prefix available for SRv6 SIDs.
2. Terminology 2. Terminology
The following terms are used as defined in [RFC8402]. The following terms are used as defined in [RFC8402].
* Segment Routing (SR) * Segment Routing (SR)
* SR Domain * SR Domain
* Segment * Segment
skipping to change at page 3, line 4 skipping to change at line 90
The following terms are used as defined in [RFC8402]. The following terms are used as defined in [RFC8402].
* Segment Routing (SR) * Segment Routing (SR)
* SR Domain * SR Domain
* Segment * Segment
* Segment Identifier (SID) * Segment Identifier (SID)
* SRv6 * SRv6
* SRv6 SID * SRv6 SID
The following terms are used as defined in [RFC8754]. The following terms are used as defined in [RFC8754].
* Segment Routing Header (SRH) * Segment Routing Header (SRH)
* SR Source Node * SR Source Node
* Transit Node * Transit Node
* SR Segment Endpoint Node * SR Segment Endpoint Node
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. SRv6 SIDs and the IPv6 Addressing Architecture 3. SRv6 SIDs and the IPv6 Addressing Architecture
[RFC8754] defines the Segment List of the SRH as a contiguous array [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 of 128-bit IPv6 addresses; further, it states that each of the
are SIDs. But all of these elements are not necessarily made equal. elements in this list are SIDs. But all of these elements are not
Some of these elements may represent a local interface as described necessarily made equal. Some of these elements may represent a local
in Section 4.3 of [RFC8754] as "A FIB entry that represents a local interface as described in Section 4.3 of [RFC8754] as "A FIB entry
interface, not locally instantiated as an SRv6 SID". From this it that represents a local interface, not locally instantiated as an
follows that not all the SIDs that appear in the SRH are SRv6 SIDs as SRv6 SID". It follows that not all the SIDs that appear in the SRH
defined by [RFC8402]. are SRv6 SIDs as defined by [RFC8402].
As stated above, the non-SRv6-SID elements that appear in the SRH SID 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 list are simply IPv6 addresses assigned to local interfaces, and they
need to conform to [RFC4291]. So, the following discussions are need to conform to [RFC4291]. So, the following discussions are
applicable solely to SRv6 SIDs that are not assigned to local applicable solely to SRv6 SIDs that are not assigned to local
interfaces. interfaces.
One of the key questions to address is how these SRv6 SIDs appearing One of the key questions to address is how these SRv6 SIDs appearing
as IPv6 Destination Addresses are perceived and treated by "transit as IPv6 Destination Addresses are perceived and treated by "transit
nodes" (that are not required to be capable of processing a Segment nodes" (that are not required to be capable of processing a Segment
or the Segment Routing Header). or the Segment Routing Header).
Section 3.1. of [RFC8986] describes the format of an SRv6 SID as Section 3.1 of [RFC8986] describes the format of an SRv6 SID as being
composed of three parts LOC:FUNCT:ARG, where a locator (LOC) is 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 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, 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. 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 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 Locator of length L. When an SRv6 SID occurs in the IPv6 Destination
Address of an IPv6 header, only the longest match prefix Address of an IPv6 header, only the longest matching prefix
corresponding to the Locator [BCP198] is used by the transit node to corresponding to the Locator [BCP198] is used by the transit node to
forward the packet to the node identified by the Locator. forward the packet to the node identified by the Locator.
It is clear that this format for SRv6 SIDs is not compliant with the 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 requirements set forth in [RFC4291] for IPv6 addresses, but it is
clear that SRv6 SIDs are not intended for assignment onto interfaces also clear that SRv6 SIDs are not intended for assignment onto
on end hosts. They look and act similarly to other mechanisms that interfaces on end hosts. They look and act like other mechanisms
use IPv6 addresses with different formats such as [RFC6052] that that use IPv6 addresses with different formats, such as those
defines the IPv6 Addressing of IPv4/IPv6 Translators and [RFC7343] described in "IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052] and
that describes ORCHIDv2 (a cryptographic hash identifier format). "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers
Version 2 (ORCHIDv2)" [RFC7343].
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 for packet delivery addresses are used purely for forwarding and not for packet delivery
to end hosts. Hence the relevant specification to apply here is to end hosts. Hence, the relevant specification to apply here is
[BCP198] that requires implementations to support the use of variable [BCP198], which requires implementations to support the use of
length prefixes in forwarding while explicitly decoupling IPv6 variable-length prefixes in forwarding while explicitly decoupling
routing and forwarding from the IPv6 address/prefix semantics IPv6 routing and forwarding from the IPv6 address/prefix semantics
described in [RFC4291]. Please note that [BCP198] does not override described in [RFC4291]. Please note that [BCP198] does not override
the rules in [RFC4291], but merely limits where their impact is the rules in [RFC4291]: it merely limits where their impact is
observed. observed.
Furthermore, in the SRv6 specifications, all SIDs assigned within a Furthermore, in the SRv6 specifications, all SIDs assigned within a
given Locator prefix are located inside the node identified by given Locator prefix are located inside the node identified by
Locator. Therefore there does not appear to be a conflict with Locator. Therefore, there does not appear to be a conflict with
section 2.6.1 of [RFC4291] since subnet-router anycast addresses are Section 2.6.1 of [RFC4291] since subnet-router anycast addresses are
neither required nor useful within a node. neither required nor useful within a node.
4. Special Considerations for Compressed SIDs 4. Special Considerations for Compressed SIDs
[CSID] introduces an encoding for compressed segment lists (C-SIDs), [CSID] introduces an encoding for Compressed-SIDs (C-SIDs), and
and describes how to use a single entry in the Segment list as a describes how to use a single entry in the Segment List as a
container for multiple SIDs. A node taking part in this mechanism container for multiple SIDs. A node taking part in this mechanism
accomplishes this by using the ARG part [RFC8986] of the Destination accomplishes this by using the ARG part [RFC8986] of the Destination
Address of the IPv6 header to derive a new Destination Address. i.e., Address of the IPv6 header to derive a new Destination Address. That
the Destination Address field of the packet changes at a segment 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 endpoint in a way similar to how the address changes as the result of
processing a segment in the SRH. processing a segment in the SRH.
One key thing to note here is that the Locator Block at the beginning 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 of the address does not get modified by the operations needed for
supporting compressed SIDs. As we have established that the SRv6 supporting C-SIDs. As we have established that the SRv6 SIDs are
SIDs are being treated simply as routing prefixes on transit nodes being treated simply as routing prefixes on transit nodes within the
within the SR domain this does not constitute a modification to the SR Domain, this does not constitute a modification to the IPv6 data
IPv6 data plane on such transit nodes and any changes are restricted plane on such transit nodes: any changes are restricted to SR-aware
to SR aware nodes. nodes.
5. Allocation of a Global Unicast Prefix for SIDs 5. Allocation of a Prefix for SIDs
All of the SRv6 related specifications discussed above are intended All of the SRv6-related specifications discussed above are intended
to be applicable to a contained SR Domain or between collaborating SR to be applicable to a contained SR Domain or between collaborating SR
Domains. Nodes either inside or outside the SR Domains that are not 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 SR-aware will not perform any special behavior for SRv6 SIDs and will
treat them solely as IPv6 routing prefixes. treat them solely as IPv6 routing prefixes.
As an added factor of security, it is desirable to allocate some As an added factor of security, it is desirable to allocate some
address space that explicitly signals that the addresses within that address space that explicitly signals that the addresses within that
space cannot be expected to comply with [RFC4291]. As described in space cannot be expected to comply with [RFC4291]. As described in
Section 3 above, there is precedent for mechanisms that use IPv6 Section 3, there is precedent for mechanisms that use IPv6 addresses
addresses in a manner different from that specified in [RFC4291]. in a manner different from that specified in [RFC4291]. This would
This would be useful in identifying and potentially filtering packets be useful in identifying and potentially filtering packets at the
at the edges of the SR Domains to make it simpler for the SR domain edges of the SR Domains to make it simpler for the SR Domain to fail
to fail closed. closed.
At the present time, global DNS [RFC8499] SHOULD NOT reference At the time of writing, global DNS [RFC9499] SHOULD NOT reference
addresses assigned from this block. Further specifications are addresses assigned from this block. Further specifications are
needed to describe the conventions and guidelines for the use of this needed to describe the conventions and guidelines for the use of this
newly allocated address block. The SRv6 operational community, which newly allocated address block. The SRv6 operational community, which
is the first intended user of this block, is requested to come up is the first intended user of this block, is requested to come up
with such conventions and guidelines in line with their requirements. with such conventions and guidelines in line with their requirements.
6. IANA Considerations 6. IANA Considerations
IANA is requested to assign the following /16 address block from the IANA has assigned the following /16 address block for the purposes
IPv6 Unicast Address Registry [UNICAST] for the purposes described in described in Section 5 and recorded the allocation in the "IANA IPv6
Section 5 and record the allocation in the IPv6 Special-Purpose Special-Purpose Address Registry" [SPECIAL] as follows:
Address Registry [SPECIAL].
Address Block: 5f00::/16 Address Block:
Name: Segment Routing (SRv6) SIDs 5f00::/16
RFC: This document
Allocation Date: Allocation Date Name:
Termination Date: N/A Segment Routing (SRv6) SIDs
Source: True
Destination: True RFC:
Forwardable: True RFC 9602
Globally Reachable: False
Reserved-by-Protocol: False Allocation Date:
2024-04
Termination Date:
N/A
Source:
True
Destination:
True
Forwardable:
True
Globally Reachable:
False
Reserved-by-Protocol:
False
7. Security Considerations 7. Security Considerations
The security considerations for the use of Segment Routing [RFC8402], The security considerations for the use of Segment Routing [RFC8402],
SRv6 [RFC8754], and SRv6 network programming [RFC8986] apply to the SRv6 [RFC8754], and SRv6 network programming [RFC8986] apply to the
use of these addresses. The use of IPv6 tunneling mechanisms use of these addresses. The use of IPv6 tunneling mechanisms
(including SRv6) also brings up additional concerns such as those (including SRv6) also brings up additional concerns such as those
described in [RFC6169]. The usage of the prefix allocated by this described in [RFC6169]. The usage of the prefix allocated by this
document improves security by making it simpler to filter traffic at document improves security by making it simpler to filter traffic at
the edge of the SR domains. the edge of the SR Domains.
In case the deployments do not use this allocated prefix, additional In case the deployments do not use this allocated prefix, additional
care needs to be exercised at network ingress and egress points so 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 that SRv6 packets do not leak out of SR Domains and do not
accidentally enter SR unaware domains. Similarly, as stated in accidentally enter SR-unaware Domains. Similarly, as stated in
Section 5.1 of [RFC8754], the SR domain needs to be configured to Section 5.1 of [RFC8754], the SR Domain needs to be configured to
filter out packets entering that use the selected prefix. filter out packets entering that use the selected prefix.
8. Acknowledgments 8. References
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, 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 and Juan Carlos Zuniga for their ideas
and comments to improve this document.
9. References 8.1. Normative References
9.1. Normative References [BCP198] Best Current Practice 198,
<https://www.rfc-editor.org/info/bcp198>.
At the time of writing, this BCP comprises the following:
[BCP198] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
Length Recommendation for Forwarding", BCP 198, RFC 7608, Length Recommendation for Forwarding", BCP 198, RFC 7608,
DOI 10.17487/RFC7608, July 2015, DOI 10.17487/RFC7608, July 2015,
<https://www.rfc-editor.org/info/rfc7608>. <https://www.rfc-editor.org/info/rfc7608>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
skipping to change at page 7, line 29 skipping to change at line 307
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>. <https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, (SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021, DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>. <https://www.rfc-editor.org/info/rfc8986>.
9.2. Informative References 8.2. Informative References
[CSID] Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F. [CSID] Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, "Compressed SRv6 Segment List Encoding in SRH", Work Clad, "Compressed SRv6 Segment List Encoding", Work in
in Progress, Internet-Draft, draft-ietf-spring-srv6-srh- Progress, Internet-Draft, draft-ietf-spring-srv6-srh-
compression-09, 23 October 2023, compression-18, 22 July 2024,
<https://www.ietf.org/archive/id/draft-ietf-spring-srv6-
srh-compression-09.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-03, 3 April 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring- <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
compression-analysis-03>. srv6-srh-compression-18>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010, DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>. <https://www.rfc-editor.org/info/rfc6052>.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, Concerns with IP Tunneling", RFC 6169,
DOI 10.17487/RFC6169, April 2011, DOI 10.17487/RFC6169, April 2011,
<https://www.rfc-editor.org/info/rfc6169>. <https://www.rfc-editor.org/info/rfc6169>.
[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay
Routable Cryptographic Hash Identifiers Version 2 Routable Cryptographic Hash Identifiers Version 2
(ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September
2014, <https://www.rfc-editor.org/info/rfc7343>. 2014, <https://www.rfc-editor.org/info/rfc7343>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, RFC 9499, DOI 10.17487/RFC9499, March 2024,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. <https://www.rfc-editor.org/info/rfc9499>.
[SPECIAL] IANA, "IANA IPv6 Special-Purpose Address Registry", [SPECIAL] IANA, "IANA IPv6 Special-Purpose Address Registry",
<https://www.iana.org/assignments/iana-ipv6-special- <https://www.iana.org/assignments/iana-ipv6-special-
registry/>. registry>.
[UNICAST] IANA, "IPv6 Global Unicast Address Assignments", Acknowledgments
<https://www.iana.org/assignments/ipv6-unicast-address-
assignments/ipv6-unicast-address-assignments.xhtml>. 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 document. The author would
also like to thank Andrew 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, Éric Vyncke, Rob Wilton,
Jingrong Xie, Chongfeng Xie, and Juan Carlos Zuniga for their ideas
and comments to improve this document.
Author's Address Author's Address
Suresh Krishnan Suresh Krishnan
Cisco Cisco
Email: suresh.krishnan@gmail.com Email: suresh.krishnan@gmail.com
 End of changes. 42 change blocks. 
151 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.48.