rfc9812.original.xml   rfc9812.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2. -ietf-6man-addr-assign-05" number="9812" category="bcp" consensus="true" submiss
3) --> ionType="IETF" updates="7249" obsoletes="" tocInclude="true" sortRefs="true" sym
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft Refs="true" xml:lang="en" version="3">
-ietf-6man-addr-assign-05" category="bcp" consensus="true" submissionType="IETF"
updates="7249" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.28.1 -->
<front> <front>
<title abbrev="IPv6 Address Allocation Policy">Clarification of IPv6 Address Allocation Policy</title> <title abbrev="IPv6 Address Allocation Policy">Clarification of IPv6 Address Allocation Policy</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-addr-assign-05"/>
<author initials="B. E." surname="Carpenter" fullname="Brian E. Carpenter"> <seriesInfo name="BCP" value="242"/>
<seriesInfo name="RFC" value="9812"/>
<author initials="B." surname="Carpenter" fullname="Brian E. Carpenter">
<organization abbrev="Univ. of Auckland">The University of Auckland</organ ization> <organization abbrev="Univ. of Auckland">The University of Auckland</organ ization>
<address> <address>
<postal> <postal>
<postalLine>School of Computer Science</postalLine> <street>School of Computer Science</street>
<postalLine>PB 92019</postalLine> <street>PB 92019</street>
<postalLine>Auckland 1142</postalLine> <city>Auckland 1142</city>
<postalLine>New Zealand</postalLine> <country>New Zealand</country>
</postal> </postal>
<email>brian.e.carpenter@gmail.com</email> <email>brian.e.carpenter@gmail.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Krishnan" fullname="Suresh Krishnan"> <author initials="S." surname="Krishnan" fullname="Suresh Krishnan">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization> <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address> <address>
<email>suresh.krishnan@gmail.com</email> <email>suresh.krishnan@gmail.com</email>
</address> </address>
</author> </author>
<author initials="D." surname="Farmer" fullname="David E. Farmer III"> <author initials="D." surname="Farmer" fullname="David E. Farmer III">
<organization abbrev="Univ. of Minnesota">University of Minnesota</organiz ation> <organization abbrev="Univ. of Minnesota">University of Minnesota</organiz ation>
<address> <address>
<postal> <postal>
<postalLine>Office of Information Technology</postalLine> <street>Office of Information Technology</street>
<postalLine>Minneapolis MN 55455</postalLine> <city>Minneapolis</city><region>MN</region><code>55455</code>
<postalLine>United States of America</postalLine> <country>United States of America</country>
</postal> </postal>
<email>farmer@umn.edu</email> <email>farmer@umn.edu</email>
</address> </address>
</author> </author>
<date year="2025" month="May" day="12"/> <date year="2025" month="October"/>
<area>Internet</area> <area>INT</area>
<workgroup>6man</workgroup> <workgroup>6man</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 80?>
<abstract>
<t>This document specifies the approval process for changes to the <t>This document specifies the approval process for changes to the
IPv6 Address Space registry. It also updates RFC 7249.</t> "IPv6 Address Space" registry. It also updates RFC 7249.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-6man-addr-assign/"/>.
</t>
<t>
Discussion of this document takes place on the
6MAN Working Group mailing list (<eref target="mailto:ipv6@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/ipv6/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ipv6/"/
>.
</t>
</note>
</front> </front>
<middle> <middle>
<?line 85?>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t>Internet Protocol Version 6 (IPv6) and its address space are <t>Internet Protocol Version 6 (IPv6) and its address space are
defined by <xref target="STD86"/> and <xref target="RFC4291"/>. defined by <xref target="STD86"/> and <xref target="RFC4291"/>.
The management of the IPv6 address space was delegated to IANA The management of the IPv6 address space was delegated to IANA
by <xref target="RFC1881"/>, some years before the relationship by <xref target="RFC1881"/>, some years before the relationship
between the IETF and IANA was formalized <xref target="RFC2860"/> between the IETF and IANA was formalized <xref target="RFC2860"/>
and registry details were clarified <xref target="RFC7020"/>, <xref target="RFC7 249"/>.</t> and registry details were clarified <xref target="RFC7020"/> <xref target="RFC72 49"/>.</t>
<t>Occasionally, IPv6 address space allocations are performed outside <t>Occasionally, IPv6 address space allocations are performed outside
the scope of routine allocations to Regional Internet Registries (RIRs). the scope of routine allocations to Regional Internet Registries (RIRs).
For example, a substantial allocation was requested by an For example, a substantial allocation was requested by an
IETF document approved by the IESG <xref target="RFC9602"/>, which moved the ran ge IETF document approved by the IESG <xref target="RFC9602"/>, which moved the ran ge
5f00::/16 from the Internet Protocol Version 6 Address Space registry 5f00::/16 from the "IPv6 Address Space" registry
<xref target="IANA1"/> <xref target="IANA1"/>
to the IANA IPv6 Special-Purpose Address Registry <xref target="IANA3"/>.</t> to the "IPv6 Special-Purpose Address Space" registry <xref target="IANA3"/>.</t>
<t>At the time of writing, the allocation policy in the Internet <t>At the time of writing, the allocation policy in the "IPv6 Address Spac
Protocol Version 6 Address Space e"
registry <xref target="IANA1"/> was shown as "IESG approval", whereas for registry <xref target="IANA1"/> was shown as "IESG approval", whereas
major allocations a more stringent policy is appropriate. a more stringent policy is appropriate for major allocations.
The present document therefore strengthens the approval level The present document therefore strengthens the approval level
needed for non-routine address allocations, which requires an needed for non-routine address allocations, which requires an
update to RFC 7249.</t> update to <xref target="RFC7249"/>.</t>
<t>This document also clarifies the status of RFC 1881. <t>This document also clarifies the status of <xref target="RFC1881"/>.
This clarification is necessary because RFC 1881, a joint This clarification is necessary because <xref target="RFC1881"/>, a joint
publication of the IAB and IESG following an IETF Last Call, publication of the IAB and IESG following an IETF Last Call,
was incorrectly listed in the RFC index at the time of writing was incorrectly listed in the RFC index at the time of writing
as "legacy", whereas it is part of the IETF stream <xref target="RFC8729"/>.</t> as "Legacy", whereas it is part of the IETF Stream <xref target="RFC8729"/>.</t>
</section> </section>
<section anchor="approval-level-of-ipv6-address-allocations"> <section anchor="approval-level-of-ipv6-address-allocations">
<name>Approval Level of IPv6 Address Allocations</name> <name>Approval Level of IPv6 Address Allocations</name>
<t>Portions of the IPv6 address space are shown in the registry <xref targ <t>Portions of the IPv6 address space are shown in the registry
et="IANA1"/> as "Reserved by IETF" <xref target="IANA1"/>. This is the address space held in
as "Reserved by IETF". This is the address space held in reserve reserve
for future use if ever the 125-bit unicast space (2000::/3) for future use if ever the 125-bit unicast space (2000::/3)
is found inadequate or inappropriate.</t> is found inadequate or inappropriate.</t>
<t>RFC 1881 did not specify an allocation policy for this space. At some <t><xref target="RFC1881"/> did not specify an allocation policy for this space. At some
point, IANA listed "IESG approval". As defined in <xref target="BCP26"/>, point, IANA listed "IESG approval". As defined in <xref target="BCP26"/>,
this is a rather weak requirement ("Although there is no this is a rather weak requirement ("Although there is no
requirement that the request be documented in an RFC, the IESG has requirement that the request be documented in an RFC, the IESG has
the discretion to request documents...") and is "a fall-back the discretion to request documents...") and is "a fall-back
mechanism in the case where one of the other allowable approval mechanism in the case where one of the other allowable approval
mechanisms cannot be employed...".</t> mechanisms cannot be employed...".</t>
<t>For something as important as the majority of the spare IPv6 address <t>For something as important as the majority of the spare IPv6 address
space, this process is clearly insufficient. The present document replaces space, this process is clearly insufficient. The present document replaces
the "IESG approval" process by the "IETF Review" process as defined by BCP 26. I the "IESG approval" process by the "IETF Review" process as defined by <xref tar
t is not get="BCP26"/>. The stricter "Standards Action"
considered necessary to require the stricter "Standards Action" policy is not considered necessary, because there may be cases where opening up
policy, because there might be cases where opening up a new range a new range of address space does not in fact require a new protocol standard.</
of address space did not in fact require a new protocol standard.</t> t>
<t>It may be noted that the allocation for <xref target="RFC9602"/>, which <t>It may be noted that the allocation for <xref target="RFC9602"/>, which
was processed as a working group document, did indeed follow the more was processed as a working group document, did indeed follow the more
stringent "IETF Review" process proposed by this document. Indeed, the stringent "IETF Review" process proposed by this document. Indeed, the
other two related registries <xref target="IANA2"/> <xref target="IANA3"/> do ci other two related registries <xref target="IANA2"/> <xref target="IANA3"/> cite
te the "IETF Review" the "IETF Review"
policy, consistently with RFC 7249.</t> policy, consistent with <xref target="RFC7249"/>.</t>
<t>This document therefore extends the first paragraph of section 2.3 <t>This document therefore extends the first paragraph of <xref target="RF
of <xref target="RFC7249"/> as follows:</t> C7249" sectionFormat="of" section="2.3"/> as follows:</t>
<t>OLD:</t> <t>OLD:</t>
<blockquote> <blockquote>
The vast bulk of the IPv6 address space (approximately 7/8ths of the The vast bulk of the IPv6 address space (approximately 7/8ths of the
whole address space) is reserved by the IETF [RFC4291], with the whole address space) is reserved by the IETF <xref target="RFC4291"/>, with t he
expectation that further assignment of globally unique unicast expectation that further assignment of globally unique unicast
address space will be made from this reserved space in accordance address space will be made from this reserved space in accordance
with future needs. with future needs.
</blockquote> </blockquote>
<t>NEW:</t> <t>NEW:</t>
<blockquote> <blockquote>
The vast bulk of the IPv6 address space (approximately 7/8ths of the The vast bulk of the IPv6 address space (approximately 7/8ths of the
whole address space) is reserved by the IETF [RFC4291], with the whole address space) is reserved by the IETF <xref target="RFC4291"/>, with t he
expectation that further assignment of globally unique unicast expectation that further assignment of globally unique unicast
address space will be made from this reserved space in accordance address space will be made from this reserved space in accordance
with future needs, through "IETF Review" as defined in [BCP26]. with future needs, through "IETF Review" as defined in <xref target="BCP26"/> .
</blockquote> </blockquote>
</section> </section>
<section anchor="rfc-editor-considerations">
<name>RFC Editor Considerations</name>
<t>The RFC Editor is requested to update the "Stream" information
for <xref target="RFC1881"/> to "IETF" in place of "Legacy".</t>
</section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to update the "Registration Procedure(s)" section <t>IANA has updated the registration procedure
of the Internet Protocol Version 6 Address Space registry <xref target="IANA1"/> of the "IPv6 Address Space" registry <xref target="IANA1"/>
to show the policy as "IETF Review".</t> to "IETF Review".</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The security considerations of <xref target="RFC7249"/> apply. While ha ving no direct security impact, carefully reviewed address allocation mechanisms are necessary to ensure operational address accountability.</t> <t>The security considerations of <xref target="RFC7249"/> apply. While ha ving no direct security impact, carefully reviewed address allocation mechanisms are necessary to ensure operational address accountability.</t>
</section> </section>
<section anchor="acknowledgements">
<name>Acknowledgements</name>
<t>Useful comments were received from
Dale Carder,
Bob Hinden,
Scott Kelly,
Philipp Tiesel,
and others.</t>
</section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<referencegroup anchor="STD86" target="https://www.rfc-editor.org/info/s
td86"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.
<reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rf 0086.xml"/>
c8200"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.
<front> 0026.xml"/>
<title>Internet Protocol, Version 6 (IPv6) Specification</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="S. Deering" initials="S." surname="Deering"/> 291.xml"/>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<date month="July" year="2017"/>
<abstract>
<t>This document specifies version 6 of the Internet Protocol (I
Pv6). It obsoletes RFC 2460.</t>
</abstract>
</front>
<seriesInfo name="STD" value="86"/>
<seriesInfo name="RFC" value="8200"/>
<seriesInfo name="DOI" value="10.17487/RFC8200"/>
</reference>
</referencegroup>
<referencegroup anchor="BCP26" target="https://www.rfc-editor.org/info/b
cp26">
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rf
c8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RF
Cs</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use c
onstants to identify various protocol parameters. To ensure that the values in t
hese fields do not have conflicting uses and to promote interoperability, their
allocations are often coordinated by a central record keeper. For IETF protocols
, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance d
escribing the conditions under which new values should be assigned, as well as w
hen and how modifications to existing values can be made, is needed. This docume
nt defines a framework for the documentation of these guidelines by specificatio
n authors, in order to assure that the provided guidance for the IANA Considerat
ions is clear and addresses the various issues that are likely in the operation
of a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC
5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
</referencegroup>
<reference anchor="RFC4291">
<front>
<title>IP Version 6 Addressing Architecture</title>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<date month="February" year="2006"/>
<abstract>
<t>This specification defines the addressing architecture of the I
P Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, te
xt representations of IPv6 addresses, definition of IPv6 unicast addresses, anyc
ast addresses, and multicast addresses, and an IPv6 node's required addresses.</
t>
<t>This document obsoletes RFC 3513, "IP Version 6 Addressing Arch
itecture". [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4291"/>
<seriesInfo name="DOI" value="10.17487/RFC4291"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC1881"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<front> 881.xml"/>
<title>IPv6 Address Allocation Management</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author> 860.xml"/>
<organization abbrev="IAB">Internet Architecture Board</organizati <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
on> 020.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author> 249.xml"/>
<organization abbrev="IESG">Internet Engineering Steering Group</o <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
rganization> 602.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="December" year="1995"/> 729.xml"/>
<abstract>
<t>The IPv6 address space will be managed by the IANA for the good
of the Internet community, with advice from the IAB and the IESG, by delegation
to the regional registries. This memo provides information for the Internet com
munity. This memo does not specify an Internet standard of any kind.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1881"/>
<seriesInfo name="DOI" value="10.17487/RFC1881"/>
</reference>
<reference anchor="RFC2860">
<front>
<title>Memorandum of Understanding Concerning the Technical Work of
the Internet Assigned Numbers Authority</title>
<author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<author fullname="M. Roberts" initials="M." surname="Roberts"/>
<date month="June" year="2000"/>
<abstract>
<t>This document places on record the text of the Memorandum of Un
derstanding concerning the technical work of the IANA that was signed on March 1
, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10,
2000. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2860"/>
<seriesInfo name="DOI" value="10.17487/RFC2860"/>
</reference>
<reference anchor="RFC7020">
<front>
<title>The Internet Numbers Registry System</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="J. Curran" initials="J." surname="Curran"/>
<author fullname="G. Huston" initials="G." surname="Huston"/>
<author fullname="D. Conrad" initials="D." surname="Conrad"/>
<date month="August" year="2013"/>
<abstract>
<t>This document provides information about the current Internet N
umbers Registry System used in the distribution of globally unique Internet Prot
ocol (IP) address space and autonomous system (AS) numbers.</t>
<t>This document also provides information about the processes for
further evolution of the Internet Numbers Registry System.</t>
<t>This document replaces RFC 2050.</t>
<t>This document does not propose any changes to the current Inter
net Numbers Registry System. Rather, it documents the Internet Numbers Registry
System as it works today.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7020"/>
<seriesInfo name="DOI" value="10.17487/RFC7020"/>
</reference>
<reference anchor="RFC7249">
<front>
<title>Internet Numbers Registries</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="May" year="2014"/>
<abstract>
<t>RFC 7020 provides information about the Internet Numbers Regist
ry System and how it is used in the distribution of autonomous system (AS) numbe
rs and globally unique unicast Internet Protocol (IP) address space.</t>
<t>This companion document identifies the IANA registries that are
part of the Internet Numbers Registry System at this time.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7249"/>
<seriesInfo name="DOI" value="10.17487/RFC7249"/>
</reference>
<reference anchor="RFC9602">
<front>
<title>Segment Routing over IPv6 (SRv6) Segment Identifiers in the I
Pv6 Addressing Architecture</title>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
<date month="October" year="2024"/>
<abstract>
<t>Segment Routing over IPv6 (SRv6) uses IPv6 as the underlying da
ta plane. Thus, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addres
ses and behave like them while exhibiting slightly different behaviors in some s
ituations. This document explores the characteristics of SRv6 SIDs and focuses o
n the relationship of SRv6 SIDs to the IPv6 Addressing Architecture. This docume
nt allocates and makes a dedicated prefix available for SRv6 SIDs.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9602"/>
<seriesInfo name="DOI" value="10.17487/RFC9602"/>
</reference>
<reference anchor="RFC8729">
<front>
<title>The RFC Series and RFC Editor</title>
<author fullname="R. Housley" initials="R." role="editor" surname="H
ousley"/>
<author fullname="L. Daigle" initials="L." role="editor" surname="Da
igle"/>
<date month="February" year="2020"/>
<abstract>
<t>This document describes the framework for an RFC Series and an
RFC Editor function that incorporate the principles of organized community invol
vement and accountability that has become necessary as the Internet technical co
mmunity has grown, thereby enabling the RFC Series to continue to fulfill its ma
ndate. This document obsoletes RFC 4844.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8729"/>
<seriesInfo name="DOI" value="10.17487/RFC8729"/>
</reference>
<reference anchor="IANA1" target="https://www.iana.org/assignments/ipv6- address-space"> <reference anchor="IANA1" target="https://www.iana.org/assignments/ipv6- address-space">
<front> <front>
<title>Internet Protocol Version 6 Address Space</title> <title>IPv6 Address Space</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="IANA2" target="https://www.iana.org/assignments/ipv6- unicast-address-assignments"> <reference anchor="IANA2" target="https://www.iana.org/assignments/ipv6- unicast-address-assignments">
<front> <front>
<title>IPv6 Global Unicast Address Assignments</title> <title>IPv6 Global Unicast Address Space</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="IANA3" target="https://www.iana.org/assignments/iana- ipv6-special-registry"> <reference anchor="IANA3" target="https://www.iana.org/assignments/iana- ipv6-special-registry">
<front> <front>
<title>IANA IPv6 Special-Purpose Address Registry</title> <title>IPv6 Special-Purpose Address Space</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
</references> </references>
</references> </references>
<?line 190?> <?line 190?>
<section anchor="acknowledgements" numbered="false">
<!-- # IPv6 Registry Title Inconsistencies <name>Acknowledgements</name>
<t>Useful comments were received from <contact fullname="Dale Carder"/>,
The authors would like to draw attention to inconsistencies in the titles for tw <contact fullname="Bob Hinden"/>, <contact fullname="Scott Kelly"/>,
o of the IPv6 Address Registries: the "Internet Protocol Version 6 Address Space <contact fullname="Philipp Tiesel"/>, and others.</t>
" registry {{IANA1}} and the "IPv6 Global Unicast Address Assignments" registry
{{IANA2}}. These two titles are inconsistent with the titles for the "IANA IPv6
Special-Purpose Address Registry" {{IANA3}} and the similar IPv4 registries, the
"IANA IPv4 Address Space Registry" and the "IANA IPv4 Special-Purpose Address R
egistry."
While these are mostly editorial issues, likely within IANA's control, confusion
caused by these different titles could have easily contributed to not updating
the Registry Procedures for the "Internet Protocol Version 6 Address Space" regi
stry at the time of RFC 7249.
The "IANA IPv6 Address Space Registry" and the "IANA IPv6 Global Unicast Address
Space Registry" are possibly more consistent titles for these registries. -->
<section anchor="change-log-rfc-editor-please-remove">
<name>Change Log [RFC Editor: please remove]</name>
<section anchor="draft-carpenter-6man-addr-assign-00">
<name>draft-carpenter-6man-addr-assign-00</name>
<ul spacing="normal">
<li>
<t>Original version</t>
</li>
</ul>
</section>
<section anchor="draft-01">
<name>Draft-01</name>
<ul spacing="normal">
<li>
<t>Added author</t>
</li>
<li>
<t>Added citations</t>
</li>
<li>
<t>Small update to RFC 7249</t>
</li>
<li>
<t>Added appendix on registry names</t>
</li>
</ul>
</section>
<section anchor="draft-02">
<name>Draft-02</name>
<ul spacing="normal">
<li>
<t>Clarified some details</t>
</li>
</ul>
</section>
<section anchor="draft-ietf-6man-addr-assign-00">
<name>draft-ietf-6man-addr-assign-00</name>
<ul spacing="normal">
<li>
<t>Adopted by WG</t>
</li>
</ul>
</section>
<section anchor="draft-01-1">
<name>Draft-01</name>
<ul spacing="normal">
<li>
<t>Changed stream for RFC 1881 to IETF</t>
</li>
<li>
<t>Editorial improvements</t>
</li>
</ul>
</section>
<section anchor="draft-02-1">
<name>Draft-02</name>
<ul spacing="normal">
<li>
<t>Further editorial improvements</t>
</li>
</ul>
</section>
<section anchor="draft-03">
<name>Draft-03</name>
<ul spacing="normal">
<li>
<t>At IESG's request, removed the appendix about registry names, whi
ch will be handled by IANA directly.</t>
</li>
<li>
<t>Clarified discussion of RFC9602</t>
</li>
<li>
<t>Improved security considerations</t>
</li>
<li>
<t>Minor editorial changes</t>
</li>
</ul>
</section>
<section anchor="draft-04">
<name>Draft-04</name>
<ul spacing="normal">
<li>
<t>Minor editorial changes</t>
</li>
</ul>
</section>
<section anchor="draft-05">
<name>Draft-05</name>
<ul spacing="normal">
<li>
<t>Corrected title to "Allocation" instead of "Assignment"</t>
</li>
<li>
<t>Minor editorial changes</t>
</li>
</ul>
</section>
</section> </section>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+1Z224bORJ9F6B/4CoPkwCSbCu2kwiDxTjOZYzJxYg8G2Bn
Bguqm5I47m72NNlWtIb/fU8VSXW3pVwmz+sXS91Fsi6nTlVRo9Go33PaZWoq
zjNZ6YVOpNOmEGYhLi5vTsVZmlbKWnGWZSa8ujSZTjb9npzPK3Uz/apcapJC
5jghreTCjbRyi9FpLouRxJqRtFYvi9HhSb/X71kni/Q/MjMFxF1VK3qoy4q/
WDc5PHx2OMHJlZI4t3CqKpTr99bLqaAd+73rdfN89ILO6/egzlTMkxLb1/Nc
4zxTXG1KnHDx8upVv1eXqXTKTsWTyfEzOrDU035PCGeSqdgoS5+tqVylFhAS
4oFI1ULWmbMQ2Qpscv+ev0PF2q1MxfvQ3yh+EEIXkHo+Fi/H4lxWpSJtm7fe
U88rLYvPSJgK1l6tlPi10DeqstptKFpndXKdwXuNYIwPyY33i5QGHs+mzYOR
mCUrYzISPzd5WeNoPNKqSFRb6vK5eDY5PHrWfha3F0dHx5PmRWLqwlWbqXin
1uLfSnY1ULnUGcJDBo/VOIn2/rSkF+PE5OTN/U6cjcUvlbargiLfdeCsBhpX
e16z9861TYyYbaxTuR0CMMl4120stKOo5Y3H12Hjb1HzxVi8klW+G+UX8kan
FGX/WlxcXNxTtBvit7oolDVOfiHGe2T2BPn9AomuOMmLhalyn7BXKlkVJjPL
TVuWd5QlktmKt+/Eycnxycme6EIDp1Ixc5RLjDaYBDbZ8eCCjf2pzhHvtCa3
FV6DG8U6zq5ePD3lT8/PLyf+04dX58eTZ0dTpoOocZDHu6OnT4/i58nT08P4
+cnhpPmM5I6fn50eTuLnp08m/vnF2buzo+AlJ6ulAmusnCvt9OBgvV6PAVA5
RlQOPGPlgKk90OXNKfMYuG9kSxmzJHBqpCJxWRnQCfLqXxRO+LphzFlcRQpM
vkuBuoCjrdsq0hLoqkNM/Tozc5lRvGhNQ9zdNaTM47+tDB6OWCNbqkTLbFSp
pbbAR1cN7O11mQWxy7oCStVWmQ/bZf3ejSpqH+llZepyKganb8/eDZihmcUH
H011rYuleE3v+YVH2oBU+YnqDWnKL2SVrPAiWkJy9AhYGke5A3pwMK/M2ip2
78GA1BiNRsg2KCUTR9+vVsgHlLaaTBds70ID+Q7MLMuyMjdwMv4lZA8QK5KV
LJaKawZk+r1O2WQQiOitsbhwQmbWiFCbCKhcnsZRlVynacbl8QGhrDJpnXAS
h7/bB5qe3pHEl1D4kNR4JIi2NQpaQJBgKMNbOAHFThfI7PlG3N5yct7dsfzt
bUjLu7sx+UPB7YVcKnYICIA8wUZ2N11L+E1laimJL+ANgkO/x9uHXL67G6Li
5grFVFZWzBX8p3i/SmXMVXalUc/nyq2VKvxJqOWsFqOLDmGayPR/VVCVmOEO
DiGh6Glo4oABK9YKJyS+BYoLiD5IFf8F3mdD+733CTIHSsgs2wz3mSi3TZAl
H4pSVaQM9jW1szqFV0ll1JeSSRi4dfBxZx0cQ1lApzQ0EvKCcPbww8UH+wj6
vAK21CeZl5kaCokCNacuyiGtWvuxQyr1V62s87Gkosg+22LYo9a/9R6dvfa2
E1+SI9YrnaxEzkIcDUJ0v3eyODycTg+OTsWiMrlf+63EJxqGuL1lCqYQ+Rz5
G0Qh/OLHIUJnjtc7nbN/15WGf5dDn5yNU0ruUFGlOzr3e19n66p7LpRmD9uV
WRcCHwbsvMgDA3IdAOZB2e/l8k8ErYMSeBVAodjCpQhGVM36TUr0R06FNCuh
CclsI+do80XYQBVLfC/uMVGmblSGUqtUiuARHxWmGG2BF6xrqRSjTaDReMmA
8XTE2GwTUpcLmbhiKnk1gEhXc1dA6yjFx2FV0pk68KBQxJgSrp2rRNaIdVxC
6P7TgNbQodfzrDWpeKw89+lPjl8YGLKmmoA2mlH+hmrdOewbYlxAHHSRmKpS
ics2Ap0NJUWAAR2ni1R9EnIvikAgiC/xV7JpBVY70r6UVcN9dC4FROY+jajV
CAB9IM5iZN5QZL4wb/E4cYn5g4HyeV4lovH4C4bsYtSr/gHoqUKek46DseBQ
6ACZzq4rlbFnKr+o3yPoLGqHNlhQcPRCQP+KVx5NTkZz+CG0I2GHh5jaiB4e
P0LvRglQU60pZApgEZiwH751QN7vxZiLFB1yYWKBJdrak8CkkyMT+MSxQPpT
+QBOCC5DzyMhyvcyE8JUjnyJg523t9x1gu2Io71XJIiOUgxFQl7HhGCoPxyc
ZZjz6uXK5yAD2BA9NDJuFXAU6Be43uaKPxM2wd5hQ7oraX2FSDGDVIpNRc7F
DeJqOx6PB6F2I64SrXWWjeYyuQbFKOo3tM0jGhAR5cEqMF1HHBm2izy6lvOs
4YvWBshRWVAIoLdClTEbldLBHCcqPuRquIqSDe7KS0BVEg14ODHXhQGGqaAk
oLbxi7mcwjb0IYwtE3MDyn9G/GxrGlgwhbqx2MuAlSoz7BHcdi/G2z1DYRtw
Zn5QN1qtm5eywQHkgAIxOeVGjGPqRL+XIAFRvCtINCwV4qJDg0IMntDQPJjR
XYasUuQyd2YDgiPBdbhlNo+ZXC9X7F0KkY0xwhhMLq1LwK/A5BxqLbzYTdCY
IAjzAq3pVhm/qoyVzAZtOGowKpdEsLSSa3mAaCu1KKd2i78nz+AyrJSUHevQ
f3N/vo3JkFUjJuWCQxDzgDDUVTaVbn80iA6Mjc1Iq7wgJLzl0HfRHsBubXxr
qLatHZUeT3zQvmkPsI9ItFO7QGjCw3EGWRRUHNbarb5U7Zraqz5hSepRv9AV
EhVQl8tKlisCv1W+QZ+MH3MYW12l4MaAPGR5xH3/5gX+/zhHMK7/qhGif/L8
RMi/IWKd19n1FyrBQ0b+J40hWcGCJwdP3SpWDt5ovTLZPaJ/RDCvWpVhW8F+
C13+H0Pvi7iJ+gRKdh4sDKBFXXk22U6EdOaSx02ogaoA+orFgbe4NxjoLCNM
5igNsZNsK+WliC8T1O5Uxisp1iqUJOpvLKL040HHee9efvy/Q7/foZRrFVe5
brLKTun8jSvnH7vep3aHMuhlqh1Y5TzQaNPdXIW2Kwjo9qji4hDsM3bG/dRA
6ObeyvckreGR1rCiJCa4MJDjBm98zxYaMG4KdnXhx1/SIIwc4Y6b6CqFox7a
R4OY4pze3zcFie4QRP0c7xQaHT9ZNBEIpsxUUnON3e9aG18nndfiPgmVZbYZ
i48rDSyv5A1RemHA4tQmN5ugwqPOgCVRxxc1AbFiZaga7IwRotVGSIZTq25i
SKl9qfMa0cQad0j4YlHOdYYzxyL0zMl1YdaZSv0lAxv4qyUtYFrOj/wgD42V
JogT6vu9FxIWnaP6qQpt3XMzFz9TXSrwZZYY58QvikZ5tNmwXZeluEL1UDQq
UG/FJcZub158fwWQ/wNfHni62I6hV3TDRRfKsYSgadnGwf8mABVNjaY609c8
SaWVXGPUoHIT+jzdXR47OL4983dJVO/adHVvHNb0a4YvcN+KwMEeCHJn6bf5
tovDnU1Qerlho14HKgcLCAgtG92WBjsm8rnffAEwaJX4qLbVOV3v0QbHrbZg
2N37+F4qNjs25m9Fv6bGmO8KfQo5tpuMzY2lVkIxvdHFjLa2JkUIA6HHQJDp
mB8sZamrTMZ9yKLmYHG7GKuIpaZvsQDOqf3wHksYUkhatCHS6mzjd9HzOjAY
tYjMYpTVPObGSG0prO3374DNvWl52zKJCP9WNL/Z459F3c5KumYzgOIctvNd
SgtfXVhZ1QLDWIxGoUSd8wWteGOW4vffmnI0RQVRkhfRzdfvf7D0g/Br5vYH
qz0/aR4yZYj3lV5qIrcb78Ownn+dHB0eeSHYRQTKDNF8R6caqXwkZjl4Vexe
wbSWl9Al1Z8w4TVxod+abPfMiT/zfHvdyZet4Sq0Y95nfqw9jEqbMlwnfny9
1yzv0zReg1AEtqM9Xf3yD7Cj4GnOjJwvIbf0vqP0q9AUqW9Y8jio6Xis/mFb
1Ichlmm8I/Nek3NTu3uOi9dgsZeCPWkW7k4Io746om7edymN7jX/1hyygeYo
L3SRh4vWzxRmL/VWF6ZtZvj9oGvh8d+QPQkq+nsvMp6LFTVLzW0TtUxIGply
x9Rw++CrB/V7/wNX7Uo7TiAAAA==
</back>
</rfc> </rfc>
 End of changes. 40 change blocks. 
472 lines changed or deleted 85 lines changed or added

This html diff was produced by rfcdiff 1.48.