Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 9870 Orange
Category: Standards Track T. Reddy.K
ISSN: 2070-1721 Nokia
October 2025
This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP Options.
この文書では、UDP オプションの新しい IP フロー情報エクスポート (IPFIX) 情報要素を指定します。
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/rfc9870.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9870 で入手できます。
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. Conventions and Definitions
3. UDP Options at a Glance
4. New UDP IPFIX Information Elements
4.1. udpSafeOptions
4.2. udpUnsafeOptions
4.3. udpExID
4.4. udpSafeExIDList
4.5. udpUnsafeExIDList
5. Examples
5.1. Reduced-Size Encoding
5.2. SAFE Experimental Option
5.3. ExIDs and Reduced-Size Encoding
6. Security Considerations
7. IANA Considerations
7.1. IPFIX Information Elements
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
IP Flow Information Export (IPFIX) [RFC7011] is a protocol that is widely deployed in networks for traffic management purposes (Section 2 of [RFC6632]). The protocol specifies the encoding of a set of basic data types and how the various Information Elements (IEs) are transmitted. In order to support the export of new Flow-related measurement data, new IEs can be defined and registered in a dedicated IANA registry [IANA-IPFIX] for interoperability.
IP フロー情報エクスポート (IPFIX) [RFC7011] は、トラフィック管理の目的でネットワークに広く導入されているプロトコルです ([RFC6632] のセクション 2)。このプロトコルは、一連の基本データ型のエンコーディングと、さまざまな情報要素 (IE) の送信方法を指定します。新しいフロー関連の測定データのエクスポートをサポートするために、新しい IE を定義し、相互運用性を確保する専用の IANA レジストリ [IANA-IPFIX] に登録できます。
This document specifies new IPFIX Information Elements for UDP Options (Section 4). A brief overview of UDP Options is provided in Section 3.
この文書では、UDP オプションの新しい IPFIX 情報要素を指定します (セクション 4)。UDP オプションの簡単な概要はセクション 3 で説明されています。
The IE specified in Section 4.1 uses the new abstract data type ("unsigned256") defined in [RFC9740].
セクション 4.1 で規定されている IE は、[RFC9740] で定義されている新しい抽象データ型 ("unsigned256") を使用します。
Transport (including MTU) considerations are discussed in Section 10 of [RFC7011].
トランスポート (MTU を含む) に関する考慮事項は、[RFC7011] のセクション 10 で説明されています。
Examples to illustrate the use of the new IPFIX Information Elements are provided in Section 5.
新しい IPFIX 情報要素の使用例をセクション 5 に示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document uses the IPFIX-specific terminology (e.g., Flow) defined in Section 2 of [RFC7011]. As in the base IPFIX specification [RFC7011], these IPFIX-specific terms have the first letter of a word capitalized.
この文書では、[RFC7011] のセクション 2 で定義されている IPFIX 固有の用語 (例: フロー) を使用します。基本 IPFIX 仕様 [RFC7011] と同様、これらの IPFIX 固有の用語では、単語の最初の文字が大文字になります。
The document adheres to the naming conventions for Information Elements per Section 2.3 of [RFC7012].
この文書は、[RFC7012] のセクション 2.3 に基づく情報要素の命名規則に準拠しています。
Also, this document uses the terms defined in Section 3 of [RFC9868], especially "datagram" and "surplus area".
また、この文書では、[RFC9868] のセクション 3 で定義されている用語、特に「データグラム」と「余剰領域」を使用します。
UDP [RFC0768] does not support an extension mechanism similar to the options supported by other transport protocols, such as TCP [RFC9293], Stream Control Transmission Protocol (SCTP) [RFC9260], or Datagram Congestion Control Protocol (DCCP) [RFC4340]. Such a mechanism can be useful for various applications, e.g., to discover a path MTU or share timestamps. To fill that void, [RFC9868] extends UDP with a mechanism to insert extensions in datagrams. To do so, and unlike the conventional approach that relies upon transport headers, [RFC9868] uses trailers. Concretely, UDP Options are placed in the surplus area (that is, the area of an IP payload that follows a UDP packet). See Figure 1. An example of the use of UDP Options for Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) is described in [RFC9869].
UDP [RFC0768] は、TCP [RFC9293]、ストリーム制御伝送プロトコル (SCTP) [RFC9260]、またはデータグラム輻輳制御プロトコル (DCCP) [RFC4340] などの他のトランスポート プロトコルでサポートされるオプションと同様の拡張メカニズムをサポートしません。このようなメカニズムは、パス MTU の検出やタイムスタンプの共有など、さまざまなアプリケーションに役立ちます。この空白を埋めるために、[RFC9868] はデータグラムに拡張機能を挿入するメカニズムを使用して UDP を拡張します。そうするために、トランスポートヘッダーに依存する従来のアプローチとは異なり、[RFC9868] はトレーラーを使用します。具体的には、ＵＤＰオプションは余剰領域（ＵＤＰパケットに続くＩＰペイロードの領域）に配置される。図 1 を参照してください。データグラム パケット化層パス MTU 検出のための UDP オプション (DPLPMTUD) の使用例は、[RFC9869] で説明されています。
IP transport payload
<------------------------------------------------->
+--------+---------+----------------------+------------------+
| IP Hdr | UDP Hdr | UDP user data | surplus area |
+--------+---------+----------------------+------------------+
<------------------------------>
UDP Length
Figure 1: Surplus Area
図 1: 余剰領域
Sections 4.1 and 4.2 introduce new IEs to export the observed UDP Options.
セクション 4.1 と 4.2 では、観察された UDP オプションをエクスポートするための新しい IE を紹介します。
UDP Options are unambiguously identified by means of a 1-byte field, called "Kind".
UDP オプションは、「Kind」と呼ばれる 1 バイトのフィールドによって明確に識別されます。
Options indicated by Kind values in the range 0-191 are called SAFE Options. Such options can be silently ignored by legacy receivers because they do not alter the UDP user data (Section 11 of [RFC9868]). SAFE Options are exported using the IE defined in Section 4.1.
0 ～ 191 の範囲の Kind 値で示されるオプションは SAFE オプションと呼ばれます。このようなオプションは、UDP ユーザーデータを変更しないため、レガシー受信機では黙って無視できます ([RFC9868] のセクション 11)。SAFE オプションは、セクション 4.1 で定義された IE を使用してエクスポートされます。
Options indicated by Kind values in the range 192-255 are called UNSAFE Options. Such options are not safe for legacy receivers to ignore because they alter the UDP user data (Section 12 of [RFC9868]). UNSAFE Options are exported using the IE defined in Section 4.2.
192 ～ 255 の範囲の Kind 値で示されるオプションは、UNSAFE オプションと呼ばれます。このようなオプションは、UDP ユーザーデータを変更するため、レガシー受信機にとって無視するのは安全ではありません ([RFC9868] のセクション 12)。UNSAFE オプションは、セクション 4.2 で定義された IE を使用してエクスポートされます。
UDP Options occur per-packet within a Flow and can be inserted at any time in the Flow.
UDP オプションはフロー内のパケットごとに発生し、フロー内でいつでも挿入できます。
[RFC9868] reserves two options for experiments: the Experimental (EXP, Kind=127) Option for SAFE Options and the UNSAFE Experimental (UEXP, Kind=254) Option. For both options, Experiment Identifiers (ExIDs) are used to differentiate concurrent use of these options. Known ExIDs are expected to be registered within IANA. Section 4.4 specifies a new IPFIX IE to export observed ExIDs in the EXP Options. Also, Section 4.5 specifies a new IPFIX IE to export observed ExIDs in the UEXP Options. Only 16-bit ExIDs are supported in [RFC9868].
[RFC9868] は実験用に 2 つのオプションを予約しています。SAFE オプションの実験 (EXP、Kind=127) オプションと UNSAFE 実験 (UEXP、Kind=254) オプションです。どちらのオプションでも、実験識別子 (ExID) を使用して、これらのオプションの同時使用を区別します。既知の ExID は IANA 内に登録されることが期待されます。セクション 4.4 では、EXP オプションで監視された ExID をエクスポートするための新しい IPFIX IE を指定しています。また、セクション 4.5 では、UEXP オプションで監視された ExID をエクスポートするための新しい IPFIX IE を指定しています。[RFC9868] では 16 ビット ExID のみがサポートされています。
This document does not intend to elaborate operational guidance/ implications of UDP Options. The document focuses exclusively on exporting observed UDP Options in datagrams.
この文書は、UDP オプションの運用上のガイダンスや影響について詳しく説明することを目的としたものではありません。このドキュメントでは、データグラム内の監視された UDP オプションのエクスポートのみに焦点を当てています。
Given the Kind structure of SAFE and UNSAFE UDP Options, using one single IE that would multiplex both types of options will limit the benefits of reduced-size encoding in the presence of UNSAFE Options. For example, at least 24 octets would be needed to report mandatory SAFE Options that are observed in a Flow. In order to use less bits to report observed UDP Options, distinct IEs are thus defined to report SAFE (Section 4.1) and UNSAFE (Section 4.2) UDP Options. As further detailed in Section 5.1, only one octet is needed to report mandatory SAFE Options.
SAFE および UNSAFE UDP オプションの Kind 構造を考慮すると、両方のタイプのオプションを多重化する 1 つの IE を使用すると、UNSAFE オプションが存在する場合のサイズ縮小エンコードの利点が制限されます。たとえば、フロー内で観察される必須の SAFE オプションを報告するには、少なくとも 24 オクテットが必要になります。観測された UDP オプションをレポートするために使用するビットを少なくするために、SAFE (セクション 4.1) および UNSAFE (セクション 4.2) の UDP オプションをレポートするために別個の IE が定義されます。セクション 5.1 で詳しく説明するように、必須の SAFE オプションを報告するために必要なオクテットは 1 つだけです。
Name:
名前：
udpSafeOptions
udpSafeオプション
ElementID:
要素ID:
525
525
Description:
説明：
Observed SAFE UDP Options in a Flow. The information is encoded in a set of bit fields.
フロー内で観察された SAFE UDP オプション。情報は一連のビットフィールドにエンコードされます。
Options are mapped to bits according to their option numbers. UDP Option Kind 0 corresponds to the least significant bit in the udpSafeOptions IE, while Kind 191 corresponds to the 65th most significant bit of the IE. The bit is set to 1 if the corresponding SAFE UDP Option is observed at least once in the Flow. The bit is set to 0 if the option is never observed in the Flow. The 64 most significant bits MUST be set to 0.
オプションは、オプション番号に従ってビットにマッピングされます。UDP オプション Kind 0 は udpSafeOptions IE の最下位ビットに対応し、Kind 191 は IE の 65 番目の最上位ビットに対応します。対応する SAFE UDP オプションがフロー内で少なくとも 1 回観察されると、このビットは 1 に設定されます。オプションがフロー内で観察されない場合、ビットは 0 に設定されます。最上位 64 ビットは 0 に設定しなければなりません。
The reduced-size encoding per Section 6.2 of [RFC7011] is followed whenever fewer octets are needed to report observed SAFE UDP Options. For example, if only option Kinds <= 31 are observed, then the value of the udpSafeOptions IE can be encoded as unsigned32, or if only option Kinds <= 63 are observed, then the value of the udpSafeOptions IE can be encoded as unsigned64.
観測された SAFE UDP オプションを報告するために必要なオクテットが少ない場合は常に、[RFC7011] のセクション 6.2 に従った縮小サイズのエンコーディングが適用されます。たとえば、オプション Kinds <= 31 のみが観察される場合、udpSafeOptions IE の値は unsigned32 としてエンコードでき、オプション Kinds <= 63 のみが観察される場合、udpSafeOptions IE の値は unsigned64 としてエンコードできます。
The presence of udpSafeExIDList is an indication that the SAFE Experimental Option is observed in a Flow. The presence of udpSafeExIDList takes precedence over setting the corresponding bit in the udpSafeOptions IE for the same Flow. In order to optimize the use of the reduced-size encoding in the presence of udpSafeExIDList IE, the Exporter MUST NOT set the EXP flag of the udpSafeOptions IE that is reported for the same Flow to 1.
udpSafeExIDList の存在は、SAFE 実験的オプションがフロー内で観察されていることを示します。udpSafeExIDList の存在は、同じフローの udpSafeOptions IE の対応するビットの設定よりも優先されます。udpSafeExIDList IE の存在下で縮小サイズのエンコーディングの使用を最適化するために、エクスポーターは、同じフローについて報告される udpSafeOptions IE の EXP フラグを 1 に設定してはなりません。
Abstract Data Type:
抽象データ型:
unsigned256
署名なし256
Data Type Semantics:
データ型のセマンティクス:
flags
フラグ
Additional Information:
追加情報：
See the "UDP Option Kind Numbers" registry at [UDP_OPTIONS].
[UDP_OPTIONS] の「UDP オプションの種類番号」レジストリを参照してください。
See [RFC9868] for more details about UDP Options.
UDP オプションの詳細については、[RFC9868] を参照してください。
Reference:
参照：
RFC 9870
RFC 9870
Name:
名前：
udpUnsafeOptions
udpUnsafeオプション
ElementID:
要素ID:
526
526
Description:
説明：
Observed UNSAFE UDP Options in a Flow. The information is encoded in a set of bit fields.
フロー内で検出された安全でない UDP オプション。情報は一連のビットフィールドにエンコードされます。
Options are mapped to bits according to their option numbers. UDP Option Kind 192 corresponds to the least significant bit in the udpUnsafeOptions IE, while Kind 255 corresponds to the most significant bit of the IE. The bit is set to 1 if the corresponding UNSAFE UDP Option is observed at least once in the Flow. The bit is set to 0 if the option is never observed in the Flow.
オプションは、オプション番号に従ってビットにマッピングされます。UDP オプションの種類 192 は udpUnsafeOptions IE の最下位ビットに対応し、種類 255 は IE の最上位ビットに対応します。対応する UNSAFE UDP オプションがフロー内で少なくとも 1 回検出された場合、このビットは 1 に設定されます。オプションがフロー内で観察されない場合、ビットは 0 に設定されます。
The reduced-size encoding per Section 6.2 of [RFC7011] is followed whenever fewer octets are needed to report observed UNSAFE UDP Options.
観察された UNSAFE UDP オプションを報告するためにより少ないオクテットが必要な場合は常に、[RFC7011] のセクション 6.2 に従った縮小サイズのエンコーディングが適用されます。
The presence of udpUnsafeExIDList is an indication that the UNSAFE Experimental Option is observed in a Flow. The presence of udpUnsafeExIDList takes precedence over setting the corresponding bit in the udpUnsafeOptions IE for the same Flow. In order to optimize the use of the reduced-size encoding in the presence of udpUnsafeExIDList IE, the Exporter MUST NOT set the UEXP flag of the udpUnsafeOptions IE that is reported for the same Flow to 1.
udpUnsafeExIDList の存在は、UNSAFE 実験的オプションがフロー内で観察されていることを示します。udpUnsafeExIDList の存在は、同じフローの udpUnsafeOptions IE 内の対応するビットの設定よりも優先されます。udpUnsafeExIDList IE の存在下で縮小サイズのエンコーディングの使用を最適化するために、エクスポーターは、同じフローについて報告される udpUnsafeOptions IE の UEXP フラグを 1 に設定してはなりません (MUST NOT)。
Abstract Data Type:
抽象データ型:
unsigned64
署名なし64
Data Type Semantics:
データ型のセマンティクス:
flags
フラグ
Additional Information:
追加情報：
See the "UDP Option Kind Numbers" registry at [UDP_OPTIONS].
[UDP_OPTIONS] の「UDP オプションの種類番号」レジストリを参照してください。
See [RFC9868] for more details about UDP Options.
UDP オプションの詳細については、[RFC9868] を参照してください。
Reference:
参照：
RFC 9870
RFC 9870
Name:
名前：
udpExID
udpExID
ElementID:
要素ID:
527
527
Description:
説明：
Observed ExID in an Experimental (EXP, Kind=127) Option or an UNSAFE Experimental (UEXP, Kind=254) Option.
実験的 (EXP、Kind=127) オプションまたは UNSAFE 実験的 (UEXP、Kind=254) オプションで観察された ExID。
A basicList of udpExID is used to report udpSafeExIDList and udpUnsafeExIDList values.
udpExID の BasicList は、udpSafeExIDList および udpUnsafeExIDList の値を報告するために使用されます。
Abstract Data Type:
抽象データ型:
unsigned16
署名なし16
Data Type Semantics:
データ型のセマンティクス:
identifier
識別子
Additional Information:
追加情報：
See the "TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)" registry at [UDP_ExIDs].
[UDP_ExIDs] の「TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)」レジストリを参照してください。
See [RFC9868] for more details about ExIDs.
ExID の詳細については、[RFC9868] を参照してください。
Reference:
参照：
RFC 9870
RFC 9870
Name:
名前：
udpSafeExIDList
udpSafeExIDList
ElementID:
要素ID:
528
528
Description:
説明：
Observed ExIDs in the Experimental (EXP, Kind=127) Option.
実験的 (EXP、Kind=127) オプションで観察された ExID。
A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an EXP Option.
udpExID 情報要素の BasicList。各 udpExID 情報要素は、EXP オプションで観察される ExID を保持します。
Abstract Data Type:
抽象データ型:
basicList
基本リスト
Data Type Semantics:
データ型のセマンティクス:
list
リスト
Additional Information:
追加情報：
See the "TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)" registry at [UDP_ExIDs].
[UDP_ExIDs] の「TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)」レジストリを参照してください。
See [RFC9868] for more details about ExIDs.
ExID の詳細については、[RFC9868] を参照してください。
Reference:
参照：
RFC 9870
RFC 9870
Name:
名前：
udpUnsafeExIDList
udpUnsafeExIDList
ElementID:
要素ID:
529
529
Description:
説明：
Observed ExIDs in the UNSAFE Experimental (UEXP, Kind=254) Option.
UNSAFE Experimental (UEXP、Kind=254) オプションで観察された ExID。
A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an UEXP Option.
udpExID 情報要素の BasicList。各 udpExID 情報要素は、UEXP オプションで観察される ExID を保持します。
Abstract Data Type:
抽象データ型:
basicList
基本リスト
Data Type Semantics:
データ型のセマンティクス:
list
リスト
Additional Information:
追加情報：
See the "TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)" registry at [UDP_ExIDs].
[UDP_ExIDs] の「TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)」レジストリを参照してください。
See [RFC9868] for more details about ExIDs.
ExID の詳細については、[RFC9868] を参照してください。
Reference:
参照：
RFC 9870
RFC 9870
Given the UDP Kind allocation in Section 10 of [RFC9868] and the option mapping defined in Section 4.1 of this document, fewer octets are likely to be used for Flows with mandatory UDP Options.
[RFC9868] のセクション 10 の UDP Kind 割り当てと、この文書のセクション 4.1 で定義されているオプション マッピングを考慮すると、必須の UDP オプションを持つフローに使用されるオクテットは少なくなる可能性があります。
Figure 2 shows an example of the Kind/bit mappings in the udpSafeOptions IE for a Flow in which End of Options List (EOL, Kind=0) and Additional Payload Checksum (APC, Kind=2) Options are observed. Only the bits that corresponds to EOL and APC Options are set to 1.
図 2 は、オプション リストの終わり (EOL、Kind=0) および追加のペイロード チェックサム (APC、Kind=2) オプションが観察されるフローの udpSafeOptions IE の Kind/ビット マッピングの例を示しています。EOL および APC オプションに対応するビットのみが 1 に設定されます。
MSB LSB
1 25
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 ... 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0| |0|0|0|0|0|1|0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+-+
Figure 2: An Example of udpSafeOptions IE with EOL and APC Options
図 2: EOL および APC オプションを使用した udpSafeOptions IE の例
One octet is sufficient to report these observed options because the leading zeros are dropped per the reduced-size encoding guidance. Concretely, the reported udpSafeOptions IE will be set to 0x05 (Figure 3).
サイズ縮小エンコードのガイダンスに従って先頭のゼロが削除されるため、これらの観察されたオプションを報告するには 1 オクテットで十分です。具体的には、報告された udpSafeOptions IE は 0x05 に設定されます (図 3)。
MSB LSB
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0|0|0|0|1|0|1|
+-+-+-+-+-+-+-+-+
Figure 3: An Example of the Wire udpSafeOptions IE Value with EOL and APC Options
図 3: EOL および APC オプションを使用したワイヤ udpSafeOptions IE 値の例
Let us now consider a UDP Flow in which SAFE Experimental Options are observed. If a udpSafeOptions IE is exported for this Flow, then that IE will have the EXP bit set to 1 (Figure 4). This example does not make any assumption about the presence of other UDP Options ("X" can be set to 0 or 1).
次に、SAFE 実験的オプションが観察される UDP フローを考えてみましょう。udpSafeOptions IE がこのフローに対してエクスポートされる場合、その IE の EXP ビットは 1 に設定されます (図 4)。この例では、他の UDP オプションの存在については何も想定していません (「X」は 0 または 1 に設定できます)。
MSB LSB
12 25
0 1 2 3 ... 7 8 9 0 1 2 3 4 5 6 7 8 9 ... 8 9 0 1 2 3 4 5
+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+
|X|X|X|X| |X|X|X|X|X|X|X|X|X|X|X|1|X|X| |X|X|X|X|X|X|X|
+-+-+-+-+...+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+
Figure 4: An Example of udpSafeOptions with EXP Option
図 4: EXP オプションを使用した udpSafeOptions の例
Now assume that EOL, APC, EXP, and UEXP Options are observed in a Flow. Let us also consider that the observed SAFE Experimental Options have ExIDs set to 0x9858 and 0xE2D4 and UNSAFE Experimental Options have ExIDs set to 0xC3D9 and 0x1234. Figure 5 shows an excerpt of the Data Set encoding with a focus on SAFE Experimental Options that have ExIDs. The fields are defined in [RFC6313].
ここで、EOL、APC、EXP、および UEXP オプションがフローで観察されると仮定します。また、観察された SAFE 実験的オプションの ExID は 0x9858 および 0xE2D4 に設定されており、UNSAFE 実験的オプションの ExID は 0xC3D9 および 0x1234 に設定されていることも考えてみましょう。図 5 は、ExID を持つ SAFE Experimental Options に焦点を当てたデータ セット エンコーディングの抜粋を示しています。フィールドは [RFC6313] で定義されています。
MSB LSB
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | List Length = 9 |semantic=allof |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpExID = 527 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAFE ExID = 0x9858 | SAFE ExID = 0xE2D4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | List Length = 9 |semantic=allof |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpExID = 527 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UNSAFE ExID = 0xC3D9 | UNSAFE ExID = 0x1234 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
Figure 5: Example of UDP Experimental Option ExID IEs
図 5: UDP 実験的オプション ExID IE の例
Following the guidance in Section 4.1, the reported udpSafeOptions IE will be set to 0x05 even in the presence of EXP Options.
セクション 4.1 のガイダンスに従って、報告される udpSafeOptions IE は、EXP オプションが存在する場合でも 0x05 に設定されます。
This document does not introduce new security considerations other than those already discussed in Section 11 of [RFC7011] and Section 8 of [RFC7012].
この文書は、[RFC7011] のセクション 11 および [RFC7012] のセクション 8 で既に説明されているもの以外の、新しいセキュリティに関する考慮事項を紹介しません。
The reader may refer to Section 24 of [RFC9868] for the security considerations related to UDP Options.
UDP オプションに関連するセキュリティ上の考慮事項については、[RFC9868] のセクション 24 を参照してください。
IANA has added the following new IEs to the "IPFIX Information Elements" registry under the "IP Flow Information Export (IPFIX) Entities" registry group [IANA-IPFIX]:
IANA は、「IP フロー情報エクスポート (IPFIX) エンティティ」レジストリ グループ [IANA-IPFIX] の下の「IPFIX 情報要素」レジストリに次の新しい IE を追加しました。
+===========+===================+=========================+
| ElementID | Name | Reference |
+===========+===================+=========================+
| 525 | udpSafeOptions | Section 4.1 of RFC 9870 |
+-----------+-------------------+-------------------------+
| 526 | udpUnsafeOptions | Section 4.2 of RFC 9870 |
+-----------+-------------------+-------------------------+
| 527 | udpExID | Section 4.3 of RFC 9870 |
+-----------+-------------------+-------------------------+
| 528 | udpSafeExIDList | Section 4.4 of RFC 9870 |
+-----------+-------------------+-------------------------+
| 529 | udpUnsafeExIDList | Section 4.5 of RFC 9870 |
+-----------+-------------------+-------------------------+
Table 1: New IPFIX Information Elements
表 1: 新しい IPFIX 情報要素
udpSafeOptions uses the abstract data type ("unsigned256") defined in [RFC9740].
udpSafeOptions は、[RFC9740] で定義されている抽象データ型 ("unsigned256") を使用します。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
"Export of Structured Data in IP Flow Information Export
(IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011,
<https://www.rfc-editor.org/info/rfc6313>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012,
DOI 10.17487/RFC7012, September 2013,
<https://www.rfc-editor.org/info/rfc7012>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9740] Boucadair, M. and B. Claise, "New IPFIX Information
Elements for TCP Options and IPv6 Extension Headers",
RFC 9740, DOI 10.17487/RFC9740, March 2025,
<https://www.rfc-editor.org/info/rfc9740>.
[RFC9868] Touch, J. and C. Heard, Ed., "Transport Options for UDP",
RFC 9868, DOI 10.17487/RFC9868, October 2025,
<https://www.rfc-editor.org/info/rfc9868>.
[IANA-IPFIX]
IANA, "IP Flow Information Export (IPFIX) Entities",
<https://www.iana.org/assignments/ipfix>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.
[RFC6632] Ersue, M., Ed. and B. Claise, "An Overview of the IETF
Network Management Standards", RFC 6632,
DOI 10.17487/RFC6632, June 2012,
<https://www.rfc-editor.org/info/rfc6632>.
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[RFC9869] Fairhurst, G. and T. Jones, "Datagram Packetization Layer
Path MTU Discovery (DPLPMTUD) for UDP Options", RFC 9869,
DOI 10.17487/RFC9869, October 2025,
<https://www.rfc-editor.org/info/rfc9869>.
[UDP_ExIDs]
IANA, "TCP/UDP Experimental Option Experiment Identifiers
(TCP/UDP ExIDs)", <https://www.iana.org/assignments/udp>.
[UDP_OPTIONS]
IANA, "UDP Option Kind Numbers",
<https://www.iana.org/assignments/udp>.
Thanks to Benoît Claise for the discussion on the ordering of IPFIX IEs. Thanks to Paul Aitken for the review and comments.
IPFIX IE の順序について議論してくれた Benoit Claise に感謝します。レビューとコメントをくださった Paul Aitken に感謝します。
Thanks to Tommy Pauly for the TSVART review, Joe Touch for the INTDIR review, Robert Sparks for the GENART review, Watson Ladd for the SECDIR review, and Jouni Korhonen for the OPSDIR review.
TSVART レビューの Tommy Pauly、INTDIR レビューの Joe Touch、GENART レビューの Robert Sparks、SECDIR レビューの Watson Ladd、OPSDIR レビューの Jouni Korhonen に感謝します。
Thanks to Thomas Graf for the shepherd review.
羊飼いのレビューを書いてくれた Thomas Graf に感謝します。
Thanks to Mahesh Jethanandani for the AD review.
AD レビューを投稿してくださった Mahesh Jethanandani に感謝します。
Thanks to Éric Vyncke, Roman Danyliw, and Zahed Sarker for the IESG review.
IESG のレビューに協力してくれた Éric Vyncke、Roman Danyliw、Zahed Sarker に感謝します。
Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy.K
Nokia
India
Email: kondtir@gmail.com