Diff: rfc9812.original.xml

	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 " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<?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"/>	<!--[rfced] This document has been assigned a new BCP number. However, it is un
	<author initials="B. E." surname="Carpenter" fullname="Brian E. Carpenter">	clear whether this document should be grouped with an existing BCP. Please revi
		ew the list of BCPs closely and let us know if the newly assigned BCP number is
		correct or if it should be added to an existing BCP.

		See the complete list of BCPs here:
		https://www.rfc-editor.org/bcps
		-->

		<seriesInfo name="BCP" value="242"/>
		<seriesInfo name="RFC" value="9812"/>

		<!-- [rfced] Brian, we have updated the document header as shown below to match
		what appears in the header of the RFCs you've authored. Please let us know if y
		ou prefer otherwise.

		Original: B. E. Carpenter
		Current: B. Carpenter
		-->
		<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="June"/>
	<area>Internet</area>	<area>INT</area>
	<workgroup>6man</workgroup>	<workgroup>6man</workgroup>

	<keyword>Internet-Draft</keyword>
	<abstract>
	<?line 80?>


		<!-- [rfced] Please insert any keywords (beyond those that appear in
		the title) for use on https://www.rfc-editor.org/search. -->

		<keyword>example</keyword>

		<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>	"Internet Protocol Version 6 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 "Internet Protocol Version 6 Address Space" registry
	<xref target="IANA1"/>	<xref target="IANA1"/>

	to the IANA IPv6 Special-Purpose Address Registry <xref target="IANA3"/>.</t>	to the "IANA IPv6 Special-Purpose Address 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 "Internet
	Protocol Version 6 Address Space	Protocol Version 6 Address Space"
	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>

		<!-- [rfced] Regarding the RFC Editor Considerations section, we would like to a
		void setting precedent that stream changes need to be documented in RFCs. We in
		tend to update the stream metadata for RFC 1881 as requested (from "Legacy" to "
		IETF") and remove 'RFC Editor Considerations' (Section 3) from this document, as
		it's not necessary to capture the metadata correction within the RFC. Please l
		et us know if you have any strong objections.

		3. RFC Editor Considerations

		The RFC Editor is requested to update the "Stream" information for
		[RFC1881] to "IETF" in place of "Legacy".
		-->

	<section anchor="rfc-editor-considerations">	<section anchor="rfc-editor-considerations">
	<name>RFC Editor Considerations</name>	<name>RFC Editor Considerations</name>

	<t>The RFC Editor is requested to update the "Stream" information	<t>Per this document, the RFC Editor has updated the Stream information
	for <xref target="RFC1881"/> to "IETF" in place of "Legacy".</t>	for <xref target="RFC1881"/> to IETF in place of Legacy.</t>
	</section>	</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 "Internet Protocol Version 6 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>Internet Protocol Version 6 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 Assignments</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>IANA IPv6 Special-Purpose Address Registry</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?>

	<!-- # IPv6 Registry Title Inconsistencies	<!-- # IPv6 Registry Title Inconsistencies

	The authors would like to draw attention to inconsistencies in the titles for tw o of the IPv6 Address Registries: the "Internet Protocol Version 6 Address Space " 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."	The authors would like to draw attention to inconsistencies in the titles for tw o of the IPv6 Address Registries: the "Internet Protocol Version 6 Address Space " 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.	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. -->	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">	<!-- Registry titles as of 6/10:
	<name>Change Log [RFC Editor: please remove]</name>	[IANA1] Internet Protocol Version 6 Address Space
	<section anchor="draft-carpenter-6man-addr-assign-00">	https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
	<name>draft-carpenter-6man-addr-assign-00</name>
	<ul spacing="normal">	IPv4: IANA IPv4 Address Space Registry
	<li>	https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml
	<t>Original version</t>
	</li>	[IANA2] IPv6 Global Unicast Address Assignments https://www.iana.org/assignments
	</ul>	/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
	</section>
	<section anchor="draft-01">	[IANA3] IANA IPv6 Special-Purpose Address Registry
	<name>Draft-01</name>	https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-re
	<ul spacing="normal">	gistry.xhtml
	<li>
	<t>Added author</t>	IPv4: IANA IPv4 Special-Purpose Address Registry
	</li>	https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-re
	<li>	gistry.xhtml
	<t>Added citations</t>	-->
	</li>
	<li>	<section anchor="acknowledgements">
	<t>Small update to RFC 7249</t>	<name>Acknowledgements</name>
	</li>	<t>Useful comments were received from <contact fullname="Dale Carder"/>,
	<li>	<contact fullname="Bob Hinden"/>, <contact fullname="Scott Kelly"/>,
	<t>Added appendix on registry names</t>	<contact fullname="Philipp Tiesel"/>, and others.</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==


		<!-- [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. Updates of this nature typically
		result in more precise language, which is helpful for readers.

		Note that our script did not flag any words in particular, but this should
		still be reviewed as a best practice.
	-->	-->


		</back>
	</rfc>	</rfc>

End of changes. 39 change blocks.
	446 lines changed or deleted	144 lines changed or added
This html diff was produced by rfcdiff 1.48.