Internet Engineering Task Force (IETF) V. Smyslov
Request for Comments: 9827 ELVIS-PLUS
Updates: 7296 November 2025
Category: Standards Track
ISSN: 2070-1721
This document clarifies and extends the meaning of Transform Type 5 in Internet Key Exchange Protocol Version 2 (IKEv2). It updates RFC 7296 by renaming Transform Type 5 from "Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)". It also renames two currently defined values for this Transform Type: 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 Numbers".
この文書は、インターネット キー交換プロトコル バージョン 2 (IKEv2) の変換タイプ 5 の意味を明確にし、拡張します。変換タイプ 5 の名前を「拡張シーケンス番号 (ESN)」から「シーケンス番号 (SN)」に変更することで、RFC 7296 を更新します。また、この変換タイプに現在定義されている 2 つの値の名前も変更されます。値 0 は「拡張シーケンス番号なし」から「32 ビット連続番号」に、値 1 は「拡張シーケンス番号」から「部分的に送信される 64 ビット連続番号」に変更されます。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9827.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9827 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Problem Description
3. Extending the Semantics of Transform Type 5
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Author's Address
The IP Security (IPsec) Architecture [RFC4301] defines a set of security services provided by the Authentication Header (AH) [RFC4302] and Encapsulating Security Payload (ESP) [RFC4303]. 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. The replay protection in AH and ESP is achieved by means of a monotonically increasing counter that never wraps around and is sent in each AH or ESP packet in the Sequence Number field. The receiver maintains a sliding window that allows duplicate packets to be detected.
IP セキュリティ (IPsec) アーキテクチャ [RFC4301] は、認証ヘッダー (AH) [RFC4302] およびカプセル化セキュリティ ペイロード (ESP) [RFC4303] によって提供される一連のセキュリティ サービスを定義します。これらのサービスの 1 つはリプレイ保護であり、これらのドキュメントでは「アンチリプレイ」と呼ばれます。IPsec では、アンチリプレイ サービスはオプションです。AH および/または ESP パケットの各受信者は、セキュリティ アソシエーション (SA) ごとにそれを有効にするかどうかを選択できます。AH および ESP のリプレイ保護は、決してラップアラウンドせず、シーケンス番号フィールド内の各 AH または ESP パケットで送信される単調増加カウンタによって実現されます。受信側は、重複パケットの検出を可能にするスライディング ウィンドウを維持します。
Both AH and ESP allow use of either a 32-bit counter or a 64-bit counter. The latter case is referred to as Extended Sequence Numbers (ESN) in AH and ESP specifications. 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 and are determined by the receiver based on previously received packets.
AH と ESP は両方とも、32 ビット カウンタまたは 64 ビット カウンタの使用を許可します。後者の場合は、AH および ESP 仕様では拡張シーケンス番号 (ESN) と呼ばれます。AH ヘッダーと ESP ヘッダーのシーケンス番号フィールドのサイズはわずか 32 ビットであるため、ESN の場合、カウンターの上位 32 ビットは送信されず、以前に受信したパケットに基づいて受信機によって決定されます。
The receiver decides whether to enable the anti-replay service based only on the receiver's local policy, so the sender, in accordance with the specifications for AH ([RFC4302], Section 3.3.2) and ESP ([RFC4303], Section 3.3.3), should always assume that the replay protection is enabled on the receiving side. Thus, the sender should always send the increasing counter values and should take care that the counter never wraps around. AH and ESP specifications also discuss situations in which replay protection is not possible to achieve, even if senders do all as prescribed -- like in multicast Security Associations with multiple unsynchronized senders. Both AH and ESP specifications allow the sender to avoid maintaining the counter if the sender has been notified that the anti-replay service is disabled by the receiver or is not possible to achieve.
受信者は、受信者のローカル ポリシーのみに基づいてリプレイ防止サービスを有効にするかどうかを決定するため、送信者は、AH ([RFC4302]、セクション 3.3.2) および ESP ([RFC4303]、セクション 3.3.3) の仕様に従って、常に受信側でリプレイ保護が有効になっていると想定する必要があります。したがって、送信者は常に増加するカウンタ値を送信し、カウンタが決してラップアラウンドしないように注意する必要があります。AH および ESP の仕様では、複数の非同期送信者によるマルチキャスト セキュリティ アソシエーションなど、送信者がすべて規定どおりに実行したとしても、リプレイ保護を達成できない状況についても説明しています。AH と ESP の両方の仕様により、送信者は、アンチリプレイ サービスが受信者によって無効にされているか、達成できないことが通知された場合に、カウンターの維持を回避できます。
AH and ESP Security Associations are usually established using IKEv2 [RFC7296]. The process of SA establishment includes calculation of a shared key and negotiation of various SA parameters, such as cryptographic algorithms. This negotiation in IKEv2 is performed via transforms (see Section 3.3.2 of [RFC7296]). The type of transform determines what parameter is being negotiated. Each Transform Type has an associated list of possible values (called Transform IDs) that determine the possible options for negotiation. See [IKEV2-IANA] for the list of Transform Types and associated Transform IDs.
AH および ESP セキュリティ アソシエーションは通常、IKEv2 [RFC7296] を使用して確立されます。SA 確立のプロセスには、共有キーの計算と、暗号アルゴリズムなどのさまざまな SA パラメータのネゴシエーションが含まれます。IKEv2 におけるこのネゴシエーションは、変換を通じて実行されます ([RFC7296] のセクション 3.3.2 を参照)。変換のタイプによって、どのパラメータがネゴシエートされるかが決まります。各変換タイプには、ネゴシエーションに使用できるオプションを決定する、使用可能な値のリスト (変換 ID と呼ばれる) が関連付けられています。変換タイプと関連する変換 ID のリストについては、[IKEV2-IANA] を参照してください。
Transform Type 5 ("Extended Sequence Numbers (ESN)") is used in IKEv2 to negotiate the way sequence numbers for replay protection are generated, transmitted, and processed in the context of an SA. There are two values are defined for this Transform Type -- "No Extended Sequence Numbers" and "Extended Sequence Numbers".
変換タイプ 5 (「拡張シーケンス番号 (ESN)」) は、SA のコンテキストでリプレイ保護のシーケンス番号が生成、送信、および処理される方法をネゴシエートするために IKEv2 で使用されます。この変換タイプには、「拡張シーケンス番号なし」と「拡張シーケンス番号」という 2 つの値が定義されています。
This document updates the IKEv2 specification [RFC7296] by renaming Transform Type 5 and the two associated Transform IDs.
この文書は、変換タイプ 5 および関連する 2 つの変換 ID の名前を変更することにより、IKEv2 仕様 [RFC7296] を更新します。
IKEv2 currently has no means to negotiate the case when both peers agree that replay protection is not needed. Even when both peers locally disable anti-replay service as receivers, they still need to maintain increasing sequence numbers as senders, taking care that they never wrap around (see [ANTIREPLAY]).
現在、IKEv2 には、両方のピアがリプレイ保護が必要ないことに同意した場合にネゴシエートする手段がありません。両方のピアが受信者としてローカルでアンチリプレイ サービスを無効にしても、送信者として増加するシーケンス番号を維持し、ラップアラウンドしないように注意する必要があります ([ANTIREPLAY] を参照)。
There is also no way to inform receivers that replay protection is not possible for a particular SA (for example in case of a multicast SA with several unsynchronized senders).
また、特定の SA ではリプレイ保護が不可能であることを受信者に通知する方法もありません (たとえば、複数の非同期送信者を持つマルチキャスト SA の場合)。
Future IPsec protocols may provide more options for the handling of anti-replay counters, like sending full 64-bit sequence numbers or completely omitting them in packets (see [EESP]). These options will require means to be negotiated in IKEv2.
将来の IPsec プロトコルでは、完全な 64 ビット シーケンス番号を送信したり、パケット内でシーケンス番号を完全に省略したりするなど、アンチリプレイ カウンタの処理に関するオプションがさらに提供される可能性があります ([EESP] を参照)。これらのオプションには、IKEv2 でネゴシエートする手段が必要です。
Transform Type 5 is the best candidate for addressing these issues: it is already used for negotiation of how sequence numbers are handled in AH and ESP, and it is possible to define additional Transform IDs that could be used in the corresponding situations. However, the current definition of Transform Type 5 is too narrow -- its name implies that this transform can only be used for negotiation of using ESN.
変換タイプ 5 は、これらの問題に対処するための最良の候補です。変換タイプ 5 は、AH および ESP でのシーケンス番号の処理方法のネゴシエーションにすでに使用されており、対応する状況で使用できる追加の変換 ID を定義することが可能です。ただし、変換タイプ 5 の現在の定義は狭すぎます。その名前は、この変換が ESN を使用するネゴシエーションにのみ使用できることを暗示しています。
This document extends the semantics of Transform Type 5 in IKEv2 to be defined as follows:
このドキュメントでは、IKEv2 の変換タイプ 5 のセマンティクスを拡張して、次のように定義します。
Transform Type 5 defines the set of properties of sequence numbers of IPsec packets of a given SA when these packets enter the network.
変換タイプ 5 は、特定の SA の IPsec パケットがネットワークに入るときのシーケンス番号のプロパティのセットを定義します。
This updated definition is clarified as follows:
この更新された定義は次のように明確になります。
* "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 into account.
* この定義における「シーケンス番号」は、必ずしも IPsec パケットのシーケンス番号フィールドの内容ではありません。それらは、回線上で送信されない情報を考慮して構築できる論理エンティティ (カウンタなど) である場合もあります。
* The properties are interpreted as characteristics of IPsec SA packets rather than the results of sender actions. For example, in multicast SA with multiple unsynchronized senders, even if each sender ensures the uniqueness of sequence numbers it generates, the uniqueness of sequence numbers for all IPsec packets is not guaranteed.
* プロパティは、送信者のアクションの結果ではなく、IPsec SA パケットの特性として解釈されます。たとえば、複数の非同期送信者が存在するマルチキャスト SA では、各送信者が生成するシーケンス番号の一意性が保証されていても、すべての IPsec パケットのシーケンス番号の一意性は保証されません。
* 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 properties (e.g., packet duplication would break sequence number uniqueness).
* プロパティは、受信者が取得するパケットではなく、ネットワークに入るパケットに対して定義されます。これは、ネットワークの動作によってこれらのプロパティの一部が壊れる可能性があるためです (たとえば、パケットの重複によりシーケンス番号の一意性が壊れる可能性があります)。
* The properties of sequence numbers are interpreted in a broad sense, which includes the case when sequence numbers are absent.
* シーケンス番号のプロパティは、シーケンス番号が存在しない場合も含めて広い意味で解釈されます。
Given this updated definition, Transform Type 5 in the "Transform Type Values" registry [IKEV2-IANA] has been renamed from "Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)" in the sense that it defines the properties of the sequence numbers in general.
この更新された定義を考慮して、「変換タイプ値」レジストリ [IKEV2-IANA] の変換タイプ 5 は、一般的なシーケンス番号のプロパティを定義するという意味で、「拡張シーケンス番号 (ESN)」から「シーケンス番号 (SN)」に名前変更されました。
It is expected that new Transform IDs will be defined for this Transform Type in the future (like in G-IKEv2 [RFC9838] for the case of multicast SAs). Documents defining new Transform IDs should include descriptions of the properties the sequence numbers would have if the new Transform ID was selected. In particular, the descriptions should include discussion of whether these properties allow replay protection to be achieved.
将来、この変換タイプに対して新しい変換 ID が定義されることが予想されます (マルチキャスト SA の場合の G-IKEv2 [RFC9838] のように)。新しい変換 ID を定義するドキュメントには、新しい変換 ID が選択された場合にシーケンス番号が持つプロパティの説明を含める必要があります。特に、説明には、これらのプロパティによってリプレイ保護が実現できるかどうかについての議論が含まれる必要があります。
Some existing protocols (like Implicit IV in ESP [RFC8750] or Aggregation and Fragmentation for ESP [RFC9347]) rely on properties that are guaranteed for the currently defined Transform IDs; however, this might not be true for future Transform IDs. When a new Transform ID is defined, its description should include discussion about the possibility of using the Transform ID in protocols that rely on some particular properties of sequence numbers.
一部の既存のプロトコル (ESP [RFC8750] の Implicit IV や ESP の集約と断片化 [RFC9347] など) は、現在定義されている変換 ID に対して保証されているプロパティに依存しています。ただし、これは将来の変換 ID には当てはまらない可能性があります。新しい変換 ID が定義される場合、その説明には、シーケンス番号の特定のプロパティに依存するプロトコルでの変換 ID の使用の可能性に関する議論が含まれる必要があります。
The two currently defined Transform IDs for Transform Type 5 define the following properties of sequence numbers.
変換タイプ 5 に対して現在定義されている 2 つの変換 ID は、シーケンス番号の次のプロパティを定義します。
* 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., [RFC8750]) or monotonically increasing sequence numbers (e.g., [RFC9347]). The sender and the receiver actions are defined in Sections 3.3.2 and 3.4.3 of [RFC4302] for AH and in Sections 3.3.3 and 3.4.3 of [RFC4303] for ESP.
* 値 0 は、AH および ESP パケットのシーケンス番号フィールドで送信される単調増加 32 ビット カウンタとしてシーケンス番号を定義します。これらはラップアラウンドすることがなく、一意であることが保証されているため、リプレイ保護に適しています。また、シーケンス番号の一意性 ([RFC8750] など) や単調増加するシーケンス番号 ([RFC9347] など) に依存するプロトコルでも使用できます。送信者と受信者のアクションは、AH については [RFC4302] のセクション 3.3.2 および 3.4.3 で、ESP については [RFC4303] のセクション 3.3.3 および 3.4.3 で定義されています。
* 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., [RFC8750]) or their monotonic increase (e.g., [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 3.3.2 and 3.4.3 of [RFC4302] for AH and in Sections 3.3.3 and 3.4.3 of [RFC4303] for ESP.
* 値 1 は、シーケンス番号を単調増加する 64 ビット カウンタとして定義します。下位 32 ビットは AH および ESP パケットのシーケンス番号フィールドで送信され、上位 32 ビットは以前に受信したパケットに基づいて受信機で暗黙的に決定されます。シーケンス番号は折り返されることがなく、一意であることが保証されているため、リプレイ保護に適しています。これらは、シーケンス番号の一意性 ([RFC8750] など) またはその単調増加 ([RFC9347] など) に依存するプロトコルでも使用できます。受信側で受信パケットを正しく処理するには、(リプレイ保護が使用されていない場合でも) パケットを認証する必要があります。送信者と受信者のアクションは、AH については [RFC4302] のセクション 3.3.2 および 3.4.3 で、ESP については [RFC4303] のセクション 3.3.3 および 3.4.3 で定義されています。
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 assume.
上記の説明と変換タイプ 5 の新しい定義を考慮して、現在定義されている 2 つの変換 ID は、それらが想定するシーケンス番号のプロパティをより適切に反映するように名前が変更されます。
* Transform ID 0 is renamed from "No Extended Sequence Numbers" to "32-bit Sequential Numbers".
* 変換 ID 0 の名前が「拡張シーケンス番号なし」から「32 ビット シーケンス番号」に変更されました。
* Transform ID 1 is renamed from "Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Numbers".
* 変換 ID 1 の名前が「拡張シーケンス番号」から「部分的に送信された 64 ビット シーケンス番号」に変更されました。
Note that the above descriptions do not change the existing semantics of these Transform IDs, they only provide clarification. Also note that ESP and AH packet processing for these Transform IDs is not affected, and bits on the wire do not change.
上記の説明は、これらの変換 ID の既存のセマンティクスを変更するものではなく、説明を提供するだけであることに注意してください。また、これらの変換 ID の ESP および AH パケット処理は影響を受けず、回線上のビットも変更されないことに注意してください。
This document does not affect security of the AH, ESP, and IKEv2 protocols.
この文書は、AH、ESP、および IKEv2 プロトコルのセキュリティには影響しません。
This document makes changes to registries within the "Internet Key Exchange Version 2 (IKEv2) Parameters" registry group [IKEV2-IANA].
この文書は、「インターネット キー交換バージョン 2 (IKEv2) パラメーター」レジストリ グループ [IKEV2-IANA] 内のレジストリに変更を加えます。
The "Transform Type Values" registry has been updated as follows:
「Transform Type Values」レジストリが次のように更新されました。
* renamed Transform Type 5 from "Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)".
* 変換タイプ 5 の名前が「拡張シーケンス番号 (ESN)」から「シーケンス番号 (SN)」に変更されました。
* added as a reference to this RFC for Transform Type 5.
* Transform Type 5 のこの RFC への参照として追加されました。
* added the following note:
* 次の注記を追加しました。
* The "Sequence Numbers (SN)" Transform Type was originally 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.
* 「シーケンス番号 (SN)」変換タイプはもともと「拡張シーケンス番号 (ESN)」という名前で、[RFC9827] より前に公開された多くの RFC でその名前で参照されていたため、現在のタイトルになりました。
The "Transform Type 5 - Extended Sequence Numbers Transform IDs" registry has been updated as follows:
「変換タイプ 5 - 拡張シーケンス番号変換 ID」レジストリが次のように更新されました。
* renamed the registry from "Transform Type 5 - Extended Sequence Numbers Transform IDs" to "Transform Type 5 - Sequence Numbers Transform IDs" and added this document as a reference.
* レジストリの名前を「Transform Type 5 - Extended Sequence Numbers Transform IDs」から「Transform Type 5 - Sequence Numbers Transform IDs」に変更し、このドキュメントを参照として追加しました。
* split the "Reserved" (2-65535) range of numbers as shown below.
* 以下に示すように、「予約済み」(2-65535) 範囲の番号を分割します。
+============+==========================+===========+
| Number | Name | Reference |
+============+==========================+===========+
| 2-1023 | Unassigned |
+------------+--------------------------+-----------+
| 1024-65535 | Reserved for Private Use | [RFC9827] |
+------------+--------------------------+-----------+
Table 1
* renamed Transform ID 0 from "No Extended Sequence Numbers" to "32-bit Sequential Numbers".
* 変換 ID 0 の名前が「拡張シーケンス番号なし」から「32 ビット シーケンス番号」に変更されました。
* renamed Transform ID 1 from "Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Numbers".
* 変換 ID 1 の名前が「拡張シーケンス番号」から「部分的に送信された 64 ビット連続番号」に変更されました。
* added a reference to this RFC for Transform ID 0 and Transform ID 1.
* 変換 ID 0 と変換 ID 1 に関するこの RFC への参照を追加しました。
* added the following registry notes:
* 次のレジストリ ノートを追加しました。
* 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.
* このレジストリは元々「Transform Type 5 - Extended Sequence Numbers Transform IDs」という名前で、[RFC9827] より前に公開された多くの RFC でその名前を使用して参照されていたため、現在のタイトルになりました。
* The "32-bit Sequential Numbers" Transform ID was originally 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.
* "32 ビット シーケンス番号" 変換 ID は元々 "No Extended Sequence Numbers" という名前で、[RFC9827] より前に公開された多くの RFC でその名前で参照されていたため、現在のタイトルになりました。
* The "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 [RFC9827], which gave it the current title.
* 「部分的に送信される 64 ビット シーケンス番号」変換 ID は、もともと「拡張シーケンス番号」という名前であり、[RFC9827] より前に公開された多くの RFC でその名前で参照されていたため、現在のタイトルが付けられました。
* Numbers in the range 2-65535 were originally marked as "Reserved" and were reclassified as "Unassigned" and "Reserved for Private Use" by [RFC9827].
* 2 ～ 65535 の範囲の番号は当初「予約済み」としてマークされていましたが、[RFC9827] によって「未割り当て」および「私用のために予約済み」として再分類されました。
[IKEV2-IANA]
IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters",
<http://www.iana.org/assignments/ikev2-parameters>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[ANTIREPLAY]
Pan, W., He, Q., and P. Wouters, "IKEv2 Support for Anti-
Replay Status Notification", Work in Progress, Internet-
Draft, draft-pan-ipsecme-anti-replay-notification-01, 21
October 2024, <https://datatracker.ietf.org/doc/html/
draft-pan-ipsecme-anti-replay-notification-01>.
[EESP] Klassert, S., Antony, A., and C. Hopps, "Enhanced
Encapsulating Security Payload (EESP)", Work in Progress,
Internet-Draft, draft-ietf-ipsecme-eesp-02, 19 October
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
ipsecme-eesp-02>.
[RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit
Initialization Vector (IV) for Counter-Based Ciphers in
Encapsulating Security Payload (ESP)", RFC 8750,
DOI 10.17487/RFC8750, March 2020,
<https://www.rfc-editor.org/info/rfc8750>.
[RFC9347] Hopps, C., "Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for IP
Traffic Flow Security (IP-TFS)", RFC 9347,
DOI 10.17487/RFC9347, January 2023,
<https://www.rfc-editor.org/info/rfc9347>.
[RFC9838] Smyslov, V. and B. Weis, "Group Key Management Using the
Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 9838, DOI 10.17487/RFC9838, November 2025,
<https://www.rfc-editor.org/info/rfc9838>.
This document was created as a result of discussions with Russ Housley, Tero Kivinen, Paul Wouters, and Antony Antony about the best way to extend the meaning of the Extended Sequence Numbers transform in IKEv2.
このドキュメントは、IKEv2 の拡張シーケンス番号変換の意味を拡張する最良の方法について、Russ Housley、Tero Kivinen、Paul Wouters、Antony Antony との議論の結果として作成されました。
Valery Smyslov
ELVIS-PLUS
Russian Federation
Email: svan@elvis.ru