rfc9827.original.xml		rfc9827.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version='1.0' encoding='UTF-8'?>
	<?rfc toc="yes"?>
	<?rfc tocompact="no"?>
	<?rfc tocdepth="3"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<rfc category="std" submissionType="IETF" docName="draft-ietf-ipsecme-ikev2-rena
	me-esn-05" ipr="trust200902" updates="7296" >
	<front>
	<title abbrev="Renaming ESN in IKEv2">Renaming Extended Sequence Number (ESN
	) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
			<!DOCTYPE rfc [
			<!ENTITY nbsp "&#160;">
			<!ENTITY zwsp "&#8203;">
			<!ENTITY nbhy "&#8209;">
			<!ENTITY wj "&#8288;">
			]>
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" submissionType="I
			ETF" docName="draft-ietf-ipsecme-ikev2-rename-esn-05" number="9827" consensus="t
			rue" ipr="trust200902" updates="7296" obsoletes="" tocInclude="true" tocDepth="3
			" symRefs="true" sortRefs="true" version="3" xml:lang="en">
			<front>
			<title abbrev="Renaming ESN in IKEv2">Renaming the Extended Sequence Numbers
			(ESN) Transform Type in the Internet Key Exchange Protocol Version 2
			(IKEv2)</title>
			<seriesInfo name="RFC" value="9827"/>
	<author fullname="Valery Smyslov" initials="V." surname="Smyslov">		<author fullname="Valery Smyslov" initials="V." surname="Smyslov">
	<organization>ELVIS-PLUS</organization>		<organization>ELVIS-PLUS</organization>
	<address>		<address>
	<postal>		<postal>
	<street></street>
	<city></city>
	<code></code>
	<region></region>
	<country>Russian Federation</country>		<country>Russian Federation</country>
	</postal>		</postal>
	<phone></phone>
	<email>svan@elvis.ru</email>		<email>svan@elvis.ru</email>
	</address>		</address>
	</author>		</author>
			<date month="August" year="2025"/>
	<date />		<area>SEC</area>
			<workgroup>ipsecme</workgroup>
	<area>Security Area</area>		<keyword>replay protection</keyword>
			<keyword>anti-replay</keyword>
			<keyword>IPsec</keyword>
			<keyword>ESP</keyword>
			<keyword>AH</keyword>
	<abstract>		<abstract>
	<t> This document clarifies and extends the meaning of transform type 5 in		<t> This document clarifies and extends the meaning of Transform Type 5 in
	IKEv2.		Internet Key Exchange Protocol Version 2 (IKEv2).
	It updates RFC 7296 by renaming the transform type 5 from "Extended Sequen		It updates RFC 7296 by renaming Transform Type 5 from "Extended Sequence N
	ce Numbers (ESN)"		umbers (ESN)"
	to "Sequence Numbers (SN)". It also renames two currently defined values f		to "Sequence Numbers (SN)". It also renames two currently defined values f
	or this transform type:		or this Transform Type:
	value 0 from "No Extended Sequence Numbers" to "32-bit Sequential Numbers" and value 1 from		value 0 from "No Extended Sequence Numbers" to "32-bit Sequential Numbers" and value 1 from
	"Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Nu mbers".		"Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Nu mbers".
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section title="Introduction">		<section>
	<t> IP Security (IPsec) Architecture <xref target="RFC4301" /> defines a s		<name>Introduction</name>
	et of security services provided by IPsec protocols		<t>The IP Security (IPsec) Architecture <xref target="RFC4301"/> defines a
	Authentication Header (AH) <xref target="RFC4302" /> and Encapsulating Sec		set of security services provided by the
	urity Payload (ESP) <xref target="RFC4303" />.		Authentication Header (AH) <xref target="RFC4302"/> and Encapsulating Secu
	One of these services is replay protection, which is referred to as "anti-		rity Payload (ESP) <xref target="RFC4303"/>.
	replay" in these documents. In IPsec the anti-replay service is optional,		One of these services is replay protection, which is referred to as "anti-
			replay" in these documents. In IPsec, the anti-replay service is optional;
	each receiver of AH and/or ESP packets can choose whether to enable it on a per Security Association (SA) basis.		each receiver of AH and/or ESP packets can choose whether to enable it on a per Security Association (SA) basis.
	The replay protection in AH and ESP is achieved by means of a monotonicall		The replay protection in AH and ESP is achieved by means of a monotonicall
	y increasing counter that never wraps around,		y increasing counter that never wraps around and
	which is sent in each AH or ESP packet in the Sequence Number field. The r		is sent in each AH or ESP packet in the Sequence Number field. The receive
	eceiver maintains a sliding window that allows		r maintains a sliding window that allows
	to detect duplicate packets.		duplicate packets to be detected.
	</t>		</t>
			<t> Both AH and ESP allow use of either a 32-bit counter or a 64-bit count
	<t> Both AH and ESP allow using either a 32-bit counter or a 64-bit counte		er.
	r.
	The latter case is referred to as Extended Sequence Numbers (ESN) in AH an d ESP specifications.		The latter case is referred to as Extended Sequence Numbers (ESN) in AH an d ESP specifications.
	Since the Sequence Number field in both AH and ESP headers is only 32 bits in size,		Since the Sequence Number field in both AH and ESP headers is only 32 bits in size,
	in case of ESN the high-order 32 bits of the counter are not transmitted a nd are determined by the receiver		in case of ESN the high-order 32 bits of the counter are not transmitted a nd are determined by the receiver
	based on previously received packets.		based on previously received packets.
	</t>		</t>
			<t>The receiver decides whether to enable the anti-replay service based on
	<t> Since the decision whether to enable the anti-replay service is taken		ly on the receiver's local policy, so
	by the receiver based only on the receiver's local policy,		the sender, in accordance with the specifications for AH (<xref target="RF
	the sender in accordance with the specifications for AH (<xref target="RFC		C4302" sectionFormat="comma" section="3.3.2"/>) and ESP (<xref target="RFC4303"
	4302" /> Section 3.3.2) and ESP (<xref target="RFC4303" /> Section 3.3.3)		sectionFormat="comma" section="3.3.3"/>),
	should always assume that the replay protection is enabled on receiving si		should always assume that the replay protection is enabled on the receivin
	de. Thus, the sender should always send the increasing counter values		g side. Thus, the sender should always send the increasing counter values
	and should take care that the counter never wraps around. AH and ESP speci		and should take care that the counter never wraps around. AH and ESP speci
	fications also discuss situations when		fications also discuss situations in which
	replay protection is not possible to achieve even if senders do all as pre		replay protection is not possible to achieve, even if senders do all as pr
	scribed -- like in multicast		escribed -- like in multicast
	Security Associations with multiple unsynchronized senders. Both AH and ES P specifications allow the sender to		Security Associations with multiple unsynchronized senders. Both AH and ES P specifications allow the sender to
	avoid maintaining the counter if the sender has been notified somehow that the anti-replay service		avoid maintaining the counter if the sender has been notified that the ant i-replay service
	is disabled by the receiver or is not possible to achieve.		is disabled by the receiver or is not possible to achieve.
	</t>		</t>
			<t> AH and ESP Security Associations are usually established using IKEv2
	<t> AH and ESP Security Associations are usually established using the Int		<xref target="RFC7296"/>.
	ernet Key Exchange protocol version 2 (IKEv2) <xref target="RFC7296" />.
	The process of SA establishment includes calculation of a shared key and n egotiation of various SA parameters,		The process of SA establishment includes calculation of a shared key and n egotiation of various SA parameters,
	such as cryptographic algorithms. This negotiation in IKEv2 is performed v		such as cryptographic algorithms. This negotiation in IKEv2 is performed v
	ia transforms (see Section 3.3.2 of <xref target="RFC7296" />).		ia transforms (see <xref target="RFC7296" sectionFormat="of" section="3.3.2"/>).
	The type of transform determines what parameter is being negotiated. Each		The type of transform determines what parameter is being negotiated. Each
	transform type has an associated list of possible values		Transform Type has an associated list of possible values
	(called Transform IDs), that determine the possible options for negotiatio		(called Transform IDs) that determine the possible options for negotiation
	n. See <xref target="IKEV2-IANA" /> for the list of transform types		. See <xref target="IKEV2-IANA"/> for the list of Transform Types
	and associated transform IDs.		and associated Transform IDs.
	</t>		</t>
			<t> Transform Type 5 ("Extended Sequence Numbers (ESN)") is used in IKEv2
	<t> Transform type 5 "Extended Sequence Numbers (ESN)" is used in IKEv2 to		to negotiate the way sequence numbers
	negotiate the way sequence numbers		for replay protection are generated, transmitted, and processed in the con
	for replay protection are generated, transmitted and processed in the cont		text of an SA. There are
	ext of an SA. For this transform type		two values are defined for this Transform Type -- "No Extended Sequence Nu
	two values are defined -- "No Extended Sequence Numbers" and "Extended Seq		mbers" and "Extended Sequence Numbers".
	uence Numbers".
	</t>		</t>
			<t> This document updates the IKEv2 specification <xref target="RFC7296"/>
	<t> This document updates IKEv2 specification <xref target="RFC7296" /> by		by renaming Transform Type 5 and the
	renaming transform type 5 and		two associated Transform IDs.
	two associated transform IDs.
	</t>		</t>
	</section>		</section>
			<section anchor="problem">
	<section anchor="problem" title="Problem Description">		<name>Problem Description</name>
	<t> IKEv2 currently has no means to negotiate the case when both peers a		<t> IKEv2 currently has no means to negotiate the case when both peers agr
	gree that replay protection is not needed.		ee that replay protection is not needed.
	Even when both peers locally disable anti-replay service as receivers, t hey still need to maintain increasing sequence numbers		Even when both peers locally disable anti-replay service as receivers, t hey still need to maintain increasing sequence numbers
	as senders, taking care that they never wrap around (see <xref target="I		as senders, taking care that they never wrap around (see <xref target="I
	-D.pan-ipsecme-anti-replay-notification" />).		-D.pan-ipsecme-anti-replay-notification"/>).
	</t>		</t>
			<t> There is also no way to inform receivers that replay protection is not
	<t> There is also no way to inform receivers that replay protection is n		possible for a particular SA
	ot possible for a particular SA
	(for example in case of a multicast SA with several unsynchronized sende rs).		(for example in case of a multicast SA with several unsynchronized sende rs).
	</t>		</t>
			<t>Future IPsec protocols may provide more options for the handling of ant
	<t> Future IPsec security protocols may provide more options for the han		i-replay counters,
	dling of anti-replay counters,		like sending full 64-bit sequence numbers or completely omitting them in
	like sending full 64-bit sequence numbers or completely omitting them in		packets (see <xref target="I-D.ietf-ipsecme-eesp"/>).
	packets (see <xref target="I-D.klassert-ipsecme-eesp" />).
	These options will require means to be negotiated in IKEv2.		These options will require means to be negotiated in IKEv2.
	</t>		</t>
			<t> Transform Type 5 is the best candidate for addressing these issues:
	<t> Transform type 5 is the best candidate for addressing these issues:		it is already used for negotiation of how sequence numbers are handled i
	it is already used for negotiation of how sequence numbers are handled i		n AH and ESP, and
	n AH and ESP and		it is possible to define additional Transform IDs that could be used in
	it is possible to define additional transform IDs that could be used in		the corresponding situations.
	the corresponding situations.		However, the current definition of Transform Type 5 is too narrow -- its
	However, the current definition of transform type 5 is too narrow -- its		name implies that
	name implies that
	this transform can only be used for negotiation of using ESN.		this transform can only be used for negotiation of using ESN.
	</t>		</t>
	</section>		</section>
			<section anchor="clarification">
			<name>Extending the Semantics of Transform Type 5</name>
			<t> This document extends the semantics of Transform Type 5 in IKEv2 to be
			defined as follows:
			</t>
			<t indent="3"> Transform Type 5 defines the set of properties of sequence n
			umbers of IPsec packets of a given SA when these packets enter the network.
			</t>
			<t> This updated definition is clarified as follows:
			</t>
			<ul>
			<li>
			<t>"Sequence numbers" in this definition are not necessarily the
			content of the Sequence Number field in the IPsec packets; they
			may also be some logical entities (e.g., counters) that could
			be constructed taking some information that is not transmitted on the wire in
			to account.
			</t>
			</li>
			<li>
	<section anchor="clarification" title="Extending the Semantics of Transform		<t> The properties are interpreted as characteristics of IPsec SA
	Type 5">		packets rather than the results of sender actions. For example, in
	<t> This document extends the semantics of transform type 5 in IKEv2 to		multicast SA with multiple unsynchronized senders, even if each
	the following definition.		sender ensures the uniqueness of sequence numbers it generates, the
	</t>		uniqueness of sequence numbers for all IPsec packets is not
			guaranteed.
	<t> Transform type 5 defines the set of properties of sequence numbers o		</t>
	f IPsec packets of a given SA when these packets enter the network.		</li>
	</t>		<li>
			<t> The properties are defined for the packets just entering the
	<t> This definition requires some clarifications.		network and not for the packets that receivers get. This is because
	</t>		network behavior may break some of these properties (e.g., packet dupl
			ication would break sequence number uniqueness).
	<ul>		</t>
	<li>		</li>
	<t> By "sequence numbers" here we assume logical entities (like		<li>
	counters) that can be used for replay protection		<t> The properties of sequence numbers are interpreted in a broad
	on receiving sides. In particular, these entities are not necess		sense, which includes the case when sequence numbers are absent.
	arily the content of the Sequence Number field in the IPsec packets,		</t>
	but may be constructed using some information, that is not neces		</li>
	saryly transmitted.		</ul>
	</t>
	</li>
	<li>
	<t> The properties are interpreted as a characteristic of IPsec
	SA packets, and not as a result of a sender actions.
	For example, in multicast SA with multiple unsynchronized sender
	s, even if each sender ensures the uniqueness of sequence numbers it generates,
	the uniqueness of sequence numbers for all IPsec packets is not
	guaranteed.
	</t>
	</li>
	<li>
	<t> The properties are defined for the packets just entering the
	network and not for the packets that receivers get.
	This is because network behavior may break some of these propert
	ies (e.g., break sequence numbers uniqueness by packet duplication).
	</t>
	</li>
	<li>
	<t> The properties of sequence numbers are interpreted in a broa
	d sense, that includes the case when sequence numbers are absent.
	</t>
	</li>
	</ul>
	<t> Given this definition, transform type 5 in the IANA registries for I
	KEv2 <xref target="IKEV2-IANA" /> is renamed from
	"Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)" with the me
	aning, that it defines the properties the sequence numbers would have.
	</t>
	<t> It is expected that new transform IDs will be defined for this trans
	form type in future
	(like in G-IKEv2 <xref target="I-D.ietf-ipsecme-g-ikev2" /> for the case
	of multicast SAs).
	Documents defining new transform IDs should include description of the p
	roperties the sequence numbers
	would have if the new transform ID is selected. In particular, this desc
	ription should include discussion whether these properties
	allow achieving replay protection.
	</t>
	<t> Some existing protocols (like Implicit IV in ESP <xref target="RFC87
	50" /> or
	Aggregation and Fragmentation for ESP <xref target="RFC9347" />) rely on
	properties that are guaranteed
	for the currently defined transform IDs, but this might not be true for
	future transform IDs.
	When a new transform ID is defined, its description should include a di
	scussion about the possibility
	of using this transform ID in protocols, that rely on some particular pr
	operties of sequence numbers.
	</t>
	<t> The two currently defined transform IDs for this transform type defi
	ne the following properties of sequence numbers.
	</t>
	<ul>		<t> Given this updated definition, Transform Type 5 in the "Transform Type
	<li>		Values" registry <xref target="IKEV2-IANA"/> has been renamed from "Extended Se
	<t> Value 0 for transform type 5 defines sequence numbers as mon		quence
	otonically increasing 32-bit counters that are transmitted in the Sequence Numbe		Numbers (ESN)" to "Sequence Numbers (SN)" in the sense
	r		that it defines the properties of the sequence numbers in general.</t>
	field of AH and ESP packets. They never wrap around and are guar		<t> It is expected that new Transform IDs will be defined for this Transfo
	anteed to be unique, thus they are suitable for replay protection.		rm Type in the future
	They can also be used with protocols that rely on sequence numbe		(like in G-IKEv2 <xref target="I-D.ietf-ipsecme-g-ikev2"/> for the case
	rs uniqueness (like <xref target="RFC8750" />) or their		of multicast SAs).
	monotonic increase (like <xref target="RFC9347" />). The sender		Documents defining new Transform IDs should include descriptions of the
	and the receiver actions are defined		properties the sequence numbers
	in Sections 3.3.2 and 3.4.3 of <xref target="RFC4302" /> for AH		would have if the new Transform ID was selected. In particular, the desc
	and in Sections 3.3.3 and 3.4.3 of <xref target="RFC4303" /> for ESP.		riptions should include discussion of whether these properties
	</t>		allow replay protection to be achieved.
	</li>		</t>
	<li>		<t> Some existing protocols (like Implicit IV in ESP <xref target="RFC8750
	<t> Value 1 for transform type 5 defines sequence numbers as mon		"/> or
	otonically increasing 64-bit counters. The low-order 32 bits are transmitted		Aggregation and Fragmentation for ESP <xref target="RFC9347"/>) rely on
	in the Sequence Number field of AH and ESP packets and the high-		properties that are guaranteed
	order 32 bits are implicitly determined on receivers		for the currently defined Transform IDs; however, this might not be true
	based on previously received packets. The sequence numbers never		for future Transform IDs.
	wrap around and are guaranteed to be unique,		When a new Transform ID is defined, its description should include disc
	thus they are suitable for replay protection. They can also be u		ussion about the possibility
	sed with protocols that rely on sequence numbers uniqueness		of using the Transform ID in protocols that rely on some particular prop
	(like <xref target="RFC8750" />) or their monotonic increase (li		erties of sequence numbers.
	ke <xref target="RFC9347" />). To be able to correctly		</t>
	process the incoming packets on receivers the packets must be au		<t>The two currently defined Transform IDs for Transform Type 5 define the
	thenticated (even when the replay protection is not used).		following properties of sequence numbers.
	The sender and the receiver actions are defined in Sections 3.3.		</t>
	2 and 3.4.3 of <xref target="RFC4302" /> for AH
	and in Sections 3.3.3 and 3.4.3 of <xref target="RFC4303" /> for
	ESP.
	</t>
	</li>
	</ul>
	<t> Given the descriptions above and the new definition of transform typ		<ul>
	e 5, the two currently defined transform IDs		<li>
			<t> Value 0 defines sequence numbers as
			monotonically increasing 32-bit counters that are transmitted in the
			Sequence Number field of AH and ESP packets. They never wrap around
			and are guaranteed to be unique, thus they are suitable for replay
			protection. They can also be used with protocols that rely on
			sequence number uniqueness (e.g., <xref target="RFC8750"/>) or monoton
			ically
			increasing sequence numbers (e.g., <xref target="RFC9347"/>). The send
			er and
			the receiver actions are defined in Sections <xref target="RFC4302"
			sectionFormat="bare" section="3.3.2"/> and <xref target="RFC4302"
			sectionFormat="bare" section="3.4.3"/> of <xref target="RFC4302"/>
			for AH and in Sections <xref target="RFC4303" sectionFormat="bare"
			section="3.3.3"/> and <xref target="RFC4303" sectionFormat="bare"
			section="3.4.3"/> of <xref target="RFC4303"/> for ESP.
			</t>
			</li>
			<li>
			<t> Value 1 defines sequence numbers as
			monotonically increasing 64-bit counters. The low-order 32 bits are
			transmitted in the Sequence Number field of AH and ESP packets, and
			the high-order 32 bits are implicitly determined on receivers based
			on previously received packets. The sequence numbers never wrap
			around and are guaranteed to be unique, thus they are suitable for
			replay protection. They can also be used with protocols that rely on
			sequence number uniqueness (e.g., <xref target="RFC8750"/>) or their
			monotonic increase (e.g., <xref target="RFC9347"/>). To
			correctly process the incoming packets on receivers, the packets must
			be authenticated (even when the replay protection is not used). The
			sender and the receiver actions are defined in Sections <xref
			target="RFC4302" sectionFormat="bare" section="3.3.2"/> and <xref
			target="RFC4302" sectionFormat="bare" section="3.4.3"/> of <xref
			target="RFC4302"/> for AH and in Sections <xref target="RFC4303"
			sectionFormat="bare" section="3.3.3"/> and <xref target="RFC4303"
			sectionFormat="bare" section="3.4.3"/> of <xref target="RFC4303"/>
			for ESP.
			</t>
			</li>
			</ul>
			<t> Given the descriptions above and the new definition of Transform Type
			5, the two currently defined Transform IDs
	are renamed to better reflect the properties of sequence numbers they as sume.		are renamed to better reflect the properties of sequence numbers they as sume.
	</t>		</t>
	<ul>
	<li><t> Transform ID 0 is renamed from "No Extended Sequence Numbers
	" to "32-bit Sequential Numbers".</t></li>
	<li><t> Transform ID 1 is renamed from "Extended Sequence Numbers" t
	o "Partially Transmitted 64-bit Sequential Numbers".</t></li>
	</ul>
	<t> Note, that the above descriptions do not change the existing semanti		<ul>
	cs of these transform IDs, they only provide clarification.		<li>
	Note also, that ESP and AH packet processing for these transform IDs is		<t> Transform ID 0 is renamed from "No Extended Sequence Numbers" to
	not affected, and bits on the wire do not change.		"32-bit Sequential Numbers".</t>
	</t>		</li>
			<li>
			<t> Transform ID 1 is renamed from "Extended Sequence Numbers" to
			"Partially Transmitted 64-bit Sequential Numbers".</t>
			</li>
			</ul>
			<t> Note that the above descriptions do not change the existing
			semantics of these Transform IDs, they only provide clarification. Also n
			ote that ESP and AH packet processing for these Transform IDs is not
			affected, and bits on the wire do not change.
			</t>
	</section>		</section>
			<section>
	<section title="Security Considerations">		<name>Security Considerations</name>
	<t> This document does not affect security of the AH, ESP and IKEv2 prot		<t> This document does not affect security of the AH, ESP, and IKEv2 proto
	ocols.		cols.
	</t>		</t>
	</section>		</section>
			<section anchor="IANA">
	<section anchor="IANA" title="IANA Considerations">		<name>IANA Considerations</name>
	<t> This document makes the following changes in the "Internet Key Exchang		<t> This document makes changes to registries within the "Internet Key Exc
	e Version 2 (IKEv2) Parameters" IANA registries		hange Version 2 (IKEv2) Parameters" registry group
	<xref target="IKEV2-IANA" />. It is assumed that RFCXXXX refers to this sp		<xref target="IKEV2-IANA"/>.
	ecification.
	</t>		</t>
	<ul>		<t>The "Transform Type Values" registry has been updated as follows: </t>
	<li><t>The existing transform type 5 "Extended Sequence Numbers (ESN)"		<ul>
	in the "Transform Type Values" registry		<li>
	is renamed to "Sequence Numbers (SN)".		<t>renamed Transform Type 5 from "Extended Sequence Numbers (ESN)"
	</t></li>		to "Sequence Numbers (SN)".
	<li><t>Appended [RFCXXXX] to the Reference column of Transform Type 5
	in the "Transform Type Values" registry.</t></li>
	<li><t>Added this note to the "Transform Type Values" registry:</t>
	<t>"Sequence Numbers (SN)" transform type was originally named "Extend
	ed Sequence Numbers (ESN)" and was referenced by that name
	in a number of RFCs published prior to [RFCXXXX], which gave it the cu
	rrent title.
	</t>		</t>
	</li>		</li>
			<li>
			<t>added as a reference to this RFC for Transform Type 5.</t>
			</li>
			<li>
			<!-- notify IANA regarding the changes to the notes displayed in the registries.
			-->
			<t>added the following note:</t>
			<blockquote><t>The "Sequence Numbers (SN)" Transform Type was origin
			ally named
			"Extended Sequence Numbers (ESN)" and was referenced by that name
			in a number of RFCs published prior to [RFC9827], which gave it
			the current title.</t></blockquote>
			</li>
			</ul>
			<t>The "Transform Type 5 - Extended Sequence Numbers Transform IDs" registry has
			been updated as follows: </t>
	<li><t>The "Transform Type 5 - Extended Sequence Numbers Transform IDs		<ul>
	" registry is renamed to
	"Transform Type 5 - Sequence Numbers Transform IDs".
	</t>
	</li>
	<li><t>The "Reserved" (2-65535) range of numbers in what was the "Tran		<li>
	sform Type 5 -		<t>renamed the registry from "Transform Type 5 - Extended Sequence Num
	Extended Sequence Numbers Transform IDs" registry is split into the		bers Transform IDs" to
	"Unassigned" (2-1023) and the "Reserved for Private Use" (1024-65535)		"Transform Type 5 - Sequence Numbers Transform IDs" and added this doc
	ranges, as shown below.		ument as a reference.
	</t>		</t>
			</li>
			<li><t>split the "Reserved" (2-65535) range of numbers as shown below.</
			t>
	<figure align="center">		<table>
	<artwork align="left"><![CDATA[		<thead>
	Number Name Reference		<tr>
	2-1023 Unassigned		<th>Number</th>
	1024-65535 Reserved for Private Use [RFCXXXX]		<th>Name</th>
	]]></artwork>		<th>Reference</th>
	</figure>		</tr>
			</thead>
			<tbody>
			<tr>
			<td>2-1023</td>
			<td colspan="2">Unassigned</td>
			</tr>
			<tr>
			<td>1024-65535</td>
			<td>Reserved for Private Use</td>
			<td>[RFC9827]</td>
			</tr>
			</tbody>
			</table>
	</li>		</li>
	<li><t>The existing Transform ID 0 "No Extended Sequence Numbers" in w		<li>
	hat was the "Transform Type 5 - Extended Sequence Numbers Transform IDs" registr		<t>renamed Transform ID 0 from "No Extended Sequence Numbers"
	y		to "32-bit Sequential Numbers".
	is renamed to "32-bit Sequential Numbers".
	</t></li>
	<li><t>The existing Transform ID 1 "Extended Sequence Numbers" in what
	was the "Transform Type 5 - Extended Sequence Numbers Transform IDs" registry
	is renamed to "Partially Transmitted 64-bit Sequential Numbers".
	</t></li>
	<li><t>Appended [RFCXXXX] to the Reference column of Transform ID 0 an
	d Transform ID 1 in what was the
	"Transform Type 5 - Extended Sequence Numbers Transform IDs" registry.
	</t></li>
	<li><t>Added these notes to what was the "Transform Type 5 - Extended
	Sequence Numbers Transform IDs" registry:</t>
	<t>This registry was originally named "Transform Type 5 - Extended Seq
	uence Numbers Transform IDs" and
	was referenced using that name in a number of RFCs published prior to
	[RFCXXXX], which gave it the current title.
	</t>
	<t>"32-bit Sequential Numbers" transform ID was originally named "No E
	xtended Sequence Numbers" and was referenced by that name
	in a number of RFCs published prior to [RFCXXXX], which gave it the cu
	rrent title.
	</t>
	<t>"Partially Transmitted 64-bit Sequential Numbers" transform ID was
	originally named "Extended Sequence Numbers" and was referenced by that name
	in a number of RFCs published prior to [RFCXXXX], which gave it the cu
	rrent title.
	</t>		</t>
			</li>
	<t>Numbers in the range 2-65535 were originally marked as "Reserved" a		<li>
	nd were re-classified		<t>renamed Transform ID 1 from "Extended Sequence Numbers"
	as "Unassigned" and "Reserved for Private Use" by [RFCXXXX].		to "Partially Transmitted 64-bit Sequential Numbers".
	</t>		</t>
	</li>		</li>
			<li>
			<t>added a reference to this RFC for Transform ID 0 and Transform ID 1
			.</t>
			</li>
			<li>
			<t>added the the following registry notes:</t>
			<blockquote><t>This registry was originally named "Transform Type 5 -
			Extended
			Sequence Numbers Transform IDs" and was referenced using that name
			in a number of RFCs published prior to [RFC9827], which gave it the
			current title.
			</t></blockquote>
			<blockquote><t>The "32-bit Sequential Numbers" Transform ID was origin
			ally named "No
			Extended Sequence Numbers" and was referenced by that name in a
			number of RFCs published prior to [RFC9827], which gave it the
			current title.
			</t></blockquote>
			<blockquote><t>The "Partially Transmitted 64-bit Sequential Numbers" T
			ransform ID
			was originally named "Extended Sequence Numbers" and was referenced
			by that name in a number of RFCs published prior to [RFC9827], which
			gave it the current title.
			</t></blockquote>
			<blockquote><t>Numbers in the range 2-65535 were originally marked
			as "Reserved" and were reclassified as "Unassigned" and "Reserved
			for Private Use" by [RFC9827].
			</t></blockquote>
			</li>
	</ul>		</ul>
	</section>		</section>
			</middle>
	<section anchor="Acknowledgements" title="Acknowledgements">		<back>
	<t>This document was created as a result of discussions with Russ Housley,		<displayreference target="I-D.ietf-ipsecme-g-ikev2" to="G-IKEv2"/>
	Tero Kivinen, Paul Wouters and Antony Antony		<displayreference target="I-D.ietf-ipsecme-eesp" to="EESP"/>
	about the best way to extend the meaning of the Extended Sequence Numbers		<displayreference target="I-D.pan-ipsecme-anti-replay-notification" to="ANTIREPL
	transform in IKEv2.		AY"/>
	</t>
	</section>
	</middle>		<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
			301.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
			302.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
			303.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			296.xml"/>
			<reference anchor="IKEV2-IANA" target="http://www.iana.org/assignments/i
			kev2-parameters">
			<front>
			<title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
			<author>
			<organization>IANA</organization>
			</author>
			<date/>
			</front>
			</reference>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			750.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			347.xml"/>
			<!-- [I-D.ietf-ipsecme-g-ikev2]
			draft-ietf-ipsecme-g-ikev2-21
			-->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
			ietf-ipsecme-g-ikev2.xml"/>
			<!-- [I-D.klassert-ipsecme-eesp]
			draft-klassert-ipsecme-eesp-02 became ietf-ipsecme-eesp
			-->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
			ietf-ipsecme-eesp.xml"/>
	<back>		<!-- [I-D.pan-ipsecme-anti-replay-notification]
	<references title="Normative References">		draft-pan-ipsecme-anti-replay-notification-01
	<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.43		expired -->
	01.xml"?>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
	<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.43		pan-ipsecme-anti-replay-notification.xml"/>
	02.xml"?>		</references>
	<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.43
	03.xml"?>
	<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.72
	96.xml"?>
	<reference anchor="IKEV2-IANA"
	target="http://www.iana.org/assignments/ikev2-parameters/ikev2-
	parameters.xhtml">
	<front>
	<title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
	<author>
	<organization>IANA</organization>
	</author>
	<date />
	</front>
	</reference>
	</references>		</references>
	<references title="Informative References">		<section anchor="Acknowledgements" numbered="false">
	<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.87		<name>Acknowledgements</name>
	50.xml"?>		<t>This document was created as a result of discussions with <contact
	<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.93		fullname="Russ Housley"/>, <contact fullname="Tero Kivinen"/>, <contact
	47.xml"?>		fullname="Paul Wouters"/>, and <contact fullname="Antony Antony"/> about
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference		the best way to extend the meaning of the Extended Sequence Numbers
	.I-D.ietf-ipsecme-g-ikev2.xml"?>		transform in IKEv2.
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference		</t>
	.I-D.klassert-ipsecme-eesp.xml"?>		</section>
	<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference
	.I-D.pan-ipsecme-anti-replay-notification.xml"?>
	</references>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 49 change blocks.
	355 lines changed or deleted		389 lines changed or added
This html diff was produced by rfcdiff 1.48.